Web Services – Beyond the Hype

Anwar M. Haneef

a.m.haneef@ieee.org

Multimedia Networks Laboratory

University of Massachusetts, Amherst

Contents:

1        Introduction

1.1  What is a web service ?

1.2  Why do we need web services ?

1.3  Service-Oriented Architecture

2        Web Services Stack

2.1  Web Service Interoperability Stacks

2.2  Wire Stack

2.3  Service Description Stack

2.4  Discovery Stack

3        Detailed Description of Important Protocols in the Stack

3.1  SOAP

3.1.1        Requirements for a SOAP Web Service

3.1.2        How SOAP works

3.2  WSDL

3.3  WSFL

3.4  UDDI

4        My Views

5        Links

6        References

1. Introduction:

1.1 What is a Web Service ?

Web Service – Hype = Distributed Components

What does this mean? From an absolute technical perspective, the term ‘web services’ is a marketing terminology representing the natural evolution of component based programming - extending the traditional model of retrieving components needed by a program to include not only libraries, accessible locally by a program, to include code resident on remote, networked computers. The fundamental difference between this model and traditional Distributed Computing Environments (DCE) such as CORBA and RMI is its congenital disposition to consider the components being accessed to be spread across the Internet (under possibly differing administrative entities). Other features of web services that make it different from older generation DCE’s are:

• its simplicity of implementation
• insulation of implementation detail
• ease of implementation over ubiquitous communication mechanisms
• lack of dependence on any programming language or software platform

Although there is a broad agreement in the industry on what a web service might be, there is no single agreed upon definition. A neutral description of web services has been provided by [GRAH02]:

“A Web Service is a platform and implementation independent software component that can be:

• Described using a service description language
• Published to a registry of services
• Discovered through a standard mechanism (at runtime or design time)
• Invoked through a declared API, usually over a network
• Composed with other services”

1.2 Why do we need Web Services ?

Traditional DCE solutions stressed on RPCs, but the need of loosely coupled applications (where components may be searched or changed as needed) are the norm. These solutions developed were solutions outside the scope of traditional distributed computing approaches:

·        Support for both document-centric messaging and RPCs

·        Transport encoded dada from both applications and business documents

·        Work over open Internet protocols such as HTTP and SMTP

Although technologies such as CORBA, COM and RMI are good technologies for tying together distributed objects on a corporate network, web services are better suited for integration of e-business applications across multiple administrative domains.

Another feature of web services, which make it a more flexible medium for cross platform communication, is its utilization of XML as its messaging and data transport mechanism. XML’s text-based form eliminates the need for byte ordering concerns. The expressive nature of attributes and nested elements in XML make it easier to represent complex data types than in pure binary formats as used traditionally. In other words, XML makes working with arbitrary data easier.

1.3 Service-Oriented Architecture:

Service-Oriented Architecture (SOA) is a conceptual representation of the web service approach. This can be summarized as in the figure below:

The roles in a SOA are:

• Service Provider: This entity creates a service description, describing a service it provides, and publishes it with a service registry. It receives web service invocation from web service requestors and processes them. This can be considered the “server side” of a client-server relationship between the service requestor and service provider.
• Service Requestor: This is the client wishing to utilize a web service. Any consumer of a web service can be called a service requestor. This can be considered the “client-side” of a client-server relationship between the service requestor and service provider.
• Service Registry: This is responsible for advertising web service descriptions published to it by service providers and for allowing service requestors to search the collection of service descriptions contained by the registry. Once a service requestor has located the service provider, the interaction is directly between the requestor and provider.

A great similarity between this architecture and traditional service-oriented architectures such as Jini’s Service Discovery [SUN99] can be seen. The difference highlighted here could be the greater scalability and scope of services that were originally addressed in the design of web services.

2. Web Services Stack

2.1 Web Service Interoperability Stacks:

The trio of web services interoperability stacks proposed to the W3C by IBM and Microsoft [IBM01] are:

• The wire stack
• The description stack
• The discovery stack

2.2 Wire Stack:

