Well Defined Service
Submissions to the W3C (http://www.w3.org/2001/03/WSWS-popa/paper51) have described a stack of Web services description standards that describe various aspects of a Web service. Details based on this stack are depicted in Figure 6.2.
The layers of the service description stack can be divided into two broad groups: functional layers and non-functional layers. The bottom three layers are functional in nature, in that they describe details of how the Web service is invoked, where it is invoked, and so on. The upper layers are non-functional, or non-operational in nature, in that they do not directly inform the mechanisms of invocation, but rather provide other details that influence whether a service requestor would choose to invoke the Web service.
The bottom, functional layers of the service description stack define the interface definition language (IDL) equivalent of the service description. The interface description language layers for Web service description serve the same function as IDLs in other distributed computing approaches (see the section "History of IDLs"). Let's examine the relationships between these layers. Fundamentally, it is the functional description of the Web service that determines what the service requestor needs to do in order to invoke a Web service.
Like most things in Web services, XML is at the basis of service description. XML is the type definition that is exploited, by default, in the service implementation and service interface definition layers of the stack. As we saw in Chapter 3, "Simple Object Access Protocol (SOAP)," XML describes the datatypes for the elements that flow within the SOAP message, and in particular, within the SOAP payload, which need to be formatted by the service requestor and interpreted by the service provider. Much of the effort within a Web services infrastructure goes into properly encoding and decoding XML elements to/from native programming language objects.
The service implementation definition and the service interface definition both use the Web Services Description Language (WSDL) standard. We will describe the WSDL language in more detail later in this chapter in the "Web Services Definition Language (WSDL)" section.
The service implementation definition describes where the service is located, or more precisely, to which network address the message must be sent in order to invoke the Web service.
The service interface definition describes exactly what message needs to be sent and how to use the various Internet standard messaging protocols and encoding schemes in order to format the message in a manner acceptable to the service provider.
What do we mean by the term non-functional description? Basically, these layers can be characterized in contrast to the functional layers. Whereas the functional layers describe where to send the message, what the message syntax needs to look like, and how to use the protocols and encoding schemes, the non-functional description addresses why a service requestor should invoke the Web service—for example, what business function the Web service addresses and how it fits into a broader business process. A non-functional description also gives more details about who the service provider is. For example, does the service provider provide auditing and ensure privacy?
As we will examine in Chapter 7, the UDDI service registry also has impact on the certain non-functional aspects of the service description. In particular, the taxonomy scheme supported by UDDI is another mechanism by which a service provider can describe what kind of service is being provided and what business function it supports.
The Web Services Flow Language (WSFL) is one technique to describe how a collection of Web services can be arranged or orchestrated into a higher level business process. WSFL addresses items like the proper order in which to invoke a set of Web services. Essentially, WSFL describes how these individual Web services fit into a bigger picture, such as a business process or a multi-party, multi-operation long running transaction.
Another approach, developed by Microsoft, is the XLANG language, part of the .NET initiative (http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm). A third approach, Business Process Markup, sponsored by a consortium (BPMI, http://www.bpmi.org/bpml-spec.esp) also exists in the marketplace. To date, none of these approaches has emerged as a dominant standard in this space.
Currently, most of the work has been devoted to establishing and evolving the IDL-level of the service description stack. The WSDL approach has only recently been established, and it continues to gain adoption with better runtime support and tooling support from multiple vendors and use by developers.
The standards related to the non-functional description are still in their infancy. WSEL is only briefly mentioned as part of the WSFL specification. There is no other publicly available information on WSEL. The same is true for aggregation/orchestration; WSFL itself remains as a proposal in the area, and has yet to undergo the rigors of submission and modification through an open standards body such as the W3C. We expect that standards in these layers of the service description stack will continue to evolve and mature.
To summarize, a Web service is described using a combination of techniques. A Web service's description is used to unambiguously answer several questions about the Web service. These questions and how they are addressed are summarized in Table 6.1.
For the remainder of this chapter, let's focus on the use of the WSDL standard as the functional description of a Web service. Toward the end of the chapter, in the "Web Services Endpoint Language (WSEL)" section, we will briefly revisit the non-functional layers of the service description stack.