Welcome!

Simeon Simeonov

Subscribe to Simeon Simeonov: eMailAlertsEmail Alerts
Get Simeon Simeonov via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: XML Magazine

XML: Article

Web Services Description Language

Web Services Description Language

In "The Interoperability Stack" (XML in Transit, Vol. 2, issue 1), I presented my view of the Web service interoperability stack, a layered architecture for analyzing the different technologies involved at various levels of interoperability (see Figure 1). Here we begin our climb up from the basic Web service-layer toward the top of the stack, with a look at the leading specification for service descriptions, the aptly named Web Services Description Language (WSDL).

Let's face it, the Internet is an arena of concealed creative madness. Under the relatively quiet and pristine cover of traditional B2C interactions (your typical entertainment sites and e-commerce storefronts) hides the raging pit of B2B computing. B2C applications are relatively mature. The technology is well understood on both client and server sides. The leaders in B2C are risk-averse in the way they evolve both the look and feel of their applications (how long did it take amazon.com to rev up the look of their site?) and in the client technologies they choose (sorry, can't use DHTML because of browser interoperability issues).

On the other hand, the B2B space is still in its creation period. Prefunding start-ups join successful post-IPO companies and enterprise gorillas of all sizes in a mad rush to lay claim to valuable pieces of B2B property. Many new horizontal and vertical specifications emerge every month, and there are probably more recent registrations of XML WhateverConsortia.org than there are of good old dot-coms.

The Need for Service Descriptions
Okay, I'm exaggerating a little. The basic premise is true, though: fueled by customer and competitive pressures to innovate quickly, companies in the B2B space are rapidly expanding the horizon of what's possible. There are exciting new ways to connect all business participants - end users, buyers, suppliers, and aggregators and value-add service providers. This innovation brings great value and presents an incredible opportunity for companies of all sizes. At the same time, however, innovation with little coordination creates an integration challenge that, if left unattended, has the potential to limit our ability to fully leverage the true power of the Net economy.

Broadly horizontal Web service specifications such as SOAP and W3C's XML Protocol (XP) offer the promise of standardizing the basic mechanisms for accessing B2B capabilities: formulating messages, encoding and packaging data, receiving responses, and handling errors. However, much more is needed to provide true interoperability. Describing Web services is the first step in that direction.

Web service descriptions specify the shared knowledge that must exist between a Web service user and a provider of that service for a successful interaction to take place. SOAP and XP don't address this problem; they only define a wire-level specification of Web services. You can't use SOAP to answer the questions, "How should I format a SOAP message so I can make a stock quote request to e-trade?" or "What will be the format of the response message?" or even "Where should I send the stock quote requests (i.e., what is e-trade's Web service entry point)?"

Of course, you can't use any service without answers to these types of questions. Traditionally, this information was - and still is - provided in some human-readable form, for example, as HTML on a service provider's Web site or in its technical documentation. An engineer would have to read these specifications, then manually configure a particular application to access a particular ser- vice. Clearly, this approach isn't scalable with respect to both the number of services and the sophistication of B2B applications. What's needed is a formal mechanism suitable for machine consumption for describing how to access Web services.

WSDL 1.0 serves precisely that purpose. It emerged as a result of a merger of several revisions of thinking between Ariba, IBM, and Microsoft (Service Control Language [SCL], Service Description Language [SDL], Network Accessible Service Spec- ification Language [NASSL]). Broadly speaking, there are two areas of Web service capability that merit formal specification:

  1. Technical
    • Low-level: Where is a service located; what protocol should we use to communicate with it; what is the format of communication messages?
    • High-level: What are the sequencing rules for messages; how can services be composed to become higher-level?
  2. Business
    • What are the quality of service (QoS) guarantees; when is a service available; what are the business rules for accessing services?
WSDL 1.0 is squarely focused on low-level technical descriptions. Future versions of the specification plan to address higher-level technical issues. Business-level descriptions are outside the scope of WSDL, at least at this time.

The What, How, and Where of Web Services
The crux of comprehending WSDL is understanding two key concepts:

  1. What categories of information do we need to know about the wire-level representation of Web services?
  2. What is the model by which this information should be exposed?
