The Web Services Architecture: The Interoperability Stacks


Every architecture needs at least one stack of components (sometimes known as a layered cake). Web services incorporate several different technologies and standards that need to work together.

Software architects in general rely on architecture stacks to define how different technology components work together. Companies that are working on Web services technologies have agreed to define three Web services "interoperability" stacks, first proposed as the Web Services Framework at the W3C Workshop on Web services in April 2001. The three stacks help us make sense of the veritable alphabet soup of Web services-related acronyms. These stacks are as follows:

  • Wire Stack Represents the components that are necessary to transmit messages including data and metadata for service discovery and invocation

  • Description Stack Represents the components that are needed to describe and compose services

  • Discovery Stack Represents the components that are needed for static (design time) or dynamic (runtime) discovery and introspection of services

These stacks have evolved since they were first introduced, and they are still evolving. The stacks are not meant to specify in complete details all the components of an architecture, but to capture the required components for true interoperability, security, and other components, while specifying the current adopted de facto or ratified standards. The next three sections present the current prevailing view of the interoperability stacks. You will see several technologies mentioned in various parts of the stacks. The main technologies (XML, SOAP, WSDL, and UDDI) will be covered in later sections.

The Web Services Wire Stack

The Web Services Wire Stack (see Figure 11.2) represents the components that are needed to transmit a message among the three roles of a generalized SOA in other words, all the components that are required to put data on the wire and ensure that it is retrieved at the other end securely by its intended recipient(s).

Figure 11.2. The Web Services Wire Stack.

graphics/11fig02.gif

At the base of the stack is the network protocol, specifying that different protocols such as HTTP or SMTP can be substituted, increasing the potential for interoperability. This means that the same service can potentially be accessed through different means. The stack goes on to specify that XML should be the data encoding of the messages, and that Simple Object Access Protocol (SOAP) is the preferred messaging protocol. Keep in mind that although SOAP is specified in the Wire Stack, you can deploy Web services that are invoked with other messaging protocols, as long as you describe that protocol somewhere. (That's where WSDL and UDDI come in, as we'll see later.) Finally, the stack specifies that issues of security, reliability, routing, and additional attachments to messages are to be handled as extensions onto XML and SOAP.

The Description Stack

One of the most important aspects of deploying a service is the ability to describe it in a manner that will allow others to locate it, invoke it, and compose it with other services. The Description Stack defines the technologies that serve that purpose (see Figure 11.3). At the base of the stack is XML schema (see the section "XML" later in this chapter) because all description mechanisms are expressed in XML. Another important technology, Web Services Description Language (WSDL), a kind of Interface Definition Language (IDL), allows service interfaces and implementations to be described. Other technologies will allow descriptions of service capabilities and the orchestration of services into workflows.

Figure 11.3. The Web Services Description Stack.

graphics/11fig03.gif

The Discovery Stack

Finally, the right service needs to be located to be used. Two aspects to discovery exist in the Web services architecture. The first aspect is the need for a well-known registry (or set of registries) that provide a search mechanism for services. The other aspect is the need for an introspection capability on services to make sure that the service being selected is the right one. The Discovery Stack (see Figure 11.4) specifies the technologies that enable service requesters to locate and introspect the services they will use.

Figure 11.4. The Web Services Discovery Stack.

graphics/11fig04.gif

The main discovery mechanism is Universal Description, Discovery, and Integration (UDDI), a set of replicated registries with a corresponding API for publishing and querying. As far as introspection mechanisms, the emerging standard seems to be Web Services Inspection Language (WSIL), also referred to as WS-Inspection. WSIL provides a mechanism that complements both WSDL from a description point of view and UDDI from a discovery point of view. It does this by providing a service with the capability of describing itself upon request. Because WSIL is still in the emerging state, we won't cover it in detail in this chapter.



JavaT P2P Unleashed
JavaT P2P Unleashed
ISBN: N/A
EAN: N/A
Year: 2002
Pages: 209

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