Classifying service model logic

So far we've been classifying most of our modeling logic as service operation candidates and service candidates. As we stated earlier in the "Services" vs. "Service Candidates" section, the use of the term "candidate" helps us distinguish an abstract piece of logic from a concrete design. However, referring to a piece of business logic as an operation candidate or service candidate gives us no indication as to the nature of the logic being represented.

Service-oriented encapsulation allows a single operation to express a potentially broad range of logic. For example, an operation can represent a small task, such as performing a simple calculation. Or an operation can represent a large task, such as invoking four other services to perform a complex series of tasks, involving different underlying systems and processes.

When modeling business logic, it is useful to be able to understand the scope of logic represented by a candidate operation, service, or process. For this we need a system of classifying units of business logic. Provided in this section is a sample classification system wherein we refer to each level of classification as a building block. The term "building block" is used primarily because the composite nature of service-oriented environments lends itself well to this metaphor.

Building blocks (also known as service modeling units) are simply labels applied to units of business logic that assist us with the composition or decomposition of a service-oriented enterprise. You can use these labels to identify specific types of logic, distinguished primarily by scope. Additionally, as part of our classification system, we also provide some supplemental terms that help us identify other pieces of SOA models.

Feel free to use this system as a starting point, from which you can derive your own classifications or create new ones to best complement existing business analysis standards. Reading this section is recommended if you will be studying the example provided in the Contrasting service modeling approaches example at the end of this chapter because the terms established by this classification system are applied in this example.

12.3.1. The SOE model

Let's first introduce a master view of a service-oriented enterprise, known as the SOE model (Figure 12.12). Within this view we establish our building blocks, each increasing in scope from left to right.

Figure 12.12. The SOE model.

Building blocks allow us to categorize distinct units of logic for both modeling and design purposes. The first layer of this view establishes the enterprise business model, a series of building blocks used to represent modeled business logic only. The third layer provides the concrete or design building blocks that comprise the enterprise technology model. The layer in between represents the core SOE model, defined collectively by abstract (business) and concrete (technology) layers. The enterprise business model layer is closely related to the service modeling process and is explained further in the following sections.

12.3.2. The enterprise business model

The building blocks in this first layer classify logic encapsulated by business service candidates only. They provide an abstract representation of a service-oriented enterprise's business intelligence, independent from the underlying technology platform with which it is implemented. Should we ever want to replace our technology platforms, we will be able to do so while still preserving our abstract, service-oriented perspective of enterprise business logic. For our purposes, these building blocks help us label and categorize logic that resides in the orchestration and business service layers.

12.3.3. "Building Blocks" versus "Service Models"

Building blocks are not an independent means of classifying service logic. They are complemented by existing classifications, such as the service models we introduced in previous chapters. While service models are useful for classifying the nature of logic encapsulated by a service, building blocks classify the scope of service logic.

The primary distinction is that a service model always will apply to a single service, but a building block can apply to a range of logic. In other words, a building block can also represent a subset of a service's logic or the collective logic of multiple services.

12.3.4. Basic modeling building blocks

Everything that exists within a modeled view of a service-oriented environment can be broken down into a collection of building blocks, each of which falls into one of the following three categories:

• activity
• service
• process

These terms establish an overall context. Hence, the names of our building blocks are derived from these three categories. The following represents the list of building blocks that form the enterprise business model part of the SOE model.

• primitive business activity
• primitive business service
• primitive business process
• extended business process
• enterprise domain business process
• enterprise business process

This section describes terms related to the first three (Figure 12.13), as they represent the most common and fundamental parts of our modeling environment. The remaining are more concerned with complex business process configurations beyond the scope of this book.

Figure 12.13. The three fundamental building blocks of the enterprise business model.

 

Primitive business activities

A primitive business activity represents the smallest piece of definable and executable business logic within a service-oriented environment. Typically this means that to whatever extent it makes sense to break down a business process, primitive business activities are the smallest parts. The assumption, therefore, is that its logic either cannot be decomposed or will not require further decomposition.

As established in the Service modeling (a step-by-step process) section, a recommended service modeling approach is to break down business process logic into a series of primitive business activities and to then represent each as an initial operation candidate.

The physical implementation of a primitive business activity can be compared to the functionality provided by a granular service operation. Coarse-grained operations tend to expose business logic that can be decomposed into numerous individual primitive business activities. Therefore, a granular operation exposing application logic that automates a single action of an overall business process is a suitable measure of implementation.

Note

Traditional business process modeling methodologies sometimes refer to a primitive business activity as an atomic activity.

 

Process activities

Related to a primitive business activity is the process activity. A process activity is not a building block; it is simply a term used to represent an executable step within a business process's workflow logic. Unlike primitive business activities, process activities do not have a fixed scope. The range of business logic represented by a process activity is determined by the granularity of its governing business process. Therefore, a process activity may or may not be comprised of multiple primitive business activities.

Business processes can be modeled at different levels of abstraction. A coarse-grained process will tend to include a number of coarse-grained steps. Each of these steps is a process activity within the context of a coarse-grained process. Some of the coarser process activities will likely be comprised of multiple primitive business activities.

A more detailed or fine-grained version of the same process, though, would consist of many more steps. Each of these would again be considered process activities, as they express individual steps within the context of a fine-grained process. Process activities representing more fine-grained pieces of business logic are more likely to have a one-to-one relationship with corresponding primitive business activities.

Note

Traditional workflow modeling conventions label a single process step that represents a collection of further process steps as a predefined process or sub-process. Also traditional business process modeling methodologies often refer to a process activity as just an activity.

 

Business services

The business service (or business service candidate) category represents the familiar business service candidate we've already been working with. Within the context of this classification system, each business service is comprised of one or more primitive business activities. These activities can reside atomically within the service, or they can inter-relate. In the latter case, primitive business activities may form a logical algorithm that can establish independent workflow logic and associated business rules.

When physically implemented, the logic a business service candidate represents typically exists as a Web service. Depending on the scope of the encapsulated logic, the service candidate may be further classified under a more specialized category. Two such sub-categories are provided:

Primitive business services

A primitive business service (or primitive business service candidate) is a type of business service that encompasses functionality limited to a simple business task or function. In other words, this variation of the business service building block represents the most granular type of service within service-oriented solutions.

What distinguishes a primitive business service from others is the assumption that this service will not encapsulate functionality exposed by another service. This means that a primitive business service does not compose other services; it simply is responsible for the execution of a specific task and may or may not be a member of service compositions.

A primitive business service usually will be implemented as a granular Web service, but it also can be expressed through a coarse-grained Web service operation.

Primitive business process

A primitive business process represents a body of workflow logic comprised of a set of related process activities. A primitive business process is defined by a distinct functional boundary typically related to a specific business task (such as Submit Invoice or Process Purchase Order). A primitive business process can be represented by a process service or task-centric business service.

SUMMARY OF KEY POINTS

• Using a classification system allows us to label services according to the scope of logic they encapsulate.
• Business logic represented by building blocks can be decomposed into activities, services, and processes.