Microsoft.NET Architecture and the C# Language A semester course for 4 th year students Comments to the presentations Prof. Vladimir O. Safonov, St. Petersburg University Email: v_o_safonov@mail.ru WWW: http://user.rol.ru/~vsafonov Lecture 11. Slide 2. Let’s consider in more detail Web service method call via HTTP-GET and HTTP-POST. An example is given on the slide. A standard HTTP-GET request to call a method of a Web service contains an URL request with a reference to the Web service’s .asmx file, method name, method argument names and the values of its actual arguments. Only .NET primitive types can be used as the types of the arguments of a Web service method. The result of the Web method is an XML document to be displayed in the client’s browser or other application. The result of the Web method can be of any .NET data type. As for an HTTP-POST request, it is similar to GET but the arguments are in the body of a Web form. Slide 3. Another way to call a Web method is using SOAP – Simple Object Access Protocol. SOAP was introduced as a standard in 1999. It provides an XML grammar for Web method, its arguments and result. SOAP supports all .NET value types, and also classes and data sets. For classes and structures SOAP supports marshaling, that is actually serialization of these data types in XML format. Slide 4. To consume a Web service, it is at first necessary to get its description. To do that, one should submit a request with the Web service URL but without any method name or parameters. As the result, an HTML description of the Web service will be returned. It contains the set of permissions, methods and protocols of the Web service. The other way of Web service description is that in WSDL format, actually as an XMl file. Web service can return WSDL if requested with the “?WSDL” parameter. The result in this case will be a formal WSDL description (or specification) of the Web service. The WSDL description is based on XML-based grammar and can be used as entry to WebServiceUtil.exe – a .NET Framework utility that generates proxy classes for using the SOAP protocol to communicate to the Web service. Slide 5. WSDL syntax is described by an XML grammar to define: - Services and ports communicating by messages; - Binding: specification of the protocol and the data format for message or port ; extensions of SOAP 1.1, HTTP GET/POST, MIME; - Publicly available description of the Web service and its contents – the so-called WSDL contract . Key elements of WSDL are service, port, port type, o perations and messages. An example will be given on one of the next slides. Slide 6. This picture illustrates an abstract view of WSDL elements. Each WSDL element specifies a Web service that can have several named ports. Each Web service can communicate to another Web service by one or more ports. Communication is performed by messages whose format is also specified by WSDL. Slide 7. Here is an example of a WSDL description of a Web service. The description starts with the definitions tag. What is defined is: - the type of the communication port to contact the Web service; - the binding, i.e. the SOAP action to be performed to contact to the Web service; - the name of the Web service, with the port and the binding also indicated. Slide 8. The Part 5 of our lecture devoted to .NET Web servers – Advanced Web servers – has the following plan: - State control - Security - Transactions - Execution model - Distributed Web applications. Slide 9. .NET Web services support state control. At first, please note that .NET Web services are stateless. So, to track down the state of communication to the .NET Web server, the state of an ASP.NET session can be used. A session, as defined by Microsoft, is memory in the shape of a dictionary or hash table (for example, key-value pairs) that can be set and read for the duration of a user’s session. A session is limited by logical limits of the application. It is the context for the user to communicate with the Web service. The functionality of a session is as follows: - Request identification and classification; - Storing data during the intervals between the requests; - Handling events in the course of the session; - Release the session data. .NET State Server is a tool to support storing data related to an ASP.NET session in memory. Slide 10. Security model for Web services is intended: - To prevent access to parts of the Web server - To record and store the user’s proprietary data. Security configuration for Web services is based on authentication, authorization and impersonation of users. Code Access Security is applied for Web services. In particular, stack walk to check permissions is performed when a Web method is called. .NET security is considered in a special lecture. Slide 11. .NET Web services support transactions. They look like ASP.NET Web Forms. There are two kinds of transactions – manual and automated. Manual transactions are those against a single database. These can be, for example, SQL server transactions. Automatic transactions are COM+ transactions. They can be configured by deriving the class from the ServicedComponent class located within the System.EnterpriseServices namespace. Principles of .NET automatic transactions can be specified by a simple formula: Atomic, consistent, isolated, durable (ACID). Slide 12. TransactionOption is a property of the WebMethod attribute used for switching between the transaction models for a given Web service. The transaction models are as follows: - Disabled - indicates that the XML Web service method does not run within the scope of a transaction. When a request is processed, the XML Web service method is executed without a transaction; - Supported - indicates that the XML Web service method can be run within the scope of transactions. When a request is processed, the XML Web service can be created with a transaction; - NotSupported – opposed to Supported; - Required - indicates that the XML Web service method requires a transaction. Since XML Web service methods can only participate as the root object in a transaction, a new transaction will be created for the XML Web service method; - RequiresNew - indicates that the XML Web service method requires a new transaction. When a request is processed, the XML Web service is created within a new transaction. Slide 13. Execution model of a Web service can be synchronous and asynchronous. Synchronous model works as any other class method call. Asynchronous model is more complicated. It is supported by design pattern for .NET Framework This model prescribes to split the method into two code blocks – BeginMethodName and EndMethodName that should be invoked by the client. Slide 14. To consume a Web service via UI, a programmer can fully separate logic of allocation and call. There can be multiple files to access a Web form, with extensions like: .aspx and, for example, .aspx.cs. The latter is a code file written in C# for accessing the Web form. In general, .NET Framework and Visual Studio.NET provide specific files for designers and programmers, easy to maintain a Web application. Slides 15-16. Here is a simple example of consuming the Web service that adds two integer numbers. The .aspx file provides the code to react to the event of clicking the related Web form . The .asmx file is the code that implements the Add method, as seen below. The WSDL file to specify the Web service is generated by ASP.NET. The C# proxy class is generated by the WSDL utility. Slide 17. To summarize what we’ve considered in this section: - Overview of .NET architecture - Web services and ASP.NET - Creating and publishing Web services - Calling and consuming Web services - WSDL and proxy classes - Programming using Web services . Slide 18. The second part of this lecture is devoted to .NET Remoting and Web Services, and our recommendations which of these techniques to use in which cases. Slide 19. Among the models of distributed applications, there are two which are the post widespread now – Intranet model and Internet model. Intranet model to be used at a single company or enterprise can be based on .NET Remoting. .NET Remoting provides a variety of protocols and object manipulation models well suitable for homogeneous network. In a word, it uses .NET to .NET interaction model, hosted by CLR. .NET Remoting is an API for communication between application domains, or AppDomains – logical utits of typing, resource allocation and business logic that will be considered later in this section in more detail. Internet model is to be used for interaction between companies located geographically remote from each other. It can be based on using and consuming .NET Web services considered before. Web services are loosely coupled and provide the “HTTP to HTTP” scheme of interaction between each other and between services and clients. .NET clients can be heterogenuous. In Java or other distributed software development platforms, there is nothing similar to the concepts of remoting and application domains. Slide 20. .NET Remoting is a set of services to enable interaction between applications. Applications can be located on the same computer, on several computers on the same LAN, or all over the world in heterogeneous WANs. .NET Remoting enables interaction between the objects from different AppDomains. It provides a variety of transport protocols, serialization formats, schemes of objects’ lifetime, and models for creating objects. Slide 21. The concept of a CLR host is one of the most important in relation to .NET Remoting. CLR host can be informally thought of as just “a separate call of CLR”. Within an operating system process, there can be several CLR hosts. CLR provides common execution environment for a code, providing such services as security, garbage collection, multi-language interoperability. .NET executable requires a small piece of code to start the CLR. Its scheme is shown on the slide. In order to be able to execute a managed code, a CLR host should get a reference to AppDomain. Usually this is the default AppDomain that exists inside the process (DefaultDomain). In the same process and CLR host, other AppDomains can be created. Slide 22. Each managed code is to be executed in some AppDomain. AppDomains are separate logical units that CLR recognizes within the framework of a single process. They could be referred to as “logical processes”. AppDomains are separated from each other. Their boundaries are similar to boundaries between processes but more lightweight – they exist in a single virtual memory space provided by the OS process that runs the CLR host. Please note the hierarchy of concepts and logical units of resource allocation characteristic of .NET: OS process / CLR host(s) / AppDomain(s). Slide 23. One of the key concepts supported by AppDomains is isolation. Each managed code before executing should be verified. The code that passed verification is considered to be type safe. Making sure the code to be executed is type safe enables CLR to isolate the code into a separate computational unit less expensive than a process. CLR enables isolation due to the fact that working directly with objects from other AppDomain is not allowed. Working with them is provided by .NET Remoting. So, .NET Remoting is a set of system services for working with objects located in different AppDomains. Slide 24. The scheme on the slide illustrates the principles of interaction between .NET applications or within a .NET application between several AppDomains. All of these kinds of interaction are supported by .NET Remoting. Each .NET executable has a stub that starts a CLR host and the default AppDomain. Later, each of the .NET executables started either on the same machine or different machines can communicate via .NET Remoting. Similar to that, if a .NET application creates new application domains, it communicates to them via the same .NET Remoting API. Slide 25. For communicating between objects that exist in different virtual address spaces and on different machines, it is not enough just to pass a pointer to an object – it would not make any sense for the other AppDomain. To enable the same way of “understanding” objects by different AppDomains, a mechanism of marshaling is provided in .NET. Marshaling is transformation of information on any object into a standard form. Marshaling can be of two kinds – marshaling by reference and marshaling by value. With marshaling by value scheme, an object is created by a client and initialized by the data taken from the server. The state of the object is downloaded. So, in this case actually the full state of the object is copied in some way. With marshaling by reference scheme, the object lives on the server and all the calls to its methods are performed remotely. The input parameters and the result returned are traveling across the network. Accordingly, the implementation of .NET Remoting provides a proxy class on the client that is used for actual remote communication with the object and its methods. Surely marshal by reference is more efficient and should be used when the amounts of data to be passed are large. Slide 26. As shown on the scheme, .NET Remoting MarshalByRef supports proxies and stubs for actual call of the remote method, passing arguments and returning the results. Besides, it provides for a channel for passing information between the client and the server, based either on TCP or on HTTP. Slide 27. When using marshal by reference, remote components should be declared as subclasses of MarshalByRef. Public methods work with serialized objects. Application host for remote objects can be IIS, NT service, or user application. It requires activation by hand. For remote components to be accessible by clients, they should be published by the server. Slide 28. On the client application side, to achieve a remote component, a reference to the component on the server required. To operate with the type of the remote component, the programmer should mark its remote type as "well-known", and let CLR know that the object lives remotely. JIT compiler at runtime automatically adds the code replacing local calls to remote calls. All that actions are performed transparently for the user. Slide 29. Now let’s compare .NET Remoting functionality to Web services. A Web service in .NET is accessible via a publicly available URL. The client code sends a request to the Web server using SOAP envelopes, usually over HTTP. In .NET, a Web service is a special kind of an ASP.NET application. IIS and ASP.NET process the request to the Web service, as if it were a request to a Web page . Web services are referred to by URLs with the .asmx extension. Special .NET features related to Web servers are testing infrastructure and client side infrastructure for data deserialization. Slide 30. To develop a Web service, it should be defined as a subclass of the WebService class. To expose the Web service’s method over the Web, they should be defined as public and then marked by the [WebMethod] attribute. This attribute is actually an extension of the visibility level all over the Web. Please note that not all the data can be passed to or returned by a Web service. Available types are limited to base types and DataSet (the latter class is used in ADO.NET to operate data tables). In general , all types that can be processed by XmlSerializer can be used with Web services (i.e., everything in .NET that is serializable in XML format). Slide 31. Consuming a Web service requires a wrapper class that lives on the client and provides the same methods as the Web service. The code of this proxy class is automatically generated by Visual Studio. There is a command line utility (wsdl.exe) that generates a proxy class, given its WSDL definition. Tha latter can be obtained before by a special request to the Web service. A Web service can be invoked by HTTP-GET or HTTP-POST packets. The above protocols provide more compact packets than SOAP, but they are less expressive and even less safe. In using a Web service, complex type are represented in XML format. Objects are deserialized on the client. Slides 32-33. Now let’s consider an example that demonstrates the use of the same class either as a Web service or by .NET Remoting. First, business object is built that will provide all services necessary for the user. Next, a .NET Remoting and a Web service wrappers are constructed on the base of this object. Deployment is performed using IIS as the host. The same basic functions accessible either via Web services or by Remoting. Slide 34. To conclude this section, let’s summarize that we have considered two distributed application models in .NET: - Web service: when multiple platforms are used and HTTP usage required; - Remoting: when the interaction takes place between .NET objects. Dino Esposito’s article in MSDN Magazine whose reference is given on the slide, and also a Microsoft press book on .NET Remoting by the same author provide more information. . course for 4 th year students Comments to the presentations Prof. Vladimir O. Safonov, St. Petersburg University Email: v_o_safonov@mail.ru WWW: http://user.rol.ru/~vsafonov Lecture 11. Slide. classification; - Storing data during the intervals between the requests; - Handling events in the course of the session; - Release the session data. .NET State Server is a tool to support storing. performed when a Web method is called. .NET security is considered in a special lecture. Slide 11. .NET Web services support transactions. They look like ASP.NET Web Forms. There are two kinds