The answers to these questions are simple but not without their subtleties. We can make an initial guess about the categories of information we need to be concerned about by identifying variability points at the levels of the interoperability stack under service description. A simple list could look something like this:
  • Communication protocol
    - Protocol type
    - Address of communication point
  • Data representation
    - Encoding of payload data
    -Encoding of protocol payload wrapper
  • Data format specification
    - Format of payload data
    - Format of protocol payload wrapper
  • Web services
    - Protocol type
    - Interaction pattern
    - Message descriptions
    - Header/body specification
    - Error-handling (fault) specification
This quick inventory of variability points shows that we need a lot of information to describe Web services. The good news is that none of it is overly complex, and we have existing specifications for addressing most of the individual pieces. We can easily identify common protocols by name, we can use URIs for addresses, XML Schema will generally cover most XML-based data format descriptions, and so on. The bad news is that the exercise of going through the layers of the interoperability stack gives us no direction about how to organize this information for maximum flexibility and reuse.

To address this issue, we have to ask ourselves the "what, how, and where" of Web services. Let's start with a real-life example. Consider a scenario in which you'd like to pay your credit card bill. You can do it two ways: (1) via your credit card company, or (2) via your bank. In both cases you'll need to provide the credit card account and the payment amount. Further, in the first case you'll have to provide some method of payment, such as a bank account number. In the latter case, you'll have to provide the address of the credit card company. Both approaches offer different ways to get the job done. You can call on the phone, go to a Web site, and, in the case of your bank, go to one of their ATM machines that offer bill payment capabilities. Finally, you have to choose where you'll go to complete the transaction because, for example, there are multiple ATM machines you can pick from. Table 1 gives an example summary of your options.

What emerges from this table is the realization that looking at the problem from a what-how-where perspective establishes an information hierarchy with three one-to-many relationships. By asking what you want to do to solve a problem, you discover alternative approaches. By asking how you can execute any one of them, you realize that there can be more than one way of doing the same thing. In this case you have to provide the same information to your bank whether you pay by phone, the Web, or an ATM. However, the way you access the bank system and the way you provide the information to it are very different indeed. Finally, you can access the same service in the same way at multiple locations. In the example you can pay at any of the available ATMs.

The lesson learned is that the best way to enable flexibility and the potential for reuse when describing a service is to separate the notions of what we want to do, how we want to do it, and where we want to get it done. To put this back in tech-speak, we can say that we want to separate the abstract specification of a service from the details of the service implementation and the locations where this particular type of implementation is available (see Figure 2). This is precisely what WSDL does for Web services.

