Deriving business services

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.

Note

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.

Case Study

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:

1. Accounting clerk creates and issues an electronic invoice using the legacy accounting system.
2. The save event triggers a custom script that exports an electronic copy of the invoice to a network folder.
3. A custom developed component, which polls this folder at ten-minute intervals, picks up the document and transforms it into an XML document.
4. The invoice XML document is then validated. If it is deemed valid, it is forwarded to the Invoice Submission Service. If validation fails, the document is rejected, and the process ends.
5. Depending on when the last metadata check was performed, the service may issue a Get Metadata request to the TLS B2B solution.
6. If the Get Metadata request is issued and if it determines that no changes were made to the relevant TLS service descriptions, the Invoice Submission Service transmits the invoice document to the TLS B2B solution using the ExactlyOnce delivery assurance. If the Get Metadata request identifies a change to the TLS service descriptions, the invoice is not submitted, and the process ends.

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:

1. The RailCo Order Fulfillment Service receives a SOAP message from TLS, containing a payload consisting of a TLS purchase order document.
2. The service validates the incoming document. If valid, the document is passed to a custom component. If the TLS PO fails validation, a rejection notification message is sent to TLS, and the process ends.
3. The component has the XML document transformed into a purchase order that conforms to the accounting system's native document format.
4. The PO then is submitted to the accounting system using its import extension.
5. The PO ends up in the work queue of an accounting clerk who then processes the document.

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.

 

Entity models

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.

Note

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.

Case Study

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:

• Invoice
• Purchase Order

Additional entities involved with these processes could include:

• Employee
• Order
• Back Order
• Customer

Here are some examples of how the entities described above could relate to each other:

• A Purchase Order can be related to zero or more Invoices.
• A Purchase Order can only be related to one Customer.
• An Order can be related to one or more Purchase Orders.
• A Back Order can be related to one or more Purchase Orders.
• An Invoice can only be related to one Customer.
• An Employee can be related to zero or more Invoices, Purchase Orders, Orders, Back Orders, or Customers.

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:

• VerifyInvoice
• GetHistoryReport

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.

Case Study

Although they are hybrid (application + business) in design, the following RailCo services follow a task-centric model:

• Invoice Submission Service
• Order Fulfillment Service
• TLS Subscription Service

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.

Case Study

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.

 

These are:

• Accounts Payable Service
• Purchase Order Service
• Ledger Service
• Vendor Profile Service

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:

1. Workflow logic and process-specific business rules are embedded in a process definition. Orchestration composes business services (and possibly application services) according to this definition.
2. Business services compose application services to execute business logic.
3. Application services interact with underlying systems to process the required functions.

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.

Case Study

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

• Business services are derived from common business model documents, including use-case models, business process definitions, and entity models.
• There are two distinct types of business services that are commonly derived: task-centric and entity-centric. Each has pros and cons, and each approaches encapsulation in a different manner.