Introduction to service-oriented analysis

The process of determining how business automation requirements can be represented through service-orientation is the domain of the service-oriented analysis.

11.1.1. Objectives of service-oriented analysis

The primary questions addressed during this phase are:

• What services need to be built?
• What logic should be encapsulated by each service?

The extent to which these questions are answered is directly related to the amount of effort invested in the analysis. Many of the issues we discussed in the past two chapters can be part of this stage. Specifically, the determination of which service layers to build and how to approach their delivery are critical decision points that will end up forming the structure of the entire service-oriented environment.

Note

While the choice of SOA delivery strategy can be added as a separate step within the service-oriented analysis phase, our assumption in this chapter is that this decision already has been made.

The overall goals of performing a service-oriented analysis are as follows:

• Define a preliminary set of service operation candidates.
• Group service operation candidates into logical contexts. These contexts represent service candidates.
• Define preliminary service boundaries so that they do not overlap with any existing or planned services.
• Identify encapsulated logic with reuse potential.
• Ensure that the context of encapsulated logic is appropriate for its intended use.
• Define any known preliminary composition models.

11.1.2. The service-oriented analysis process

Introducing a new analysis process into an existing IT environment can be a tricky thing. Every organization has developed its own approach to analyzing business automation problems and solutions, and years of effort and documentation will have already been invested into well-established processes and modeling deliverables. The process described in this section is not intended to supplant existing procedures. Instead, it proposes a sequence of supplementary steps, specific to the delivery of a service-oriented solution.

Service-oriented analysis can be applied at different levels, depending on which of the SOA delivery strategies are used to produce services. As explained in the previous chapter, the chosen strategy will determine the layers of abstraction that comprise the service layers of a solution environment.

From an analysis perspective, each layer has different modeling requirements. For example, the nature of the analysis required to define application services is different from what is needed to model the business service layer.

Therefore, as previously mentioned, a key prerequisite of this process is the choice of SOA delivery strategy. Other questions that should be answered prior to proceeding with the service-oriented analysis include:

• What outstanding work is needed to establish the required business model(s) and ontology?
• What modeling tools will be used to carry out the analysis?
• Will the analysis be part of an SOA transition plan?

Note that the answer to this last question often will depend on the scope of the project. This analysis may be a scheduled phase in a larger plan that maps out an organization-wide transition toward SOA. Or, in smaller projects, the service-oriented analysis itself may incorporate a separate step for transition planning. Creating a transition plan is a topic unto itself and is therefore beyond the scope of this book.

The service-oriented analysis process is a sub-process of the overall SOA delivery lifecycle. The steps shown in Figure 11.1 are common tasks associated with this phase and are described further in the following sections.

Figure 11.1. A high-level service-oriented analysis process.

Note that Steps 1 and 2 essentially represent information gathering tasks that are carried out in preparation for the modeling process described in Step 3.

Step 1: Define business automation requirements

Through whatever means business requirements are normally collected, their documentation is required for this analysis process to begin. Given that the scope of our analysis centers around the creation of services in support of a service-oriented solution, only requirements related to the scope of that solution should be considered.

Business requirements should be sufficiently mature so that a high-level automation process can be defined. This business process documentation will be used as the starting point of the service modeling process described in Step 3.

Step 2: Identify existing automation systems

Existing application logic that is already, to whatever extent, automating any of the requirements identified in Step 1 needs to be identified. While a service-oriented analysis will not determine how exactly Web services will encapsulate or replace legacy application logic, it does assist us in scoping the potential systems affected.

The details of how Web services relate to existing systems are ironed out in the service-oriented design phase. For now, this information will be used to help identify application service candidates during the service modeling process described in Step 3.

Note that this step is more geared to supporting the modeling efforts of larger scaled service-oriented solutions. An understanding of affected legacy environments is still useful when modeling a smaller amount of services, but a large amount of research effort would not be required in this case.

Step 3: Model candidate services

A service-oriented analysis introduces the concept of service modelinga process by which service operation candidates are identified and then grouped into a logical context. These groups eventually take shape as service candidates that are then further assembled into a tentative composite model representing the combined logic of the planned service-oriented application.

This process is explained in detail in the Service modeling (a step-by-step process) section of Chapter 12.

Case Study

Back in Chapter 2 we established that RailCo's ultimate goal is to standardize on SOA to solve its current automation problems and increase its online clientele. Subsequent chapters have talked at length about the various services RailCo has built that allow it to take part in online commerce exchanges with TLS's B2B solution.

Here is the familiar list of RailCo services:

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

Although their use has allowed RailCo to establish a Web services extension to their legacy solution environment, these three services do not constitute a true SOA. In the previous chapter we identified that the construction of these services was based purely on a bottom-up approach, resulting in the creation of what we've termed "hybrid" application services (application services that also contain business logic, intended for narrowly focused business tasks).

These services were assembled quickly to accommodate a single client. However, because that client has now formed a partnership with another air brake vendor, RailCo is only receiving a subset of its original revenue stream. This new reality has turned into a driving motivation for RailCo to commit to and invest in the standardization of a service-oriented architecture.

After a preliminary analysis of its existing Web services, it is quickly determined that there is little benefit in trying to build upon the services produced so far. Instead, it is decided to start from scratch and build a set of new services.

The agile delivery strategy (described in the previous chapter) is chosen as the approach by which these new services will be delivered. It is further determined that only application and business service layers will be modeled because RailCo is not in a position to invest in the middleware required to implement an orchestration layer.

As RailCo proceeds with its service-oriented analysis, it is able to identify some tangible benefits that an SOA can realize. These benefits appear to provide the potential to fulfill key business goals of the organization.

Specifically, preliminary analysis results indicate that:

• The application of service-orientation principles and the standardization introduced by SOA will allow a single set of services to accommodate interaction with different online partners. This would free RailCo from its ties to TLS and allow it to pursue new customers without necessarily having to build a new set of services each time.
• SOA facilitates the integration of internal legacy systems by establishing standardized application endpoints. In particular, the abstraction provided by service layers will enable RailCo to create integration channels that do not need to be removed if underlying legacy technology is replaced. This gives RailCo the ability to connect its accounting and contact management solutions knowing full well that the latter will likely need to be replaced in the future.

Because RailCo is focusing on overhauling its existing set of services, it has not yet identified any specific reusability requirements. However, it has been decided that, where feasible, services should be designed to support potential reuse. We explore the details of RailCo's analysis effort in the Service modeling (a step-by-step process) section in Chapter 12.

SUMMARY OF KEY POINTS

• The service-oriented analysis phase of an SOA delivery project requires that critical decisions be made that affect the shape and form of individual services as well as the overall service layers.
• Service modeling is the process of identifying candidate service operations and grouping them in candidate services.