To ensure interoperability when performing the publish, find and bind operations expressed in the SOA diagram; conceptual and technical standards must be defined for each role and type of interaction. This section will explore each of roles and interactions in order identify each relevant stack of technologies.
There are over arching concerns involving security, management and quality of services that must be addressed at each layer in the conceptual and technical stacks. The various solutions at each layer may or may not be independent of one other. More of these overarching concerns will emerge as the web services paradigm is adopted and evolved. What is most important is building a framework through which all such concerns may be applied to each of the layers in the stack so that as new concerns emerge they may be dealt with flexibly and consistently.
At the end of this section we assemble the independent stacks into a single stack where each additional layer builds upon the capabilities provided by those below it. The vertical towers represent the variety of over arching concerns that must be addressed at every level of each of the stacks.
An important point is that, towards the bottom layers of the stack, the technologies and concepts are relatively more mature and achieve a higher level of standardization than many of the upper layers. The maturation and adoption of Web services will drive the continued development and standardization of the higher levels of the stack and the overarching concerns.
The wire stack encapsulates the concepts and technologies dealing with the actual physical exchange of information between any of the roles in the SOA diagram. This includes the variety network transport, message packaging and message extensions that may be utilized to facilitate data exchange.
The foundation of the web services stack is the network. Web services must be network accessible to be invoked by a service requestor. Web services that are publicly available on the Internet use commonly deployed network protocols. Because of its ubiquity, HTTP is the de facto standard network protocol for Internet-available web services. Other Internet protocols may be supported including SMTP and FTP. Intranet domains may use proprietary or platform and vendor specific protocols such as MQSeries, CORBA, etc.. The specific choice of network protocol used in any given scenario depends entirely upon application requirements, including concerns such as security, availability, performance, and reliability. This allows web services to capitalize on existing higher function networking infrastructures and message oriented middleware, such as MQSeries.
Within an enterprise with multiple types of network infrastructures, HTTP can be used as a common, interoperable bridge to connect disparate systems. One of the benefits of web services is that it provides a unified programming model for the development and usage of private Intranet as well as public Internet services. As a result, the choice of network technology can be made entirely transparent to the developer and consumer of the service.
Moving up the Wire stack, the next layer, Packaging, represents the technologies that may be used to package information being exchanged. XML has been broadly adopted as the basis for Web service message packaging protocols. The current industry standard for XML packaging is the Simple Object Access Protocol (SOAP)[SOAP 00]. IBM, Microsoft and others submitted SOAP to the W3C as the basis of the XML Protocol Working Group [XMLP 00]. Once complete, XML Protocol implementations will replace the existing SOAP implementations as the industry standard XML messaging protocol.
SOAP is a simple and lightweight XML-based mechanism for creating structured data packages that can exchanged between network applications. SOAP consists of four fundamental components: an envelope that defines a framework for describing message structure, a set of encoding rules for expressing instances of application-defined data types, a convention for representing remote procedure calls (RPC) and responses, and a set of rules for using SOAP with HTTP. SOAP can be used in combination with a variety of network protocols; such as HTTP, SMTP, FTP, RMI/IIOP or MQSeries.
SOAP is currently the de facto standard for XML messaging for a number of reasons. First, SOAP is relatively simple, defining a thin layer that builds on top of existing network technologies such as HTTP that are already broadly implemented. Second, SOAP is flexible and extensible in that rather than trying to solve all of the various issues developers may face when constructing Web services, it provides an extensible, composable framework that allows solutions to be incrementally applied as needed. Thirdly, SOAP enjoys broad industry and developer community support.
Building on the transport and packaging layers, the final layer in the Wire stack provides a framework that allows additional information to be attached to Web service messages representing a variety of additional concerns; such as context, routing, policy, etc. As a key part of its envelope message structure, SOAP defines a mechanism to incorporate orthogonal extensions to the message in the form of headers and encoding rules. It is expected that as Web services are adopted and evolved, a broad collection of such extensions will emerge and be standardized.
Here is an example of how SOAP, HTTP, and the internet can be used to implement the Wire stack. The following figure shows how XML messaging (SOAP) and network protocols can be used as the basis of the web services architecture.
Figure 1 - XML Messaging using SOAP
The basic requirements for a network node to play the role of requestor or provider in XML Messaging based distributed computing are the ability to build and/or parse a SOAP message and the ability to communicate over a network (receive and/or send messages).
Typically, a SOAP Server running in a web application server performs these functions. Alternatively, a programming language-specific runtime library can be used that encapsulates these functions within an API. Application integration with SOAP can be achieved by using four basic steps:
· In the Figure 1 above at (1), a service requestor’s application creates a SOAP message. This SOAP message is the request that invokes the web service operation provided by the service provider. The XML document in the body of the message can be a SOAP RPC request or a document-centric message as indicated in the service description. The service requestor presents this message together with the network address of the service provider to the SOAP infrastructure (e.g. a SOAP client runtime). The SOAP client runtime interacts with an underlying network protocol (e.g. HTTP) to send the SOAP message out over the network.
· The network infrastructure delivers the message to the service provider’s SOAP runtime (e.g. a SOAP server) (2). The SOAP server routes the request message to the service provider's web service. The SOAP runtime is responsible for converting the XML Message into programming language specific objects if required by the application. This conversion is governed by the encoding schemes found within the message.
· The web service is responsible for processing the request message and formulating a response. The response is also a SOAP message. The response SOAP message is presented to the SOAP runtime with the service requestor as the destination (3). In the case of synchronous request/response over HTTP, the underlying request/response nature of the networking protocol is used to implement the request/response nature of the messaging. The SOAP runtime sends the SOAP message response to the service requestor over the network.
· The response message is received by the networking infrastructure on the service requestor’s node. The message is routed through the SOAP infrastructure; potentially converting the XML message into objects in a target programming language (4). The response message is then presented to the application.
This example uses the request/response transmission primitive that is quite common in most distributed computing environments. The request/response exchange may be synchronous or asynchronous. Other transmission primitives such as one-way messaging (no response), notification (push style response), publish/subscribe are possible using SOAP.
One Way:
Message sent from requestor to provider. Provider may or may not return a response. If the provider returns a response, the requester may have already stopped ‘listening’ for it or closed the communications channel. Response will be ‘thrown away’ and not processed by the requester
Conversation:
Requester and Provider exchange multiple messages. Can be defined by choreography language.
Many-to-Many:
Requester sends message to many providers. Or, service provider responds to many requestors. Can be defined by choreography language.