Protocols, Web Services and .NET

• Overview
• HTTP-GET and HTTP-POST
• SOAP
• HTTP
• CGI
• GET
• RPC
• RMI
• .NET
• XML common language
• Web Services
  • Browser as a Client
  • ASP 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, these solutions are broad, flexible and relatively inexpensive to implement.

XML Web services are not limited to providing remote procedure call (RPC) access, essentially calling a procedure on one machine from another. They can also be built to exchange structured information, such as purchase orders and invoices, and can be used to automate and connect internal and external business processes.

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 url-encoded text using the MIME type application/x-www-form-url-encoded, 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.

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

SOAP

SOAP is a simple, lightweight XML-based protocol for exchanging structured 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. 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.

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.

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.

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.

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.

CGI

CGI (Common Gateway Interface) provides a standard for a program on the server to get input from and send output to a Web client such as a browser. Programs can be written in nearly any language, C++, Perl, Java, etc. and are executed by the server. The server passes any data sent by the browser client to the program as input and passes program output back to the client. The CGI program generally would output HTML which the server sends back to the client. A simple C++ that outputs "Hello World" :

CGI Program in C++

HelloWorld.cpp #include <iostream.h> void main(void) {    cout << "Content-type: text/html\n\n";    cout << "<H1>Hello World</H1>"; } C++ Output Content-type: text/html <H1>Hello World</H1>

The interaction between browser, server, and C++ executable program would be:

The key points of CGI programs are:

CGI input is from standard input or program arguments. These arguments are supplied by the browser to the server, the server passes the arguments on to the CGI program as though the CGI were executed from the command line. CGI output is to standard output. The server sends the output back to the browser. CGIs must output information  back to the browser after a HTTP protocol header. If the HTML of <b>Hello</b>, the header and HTML would minimally appear as (note separating the blank line): Content-type: text/html <b>Hello World</b>

HTML <FORM> 

Sending parameters to a CGI program from a HTML input form uses the GET or POST method. The main difference is that the GET passes parameters in the URL request (identical to the previous example) so is limited to how much data can be passed. The POST method passes parameters back to the server through standard input so is effectively unlimited in the amount of data that can be returned. As before, the CGI writes to standard output to send back to the browser via the server.

The following produces the similar results as before but uses named parameters in HTML form rather than positional parameters as program arguments. The <Input Type='Text' name="myname"> defines a text box for input and the parameter of myname.

Note that any form INPUT type with a name (e.g. name="myname") will be submitted, including buttons.

Form GET Method 

The GET method passes user data from the browser to the server as part of the URL. The Get method and form to input from a Text box is:

<FORM Method='GET' Action='http://localhost/N342/Get.exe'> Enter your name: <Input Type='Text' name="myname"><br> </FORM>

Get - Form data is passed to server appended to the URL. Action - The URL when user presses the Enter key. Text - The browser renders a text box for user input. myname - The name of the text box. Suppose that ABC is entered into the text box. Browser will send myname=ABC for the myname text box value.

The browser passes the parameters to the server appended to the URL, the server passes the parameters to the CGI program in a QUERY_STRING environment variable. The Get.cpp program reads the QUERY_STRING variable and parses out the "myname=" string and assigns whatever string follows to the character array myname. The steps followed are roughly:

1. Load the get.htm file into the browser, enter Ray, and press Enter.
2. The form instructs the browser to send request from the server http://localhost/N342/Get.exe?myname=Ray which executes the Get.exe CGI with parameter data myname=Ray.
3. The server receives the request, sets QUERY_STRING="myname=Ray" and executes the CGI  Get.exe program. The localhost server receives exactly the following:
   

   GET /N342/Get.exe?myname=Ray HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt) Host: localhost Connection: Keep-Alive

    

4. The CGI program outputs:
    

   Content-type: text/html <H1>Hello Ray</H1>

5. The CGI program output of <H1>Hello Ray</H1> is passed back from the server to the browser which renders the HTML. The browser receives fro the server:
    

   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: 22  <H1>Hello Ray</H1>

<FORM Method='GET'>

Get.htm <FORM Method='GET'                 Action='http://localhost/N342/Get.exe'> Enter your name: <Input Type='Text'                               name="myname"> </FORM> URL generated by browser for form http://localhost/N342/Get.exe?myname=Ray Variable generated on server QUERY_STRING="myname=Ray"

Get.cpp  #include <iostream.h>   #include <stdlib.h>   #include <stdio.h>   void main(void) {     char name[128]="";     cout << "Content-type: text/html\n\n";     if( getenv("QUERY_STRING") != NULL)       sscanf( getenv("QUERY_STRING"),                "myname=%s", name);      cout << "<H1>Hello " << name << "</H1>\n";  } Output Content-type: text/html <H1>Hello Ray</H1>

Points of note:

• getenv("QUERY_STRING") - Returns the string "myname=Ray".
• sscanf - Provides some basic string scanning or matching capability. The three parameters are scan string, match pattern format, and destination. The prototype is:

  int sscanf( const char *string, const char *format, void *destination1, void *destination2, ...);

The statements:

char me[128]; sscanf("myname=Ray", "myname=%s", me);

assigns me="Ray". Basically, one provides a pattern to match in the string (myname=) and a format what comes after the pattern should follow. The %s specifies that string formatting should be used to interpret what comes after myname=.

Further Information - See Microsoft Development Environment Help index sscanf.

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. For example a client might execute a function sqroot on a remote 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. The function call and data communicated between the proxy and server must be represented in form common to both. The actual communication is:

The steps required to execute the RPC for sqroot:

RMI

Remote Method Invocation is the Java implementation of RPC, see Java RMI for working examples. Method and data are passed as objects between the Java client and Java server. The main advantage of the approach is that Java is architecture neutral, no translation is needed to accommodate client/server differences. The main disadvantage is that both client and server ends must be implemented in Java because Java objects are passed between.

.NET Overview

.NET is built upon several standard protocols to implement RPC as architecture AND language neutral. The implementation of .NET uses the following protocol hierarchy:

The use of standard protocols (note that IIS could be an 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.

XML common language 

If the server implemented method f in Java and had the same hardware (it would need to have a common definition of MyObject of course) then translating the XML back to Java would be trivial. 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:
 

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.

Examples

Temperature

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.ConnectorProperty("UseProxy") = true - necessary when communications must pass through a proxy
4. 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" gr.ConnectorProperty("UseProxy") = true wscript.echo gr.getTemp("47150")

StockQuote

An ASP example of a delayed stock quote provided through the http://www.xmethods.net server. The following displays the quote for IBM.

StockQuote.asp <%@ Language=JavaScript %> <% var ms = Server.CreateObject("MSSOAP.SoapClient"); ms.mssoapinit ("http://services.xmethods.net/soap/urn:xmethods-delayed-quotes.wsdl"); ms.ConnectorProperty("UseProxy") = true Response.Write( ms.getQuote ("IBM")); %>

Implementation

The following 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.asmxwhich 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. 

ASP as a Client

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

MathClient.asp

<%@ Language=JavaScript %>
<%
	var ms = Server.CreateObject("MSSOAP.SoapClient");
	ms.mssoapinit ("http://localhost/MathWebService/MathService.asmx?WSDL");
	Response.Write( ms.Plus (6,4) + ms.Minus(3,2));
%>

Points of note:

1. var ms = Server.CreateObject("MSSOAP.SoapClient"); - Create a SOAP object.
2. ms.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. Response.Write( ms.Plus (6,4) + ms.Minus(3,2)); - Call the methods and write result.

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 from the service by the server and returned to the client. The client can then determine precisely how to use 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 the service client 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.