IntroductionWeb services as SOA compliantManifesting services in real world automation solutions requires the use of a technology capable of preserving fundamental service-orientation, while implementing real world business functionality. Web services framework is flexible and adaptable. Web services can be designed to duplicate the behavior and functionality found in proprietary distributed systems, or they can be designed to be fully SOA-compliant. This flexibility has allowed Web services to become part of many existing application environments and has been one of the reasons behind their popularity. It also reveals the fact that Web services are not necessarily inherently service-oriented. Let's start with an overview of the most basic Web services design concepts. Fundamentally, every Web service can be associated with: · a temporary classification based on the roles it assumes during the runtime processing of a message · a permanent classification based on the application logic it provides and the roles it assumes within a solution environment We explore both of these design classifications in the following two sections: · service roles (temporary classifications) · service models (permanent classifications) Service rolesA Web service is capable of assuming different roles, depending on the context within which it is used. For example, a service can act as the initiator, relayer, or the recipient of a message. A service is therefore not labeled exclusively as a client or server, but instead as a unit of software capable of altering its role, depending on its processing responsibility in a given scenario. Service providerThe service provider role is assumed by a Web service under the following conditions: · The Web service is invoked via an external source, such as a service requestor (Figure 1) Figure 1. As the recipient of a request message, the Web service is classified as a service provider. · The Web service provides a published service description offering information about its features and behavior. The service provider role is synonymous with the server role in the classic client-server architecture. Depending on the type of message exchange used when invoking a service provider, the service provider may reply to a request message with a response message. · The term "service provider" also is used to identify the organization (or individual) responsible for actually providing the Web service. To help distinguish the service role from the service's actual provider, the following, more qualified terms are sometimes used: Service requestorAny unit of processing logic capable of issuing a request message that can be understood by the service provider is classified as a service requestor. A Web service is always a service provider but also can act as a service requestor. A Web service takes on the service requestor role under the following circumstances: · The Web service invokes a service provider by sending it a message (Figure 2). Figure 2. The sender of the request message is classified as a service requestor. · The Web service searches for and assesses the most suitable service provider by studying available service descriptions. The service requestor is the natural counterpart to the service provider, comparable to the client in a typical client-server environment. It is important to note that a service provider is not acting as a service requestor when it sends a message in response to a request message. A service requestor is best viewed as a software program that initiates a conversation with a service provider. IntermediariesThe communications framework established by Web services contrasts the predictable nature of traditional point-to-point communications channels. Though less flexible and less scalable, point-to-point communication was a great deal easier to design. Web services communication is based on the use of messaging paths, which can best be described as point-to-* paths. This is because once a service provider submits a message, it can be processed by multiple intermediate routing and processing agents before it arrives at its ultimate destination. Web services and service agents that route and process a message after it is initially sent and before it arrives at its ultimate destination are referred to as intermediaries or intermediary services. Because an intermediary receives and submits messages, it always transitions through service provider and service requestor roles (Figure 3). Figure 3. The intermediary service transitions through service provider and service requestor roles while processing a message. There are two types of intermediaries. The first, known as a passive intermediary, is typically responsible for routing messages to a subsequent location (Figure 4). It may use information in the SOAP message header to determine the routing path, or it may employ native routing logic to achieve some level of load balancing. Either way, what makes this type of intermediary passive is that it does not modify the message. Figure 4. A passive intermediary service processing a message without altering its contents. Like passive intermediary services, active intermediaries also route messages to a forwarding destination. Prior to transmitting a message, however, these services actively process and alter the message contents (Figure 5). Typically, active intermediaries will look for particular SOAP header blocks and perform some action in response to the information they find there. They almost always alter data in header blocks and may insert or even delete header blocks entirely. Figure 5. An active intermediary service Initial sender and ultimate receiverInitial senders are simply service requestors that initiate the transmission of a message. Therefore, the initial sender is always the first Web service in a message path. The counterpart to this role is the ultimate receiver. This label identifies service providers that exist as the last Web service along a message's path (Figure 6). Figure 6.. Web services acting as initial sender and ultimate receiver. Service compositionsAs the name suggests, this particular term does not apply to a single Web service, but to a composite relationship between a collection of services. Any service can enlist one or more additional services to complete a given task. Further, any of the enlisted services can call other services to complete a given sub-task. Therefore, each service that participates in a composition assumes an individual role of service composition member (Figure 7). Figure 7. A service composition consisting of four members. Typically, Web services need to be designed with service composition in mind to be effective composition members. Service-orientation principles place an emphasis on composability, allowing some Web services to be designed in such a manner that they can be pulled into future service compositions without a foreknowledge of how they will be utilized. The concept of service composability is very important to service-oriented environments. In fact, service composition is frequently governed by WS-* composition extensions, such as WS-BPEL and WS-CDL, which introduce the related concepts of orchestration and choreography, respectively Service modelsThe roles we've explored so far are agnostic to the nature of the functionality being provided by the Web service. They are generic states that a service can enter within a generic context. The manner in which services are being utilized in the real world, though, has led to a classification based on the nature of the application logic they provide, as well as their business-related roles within the overall solution. These classifications are known as service models. Business service modelWithin an SOA, the business service represents the most fundamental building block. It encapsulates a distinct set of business logic within a well-defined functional boundary. It is fully autonomous but still not limited to executing in isolation, as business services are frequently expected to participate in service compositions. Business services are used within SOAs as follows: · as fundamental building blocks for the representation of business logic · to represent a corporate entity or information set · to represent business process logic · as service composition members Utility service modelAny generic Web service or service agent designed for potential reuse can be classified as a utility service. The key to achieving this classification is that the reusable functionality be completely generic and non-application specific in nature. Utility services are used within SOAs as follows: · as services that enable the characteristic of reuse within SOA · as solution-agnostic intermediary services · as services that promote the intrinsic interoperability characteristic of SOA · as the services with the highest degree of autonomy Controller service modelService compositions are comprised of a set of independent services that each contribute to the execution of the overall business task. The assembly and coordination of these services is often a task in itself and one that can be assigned as the primary function of a dedicated service or as the secondary function of a service that is fully capable of executing a business task independently. The controller service fulfills this role, acting as the parent service to service composition members. Controller services are used within SOAs as follows: · to support and implement the principle of composability · to leverage reuse opportunities · to support autonomy in other services Note that controller services themselves can become subordinate service composition members. In this case the composition coordinated by a controller is, in its entirety, composed into a larger composition. In this situation there may be a master controller service that acts as the parent to the entire service composition, as well as a sub-controller, responsible for coordinating a portion of the composition (Figure 8). Figure 8. A service composition consisting of a master controller, a sub-controller, four business services, and one utility service. Reference: Service-Oriented Architecture: Concepts, Technology, and Design | By Thomas Erl |
|