SDN Journal Authors: Destiny Bertucci, Liz McMillan, Pat Romanski, Elizabeth White, Amitabh Sinha

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
In his Opening Keynote at 21st Cloud Expo, John Considine, General Manager of IBM Cloud Infrastructure, led attendees through the exciting evolution of the cloud. He looked at this major disruption from the perspective of technology, business models, and what this means for enterprises of all sizes. John Considine is General Manager of Cloud Infrastructure Services at IBM. In that role he is responsible for leading IBM’s public cloud infrastructure including strategy, development, and offering m...
With tough new regulations coming to Europe on data privacy in May 2018, Calligo will explain why in reality the effect is global and transforms how you consider critical data. EU GDPR fundamentally rewrites the rules for cloud, Big Data and IoT. In his session at 21st Cloud Expo, Adam Ryan, Vice President and General Manager EMEA at Calligo, examined the regulations and provided insight on how it affects technology, challenges the established rules and will usher in new levels of diligence arou...
The past few years have brought a sea change in the way applications are architected, developed, and consumed—increasing both the complexity of testing and the business impact of software failures. How can software testing professionals keep pace with modern application delivery, given the trends that impact both architectures (cloud, microservices, and APIs) and processes (DevOps, agile, and continuous delivery)? This is where continuous testing comes in. D
Modern software design has fundamentally changed how we manage applications, causing many to turn to containers as the new virtual machine for resource management. As container adoption grows beyond stateless applications to stateful workloads, the need for persistent storage is foundational - something customers routinely cite as a top pain point. In his session at @DevOpsSummit at 21st Cloud Expo, Bill Borsari, Head of Systems Engineering at Datera, explored how organizations can reap the bene...
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 f...
The dynamic nature of the cloud means that change is a constant when it comes to modern cloud-based infrastructure. Delivering modern applications to end users, therefore, is a constantly shifting challenge. Delivery automation helps IT Ops teams ensure that apps are providing an optimal end user experience over hybrid-cloud and multi-cloud environments, no matter what the current state of the infrastructure is. To employ a delivery automation strategy that reflects your business rules, making r...
The 22nd International Cloud Expo | 1st DXWorld Expo has announced that its Call for Papers is open. Cloud Expo | DXWorld Expo, to be held June 5-7, 2018, at the Javits Center in New York, NY, brings together Cloud Computing, Digital Transformation, Big Data, Internet of Things, DevOps, Machine Learning and WebRTC to one location. With cloud computing driving a higher percentage of enterprise IT budgets every year, it becomes increasingly important to plant your flag in this fast-expanding busin...
In a recent survey, Sumo Logic surveyed 1,500 customers who employ cloud services such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). According to the survey, a quarter of the respondents have already deployed Docker containers and nearly as many (23 percent) are employing the AWS Lambda serverless computing framework. It’s clear: serverless is here to stay. The adoption does come with some needed changes, within both application development and operations. Tha...
SYS-CON Events announced today that Synametrics Technologies will exhibit at SYS-CON's 22nd International Cloud Expo®, which will take place on June 5-7, 2018, at the Javits Center in New York, NY. Synametrics Technologies is a privately held company based in Plainsboro, New Jersey that has been providing solutions for the developer community since 1997. Based on the success of its initial product offerings such as WinSQL, Xeams, SynaMan and Syncrify, Synametrics continues to create and hone in...
Smart cities have the potential to change our lives at so many levels for citizens: less pollution, reduced parking obstacles, better health, education and more energy savings. Real-time data streaming and the Internet of Things (IoT) possess the power to turn this vision into a reality. However, most organizations today are building their data infrastructure to focus solely on addressing immediate business needs vs. a platform capable of quickly adapting emerging technologies to address future ...
In his general session at 21st Cloud Expo, Greg Dumas, Calligo’s Vice President and G.M. of US operations, discussed the new Global Data Protection Regulation and how Calligo can help business stay compliant in digitally globalized world. Greg Dumas is Calligo's Vice President and G.M. of US operations. Calligo is an established service provider that provides an innovative platform for trusted cloud solutions. Calligo’s customers are typically most concerned about GDPR compliance, application p...
Kubernetes is an open source system for automating deployment, scaling, and management of containerized applications. Kubernetes was originally built by Google, leveraging years of experience with managing container workloads, and is now a Cloud Native Compute Foundation (CNCF) project. Kubernetes has been widely adopted by the community, supported on all major public and private cloud providers, and is gaining rapid adoption in enterprises. However, Kubernetes may seem intimidating and complex ...
In his session at 21st Cloud Expo, Michael Burley, a Senior Business Development Executive in IT Services at NetApp, described how NetApp designed a three-year program of work to migrate 25PB of a major telco's enterprise data to a new STaaS platform, and then secured a long-term contract to manage and operate the platform. This significant program blended the best of NetApp’s solutions and services capabilities to enable this telco’s successful adoption of private cloud storage and launching ...
You know you need the cloud, but you’re hesitant to simply dump everything at Amazon since you know that not all workloads are suitable for cloud. You know that you want the kind of ease of use and scalability that you get with public cloud, but your applications are architected in a way that makes the public cloud a non-starter. You’re looking at private cloud solutions based on hyperconverged infrastructure, but you’re concerned with the limits inherent in those technologies.
Nordstrom is transforming the way that they do business and the cloud is the key to enabling speed and hyper personalized customer experiences. In his session at 21st Cloud Expo, Ken Schow, VP of Engineering at Nordstrom, discussed some of the key learnings and common pitfalls of large enterprises moving to the cloud. This includes strategies around choosing a cloud provider(s), architecture, and lessons learned. In addition, he covered some of the best practices for structured team migration an...
Most technology leaders, contemporary and from the hardware era, are reshaping their businesses to do software. They hope to capture value from emerging technologies such as IoT, SDN, and AI. Ultimately, irrespective of the vertical, it is about deriving value from independent software applications participating in an ecosystem as one comprehensive solution. In his session at @ThingsExpo, Kausik Sridhar, founder and CTO of Pulzze Systems, discussed how given the magnitude of today's application ...
The “Digital Era” is forcing us to engage with new methods to build, operate and maintain applications. This transformation also implies an evolution to more and more intelligent applications to better engage with the customers, while creating significant market differentiators. In both cases, the cloud has become a key enabler to embrace this digital revolution. So, moving to the cloud is no longer the question; the new questions are HOW and WHEN. To make this equation even more complex, most ...
As you move to the cloud, your network should be efficient, secure, and easy to manage. An enterprise adopting a hybrid or public cloud needs systems and tools that provide: Agility: ability to deliver applications and services faster, even in complex hybrid environments Easier manageability: enable reliable connectivity with complete oversight as the data center network evolves Greater efficiency: eliminate wasted effort while reducing errors and optimize asset utilization Security: imple...
Mobile device usage has increased exponentially during the past several years, as consumers rely on handhelds for everything from news and weather to banking and purchases. What can we expect in the next few years? The way in which we interact with our devices will fundamentally change, as businesses leverage Artificial Intelligence. We already see this taking shape as businesses leverage AI for cost savings and customer responsiveness. This trend will continue, as AI is used for more sophistica...
In his session at 21st Cloud Expo, Raju Shreewastava, founder of Big Data Trunk, provided a fun and simple way to introduce Machine Leaning to anyone and everyone. He solved a machine learning problem and demonstrated an easy way to be able to do machine learning without even coding. Raju Shreewastava is the founder of Big Data Trunk (www.BigDataTrunk.com), a Big Data Training and consulting firm with offices in the United States. He previously led the data warehouse/business intelligence and B...