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:
- 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?
- 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:
- What categories of information do we need to know about the
wire-level representation of Web services?
- 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.