• The base of the wire stack is the network protocol (application-layer networking protocol) such as HTTP, SMTP, FTP or even others such as RMI/IIOP.
• Data encoding is done via XML
• For XML messaging, SOAP is used for data encoding, interaction style, and protocol binding variations. SOAP is used as a wrapper around XML messages in an envelope.
• Layer on top of a SOAP envelop is a SOAP Header for extensions such as digital signatures associated with the body of the SOAP envelope

2.3 Service Description Stack:

• XML is the basis for describing service descriptions
• The service implementation and service description are described via the Web Services Description Language (WSDL). This acts as the interface definition language for web services. It defines the set of operations supported by a web service, including the kind of objects that are expected as input and output of the operations, the various bindings to concrete network and data encoding schemes. This level constitutes the core definition of the service’s interface.
• The Web Service Endpoint Language (WSEL) layers on top of the WSDL to describe the service. Multiple service providers may provide the same service with different features. These are described using WSEL. It defines the characteristics of the web service that are impacted by its implementation environment. This protocol has only been hinted at publicly and needs a LOT of work. ebXML Collaboration-Protocol Profile and Agreement Specification (CPP) is another example of such a description. These protocols are still in a very rudimentary face.
• Service orchestration comes as a layer above the WSEL. This deals with utilizing multiple web services to perform various tasks such as using a text translator to translate English text to Spanish  and then using a text to voice transcoder to read the text, resulting in the creation of a Spanish reader for English text. More sophisticated web services may be used in hierarchies to generate very complicated applications. The Web Services Flow Language (WSFL) has been proposed by IBM and Microsoft has proposed Xlang. These proposals may one day merge to develop a universally recognized standard for service orchestration. This is also a topic of study.

2.4 Discovery Stack:

• This provides a publication mechanism by which to register and locate web services
• Inspection is a technique of discovering a service description given the details of a service (such as service identifier or URL) are already known. IBM has proposed ADS and Microsoft DISCO in this layer.
• UDDI represents the standard for directories of web services

3. Detailed description of important protocols in the stack:

3.1 SOAP

SOAP, the Simple Object Access Protocol [W3C01], is the industry’s best effort to standardize on the infrastructure technology for cross-platform XML distributed computing. SOAP is a rather simple protocol with a specification running to just around 40 pages. It provides the following features:

• Mechanism for defining the unit of communication. All information is packed in a clearly identifiable SOAP message. SOAP messages are wrapped in a SOAP envelope that is composed of:
• SOAP Header
• SOAP Body
• The SOAP body consists of the XML messages sent across and the SOAP Header encapsulates the information outside the body of the message.
• Error signals are sent across in messages known as SOAP fault messages.
• Extensibility to the messages that can be sent is allowed easily as XML schemas are used. As long as no central coordination or registration is required, extensions may be added. Extensions are introduced via SOAP Headers.
• SOAP provides a flexible mechanism for data representation that allows for the exchange of data already serialized in some format (text, XML, etc.) as well as abstract data types like programming language datatypes in an XML format.
• A convention for representing Remote Procedure Calls (RPCs) and responses as SOAP messages.
• A binding mechanism for SOAP messages to HTTP, because of the ubiquity of HTTP.

3.1.1 Requirements for a SOAP Web Service

The following are required for running a SOAP-based web service:

• Web Server – In our case, Apache 1.3.19 [APACHE]
• Servlet Engine – In our case, Apache Tomcat 4.0 [TOMCAT]
• SOAP APIs – In our case, Apache SOAP 2.2 [APACSOAP]

3.1.2 How SOAP works

The SOAP APIs on the servlet engine are configured to handle incoming SOAP requests. The SOAP Servlet on the web server parses the SOAP messages sent to it and responds with a SOAP response message. A simple example of a SOAP message embedded in an HTTP request will clear out the haze. This SOAP request sends a stock symbol to a StockQuote web service to get the stock quote:

As we can clearly see, the SOAP message is encapsulated in an HTTP message as an XML document. The destination of the HTTP request sent is the “StockQuote” servlet, running on the host “www.stockquoteserver.com” in this case. The request parameter for the stock web-service, parsed out by the web service on the server is shown in bold font - DIS. This is the request sent by the client. It requests the GetLastTradePrice method on the StockQuote web service to be invoked with “DIS” as the stock symbol. The parameter sent to this method is the stock symbol. The response sent by the web service, once it has processed the request, is shown in Figure 7.

