As much as no industry-standard definition of SOA exists and as much as service-orientation principles have not been globally standardized, there is also no standardized means of modeling business services. As with all other aspects of SOA, there are plenty of opinions, and though many have ideas, few concrete methodologies have emerged. Instead, there are a select set of approaches, some of which have been more accepted than others.
Perhaps there should be no single approach to deriving services. It is not unusual for the business model behind a typical enterprise to have undergone thousands of revisions, shaped through years of adapting to the organization's surrounding business climate. Organizations employ different methodologies, business entity relationships, and vocabularies, resulting in vastly diverging business model structures. Further, there are cultural preferences and vendor platform influences that result in expression of the business models through different sets of modeling tools and languages.
The bottom line is that every business model is unique. Therefore, up-front analysis cannot be avoided to properly derive business services that best represent an organization as a cohesive business entity.
11.3.1. Sources from which business services can be derived
The inner workings of any organization, regardless of structure or size, can be decomposed into a collection of business services. This is because a business service simply represents a logical unit of work, and pretty much anything any organization does consists of units of work.
What differs, though, is how organizations structure and document the work they perform. At the beginning of this section we stressed the fact that every corporate environment is unique in the shape and size of its business models and in how it implements and maintains them. It is therefore up to the service-orientation-aware analyst to determine how to best map existing logic to services.
Below are some examples of common business analysis approaches used by many organizations. For each we briefly discuss how services can be derived.
Business Process Management (BPM) models
The advent of BPM has resulted in an industry-wide flurry of process modeling and remodeling activity. Process models have therefore become a central form of business analysis documentation in many organizations. Business services can be derived from process workflow logic.
In Chapter 3 we established how the scope of a business service can vary. Specifically, we discussed how a service can represent a step within a process, a sub-process part of a larger process, or even an entire process (Figure 11.3).
Figure 11.3. Parts of a process that can be encapsulated by a business service.
Deriving a business service from a business process requires a thorough knowledge of the underlying workflow logic. This is because defining the scope of the business logic to be represented is a judgment call that can have significant implications when the business service is implemented as part of solution environments; hence, the better the judgment, the better the quality of the service. And, of course, the better quality services you end up with, the better quality your service-oriented environment will be.
It is worth recalling that even though business logic encapsulation typically is illustrated using services, it is actually the service operations that represent and execute the logic in the service layer. Therefore, it is critical to ensure that when identifying logic suitable for service encapsulation, it be broken down into individual operations. Services are then determined by the proposed grouping of these operations.
Following are descriptions of two existing RailCo processes that are currently being partially automated by its services. In past chapters, we focused solely on service interaction and therefore only described the involvement of RailCo's Invoice Submission and Order Fulfillment Services as part of interaction scenarios with the TLS B2B solution. The descriptions provided here document the steps that comprise internal RailCo processes because these are the processes that eventually will be affected by the introduction of SOA.
First, we'll explore the existing Invoice Submission Process. It consists of a series of steps that describe how invoices are generated specifically for TLS, as follows:
The internal Order Fulfillment Process is similar in that it establishes the same type of relationship between the accounting system and a Web serviceonly this time, the data flow is reversed, as described here:
Note that both of these processes are intentionally incomplete. The Invoice Submission Process contains additional steps related to an acknowledgement it receives from TLS upon the successful delivery of the invoice submission. The complete Order Fulfillment Process consists of several additional steps that are required to formulate a response to TLS containing back-order information, if required. The process steps that are provided are those most relevant to our study of how implementing SOA leads to improvements for RailCo.
Note that these two process descriptions form the basis of the examples used to demonstrate the service modeling process in Chapter 12.
Primary entities represent the main business documents and transaction areas of an enterprise. For example, Invoice, Purchase Order, Customer, and Claim are all milestone entities within different types of businesses. Further, organizations model entities according to proprietary rules and business policies. This results in entities having relationships with each other.
Entity-centric services (explained shortly) mirror the entity model by containing a set of generic operations that facilitate the different types of functions associated to the processing of the entity. Communication between different entity-centric services also can be governed by constraints relating to the inherent relationship between entities.
These types of services often follow the OOP naming convention where a noun is used to label an object and verbs are used to name methods. Because entity-centric services represent data entities, the services can be named with nouns and the operations with verbs.
RailCo has decided to build services centered around specific tasks and is therefore not using entity models as a source for deriving business services. However, to demonstrate the concept of entities, let's briefly look at what entities exist within the RailCo business areas we've been exploring so far.
Based on the business processes we described earlier, RailCo entities of relevance are:
Additional entities involved with these processes could include:
Here are some examples of how the entities described above could relate to each other:
Figure 11.4 illustrates this series of one-to-one and one-to-many relationships.
Figure 11.4. Relationships between RailCo entities (normally these entity symbols would contain attributes as well).
11.3.2. Types of derived business services
Deriving services from the two sources we just identified results in the creation of distinct types of business services.
Task-centric business services
These are Web services that have been modeled to accommodate a specific business process. Operations are grouped according to their relevance to the execution of a task in support of a process.
Typical examples of task-centric business services are:
Each of these services contains operations that relate to a particular task within the context of a process. Task-centric services usually result from modeling exercises that are focused on meeting immediate business requirements. Typical sources include use-case models and BPM process definitions.
While they require less analysis effort to produce, these types of business services have limited reusability potential. Modeling reusable task-centric business services often requires that multiple use-cases and business process models first be analyzed to identify commonality, prior to the actual modeling of the services.
Although they are hybrid (application + business) in design, the following RailCo services follow a task-centric model:
Note that the TLS Subscription Service displayed in the preceding list does not actually belong to TLS. It is just a poorly named service produced by RailCo for communication with TLS.
Entity-centric business services
Entity-centric business services generally are produced as part of a long-term or on-going analysis effort to align business services with existing corporate business models. Their inherent generic nature makes them highly reusable by numerous business processes. Even though entity-centric business services often are built as part of application development projects centered around a particular business process, they differ from task-centric services in that they do not provide an interface specific to that process. Instead, the source of inspiration for these types of services is entity models.
When compared to task-centric services, entity-centric services significantly increase the agility with which service-oriented processes can be remodeled. This is because task-centric services often are built to help automate one business process and can therefore get tied to that process. When the process logic changes, the context under which the services are used and composed may change as well. This may invalidate the original grouping of service operations and could result in the requirement for a redesign and redevelopment effort.
Entity-centric services do require more up-front analysis, increasing both the cost of each service and the time required to produce it. Additionally, they can be so generic in nature that they are delivered with no concept of business process logic. Their use may therefore become dependent on parent business controllers, such as process services or task-centric controller services. As we established in Chapter 9, building a business service layer consisting of a series of entity-centric services composed by a parent orchestration service layer establishes a desirable SOA, promoting a high degree of agility and accurate business model representation.
Although we have identified logical entities within RailCo, no entity-centric business services currently exist. Having followed the top-down SOA delivery strategy, though, TLS already has a set of entity-centric business services in place (Figure 11.5).
Figure 11.5. Different organizations, different approaches to building services.
When utilized within the B2B solution, these services actually do not need to be composed by a separate task-centric or process service. The reason this parent controller layer is not required is because the Accounts Payable and Purchase Order Services are not part of a solution-specific business process. They are simply fulfilling their respective document processing roles for the accounting system, receiving valid invoices and issuing valid purchase orders. Therefore, no further workflow logic is required.
TLS is planning to continue building entity-centric services. But, as decided in Chapter 10, they will deliver future business services according to the agile delivery strategy. RailCo does not have the time or budget to outfit each new business service with additional functionality for future reuse opportunities. No entity-centric services are therefore planned for RailCo.
11.3.3. Business services and orchestration
The process service, an implementation of orchestration, also can be classified as a form of business service. It is very much "business-centric," as it resides at the top of the service layer hierarchy and is responsible for composing business services according to the rules specified in the orchestration workflow logic.
Details regarding the process service are described in the Orchestration section of Chapter 6, the Orchestration services layer section of Chapter 9, as well as the service-oriented business process design portions of Chapter 16. An orchestration can compose a combination of task-centric and entity-centric business services. The core business model is represented by the entity-centric services, while business logic-related tasks can be implemented in task-centric services that are designed specifically to supplement the process service.
Essentially, the use of orchestration establishes the following structure in the services layer:
Orchestration abstracts workflow logic, positioning it outside of service boundaries. This increases agility by allowing changes to business rules to be made without affecting business or application services. This is a critical aspect of orchestration, as business process logic is subject to many factors that can result in change. These include human intervention, changes to corporate policies and business rules, and unforeseeable exception conditions.
TLS has decided that as part of its plans to expand its existing SOA, it will introduce an orchestration service layer. It begins by introducing a process service that abstracts business rules and workflow logic from the business services already in use.
Although this requires a significant modeling effort, it is anticipated that the existing service structures and service interfaces will remain unaffected. After the workflow logic represented by the process service is finalized in the service-oriented design phase, the true impact of the orchestration service layer on the existing business services will be determined.
This example is continued in the Contrasting service modeling approaches (an example) section at the end of Chapter 12.
SUMMARY OF KEY POINTS