Protocols, Web Services and .NET

• Overview
• .NET
• HTTP-GET and HTTP-POST
• SOAP
• HTTP
• GET
• RPC
• XML common language
• Web Services
  • Browser as a Client
  • VB Script as a Client
  • WSDL (Web Services Discovery Language)
  • Windows Client

Overview

Some portions of the following Overview have been excerpted from Microsoft XML Web Service Wire Formats

The Internet and Web's value is largely defined by the sharing of resources.

• Most resources distributed across the Web, such as stock quotes, phone number lookups, etc. are accessible through a browser or screen-scraping, a client program acting as a browser and groveling through the returned HTML for the requested data. Not conducive to creating distributed services.
   
• Another approach for accessing resources implements specialized systems using low-level protocols such as TCP/IP. The solution is narrow, brittle, and expensive to implement.
   
• An emerging standard for implementing distributed services is based on XML. XML Web services can work with one or more open protocols, such as a combination of HTTP and SOAP.
   
• As we will see, high-level standards-based solutions are broad, flexible and relatively inexpensive to implement.

.NET Overview

.NET is built upon several standard protocols to implement RPC (Remote Procedure Call) that is computer architecture AND language neutral. The implementation of .NET uses the following protocol hierarchy:

The use of standard protocols (note that IIS could be any Web server capable of invoking Web services) allow RPC client and Web services to be implemented in a wide variety of approaches, a SOAP knowledgeable Web browser could act as a client (consumer) of a Web service written in C++, Visual Basic, etc.

The list of protocols and a rough hierarchy within .NET is:

