Services (as Web services)

In Chapter 3 we introduced the concept of services and how they provide a means of encapsulating various extents of logic. Manifesting 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 provide the potential of fulfilling these primitive requirements, but they need to be intentionally designed to do so. This is because the 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.

Note

We use the terms "Web services" and "services" interchangeably throughout this book.

Let's start with an overview of the most basic Web services design concepts. Fundamentally, every Web service can be associated with:

We explore both of these design classifications in the following two sections:

In Plain English

Bob and Jim are two old friends I occasionally meet. During our last get-together we talked about Chuck, another friend we used to hang out with, but with whom we lost touch several years ago. None of us know where he went off to, and we think it would be fun to see if we could contact him again. Bob says that he's heard of an agency called "Reconnect" that specializes in this particular type of service.

For us to make use of any of the services offered by Reconnect, we must:

  1. Find out (discover) how we can contact this agency.

  2. Compile the information about Chuck that the agency will require to perform the search (formulate a request).

  3. Forward this information (issue the request) to the agency.

(These steps are explained individually in the subsequent In Plain English sections.)

Reconnect is providing a service and can therefore be seen as fulfilling the role of service provider. We are requesting a service and are therefore considered to be acting as service requestors.

 

5.2.1. Service roles

A 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.

It is not uncommon for a Web service to change its role more than once within a given business task. It is especially not uncommon for a Web service within an SOA to assume different roles in different business tasks.

Provided here are descriptions of the fundamental service roles.

Service provider

The service provider role is assumed by a Web service under the following conditions:

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. (Types of message exchanges are categorized as "message exchange patterns," which are explained in the next chapter.)

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:

It is, however, most common to simply refer to the service being invoked as the service provider.

Note

A service provider agent is different from a service agent, which is a small runtime program used to perform generic processing tasks in support of Web services. Service agents are explained in Chapter 18.

 

Service requestor

Any 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.

Note

Almost all of the service requestors discussed in this book are classified as Web services and are referenced and depicted as such. Chapter 18 provides platform-specific details about how Web services are implemented and how the physical parts of a Web service interact in service provider and service requestor roles.

A Web service takes on the service requestor role under the following circumstances:

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.

As with "service provider," this term is subject to some ambiguity. A service requestor can represent both the Web service itself as well as the Web service owner. Therefore, the following extended terms are available (but not really used that often):

Note

Another term frequently used instead of service requestor is service consumer.

Case Study

RailCo is one of many long-time vendors used by TLS. Historically, it was the primary air brake parts supplier TLS relied upon. Until recently, TLS had to order parts from RailCo via phone or fax. When a new air brake supplier surfaced, offering competitive prices and signing up with TLS's B2B solution, there was little need for TLS to continue exclusively with RailCo. In fact, TLS only contacted RailCo again when its new primary vendor could not supply a requested part.

For RailCo to join its competitor as an online partner of TLS, it had to conform to rules and specifications defined by TLS. Specifically, TLS dictates that every supplier must allow TLS to programmatically interface with their inventory control system to submit purchase orders. Additionally, the supplier must be able to connect to TLS's external accounting interface to submit invoices and back-order information.

These policies forced RailCo to build an extension to their accounting system, capable of interacting with TLS's Web service-based B2B solution. After RailCo's application went online, the most common data exchange scenarios were as follows:

  • TLS's Purchase Order Service submits electronic POs that are received by RailCo's Order Fulfillment Service.

  • Upon shipping the order, RailCo's Invoice Submission Service sends an electronic invoice to TLS's Accounts Payable Service.

Figure 5.4 illustrates these two message exchanges.

Figure 5.4. TLS and RailCo services swapping roles in different but related message exchanges.

 

In the first scenario, TLS acts as the service requestor entity. Its Purchase Order Service was the service requestor (or service requestor agent) that initiated the interaction. Being the recipient of the order request, the Order Fulfillment Service is classified as the service provider (or service provider agent). As the owner of this Web service, RailCo is the service provider entity.

The roles are reversed in the second scenario, where RailCo is the service requestor entity because its Invoice Submission Service acts as the service requestor. TLS's Accounts Payable Service receives the invoice message, making that Web service the service provider, and TLS the service provider entity.

In Plain English

Because we need to send a piece of mail to Reconnect for them to initiate the search, we also introduce an intermediary into this scenario. Although the letter is addressed to Reconnect, it is actually first sent to the Post Office. From there it is routed to a carrier that delivers it to the Reconnect office. In this scenario, the Post Office acts as an intermediary that provides a routing service.

 

Intermediaries

The 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. (Message paths are explained at the end of this chapter.)

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 5.5).

Figure 5.5. 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 5.6). 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 5.6. A passive intermediary service processing a message without altering its contents.

Case Study

After shipping a TLS order, RailCo's Invoice Submission Service transmits a message containing an electronic invoice. The first TLS Web service to receive the message is a passive intermediary called the Load Balancing Service. Its purpose is to provide load balancing logic by checking the current processing statistics of available TLS servers. When the server with the lowest usage is identified, this passive intermediary routes the message accordingly.

Upon receiving the message from the Invoice Submission Service requestor, the passive Load Balancing intermediary acts as the service provider. After it has determined where the message is to be forwarded to, it changes its role to service requestor to forward the invoice document to the destination Accounts Payable Service provider.

