Most Read This Week
The Brave New World of Web Services: SOAP, WSDL, and UDDI - Part 2
The Brave New World of Web Services: SOAP, WSDL, and UDDI - Part 2
By: Ron Ben-Natan
Nov. 20, 2001 12:00 AM
In the complex business world of service, organizations need to lower costs and find efficient business delivery models. This means they often outsource parts of the service delivery business. For example, they may preserve customer relations personnel and the customer relationship, but outsource the actual work. New information needs to be communicated from one organization to another.
In the "old" world this would involve point-to-point integration between various systems, which would be extremely painful. It would involve a lock-in to one workforce-delivering company and would preclude, for example, bidding out the work, working with multiple providers of workforce services, and, obviously, the notion of workforce marketplaces.
Since these concepts are the crux of B2B interactions and the true enablers of business efficiencies, they are of fundamental interest to the service industry. The examples in this article involve the transmission of "service order" information.
In one scenario an organization captures order-related information, such as customer location, the required service to be performed, and various entitlement terms (such as when the service should be provided). Once the company owning the customer relationship captures this information, it communicates with a workforce provider and creates a call entity. This is done by sending a SOAP request, that is, activating a Web service provided by the second company. The Web service is defined in WSDL (Web Services Description Language) and discovered through the use of a UDDI registry.
In Part 1 of this series we examined the Web services model, SOAP, WSDL, and the UDDI mechanism. In this article we delve into more detail and offer some examples.
The goal is to provide the basics of how the three technologies fit together and how they'd be used, and a general understanding of the structures in each technology set. You won't master these technologies; for that you should read the actual specs and examples available at www.soap.org, www.wsdl.org and www.uddi.org, or on IBM's and Microsoft's Web sites.
In this article the examples are taken from ViryaNet's Service Hub platform - a solution used by companies in the business of service delivery (companies doing installations in homes and businesses, companies that dispatch technicians for fixing and replacing equipment, companies that manage a distributed workforce of claims adjusters or other service personnel).
Businesses in such industries are constantly looking for more efficient business models that often require cooperative business processes between disparate organizations - environments perfect for reaping the benefits of Web services.
The information passed into the Service Hub describes the customer, the equipment, and the service requested. This is then sent to the workforce management system so field engineers can be dispatched to the field to work the order.
As can be seen from Listings 1 and 2, SOAP messages are usually encapsulated in HTTP requests and responses. The data itself is an XML document and is encapsulated inside an XML envelope defining the routing and messaging information.
SOAP messages typically have three parts: an envelope, a header, and a body. The envelope and the body are mandatory elements within the SOAP message; the header is optional. The envelope is the root element of the XML document and the body is the payload of the message. The body is a child element in the envelope.
The header element is a generic mechanism for adding attributes and properties to the messaging without requiring (1) prior centralized agreement between communicating parties and (2) some form of federation for messaging patterns. Header attributes are used by recipients to tell them how to process the messages.
A header in a SOAP message may have various attributes. One is the mustUnderstand attribute. By tagging a header element with a "1" value for this attribute, the sender language is implying a processing pattern that requires that the semantics of that element be obeyed. If the receiver can't abide by that directive, it must fail in the processing of the message.
Another important attribute for header elements is the actor attribute. SOAP documents can be passed from a sender to an ultimate receiver in a way that passes through multiple parties that may or may not do some processing based on the SOAP document. These can be technical "actors" that perform simple things like routing or may involve message semantics. The actor attribute allows the tagging of header elements in a way that forces an intermediary to process the element and remove it from the SOAP document.
Encoding of data within a SOAP message is fairly straightforward - and similar to most information systems, such as databases and object-oriented languages. Types are either primitive or compound and may be constructed from several parts. This is a recursive structure in which the compound types are made from other compound types or primitive types. Eventually everything is simply one big tree (or hierarchy) where the leaf nodes are simple (primitive) types.
The types themselves follow the XML Schema methodology and allow the messages to be truly self-describing. Although this is an assumption that SOAP is built on, it can't be called an inherent part of SOAP. SOAP is more focused on the messaging and routing elements, and makes use of XML and XML Schema for the body of the message; this is often called the message payload. An example of the generic encoding method (without the use of a Schema) follows:
<SOAP-ENV:Body>SOAP is not directly related to HTTP. It can be delivered on multiple transports using multiple protocols, not just HTTP. Still, HTTP plays a central role in the life of SOAP. Remember, the main theme is that of XML over HTTP. So while SOAP messages can be sent over additional protocols (and mail protocols are certainly being used), the major binding of SOAP to a transport is to HTTP. Therefore, a large part of the SOAP specification document is dedicated to describing the use of SOAP in HTTP.
SOAP makes use of the HTTP headers in many ways, but adds a few that are SOAP specific. A SOAP message in an HTTP request/response pair always uses the text/XML content type, as mandated by the SOAP specification. Other than that, most headers remain the same. One additional header is the SOAPAction header field that specifies a URI that hints at the intent of the message. SOAP responses use the same structure as HTTP responses, including the header.
Apart from using general HTTP requests and responses, SOAP also defines an HTTP extension framework. Messages sent in this way force the receiver of the SOAP messages to manage the processing of this request as a SOAP operation as opposed to letting the receiver decide what to do with the request. Basically, the difference is the use of an M-POST request type instead of a POST request type. For example, the message shown in Listing 1 will appear as shown in Listing 3 when invoked within the HTTP extension framework.
WSDL describes seven abstractions: services, ports, bindings, port types, operations, messages, and types.
A service is the entity that is the focus of what WSDL is all about, and the purpose of a WSDL document is to describe the structure of a service. A service is described in terms of a collection of ports that represent network endpoints, that is, routines that can communicate over the Web to request and provide the service.
A port is defined in terms of a combination of an address on the Web along with a binding as the concrete protocol and data format that is supported by the endpoint. The binding is described by a more abstract entity - the port type that itself is described as a collection of operations. The data exchanged by the endpoints is also described in an abstract manner by messages.
Finally, the definition of the data being passed within a message is encapsulated within type definitions. Types in WSDL are described according to the XML Schema specification. WSDL defines a set of specific bindings in addition to the general binding method. The extensions of concrete bindings are for SOAP, HTTP GET and POST requests, and MIME.
Listing 4 shows the canonical service document structure as defined by the WSDL specification. Listing 5 is an example WSDL document describing the order creation service in ViryaNet's Service Hub platform. Note that services are defined using the following major element categories:
If the port type defines a one-way operation, the definition will take the form:
<wsdl:portType>If the port type defines a request-response or a solicit-response operation, the definition will take the form:
<wsdl:output ... />If the port type defines a notification operation, the definition will take the form:
<wsdl:portType>Bindings describe the message formats and protocol details for operations and messages defined by a particular port type. There may be numerous bindings for a single port type. Ports are the physical endpoint descriptors and specify the physical location from which the service may be received. Finally, services group a set of related ports together and effectively define a domain where a service is provided.
Since WSDL is in many ways so close to SOAP, the WSDL specification has a special section describing a SOAP binding. The SOAP-specific definitions include a way to specify that a binding is bound to SOAP, a way to specify an address for a SOAP endpoint, a way to use a SOAPAction URL in an operation definition, a set of definitions for headers transmitted as part of a SOAP envelope, and a way for specifying SOAP roots in XSD.
Each of these specifications makes use of a SOAP namespace. For example, a SOAP binding element can be used to specify that SOAP is being used as the underlying protocol. In this case the WSDL binding section will take the form:
<binding ... >In the same way, when an operation is defined using the SOAP extension, the operation takes the form:
<operation ... >Other similar examples exist, including soap:body, soap:fault, soap:header, and soap:address.
Another part of the WSL specification defines an HTTP GET/POST binding that allows for a more primitive implementation. Here, HTTP is used for the messaging transport and the service definer can specify a binding using HTTP GET or HTTP POST, can specify that the port is implemented as an HTTP endpoint, and can specify an address for each operation relative to the HTTP endpoint.
The focus of UDDI is the registration and discovery of services. UDDI relies on the existence of a distributed registry that is implemented in XML and communicated with using XML. UDDI business registration is done using an XML file that describes a business entity and the associated Web services.
There are three parts to such definitions - three parts that are equivalent to the real-world services provided by "white pages," allowing address and contact information to be discovered; "yellow pages," allowing categorizations; and "green pages," exposing technical information about services that are being exposed.
All of this information is maintained within the UDDI registry on the Web. UDDI defines the XML standards allowing developers to register information within the registry and to discover and use information stored within the registry.
In a typical scenario using UDDI, one party registers information about the Web services supported in a system. The information is added to the UDDI registry through a Web site or by using tools that make use of the programmatic APIs defined by the UDDI specification. The UDDI registry is logically one database, but physically may be (and most probably is) distributed through sets of physical registries (after all, it has to scale well). UDDI doesn't focus on the discovery stage per se, and doesn't mean to replace search engines and portals. It merely defines the structure through which such programs can look up information.
Technically, UDDI consists of an XML Schema (XSD) for SOAP messages and a definition of APIs for performing the UDDI operations. The schema definitions allow a programmer to define business information, service information, binding information, and information about specifications for services.
Business information takes the form of the businessEntity elements that support "yellow pages" taxonomies so that searches can be performed. Substructures of the businessEntity element also define the information required to support "green pages" type functions.
Service information is described by the businessService element. Such elements are higher level elements. Within each one of the businessService elements, many Web service descriptors can exist. Such an element allows segmentation and categorization at a higher level. The bindingTemplate element allows programmers to provide information about the addresses through which a Web service can be contacted.
A businessEntity structure typically represents information about a business as well as the services it offers. This includes the business name, a unique identifier for the business, a description of the business entity, contact information, and, in particular, the list of businessServices supported.
A businessService has a name and a description, a unique key, and, most important, the list of bindingTemplates. The bindingTemplate also has a set of descriptors as well as a required element called accessPoint that describes the endpoint access. This element also points at the tModel entity that defines the actual technical fingerprint of the service.
In terms of the UDDI API itself, it's a SOAP-based API, meaning that every invocation takes the form of a SOAP message. The requests typically define which function is requested. This is passed to a UDDI registry provider that replies with a SOAP document. The API consists of more than 30 SOAP messages that can be partitioned into three groups:
The world of software technologies is a constantly changing one, making it exciting and full of pitfalls at the same time. We're constantly discovering that emerging technologies mean we have to constantly update our skills. Sometimes it's fun; at other times it's frustrating and difficult. In fact, it's all too easy to just give up on one of these technology waves. Well, don't let go of this one: SOAP, WSDL, and UDDI hold too much promise and are quickly becoming the cornerstone of too many jobs. Take my advice: learn them and implement them.
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads