Service activity

The completion of business tasks is an obvious function of any automated solution. Tasks are comprised of processing logic that executes to fulfill a number of business requirements. In service-oriented solutions, each task can involve any number of services. The interaction of a group of services working together to complete a task can be referred to as a service activity (Figure 6.10).

Figure 6.10. In an activity, multiple Web services collaborate to do a specific piece of work.

Note

Though there is no formal definition of the term "activity," it is used by several of the specifications we discuss in this book. It is a generic term that is most frequently associated with a logical unit of work completed by a collection of services.

In Plain English

Any type of task will consist of one or more steps. The task of turning on the TV is relatively simple, consisting of perhaps the following two steps:

1.

Pick up the remote control.

 

2.

Press the "Power" button.

 

The task of washing a car, on the other hand, can be a bit more complicated. It could exist of a series of steps, including:

1.

Locate bucket.

 

2.

Locate sponge.

 

3.

Locate hose.

 

4.

Fill bucket with warm water.

 

5.

Add soap to water.

 

6.

Soak sponge in water.

 

7.

Rub sponge on car.

 

...and so on.

The steps that comprise this more complex task could be summarized into a series of simple (or primitive) tasks, as follows:

1.

Gather required equipment.

 

2.

Prepare water.

 

3.

Wash car.

 

Each simple task consists of a smaller number of steps. Collectively these simple tasks represent a larger, logical unit of work. Individually, simple tasks do not accomplish anything of relevance, primarily because each subsequent task is dependent on the completion of the former. It is only when they are assembled into a complex task that they represent a useful unit of work.

Similarly, most business tasks automated by service-oriented applications consist of a complex activity that requires the involvement of multiple services that each complete a subset of the work.

 

6.2.1. Primitive and complex service activities

The scope of an activity can drastically vary. A simple or primitive activity is typified by synchronous communication and therefore often consists of two services exchanging information using a standard request-response MEP (Figure 6.11). Primitive activities are almost always short-lived; the execution of a single MEP generally constitutes the lifespan of a primitive activity.

Figure 6.11. A primitive service activity consisting of a simple MEP.

Complex activities, on the other hand, can involve many services (and MEPs) that collaborate to complete multiple processing steps over a long period of time (Figure 6.12). These more elaborate types of activities are generally structured around extension-driven and composition-oriented concepts, such as choreography and orchestration. However, a business task automated by a series of custom-developed services and without the use of a composition extension can just as easily be classified a complex activity.

Figure 6.12. A complex activity involving four services.

 

6.2.2. Service activities and SOA

In SOAs, activities represent any service interaction required to complete business tasks. The scope of a service activity is primarily concerned with the processing and communication between services only. The underlying application logic of each Web service, whether it consists of a single component or an entire legacy system, is generally not mapped as part of a service activity. Complex activities are commonplace in larger service-oriented solutions and can involve numerous participating services.

Note

The term "Web services activity" also happens to represent the ongoing Web services-related work being performed by numerous W3C working groups.

Case Study

The message path traveled by a RailCo invoice submission is a great example of a complex activity.

Here is a recap of the Invoice Submission Process we introduced in Chapter 5:

1.

The initial sender, RailCo's Invoice Submission Service, transmits the invoice message.

 

2.

The message is first received by a passive intermediary, TLS's Load Balancing Service, which routes the message according to environmental conditions. The message subsequently arrives at TLS's Accounts Payable Service.

 

3.

The Accounts Payable Service acts as a controller and initiates a service composition to begin processing the message contents. It begins by interacting with the Vendor Profile Service to validate invoice header data and attaches the invoice document to the vendor account.

 

4.

The Accounts Payable Service then extracts taxes, shipping fees, and the invoice total. It passes these values to the Ledger Service, which updates various ledger accounts, including the General Ledger.

 

5.

Finally the activity ends, as the Accounts Payable Service completes its processing cycle by sending a response message back to RailCo.

 

Collectively, these processing steps constitute a complex activity involving five services (Figure 6.13).

Figure 6.13. A sample complex activity spanning RailCo and TLS boundaries.

SUMMARY OF KEY POINTS
  • An activity is a generic concept used to represent a task or a unit of work performed by a set of services.

  • The scope of primitive activities can be limited to the completion of simple MEPs.

  • Complex activities are common within SOAs and exist as part of any non-trivial service-oriented application.

Related

Категории