1. .NET Programming language (e.g. C#) - Implements algorithms on client and server utilizing RPC. 
2. .NET - Defines the infrastructure used by languages to implement more or less transparent RPC. 
3. SOAP - Simple Object Access Protocol, a subset of XML that defines a common representation for basic data types such as integer, character, etc. and objects 
4. XML - eXtensible Markup Language to define and represent arbitrary data structures in SOAP.
5. HTTP - Protocol to pass XML messages between client and server.
6. IIS - Internet Information Services - Handles communication between client and server.
7. TCP - Reliable point-to-point communications over a network.
8. IP - Internet Protocol.
9. Physical layer - Ethernet/Point-to-Point/etc.

RPC

One high-level approach to distributed system implementation follows the standard model of calling a function, the difference is that the client caller and the server callee function are on different computers.

• Calling functions on another machine is termed Remote Procedure Call (RPC) which is itself a protocol standard.
• A client program can execute a function sqroot on a remote RPC server.
• The apparent communication to the client is a direct call to the function on the server as illustrated below:

• In reality, the client program does not call the server function directly but through a proxy.
• The proxy is responsible for communication and translating the function parameters and results.
  • Floating point numbers, strings are represented differently on different architectures and languages.
• The function call and data communicated between the proxy and server must be represented in a form common to both. 
• The actual communication is:

The steps required to execute the RPC for sqroot:

StockQuote RPC

A real example of a client side RPC, this to a foreign machine, is a delayed stock quote provided through the http://www.xmethods.net server. The following displays the quote for IBM.

StockQuote.vbs

  Set gr = CreateObject("MSSOAP.SoapClient") 
  gr.mssoapinit "http://services.xmethods.net/soap/urn:xmethods-delayed-quotes.wsdl"
  wscript.echo gr.getQuote ("IBM")

• Execute at command prompt by: cscript StockQuote.vbs

IIS

.NET or other web service infrastructure requires a contact point on the server machine, IIS for Microsoft systems.

• Client sends service request to server machine in form of HTTP-GET.

• Server locates file, extension defines how to handle.

  • HTML, HTM, JPEG, etc. are returned to client.

  • EXE executed external to server, raw results returned to client.

  • ASP executed internal to server, raw results returned to client.

  • ASMX define service programs with parameters passed to program functions/methods. Results returned to client in XML wrapper.

HTTP-GET and HTTP-POST

• HTTP-GET and HTTP-POST are standard protocols that use HTTP (Hypertext Transfer Protocol) verbs for the encoding and passing of parameters as name/value pairs, along with the associated request semantics.
   
• Each consists of a series of HTTP request headers that among other things define what the client is requesting from the server, which responds with a series of HTTP response headers and the requested data if successful.
   
• HTTP-GET passes its parameters in the form of urlencoded text using the MIME type application/x-www-form-urlencoded, which is appended to the URL of the server handling the request. Urlencoding is a form of character encoding that ensures the passed parameters consist of conforming text, such as encoding a space as %20. The appended parameters are also referred to as a query string.
•  

  • GET /rwisman/Hello.htm HTTP/1.0

• Similar to HTTP-GET, HTTP-POST parameters are also urlencoded. However, instead of being passed as part of the URL, the name/value pairs are passed inside the actual HTTP request message.

Client - A computer that accesses shared network resources provided by another computer, called a server. An Internet client application is a program that accesses information from a network data source (server) using Internet protocols such as gopher, FTP, or HTTP. An Internet client application might access a server to retrieve data such as weather maps, stock prices, or newspaper headlines, for example. The Internet client can access the server through an external network (the Internet) or an internal network (sometimes called an intranet).

Web browsers are a common Internet client, providing a graphical interface to resources stored on a Web server. The relationship of a client and server is illustrated by the following diagram. The communication exchange is as follows:

Client connects to a server at www.ius.edu. Client sends a request to server as rwisman/Hello.htm Server receives request, retrieves the file Hello.htm and copies the contents of the file back to the client. Client receives server response as the contents of file Hello.htm and renders the contents as Hello World.

Server - In general, refers to a computer that provides shared resources to network users. On a network, the computer running software that provides data and services to clients over the network.  On the Internet, refers to a network data source using Internet protocols such as gopher, FTP, or HTTP. In the illustration above, the server provides file resources using the HTTP protocol.

HTTP - The rules for Web browser and server interaction are defined by the HyperText Transfer Protocol (HTTP). HTTP supports four basic operations that the browser can specify:

GET requests a specific item from the server such as a file. The server returns a status heading, a blank line, followed by the item. HEAD requests item status, the server returns only the status. POST sends data to the server. PUT sends data to the server.

The communication exchange listed above would be more accurately specified as an HTTP exchange.

• Client connects to the server www.ius.edu
• Client then sends a HTTP request:

GET /rwisman/Hello.htm HTTP/1.0

• Server receives request, retrieves the item Hello.htm and responds by returning status information (200 indicates the server honored the request) and copies the item contents of the file back to the client.

HTTP/1.1 200 OK Server: Microsoft-IIS/4.0 Date: Tue, 10 Apr 2006 03:37:48 GMT Content-Type: text/html Accept-Ranges: bytes Last-Modified: Tue, 10 Apr 2006 03:35:48 GMT ETag: "021f556fc1c01:60ca" Content-Length: 24 <H1>Hello World</H1>

• Client receives server response and renders the <H1>Hello World</H1> as Hello World.

XML common language 

• If the client and server implement the calling program and some method f in Java or had the same hardware (it would need to have a common definition of MyObject of course) then RPC would be relatively simple.
• If the server implemented method f in another language the translation would be impossible without a common representation for calling methods and passing parameters on the client and server machines.
• For example, how should a C++ char * be translated into a VB String?
• The .NET approach is to restrict the data transferred to a limited number of data types and use a common language representation for those types.
• C++ can call remote VB functions and conversely in many cases using XML as the common representation language.

For communicating arbitrary data structures or objects both the client and server must have a common representation in XML. Consider the C++ and corresponding XML:
 

SOAP

SOAP is a simple, lightweight XML-based protocol for exchanging structure and type information on the Web.

The overall design goal of SOAP is to keep it as simple as possible, and to provide a minimum of functionality. The protocol defines a messaging framework that contains no application or transport semantics. As a result, the protocol is modular and very extensible.

By traveling over standard transport protocols, SOAP is able to leverage the existing open architecture of the Internet and gain easy acceptance by any arbitrary system capable of supporting the most basic Internet standards. You could view the infrastructure required to support a SOAP-compliant XML Web service as rather simplistic, yet powerful, since it adds relatively little to the existing infrastructure of the Internet and still facilitates universal access to the services built with SOAP.

The SOAP protocol specification consists of four main parts.

1. The first part defines a mandatory extensible envelope for encapsulating data.
   • The SOAP envelope defines a SOAP message and is the basic unit of exchange between SOAP message processors.
   • This is the only mandatory part of the specification.
      
2. The second part of the SOAP protocol specification defines optional data encoding rules for representing application-defined data types and directed graphs, and a uniform model for serializing non-syntactic data models.
    
3. The third part defines an RPC-style (request/response) message exchange pattern. Each SOAP message is a one-way transmission.
   • Although SOAP's roots are in RPC, it is not limited to being a request/response mechanism.
   • XML Web services often combine SOAP messages to implement such patterns, but SOAP does not mandate a message exchange pattern and this part of the specification is also optional.
      
4. The fourth part of the specification defines a binding between SOAP and HTTP.
   • However, this part is also optional.
   • You can use SOAP in combination with any transport protocol or mechanism that is able to transport the SOAP envelope, including SMTP, FTP or even a floppy disk.

Web Services

Web services are essentially remote procedure calls from a client that are executed on a server. The two key elements of Microsoft .NET are:

1. support for Web services implementation through the Visual Studio, VB Script, etc.
2. response to service requests through the IIS server.

Example

Following contacts a current temperature for a zip code Web service, the client is written in VBScript. The three lines of code are:

1. Set gr = CreateObject("MSSOAP.SoapClient") - create a Soap client object.
2. gr.mssoapinit "http://www.xmethods.net/sd/2001/TemperatureService.wsdl" - Contact service, receiving Web Services Description Language of how to call the service.
3. gr.getTemp ("47150") - Call the service with parameter "47150" and receive service result.

The script can be executed at the command line by (assuming named tempquote.vbs):

cscript tempquote.vbs

Set gr = CreateObject("MSSOAP.SoapClient") gr.mssoapinit "http://www.xmethods.net/sd/2001/TemperatureService.wsdl" wscript.echo gr.getTemp("47150")

Example:

A Web service, MathService, written in C#, defines two operations (Plus and Minus) and can be invoked through HTTP GET, HTTP POST, or SOAP protocols.

• The service is invoked through the IIS server and is stored in an IIS virtual directory named MathWebService (by default in \Inetpub\wwwroot\MathWebService).
   
• The directory holds a minimum of two files:

1. MathWebService/bin/MathWebService.dll - Is the executeable code which implements the service. MathService.asmx.cs is the C# program.
2. MathWebService/MathService.asmx - Holds the service description and location needed by the IIS server to pass parameters and execute the requested service methods.

• Requesting the file in a HTTP GET (i.e. http://localhost/MathWebService/MathService.asmx/Plus?x=4&y=6) results in the execution of MathService.Plus(4,6); and the return of the result 10.
   
• The browser address of:

• http://localhost/MathWebService/MathService.asmx/Plus?x=4&y=6

requests MathService.asmx which executes the code from the MathService.asmx.cs program that implements the Web service. 

The code is in bin/MathWebService.dll file, which is executed through the IIS server.

Implementing: It is simpler to use .NET Visual Studio to implement Web services in any of the supported languages (C#, VB, C++). Much of the administration (such as creating an IIS virtual directory, compiling and uploading files, etc.) are performed automatically. Essentially all that is necessary is to create a C# project as a Web Service and edit in the service methods.

Browser as a Client

Browser's speak HTTP protocol so can act as a simple client, below invoking MathService.Plus(4,6); via HTTP GET protocol. 

VBScript as a Client

VB scripts can act as a client also, contacting servers for information. The following VB script MathClient.vbs uses the MathService Plus and Minus methods.

MathClient.vbs

   set SOAPClient = createobject("MSSOAP.SOAPClient")
   SOAPClient.mssoapinit("http://localhost/MathWebService/MathService.asmx?WSDL") 
   wscript.echo SOAPClient.Plus (6,4) + SOAPClient.Minus(3,2)

Points of note:

1. var SOAPClient = Server.CreateObject("MSSOAP.SoapClient"); - Create a SOAP object.
2. SOAPClient.mssoapinit ("http://localhost/MathWebService/MathService.asmx?WSDL");  - Initializes the SOAP object from the WSDL (Web Services Description Language) tree returned that defines how to call the Plus and Add methods. Click the link for the WSDL of the service.
3. wscript.echo SOAPClient.Plus (6,4) + SOAPClient.Minus(3,2) - Call the methods and write result.

• Execute at command prompt by: cscript MathClient.vbs

WSDL (Web Services Discovery Language)

• A key element to simple to use Web services is a service discovery mechanism that allows the client to discover the services (e.g. method names) and details (e.g. parameter types) for using the services.
• WSDL can be generated automatically from the service definition (in .NET) by the server and returned to the client as in above examples.
• The client can then determine precisely how to call a service.
• The programmer must still know how to write a proper procedure call to access the service but the communication and data marshalling details are handled by a service client proxy and server following the WSDL description.

A part of the WSDL returned by the server for the MathService is listed below. Telnet was used to request the WSDL to demonstrate that HTTP is the underlying protocol used (in this case).

User input

telnet localhost 80
GET /MathWebService/MathService.asmx?WSDL HTTP/1.0

MathService

namespace MathWebService   { 
  [WebService(Namespace="http://localhost/MathWebService/")] 
  public class MathService : System.Web.Services.WebService 
  { 
            public MathService() 
            { 
                  InitializeComponent(); 
            } 
            [WebMethod] 
            public int Plus(int x, int y) 
            {
                  return x+y; 
            } 
} 

Windows Client

The MathService can be invoked by a client program in Windows as illustrated below:

The client side consists of two programs: 

• Client - The client invokes the service methods on the server via the proxy. The client is insulated by the proxy which invokes the services transparently to the details of marshalling the data, translating to a common data representation, and communicating with the server. The client invokes MathService methods through the proxy. For example, on the client:

MathService ms = new MathService();
Console.WriteLine( ms.Plus(6, 8) );

invokes the proxy Plus(6,8) method which in turn invokes the MathService Plus(6,8) method on the server.

• Proxy - A proxy defines MathService methods that manage the communication with the server.
• The proxy has knowledge of the service location, services, and how to invoke the services, for example:

this.Url = "http://localhost/MathWebService/MathService.asmx"; 

is the location of the MathService. The proxy defines an interface to the Plus method as:

       public int Plus(int x, int y) {
            object[] results = this.Invoke("Plus", new object[] {  x, y });
            return ((int)(results[0]));
        }

The proxy Plus method is invoked by the client identically to the service Plus method, however the proxy Plus invokes the service Plus method located on a server.

Implementing: The client can be implemented within or without the .NET Visual Studio. The browser request:

http://localhost/MathWebService/MathService.asmx?WSDL

produces the formal specification of the MathService in SOAP.