CSE 134A Lecture Notes, June 6, 2001

CSE134A LECTURE NOTES

June 6, 2001

ANNOUNCEMENTS

The final exam is on Thursday next week, 3pm to 6pm, in this room. The exam will be similar in format and style to the midterm.

We'll have a review session next week on Tuesday from 11:30am to 1pm, in Sequoyah Hall room 147. (Sequoyah Hall is north of APM and south of RIMAC, near the Economics building.)

WEB SERVICES

There are two views of the theme of this course. The more pedestrian and technical view is server-side programming for the web. The more ambitious view is "web services."

Today we'll look at SOAP, a simple but useful standard for building web services. SOAP was defined in 1999. There are many implementations of it available, but very few public services using it--we'll discuss possible reasons later.

SIMPLE OBJECT ACCESS PROTOCOL (SOAP)

DCOM and CORBA are complex protocols, so their implementations tend to be symmetrical: the same distributed object model is used at both ends. But all the Internet really guarantees is HTTP and XML.

HTTP traffic is permitted by most firewalls. Note the paradox: because firewalls view other protocols as security risks, we are punching security holes into HTTP.

Currently HTTP is used only for transmitting files. As procedure parameters, we need to transmit structured data such as arrays.

SOAP uses HTTP to define headers for remote procedure calls (commands), and XML to define payloads.

SOAP does not provide encryption, authentication, type safety, versioning, co-routines, message grouping, call-by-reference, or complex operations on objects. Because it does not assume object-orientedness, SOAP is easy to use for small and simple servers, like sensor devices, and server languages, like PHP.

SOAP IN PHP

This code example is taken from http://www.gigaideas.com.cn/phpsoap/

$send_int=2001; $send_string="happy!"; $send_arr=array("2001","happy" );
$soap_msg=new soapmsg( 'get_array',                    //Invoked Method Name
                       'urn:soap_test',                //Invoked Target Object Id
                        array(                         //Parameters List Below
                        new soapval($send_int,    "int"),
                        new soapval($send_string, "string"),
                        new soapval($send_arr,    "array")));
$client=new soap_client("/soap/servlet/rpcrouter", "office.gigaideas.com.cn", 8080);

Here /soap/servlet/rpcrouter is the servlet program on the server office.gigaideas.com.cn at port 8080.

$return=$client->send($soap_msg);
if (!$return) { die("send failed"); }
$v=$return->value();
//Check the response.
if(!$return->faultCode()) {
    $back_arr=$v->scalarval();
    print "Back array is:\n<br>";
    for($i=0;$i<sizeof($back_arr);$i++) echo $i." => ".$back_arr[$i]."\n<br>";
} else {
print "Fault: ";
print "Code: " . $return->faultCode() . " Reason '" .$return->faultString()."'<BR>";
}

Notice the SOAP client blocks until the response is received. A non-blocking client would be a useful extension to this SOAP implementation.

A SOAP EXAMPLE

Here is an example of a SOAP call, taken from http://msdn.microsoft.com/xml/general/soap_webserv.asp

POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml
Content-Length: nnnn
SOAPMethodName: Some-Namespace-URI#GetLastTradePrice
<SOAP:Envelope xmlns:SOAP="urn:schemas-xmlsoap-org:soap.v1">
    <SOAP:Body>
        <m:GetLastTradePrice xmlns:m="Some-Namespace-URI">
                <symbol>DIS</symbol>
        </m:GetLastTradePrice>
    </SOAP:Body>
</SOAP:Envelope>

And here is the corresponding response:

HTTP/1.1 200 OK
Content-Type: text/xml
Content-Length: nnnn
<SOAP:Envelope xmlns:SOAP="urn:schemas-xmlsoap-org:soap.v1">
    <SOAP:Body>
        <m:GetLastTradePriceResponse xmlns:m="Some-Namespace-URI">
            <return>34.5</return>
        </m:GetLastTradePriceResponse>
    </SOAP:Body>
</SOAP:Envelope>

The use of XML namespaces avoids confusion between names of XML elements defined by different sources.

ANOTHER EXPLANATION

From http://www.xml.com/pub/a/2000/02/09/feature/