WSDL Information Model
The WSDL information model takes full advantage of the separation between abstract specifications, specific implementations of these specifications, and the locations of the implementations. In WSDL, a capability is exposed by the notion of an abstract endpoint (note that this is not the exact WSDL terminology; we'll get to that in a moment). The description of the endpoint's capabilities is the abstract specification. A binding mechanism is used to map this to a specific implementation using a particular Web service protocol, data encoding model, and underlying communication protocol. When the binding is combined with an address where the implementation can be accessed, the abstract endpoint has become a concrete endpoint that your applications can actually talk to. If you think back to the credit card payment example and consider the Web service capabilities exposed by your bank, you can think of the payment system as an endpoint.

An endpoint can support any number of operations. In the payment system's case these could be actions such as payBill, checkBill, and registerPayee. An operation is defined by the set of messages that define its interaction pattern. For example, the payBill operation has an input message that constitutes the payment request and an output message that returns information on whether the payment has been successfully scheduled. Optionally, the bank payment system can respond with a fault message in the case of an error. Messages have any number of parts that contain data of a particular type. In the case of the payBill operation its input message may contain a part called "body" whose type is identified as that of the element paymentInfo in the bill payment XML Schema of your bank.

For the abstract concepts of message, operation, and endpoint, there are concrete counterparts specified during the binding process. Since WSDL doesn't address the problem of specifying types and can allow any type specification grammar (such as DTDs, XML Schema, or something completely different) to be used, it's best not to apply the abstract/ concrete view to message parts and the types in them.

Figure 3 shows one possible view of the organization of the WSDL information model. You can see a clear relationship between the abstract and concrete notions of message, operation, and endpoint linked by a binding. The relationships in the diagram mean "is defined in terms of." The diagram connectors with gray dots at their ends are used to denote the fact that an element may be defined in terms of potentially many other elements, as is the case with messages that have more than one part (consider an auto insurance accident claim message with one part describing the claim and any number of other parts containing images of the accident).

The diagram introduces a new concept - that of a service. (Thank you for patiently waiting for the definition of the "S" part of WSDL.) A service is defined as a collection of concrete endpoints. In the example we've used so far your banking service can be defined by the collection of concrete endpoints for bill payment, account management, loan applications, and so on.

The boldfaced words on the diagram signify the terms the WSDL specification uses to refer to the concepts we've discussed so far. Honestly, I find the terms somewhat confusing because there's no consistent naming convention that allows the reader to distinguish between abstract and concrete concepts. WSDL does this for endpoints, the abstract ones called port types, and the concrete ones called simply ports. I think this is a fine convention to use. Trouble is, it's not observed for operation and message, where only the context can help you distinguish whether you're referring to the abstract or the concrete (bound) concepts.

I can't stress enough how important it is to be very clear about WSDL's information model; everything else just falls into place after that. The overloaded terminology in the specification doesn't help. At the risk of some further confusion - but with the best of intentions - I present Table 2, a quick reference to possible language mappings of the abstract versus concrete concepts we've discussed so far.

Transmission Primitives
One of the things that WSDL has to help with is the specification of Web service interaction patterns. WSDL 1.0 doesn't deal specifically with high-level interaction patterns that define the behavior of services (the sequencing rules for sending and receiving messages). However, the specification does define four endpoint message transmission primitives that can be useful in a variety of settings:

  • One-way: Where the endpoint re- ceives a message sent to it
  • Notification: The inverse of one-way - the endpoint sends a message
  • Request-response: Where the endpoint sends a response message that's correlated with the request message
  • Solicit-response: The inverse of request-response - the endpoint sends a message and receives a correlated message
This is an interesting choice of primitives. Having notification and solicit-response makes the logistical support of one-to-many interaction patterns easy. Consider a stock price notification capability exposed by your favorite financial company. Without these built-in primitives, any application that wishes to receive notifications will have to expose a WSDL spec defining its one-way stock price notification destination endpoint. Even if the financial company provides the core WSDL specification, all service subscribers will have to maintain a slightly modified version with their specific port (at some specific address). Allowing the endpoint to initiate communications eliminates the WSDL management hassles. Of course, you'll still have to tell the endpoint where to communicate to, but there's no need to maintain more than one WSDL document.

Similarly, although request-response and solicit-response can be modeled using two one-way messages, it's much better to have these transmission patterns built into the specification because they're commonly used. Treating them as primitives promotes simplicity and efficiency. For example, it's trivial to efficiently map request-response interactions on top of HTTP requests and responses. To get the same efficiency without the request-response primitive will require providing a lot of additional information, so it's clear that the first of the one-way messages can be mapped onto the HTTP request and the second onto the HTTP response.

In the WSDL specification the four transmission primitives are identified by the sequencing of input and output messages for any given operation, as shown in Figure 4. For example, an input message followed by an output message defines request-response. In cases where responses are allowed it's also possible to define any number of fault messages that can be used to communicate error-handling information to the endpoint that initiates the interaction.

For now, don't worry about the details of the WSDL XML. We'll take a look at that in next month's XML in Transit, when we'll focus on the WSDL schema, the binding mechanism, and the particular bindings to SOAP 1.1, HTTP, and MIME. Trust me, it will all make perfect sense, given that you're now armed with a good understanding of the WSDL information model and the supported transmission primitives.

More Stories By Simeon Simeonov

Simeon Simeonov is CEO of FastIgnite, where he invests in and advises startups. He was chief architect or CTO at companies such as Allaire, Macromedia, Better Advertising and Thing Labs. He blogs at blog.simeonov.com, tweets as @simeons and lives in the Greater Boston area with his wife, son and an adopted dog named Tye.

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.