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.
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:
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:
...and so on.
The steps that comprise this more complex task could be summarized into a series of simple (or primitive) tasks, as follows:
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.
The term "Web services activity" also happens to represent the ongoing Web services-related work being performed by numerous W3C working groups.
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:
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