Well Defined Service


What makes a good service description? What aspects of the Web service must be described in order for the Web service to be considered sufficiently defined?

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.

Figure 6.2. The service description stack.

graphics/06fig02.gif

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.

Functional Description

The bottom, functional layers of the service description stack define the interface definition language (IDL) graphics/book.gif 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 graphics/book.gif and the service interface definition graphics/book.gif 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.

Non-Functional Description

The IDL level description embodied by the functional description layers of the service description stack is very important, but there is more that should be described about a Web service.

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 servicefor 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?

You can use the Web Services Endpoint Language (WSEL) to describe the environment or endpoint which hosts the Web service. Characteristics of the hosting environment could include the security policy in place at the service provider, what levels of quality of service are available to support Web service invocation, what kind of privacy policy is enforced by the service provider, and so on. At one level, you can think of the non-functional description layers as descriptions of the Web service that do not affect the shape of the SOAP message body. Non-functional descriptions might have some influence on the syntax of the message, related to orthogonal extensions of the message (for example, parameters related to a required security protocol), but the core shape of the payload of the message is derived from the functional description. At this point, WSEL is not a concrete proposal, but rather a vague notion of requirement expressed within the Web services community.

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.

Aggregation/Orchestration Description

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.

Stack Summary

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.

Table 6.1. Roles of Each Layer of the Service Description Stack
Question Where Addressed
Who Non-functional description
What Service interface
Where Service implementation
Why Non-functional description
How Service interface

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.



Building Web Services with Java. Making Sense of XML, SOAP, WSDL and UDDI
Building Web Services with Java: Making Sense of XML, SOAP, WSDL and UDDI
ISBN: B000H2MZZY
EAN: N/A
Year: 2001
Pages: 130

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net