SDN Journal Authors: Liz McMillan, Yeshim Deniz, Elizabeth White, Pat Romanski, TJ Randall

Related Topics: Industrial IoT

Industrial IoT: Article

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

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.

SOAP Messaging
Listing 1 shows a SOAP message for creating a service order within the ViryaNet Service Hub. The scenario in which such a document would be used is one in which an external system sends a message to the Service Hub - specifically, to the workforce management system. The external system can be a provisioning system or a trouble-ticket management system in the telecommunications industry, or a help-desk system or call-center system in other verticals.

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 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 is an XML format for describing services on the Web. It views a service as a set of endpoints that communicate by passing XML documents or through an invocation paradigm. WSDL describes services both abstractly and as a concrete implementation. Since WSDL follows the same general pattern as SOAP, the WSDL specification describes how it can be used in a SOAP environment. While WSDL is not limited to use with SOAP, and is protocol and platform agnostic, people writing software that conforms to WSDL are probably using SOAP.

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:

  • Types that define the data types used in the messages
  • Messages that logically define what is transmitted between the endpoints
  • Port types that specify the abstraction of the operation
  • Bindings that define the concrete protocol and data format
  • Ports that specify the address for the binding
  • And finally, the service definition itself that aggregates all of the above
Types in WSDL are XML Schema types. Messages consist of one or more logical parts, each one having a type. Message parts have a name and an element; the element attribute specifies a type that is defined in the document. Messages, therefore, define the abstractions in terms of the data types used in communication between the two systems. A port type is a named set of abstract operations and messages. Each port type has a name and some optional attributes, such as an attribute that defines if the endpoint can support one-way, request-response, solicit-response, and notification-type communications.

If the port type defines a one-way operation, the definition will take the form:

<wsdl:operation name="createCall">
<wsdl:input .../>
If the port type defines a request-response or a solicit-response operation, the definition will take the form:

<wsdl:operation name="createCall">
<wsdl:input ... />

<wsdl:output ... />
<wsdl:fault ... />
If the port type defines a notification operation, the definition will take the form:

<wsdl:operation name="createCall">
<wsdl:output .../>
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 ... >
<soap:binding ... />
In the same way, when an operation is defined using the SOAP extension, the operation takes the form:

<operation ... >
<soap:operation soapAction="..." />
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.

UDDI defines a way to publish and discover information about Web services. It defines infrastructure that's mandatory for the development of e-commerce, collaborative marketplaces, and the like. It's a tool for developers and designers more than anything else, and helps standardize how services can be defined and discovered. Thus it complements WSDL and SOAP in the sense that it's fairly logical to see the definitions themselves defined in WSDL, activated using SOAP, but registered and discovered using UDDI.

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:

  1. Browse APIs: These APIs find elements and the information associated with entries in a UDDI registry. This category consists of find_xx APIs.
  2. Drill-down APIs: The elements in a UDDI registry are organized in hierarchies. Once we can find elements using the find_xx APIs, we can further navigate the hierarchy using get_xx APIs.
  3. Publishing APIs: These allow programmers and systems to manage information stored in a UDDI registry.
Final Word
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.

More Stories By Ron Ben-Natan

Ron Ben-Natan is Chief Technology Officer at ViryaNet Inc. Prior to that he worked for companies such as Intel, AT&T Bell Laboratories, Merrill Lynch and as a consultant at J.P. Morgan. He has a Ph.D. in Computer Science in the field of distributed computing and has been architecting and developing distributed applications for over 15 years. His hobby is writing about how technology is used to solve real problems and he has authored numerous books including “IBM WebSphere Application Server: The Complete Reference” published by Osborne/McGraw. He can be reached at

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

CloudEXPO Stories
Nutanix has been named "Platinum Sponsor" of CloudEXPO | DevOpsSUMMIT | DXWorldEXPO New York, which will take place November 12-13, 2018 in New York City. Nutanix makes infrastructure invisible, elevating IT to focus on the applications and services that power their business. The Nutanix Enterprise Cloud Platform blends web-scale engineering and consumer-grade design to natively converge server, storage, virtualization and networking into a resilient, software-defined solution with rich machine intelligence.
Intel is an American multinational corporation and technology company headquartered in Santa Clara, California, in the Silicon Valley. It is the world's second largest and second highest valued semiconductor chip maker based on revenue after being overtaken by Samsung, and is the inventor of the x86 series of microprocessors, the processors found in most personal computers (PCs). Intel supplies processors for computer system manufacturers such as Apple, Lenovo, HP, and Dell. Intel also manufactures motherboard chipsets, network interface controllers and integrated circuits, flash memory, graphics chips, embedded processors and other devices related to communications and computing.
Digital transformation is about embracing digital technologies into a company's culture to better connect with its customers, automate processes, create better tools, enter new markets, etc. Such a transformation requires continuous orchestration across teams and an environment based on open collaboration and daily experiments. In his session at 21st Cloud Expo, Alex Casalboni, Technical (Cloud) Evangelist at Cloud Academy, explored and discussed the most urgent unsolved challenges to achieve full cloud literacy in the enterprise world.
Wasabi is the hot cloud storage company delivering low-cost, fast, and reliable cloud storage. Wasabi is 80% cheaper and 6x faster than Amazon S3, with 100% data immutability protection and no data egress fees. Created by Carbonite co-founders and cloud storage pioneers David Friend and Jeff Flowers, Wasabi is on a mission to commoditize the storage industry. Wasabi is a privately held company based in Boston, MA. Follow and connect with Wasabi on Twitter, Facebook, Instagram and the Wasabi blog.
Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to advisory roles at startups. He has worked extensively on monetization, SAAS, IoT, ecosystems, partnerships and accelerating growth in new business initiatives.