Web Services Architecture


Let's observe the Web services architecture in the context of a distributed computing environment. 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. There are two important actors in the SOAP model. One actor is the network node that plays the role of requestor, which might be a Web service executing on a network computer (node) requesting the service of another Web service. The other actor is another network node that plays the role of a provider: this is a Web service executing on a network computer (node) providing the service. Note that a provider of a service may in turn make several requests to other providers to complete a request; by the same token the requestor of a Web service could be a Web service trying to satisfy other requests. So a Web service may play the role of both the provider and the requester. Since SOAP messages are represented in XML, there has to be some mechanism on both the client and the server side to build and/or parse a SOAP message. These functions in most cases can be provided by a SOAP server running in an HTTP server. The SOAP server implements the functionality expressed by the SOAP specification. Given this summary, a service-oriented architecture of Web services environment is illustrated in Figure 8-1.

click to expand
Figure 8-1: Service-oriented architecture: peer-to-peer pattern

Figure 8-1 illustrates Web-service1 hosted in a SOAP server and running in an HTTP server at http://www.business1.com. Web-service2 is hosted in a SOAP server running in an HTTP server at http://www.business2.com. The UDDI services are also exposed as Web services according to the UDDI standards, but for simplicity's sake we do not show this in the diagram.

The following discussion summarizes this architecture by tracing a request-response transmission between the requestor (assuming Web-service1 is in the role of the requestor) and the provider (assuming Web-service2 is in the role of the provider) of Figure 8-1. The service requestor could very well be a requestor that may not be a Web service, however, to demonstrate a service-centric architecture we assume that several Web services may need to interact for fulfilling the original service request.

  1. Web-service1 (the requestor) creates a SOAP message that invokes the operation exposed by Web-service2 (the provider). The XML payload in the body of the message can be a RPC-style or a document-style message. We discuss these two styles of messaging when discussing WSDL in the section "Introduction to Web Services Description Language." The Web-service1 presents this message together with the network address of the Web-service2 to the SOAP infrastructure (SOAP client runtime). The SOAP client runtime interacts with an underlying network protocol (such as HTTP) to send the SOAP message over the network. The network infrastructure delivers the message to Web-service2's SOAP runtime which is the SOAP server.

  2. The SOAP server routes the request message to Web-service2. The SOAP runtime is responsible for converting the XML message into programming language–specific objects if required by the Web-service2 implementation. This conversion is governed by the encoding schemes specified within the message. Web-service2 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 Web-service1 as the destination.

  3. The response message is received by the networking infrastructure on the Web-service1's node. The message is routed through the SOAP infrastructure; the SOAP runtime will potentially convert the XML message into objects corresponding to the target programming language, that is the implementation language of Web-service1.

  4. The response message is then presented to the Web-service1.

In this architecture, the granularity is at the service level and not the object or component level; component in this context means EJB, .NET, CORBA, or Java bean components and objects that are not executable entities unless they are packaged, according to their component model, into a coarser-grained entity known as a container; the containers ultimately execute in their respective application servers (J2EE, .NET, CORBA). From granularity perspective, a Web service is analogous to a container. Services are the entities known at the network level (distribution) that expose their public interfaces as contracts to the outside world. Interacting services can be hosted on any operating system platform and can be implemented in any programming language.

SOAP provides semantic constructs like the SOAP Header element, which adds more flexibility to this service-oriented architecture. For example, using the flexibility and extensibility of XML, a Header element can be modified by an intermediary service along the message path and passed to the next service. The semantics of header entries are only known between the sender and the receiver, a receiver cannot forward the Header element to the next application in the SOAP message path; however, the recipient may insert a similar Header element but in that case, the contract is between that application and the recipient of the Header element. The header entries assist in adding extra semantics to the message being delivered. For example, a Header element may provide a transaction ID that is not part of the application code but instead part of an infrastructure component; by adding a header entry with a transaction ID, the transaction manager on the receiving side can extract the ID and use it without affecting the SOAP construct that represents a remote procedure call. Therefore, the header part of a message can include information pertinent to extended Web services functionality, such as transaction context, security, orchestration information, or message routing information.

Figure 8-1 showed the software agents participating in the basic architecture. The Web Services Architecture document specifies an extended architecture that describes Web services support for message exchange patterns (MEPs) that group basic messages into higher-level interactions, details how support for features such as security, transactions, orchestration, privacy, and others may be represented in SOAP messages, and describes how additional features can be added to support business-level interactions.

In a service-oriented architecture, many different kinds of interactions between service requester and service provider are possible. One-way interaction is comprised of a message sent from a requestor to a provider, Conversational interaction comprises several messages exchanged between a requestor and a provider, and Many-to-Many interaction comprises a message sent from a requestor to many providers, or a service provider responds to many requestors. These interactions can be defined by a choreography language. More information is available at http://www.w3.org/TR/ws-arch.




Practical J2ee Application Architecture
Practical J2EE Application Architecture
ISBN: 0072227117
EAN: 2147483647
Year: 2003
Pages: 111
Authors: Nadir Gulzar

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