Note

The Load Balancing Service (and the upcoming Internal Policy Service) is a form of intermediary that can be explicitly accessed as a Web service through a WSDL or it can act as a service agent. Service agents are intermediaries designed to intercept and process messages en route to their ultimate destinations and are explained further in Chapter 18. TLS opted to develop flexible intermediaries to fulfill requirements specific to their environments.

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.7). 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. (Header blocks are explained later in this chapter.)

Figure 5.7. An active intermediary service.

Case Study

TLS employs a number of active intermediaries. The Internal Policy Service, for example, examines the message to determine whether it is subject to any internal policy restrictions. If it is, the active intermediary inserts a new header block containing one or more policy rules used by subsequent service providers. As with the passive intermediary example, the active intermediary transitions through service provider and service requestor roles before finally forwarding the message to the appropriate TLS service provider.

 

Initial sender and ultimate receiver

Initial 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 5.8).

Figure 5.8. Web services acting as initial sender and ultimate receiver.

Note that intermediary services can never be initial senders or ultimate receivers within the scope of a service activity.

Case Study

Expanding on the previous example that demonstrated the use of a passive intermediary, let's take a look at all the services involved in that message exchange. In this scenario, we had the RailCo Invoice Submission Service (acting as the service requestor) initiating the message transmission. By receiving the message, the Load Balancing intermediary acts as the service provider. Upon routing the message, the intermediary temporarily assumes the service requestor role and sends the message to the Accounts Payable Service, another service provider (Figure 5.9).

Figure 5.9. The TLS Load Balancing Service acting as an intermediary between the RailCo initial sender and the TLS ultimate receiver.

 

These three physical services created four logical roles to complete two service requestor-to-service provider transmissions. There was, however, only one Web service that initiated the transmission. This was the Invoice Submission Service, and it is therefore considered the initial sender. Similarly, there was only one Web service that ended the overall activity, which makes the Accounts Payable Service the ultimate receiver.

 

Service compositions

As 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 5.10).

Figure 5.10. 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 (and is explained as a service-orientation principle in Chapter 8). 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 (as explained in Chapter 6).

Note

Service compositions also are referred to as service assemblies.

Case Study

When the TLS Accounts Payable Service receives an invoice, it invokes a series of additional services to fully process the invoice contents:

  1. It first uses the Vendor Profile Service to validate the invoice header data and link the invoice document to a vendor account.

  2. Next, the Accounts Payable Service extracts taxes and shipping fees and directly logs all amounts into the appropriate A/P accounts.

  3. Finally, the Accounts Payable Service passes the Ledger Service the invoice total, which it uses to update the General Ledger.

In this scenario our service composition consists of three composition members, spearheaded by the Accounts Payable Service (Figure 5.11).

Figure 5.11. The Accounts Payable Service enlisting other TLS services in a service composition.

Note

A characteristic of this particular composition that is not discussed here is the fact that all three actions we described would very likely be wrapped in a transaction. Should one of them fail, all others would be rolled back. (Concepts relating to service transactions are covered in Chapter 6.)

 

5.2.2. Service models

The 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.

The sections that follow describe the basic set of common service models. Additional service models are introduced in later chapters. Appendix B further provides a reference table listing all service models covered in this book. It is important to note that a service can and frequently does belong to more than one service model.

Business service model

Within 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:

For future reference, when building an SOA around layers of abstraction, the business service model can correspond to the business service layer introduced in Chapter 9. In this case the business service would act as a controller, composing utility application services. (The controller service model is explained shortly.)

Utility service model

Any 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:

When working with the service abstraction layers described in Chapter 9, a utility service is most commonly associated with the application service layer. As a result, a utility service can be referred to as a utility application service.

Case Study

In the examples we've gone through so far in this chapter, we've described eight Web services. Six of these are business services, while the other two are utility services, as follows:

  • Accounts Payable Service = business service

  • Internal Policy Service = utility service

  • Invoice Submission Service = business service

  • Ledger Service = business service

  • Load Balancing Service = utility service

  • Order Fulfillment Service = business service

  • Purchase Order Service = business service

  • Vendor Profile Service = business service

The Load Balancing and Internal Policy Services are classified as utility services because they provide generic functionality that can be reused by different types of applications. The application logic of the remaining services is specific to a given business task or solution, which makes them business-centric services.

 

Controller service model

Service 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:

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 5.12).

Figure 5.12. A service composition consisting of a master controller, a sub-controller, four business services, and one utility service.

The controller service model is used frequently when building SOA with specialized service abstraction layers, as explained later in Chapter 9.

Case Study

In our previous example we demonstrated how the Accounts Payable Service initiated and coordinated a service composition consisting of two additional composition members. That would classify the Accounts Payable Service as a controller service. The fact that we already labeled this service as a business service does not conflict with this new classification; a single service can be classified as more than one service model (Figure 5.13).

Figure 5.13. The Accounts Payable Service acting as a business and controller service, composing two other business services.

SUMMARY OF KEY POINTS
  • Web services can be labeled using temporary and permanent classifications.

  • Temporary classifications relate to roles assumed by a service at runtime. For example, an intermediary service can transition through different roles while processing a message.

  • Service models refer to permanent classifications that represent the logic housed by the service, as well as its role within the overall solution. A service can belong to more than one service model.

Related

Категории