SOAP allows methods to be invoked against endpoints over HTTP. A SOAP endpoint is identified by a URL (just like any HTTP-based resource). A SOAP method is uniquely identified by a namespace URI and an NCName. The NCName maps to the symbolic name of the method. The namespace URI scopes the method name. SOAP method requests are transported in HTTP POST requests. They must have a SOAPMethodName HTTP header indicating the method being invoked. The following is a minimal SOAP HTTP header:
POST /objectURI HTTP/1.1
Host: www.foo.com
SOAPMethodName: urn:develop-com:IBank#getBalance
Content-Type: text/xml
Content-Length: nnnn
This HTTP header indicates that the getBalance method (from the urn:develop-com:IBank namespace) should be invoked against the endpoint identified by http://www.foo.com/objectURI.
The HTTP payload of a SOAP method request is an XML document that contains the information needed to invoke the request. Assuming that all that is needed to get a bank balance is an account number, the HTTP payload of the request would look something like this:
<?xml version='1.0'?>
<SOAP:Envelope
  xmlns:SOAP='urn:schemas-xmlsoap-org:soap.v1'>
 <SOAP:Body>
  <i:getBalance
    xmlns:i='urn:develop-com:IBank'>
   <account>23619-22A</account>
  </i:getBalance>
 </SOAP:Body>
</SOAP:Envelope>
After drilling through the SOAP:Envelope and SOAP:Body elements, note that "root" element of SOAP:Body is an element whose namespace-qualified tag name matches the SOAPMethodName HTTP header exactly. This redundancy is to allow the HTTP-based infrastructure (proxies, firewalls, web server software) to process the call without parsing XML, while also allowing the XML payload to stand independent of the surrounding HTTP message. Since all that was needed to invoke the getBalance method was an account number, only one child element appears below the i:getBalance element.
Upon receiving this request, the server-side software is expected to execute some code that corresponds to getBalance. How this happens is completely outside the scope of the SOAP protocol. Here are some possible reactions to the request:

A CGI program may run.

An Apache module may be called.

An ASP or JSP page may be processed.

A Java Servlet or ISAPI extension may be invoked.

A servant may be dispatched inside a CORBA ORB.

An XSLT may be run against the request.

A human may read the request and start typing a response (unlikely, but legal SOAP!).

Once the server-side operation has executed, an HTTP response message will be returned to the client containing the results of the operation. There are no SOAP-specific HTTP response headers. However, the HTTP payload will contain an XML document that contains the results of the operation. The results will be inside an element whose name matches the method name suffixed by "Response." Here's an example response message (including the HTTP header):
200 OK
Content-Type: text/xml
Content-Length: nnnn

<?xml version='1.0'?>
<SOAP:Envelope
   xmlns:SOAP='urn:schemas-xmlsoap-org:soap.v1'>
 <SOAP:Body>
  <i:getBalanceResponse
     xmlns:i='urn:develop-com:IBank'>
   <amount>45.21</amount>
  </i:getBalanceResponse>
 </SOAP:Body>
</SOAP:Envelope>
That's it. SOAP endpoints are just URLs. SOAP methods are just a pair of XML element declarations identified by a namespace URI and an NCName. Section 8 of the SOAP specification describes the rules used to encode instances of types. The section 8 rules describe an element-normal-form encoding style, in which all properties of an instance are encoded as child elements, never as attributes.

WHAT SOAP DOES NOT PROVIDE

The SOAP standard does not provide any of the following:

client and/or server authentication
payload encryption
non-blocking clients
client-side or server-side grouping of related SOAP calls
transactions consisting of multiple SOAP calls
ACID properties (atomicity, consistency, integrity, durability) for transactions
session management
payment mechanisms

Most of these are necessary for all non-trivial distributed applications, including Internet-based web services.

THE FUTURE OF SOAP

Microsoft is pushing SOAP as part of its .NET initiative. To support .NET, and all its programming standards, Microsoft provides software development environments and large, useful libraries of reusable code. Critically, Microsoft provides easy-to-use GUI-based programming tools, so it can attract a much larger number of developers than vendors who do not provide visual tools. Microsoft also provides excellent documentation and guidance for programmers at all levels of expertise.

Microsoft's strategy is always embrace, extend, dominate. Because so many services are needed on top of SOAP by applications, this strategy should work well with SOAP.

Most SOAP services will be private, not public for end-users. End-users need attractive, easy-to-use graphical services, as provided by HTML, not remote-procedure-call interfaces

The era of free web services is over. How will SOAP services be paid for? There may be an initialization problem: we need reliable, useful micropayment services in order to support the development of other SOAP services.