The portion of the XML text of significance to the client application is shown in bold. This is the response to the query.

Even superficial observation of this process will make it clear to a technocrat that the SOAP web service is simply the age old servlet/cgi technology for processing requests on a web server – repackaged for the masses. Even the HTTP request (the HTTP POST command) is the same. The difference that SOAP brings in this situation is the utility of XML as a standardized means of sending requests and receiving responses. SOAP greatly extends the functionality of traditional servlet/cgi. Besides basic data types such as ‘string’, complex data that can be serialized or encoded as binary data can be encoded and sent across the wire as part of a SOAP message. An appropriate analogy for the relationship between the client, SOAP/HTTP and the web service provider is the relationship between a web browser, HTML/HTTP and a web server. Just like the implementation or platform of the web server or the cgi application is oblivious to a web browser client, so is the same for a SOAP client that requests a SOAP service for a web service.

3.2  WSDL

As mentioned earlier, the Web Services Description Language (WSDL) acts as the interface definition language for web services. This defines the interface by which implementations of SOAP clients may interact with a SOAP web service provider. Figure 8 shows a sample WSDL document taken from [XMETHODS]. The web service example described here takes a zip code as input and returns the current temperature of the zip code area.

The portion of significance in the WSDL document has been highlighted in bold. This is the interface definition portion of the document identifying the input and output parameters of the SOAP message. The input parameter in this case is a ‘string’, the zip code and the output of the service is a ‘float’, the current temperature of the location defined by the zip code. A sample SOAP Request/Response for this service is shown in Figures 9 and 10.

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema">

<SOAP-ENV:Body>

<ns1:getTemp xmlns:ns1="urn:xmethods-Temperature" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<zipcode xsi:type="xsd:string">94041</zipcode>

</ns1:getTemp>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema">

<SOAP-ENV:Body>

<ns1:getTempResponse xmlns:ns1="urn:xmethods-Temperature" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<return xsi:type="xsd:float">68.0</return>

</ns1:getTempResponse>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

As we can see from this example, the WSDL is a platform and language independent interface definition for SOAP clients to send requests to web services. An important question that arises is, how complicated is it to create a client program given a WSDL document. Tools such as those provided by Axis [AXIS], Apache’s follow-up to Apache SOAP, and my personal recommended SOAP server-end API suite, allow developers to generate SOAP clients in their preferred programming language (Java in Axis’s wsdl2java tool’s case), given the WSDL definition.  Other permutations and combinations exist, such as the generation of WSDL given a SOAP service implementation.

But, the fact still remains that there needs to be a certain deal of human interaction to generate the code and interact with the web service. The interface definition is only a suggestion to the developer to create a client. Automated generation of web service clients is still far away from reality. Some of the protocols mentioned below do try to address this issue – but mind you, they are still under development as of this writing.

3.3  WSFL

WSDL only allows the description of the detailed information necessary to invoke operations within a single web service. The Web Services Flow Language (WSFL) [WSFL] is a language proposed by IBM to define a mechanism for orchestrating a series of web service invocations into an overall business process or workflow. Microsoft’s Xlang [XLANG] also competes in the same space as WSFL, and may potentially merge to become an industry standard. WSFL also provides developers with an interface definition, similar to that provided by WSDL to invoke web services.

3.4  UDDI

The Universal Description Discovery Integration (UDDI) [UDDI] is a ‘search engine’-cum-‘directory service’ for web services. UDDI registries act as Service Registries. These, unlike search engines, allow the provider of a service to register themselves as part of the registry allowing people wishing to use these services to access them. Most existing registries have classified businesses according to categories defined by organizations such as the North American Industry Classification System, allowing developers to search for services based on such categories. Other search parameters are also provided. The most notable UDDI registries are provided by Microsoft [MSUDDI] and IBM [IBMUDDI]. The Microsoft UDDI registry’s web interface is definitely far more user friendly than IBM’s. These UDDI registries provide a plethora of information related to the company and the services provided by it. Unlike in the case with traditional search engines, UDDI registries allow the service providers to input a great deal of information related to the service and provider, including contact information, WSDL document locations, web site etc.  To quote from the UDDI Executive White Paper:

