Dotnet course 11 potx

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

Microsoft.NET Architecture and the C# Language

A semester course for 4th 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