“In summary, UDDI-based registries will help businesses to take advantage of Web services:

• Businesses will have a means to describe their services and business processes in a global, open environment on the Internet thus extending their reach.
• Potential trading partners will quickly and dynamically discover and interact with each other on the Internet via their preferred applications thus reducing time to market.
• The barriers to rapid participation in the global Internet economy will be lowered for any business anywhere
• Businesses will be able to organize their portfolio of services in a controlled environment.”

Communication with the UDDI registries is done via SOAP messages. Regardless of this, most UDDI registries provide a web interface for humans to interact or browse through. A sample UDDI registry ‘businessEntity’ entry from the Microsoft UDDI registry is shown in Figure 11.

The text marked in bold represent the location of the WSDL document referenced by this UDDI entry. The other portion of the XML document marked in bold is the description of the service, acting as a reference point for human programmers to understand the service provided. Yet, again, nothing can be done without the aid of human developers.

4. My Views:

After a study of web services, and some sample implementations (on Apache SOAP), including:

• Image transcoding web-service: This SOAP based web service, takes in an image from the client and returns a black and white image, which is half the size (maintaining the aspect ratio) of the original.
• Text to voice synthesis web-service: This SOAP based web service, takes in a line of text, synthesizes an audio sample of the text and returns the audio file to the client.

I have realized that web services do hold a great deal of promise. Service orchestration on the other hand may still need some time, as there seems to be a disparate amount of work done on it, work lacking in harmony. Service orchestration is still not in a draft stage unlike the other web services protocols such as SOAP, which means real-life deployment in commercial scenarios, will take some more time. The promise of service orchestration seems real, but the promise of applications searching UDDI registries, looking up web services and automatically utilizing them seem rather far fetched as of now. This technology brings out a certain feeling of deja-vou. Mobile and intelligent, autonomous agents is one thing that comes to my mind. This was a promise that researchers in agents [DAML-S] have been trying to achieve for some time now. Hopefully, this research will mature and we will be able to include enough intelligence in our applications to act autonomously and mobilize web services for our needs. So, till this dream is realized, utilization of web services by our applications will need to be done manually by an uncouth software engineer, browsing through WSDL documentation provided by a web service provider, or through thinly veiled attempts at ‘artificial intelligence’ ingrained into applications which could select a web services from providers based on a limited set of parameters. Until then, those web services programmers ads in the classified sections will continue to grow……

5. Links

Some more links related to web services, not mentioned in the references section, can be obtained at:

http://www-unix.ecs.umass.edu/~ahaneef/publications/thesis/ResearchLinks.htm

6. References:

[GRAH02] Steve Graham, et. al., “Building Web Services with Java: Making Sense of XML, SOAP, WSDL and UDDI”, Sam Publishing, 2002.

[SUN99] Jini Technology, Sun Microsystems, <http://www.jini.org>

[IBM01] IBM and Microsoft, 2001 <http://www.w3c.org/2001/03/WSWS-popa/paper51>

[W3C01] SOAP 1.1, W3C Note, < http://www.w3.org/TR/SOAP/ >

[APACHE] Apache HTTP Server Project, Apache Software Foundation, <http://httpd.apache.org/>

[TOMCAT] Jakarta Tomcat, Apache Software Foundation, <http://jakarta.apache.org/tomcat/>

[APACSOAP] Apache SOAP, Apache Software Foundation, <http://xml.apache.org/soap/>

[XMETHODS] XMethods Weather Service, XMethods.com, <http://www.xmethods.com/ve2/ViewListing.po;jsessionid=KKORT5kRgulPYKcBjsaxl2DR(QCcd0CRM)?serviceid=8>

[AXIS] Apache Axis, Apache Software Foundation, <http://xml.apache.org/axis/>

[WSFL] IBM, <http://www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf>

[XLANG] Microsoft, <http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm>

[UDDI] UDDI.org, <http://www.uddi.org/>

[MSUDDI] Microsoft UDDI, <http://uddi.microsoft.com/>

[IBMUDDI] IBM UDDI, <http://www-3.ibm.com/services/uddi/>

[DAML-S] The DARPA Agent Markup Language, DARPA,  <http://www.daml.org/services/daml-s/2001/05/>