Service modeling (a step-by-step process)

A service modeling process is essentially an exercise in organizing the information we gathered in Steps 1 and 2 of the parent service-oriented analysis process. Sources of the information required can be diverse, ranging from various existing business model documents to verbally interviewing key personnel that may have the required knowledge of a relevant business area. As such, this process can be structured in many different ways. The process described in this section is best considered a starting point from which you can design your own to fit within your organization's existing business analysis platforms and procedures.

12.1.1. "Services" versus "Service Candidates"

Before we begin, let's first introduce an important modeling term: candidate. The primary goal of the service-oriented analysis stage is to figure out what it is we need to later design and build in subsequent project phases. It is therefore helpful to continually remind ourselves that we are not actually implementing a design at this stage. We are only performing an analysis that results in a proposed separation of logic used as input for consideration during the service-oriented design phase. In other words, we are producing abstract candidates that may or may not be realized as part of the eventual concrete design.

The reason this distinction is so relevant is because once our candidates are submitted to the design process, they are subjected to the realities of the technical architecture in which they are expected to reside. Once constraints, requirements, and limitations specific to the implementation environment are factored in, the end design of a service may be a significant departure from the corresponding original candidate.

So, at this stage, we do not produce services; we create service candidates. Similarly, we do not define service operations; we propose service operation candidates. Finally, service candidates and service operation candidates are the end-result of a process called service modeling.

12.1.2. Process description

Up next is a series of 12 steps that comprise a proposed service modeling process (Figure 12.1). Specifically, this particular process provides steps for the modeling of an SOA consisting of application, business, and orchestration service layers.

Figure 12.1. A sample service modeling process.

 

Step 1: Decompose the business process

Take the documented business process and break it down into a series of granular process steps. It is important that a process's workflow logic be decomposed into the most granular representation of processing steps, which may differ from the level of granularity at which the process steps were originally documented. (The Classifying service model logic section at the end of this chapter introduces new terms that help distinguish the scope of individual process steps.)

Case Study

The scope of RailCo's service-oriented analysis includes both of the business processes we described in the Business Process Management (BPM) models section in Chapter 11.

Let's begin by decomposing the Invoice Submission Process (displayed in Figure 12.2) into a series of granular steps:

• Create electronic invoice.
• Issue electronic invoice.
• Export electronic invoice to network folder.
• Poll network folder.
• Retrieve electronic invoice.
• Transform electronic invoice to XML document.
• Check validity of invoice document. If invalid, end process.
• Check if it is time to verify TLS metadata.
• If required, perform metadata check. If metadata check fails, end process.

Figure 12.2. The RailCo Invoice Submission Process.

 

Next are the process steps of a decomposed Order Fulfillment Process (Figure 12.3):

• Receive PO document.
• Validate PO document.
• If PO document is invalid, send rejection notification and end process.
• Transform PO XML document into native electronic PO format.
• Import electronic PO into accounting system.
• Send PO to accounting clerk's work queue.

Figure 12.3. The RailCo Order Fulfillment Process.

 

Step 2: Identify business service operation candidates

Some steps within a business process can be easily identified as not belonging to the potential logic that should be encapsulated by a service candidate.

Examples include:

• Manual process steps that cannot or should not be automated.
• Process steps performed by existing legacy logic for which service candidate encapsulation is not an option.

By filtering out these parts we are left with the processing steps most relevant to our service modeling process.

Case Study

After reviewing each of the previously identified processing steps, we remove those that we either cannot or do not want to make part of our service-oriented solution.

Here, again, are the steps of our two processes. Those that are no longer part of our solution environment have been crossed out. Each step is further supplemented with a brief note that explains either why we have decided to remove it from our list or what we have planned for it.

Invoice Submission Process:

• Create electronic invoice. (A manual step performed by the accounting clerk.)
• Issue electronic invoice. (A manual step performed by the accounting clerk.)
• Export electronic invoice to network folder. (Currently a custom developed extension of the legacy system. Could be made part of a generic service candidate.)
• Poll network folder. (Currently performed by a custom developed component. Could be made part of a service candidate.)
• Retrieve electronic invoice. (Same as previous.)
• Transform electronic invoice to XML document. (Same as previous.)
• Check validity of invoice document. If invalid, end process. (Is currently being performed as part of the Invoice Submission Service's parsing routine. No foreseeable need to change this.)
• Check if it is time to verify TLS metadata. (Is currently being performed as part of the Invoice Submission Service's parsing routine. Looks like a potentially reusable operation candidate. Could be moved to a separate service candidate.)
• If required, perform metadata check. If metadata check fails, end process. (Same as previous.)

And here are the process steps of the decomposed Order Fulfillment Process:

• Receive PO document. (Is currently being performed by the Order Fulfillment Service. No foreseeable need to change this.)
• Validate PO document. (Same as previous.)
• If PO document is invalid, send rejection notification and end process. (Same as previous.)
• Transform PO XML document into native electronic PO format. (Currently performed by a custom developed component. Could be made part of a service candidate.)
• Import electronic PO into accounting system. (Currently a custom developed extension of the legacy system. Could be made part of a generic service candidate.)
• Send PO to accounting clerk's work queue. (Same as previous.)

The result of this review is that only two processing steps were removed from the Invoice Submission Process and none from the Order Fulfillment Process.

 

Step 3: Abstract orchestration logic

If you have decided to build an orchestration layer as part of your SOA, then you should identify the parts of the processing logic that this layer would potentially abstract. (If you are not incorporating an orchestration service layer, then skip this step.)

Potential types of logic suitable for this layer include:

• business rules
• conditional logic
• exception logic
• sequence logic

Note that these forms of orchestration logic may or may not be represented accurately by a step description. For example, some processing step descriptions consist of a condition and an action (if condition x occurs, then perform action y). In this case, only remove the condition and leave the action.

Also note that some of the identified workflow logic likely will be dropped eventually. This is because not all processing steps necessarily become service operations. Remember that at this point, we are only creating candidates. When we enter the service-oriented design phase, practical considerations come into play. This may result in the need to remove some of the candidate operations, which would also require that corresponding workflow logic be removed from the orchestration layer as well.

Case Study

As stated previously, RailCo has decided not to invest in building a separate orchestration service layer. However, we still can speculate as to what parts of the process step logic would normally be abstracted if this layer were to exist.

Based on our two process descriptions, the workflow logic represented by a separate process service candidate would include (but not be limited to) the following:

• If the invoice document is valid, proceed with the metadata check step.
• If the invoice document is invalid, end process.
• If the interval period for performing a metadata check has completed, proceed to the perform metadata check step.
• If the interval period has not completed, skip the perform metadata check step.
• If the PO document is valid, proceed with the transform PO document step.
• If the PO document is invalid, end process.

Note that the orchestration workflow logic also would include the sequence in which the individual processing steps are executed.

 

Step 4: Create business service candidates

Review the processing steps that remain and determine one or more logical contexts with which these steps can be grouped. Each context represents a service candidate. The contexts you end up with will depend on the types of business services you have chosen to build.

For example, task-centric business services will require a context specific to the process, while entity-centric business services will introduce the need to group processing steps according to their relation to previously defined entities. (As stated in the Deriving business services section in Chapter 11, an SOA also can consist of a combination of these business service types.)

It is important that you do not concern yourself with how many steps belong to each group. The primary purpose of this exercise is to establish the required set of contexts.

Also it is encouraged that entity-centric business service candidates be equipped with additional operation candidates that facilitate future reuse. Therefore, the scope of this step can be expanded to include an analysis of additional service operation candidates not required by the current business process, but added to round out entity services with a complete set of reusable operations. (This step is reiterated in the service design processes provided in Chapter 15.)

Case Study

Going through the RailCo steps we listed from both processes, here is how they could be grouped:

Legacy System Service

• Export electronic invoice to network folder.
• Import electronic PO into accounting system.
• Send PO to accounting clerk's work queue.

Invoice Processing Service

• Poll network folder for invoice.
• Retrieve electronic invoice.
• Transform electronic invoice to XML document.
• Check validity of invoice document. If invalid, end process.

PO Processing Service

• Receive PO document.
• Validate PO document.
• If PO document is invalid, send rejection notification and end process.
• Transform PO XML document into native electronic PO format.

Metadata Checking Service

• Check if it is time to verify TLS metadata.
• If required, perform metadata check. If metadata check fails, end process.

As also shown in Figure 12.4, our operation candidates are grouped according to contexts that represent service candidates.

Figure 12.4. Our first round of service candidates.

 

Step 5: Refine and apply principles of service-orientation

So far we have just grouped processing steps derived from an existing business process. To make our service candidates truly worthy of an SOA, we must take a closer look at the underlying logic of each proposed service operation candidate.

This step gives us a chance to make adjustments and apply key service-orientation principles. This is where the study we performed in the Native Web service support for service-orientation principles section of Chapter 8 becomes useful. As you may recall, we identified the following four key principles as those not intrinsically provided through the use of Web services:

• reusability
• autonomy
• statelessness
• discoverability

Of these four, only the first two are important to us at the service modeling stage. The latter two on this list are addressed in the service-oriented design process. Therefore, our focus in this step is also to ensure that each service operation candidate we identify is potentially reusable and as autonomous as possible.

Case Study

In reviewing the operation candidates within our service candidates, we make a series of adjustments, as follows.

Within the Legacy System Service, the "Send PO to accounting clerk's work queue" action can be performed only upon the receipt of a document. This operation candidate is therefore directly dependent on the "Import electronic PO into accounting system" step. We therefore decide to combine these two steps into one.

Further the "Export electronic invoice to network folder" action is performed automatically by a macro added to the legacy accounting system. It is therefore not required as part of our service candidate. This leaves us with a single operation candidate that we would like to make more reusable by allowing it to handle different types of documents.

The revised Legacy System Service list contains the following steps:

• Export document to network folder.
• Import and forward document to work queue.

Upon reviewing the Invoice Processing Service, a number of refinement opportunities arise. We determine that the "Poll network folder for invoice" action can be made more generic by turning it into an operation candidate that simply polls a given folder for different types of documents. We also decide that this action should be made part of a service candidate capable of notifying subscribers of the arrival of new documents.

Next, we decide to combine the "Retrieve electronic invoice," "Transform electronic invoice to XML document," and "Check validity of invoice document" operation candidates into a single service operation candidate called "Retrieve and transform invoice document." We don't mention the validation aspect of this action because the XML document automatically is assigned a corresponding schema. The validation of the document is therefore an intrinsic part of the transformation process.

The result of our analysis is a new context (a new service candidate), established to represent generic notification actions, as follows:

Polling Notification Service:

• Poll folder for new documents.
• If documents arrive for which there are subscribers, issue notifications.

The revised Invoice Processing Service list is left with just one step:

• Retrieve and transform invoice document.

Next, we tackle the operation candidates in the PO processing group. Though listed as such, the "Receive PO document" is not a suitable service operation candidate, as receiving a message is a natural part of service operations (and therefore not generally explicitly accounted for). We therefore remove this action from our list.

We then detect a direct dependency between the "If PO document is invalid, send rejection notification and end process" and "Validate PO document" actions. As a result we decide to combine these into a single operation candidate called "Validate PO document and send rejection notification, if required."

We move on to discover commonality between the "Transform PO XML document into native electronic PO format" action and the "Retrieve and transform invoice document" action from our Invoice Processing Service list. Both operation candidates transform accounting documents. We therefore decide to create a new service candidate that provides generic transformation. The result is a new grouping category:

Transform Accounting Documents Service:

• Transform XML documents to native format.
• Transform native documents to XML.

The revised PO Processing Service list is left with just one step:

• Validate PO document and send rejection notification, if required.

Finally, our last group of operation candidates is reviewed. The candidates themselves are still relatively suitable for what we intended. However, because we've abstracted these into a generic service candidate, we need to revise the wording to better reflect this. Specifically, we add a notification feature to our Metadata Checking Service candidate.

The revised Metadata Checking Service list contains the following steps:

• Check if it is time to verify TLS metadata. If required, perform metadata check.
• If metadata check fails, issue notification.

In this step we performed some major revisions to our original business process logic. The result is the creation of additional service candidates that succeed in abstracting logic in support of key service-orientation principles (Figure 12.5).

Figure 12.5. The revised set of RailCo service candidates.

 

Step 6: Identify candidate service compositions

Identify a set of the most common scenarios that can take place within the boundaries of the business process. For each scenario, follow the required processing steps as they exist now.

This exercise accomplishes the following:

• It gives you a good idea as to how appropriate the grouping of your process steps is.
• It demonstrates the potential relationship between orchestration and business service layers.
• It identifies potential service compositions.
• It highlights any missing workflow logic or processing steps.

Ensure that as part of your chosen scenarios you include failure conditions that involve exception handling logic. Note also that any service layers you establish at this point are still preliminary and still subject to revisions during the design process (as explained in the Considerations for choosing service layers section in Chapter 14).

Case Study

In Step 4 we identified a series of service candidates that form preliminary business and application service layers.

Let's recap some of the service candidates established so far.

• Legacy System Service
• Polling Notification Service
• Transform Accounting Documents Service
• Metadata Checking Service

Each of these service candidates represents generic, reusable, and business-agnostic logic. In other words, these can all be classified as application service candidates. Collectively they establish a preliminary application service layer.

But what about our business service candidates? Well, the PO Processing Service candidate still had one action associated with it, but our Invoice Processing Service operation candidates disappeared after we abstracted all of the associated process actions into separate application service candidates.

The fact that we've reduced the processing requirements of these two service candidates does not mean that we don't have a need for them. Remember that the primary role of task-centric business services is to act as controllers, composing application services to carry out the required business logic. Both the PO Processing and Invoice Processing Service candidates establish a preliminary parent business service layer and contain all of the process logic required to compose the underlying application service candidates (Figures 12.6 and 12.7).

Figure 12.6. A sample composition representing the Invoice Submission Process.

 

Figure 12.7. A sample composition representing the Order Fulfillment Process.

 

Step 7: Revise business service operation grouping

Based on the results of the composition exercise in Step 6, revisit the grouping of your business process steps and revise the organization of service operation candidates as necessary. It is not unusual to consolidate or create new groups (service candidates) at this point.

Step 8: Analyze application processing requirements

By the end of Step 6, you will have created a business-centric view of your services layer. This view could very well consist of both application and business service candidates, but the focus so far has been on representing business process logic.

This next series of steps is optional and more suited for complex business processes and larger service-oriented environments. It requires that you more closely study the underlying processing requirements of all service candidates to abstract any further technology-centric service candidates from this view that will complete a preliminary application services layer. To accomplish this, each processing step identified so far is required to undergo a mini-analysis.

Specifically, what you need to determine is:

• What underlying application logic needs to be executed to process the action described by the operation candidate.
• Whether the required application logic already exists or whether it needs to be newly developed.
• Whether the required application logic spans application boundaries. In other words, is more than one system required to complete this action?

Note that the information we gathered during Step 2 of the parent service-oriented analysis process will be referenced at this point.

Case Study

Our business process is by no means complex, and we already have identified all of the application service candidates that represent our preliminary application logic. Therefore, the remaining steps are not required for our RailCo case study.

 

Step 9: Identify application service operation candidates

Break down each application logic processing requirement into a series of steps. Be explicit about how you label these steps so that they reference the function they are performing. Ideally, you would not reference the business process step for which this function is being identified.

Step 10: Create application service candidates

Group these processing steps according to a predefined context. With application service candidates, the primary context is a logical relationship between operation candidates. This relationship can be based on any number of factors, including:

• association with a specific legacy system
• association with one or more solution components
• logical grouping according to type of function

Various other issues are factored in once service candidates are subjected to the service-oriented design process. For now, this grouping establishes a preliminary application service layer.

Step 11: Revise candidate service compositions

Revisit the original scenarios you identified in Step 5 and run through them again. Only, this time, incorporate the new application service candidates as well. This will result in the mapping of elaborate activities that bring to life expanded service compositions. Be sure to keep track of how business service candidates map to underlying application service candidates during this exercise.

Step 12: Revise application service operation grouping

Going through the motions of mapping the activity scenarios from Step 11 usually will result in changes to the grouping and definition of application service operation candidates. It will also likely point out any omissions in application-level processing steps, resulting in the addition of new service operation candidates and perhaps even new service candidates.

Optional Step: Keep an inventory of service candidates

So far, this process has assumed that this is the first time you are modeling service candidates. Ideally, when going through subsequent iterations of this process, you should take existing service candidates into account before creating new ones.

It can, however, be tricky to look for reuse opportunities when modeling documents. This is because so much of the verbiage used to describe service and service operation candidates gets lost when this information is later translated into concrete service designs. As a result, this step is considered optional. The service-oriented design processes also provide steps dedicated to checking for reuse opportunities.

Case Study

Our heavily revised and now "service-oriented" business process has resulted in the creation of two distinct preliminary service layers, each with its own set of well defined service candidates. Our service-oriented analysis has provided us with extremely useful results that we carry over to the upcoming service-oriented design process.

The modeling exercise has tentatively addressed the goals RailCo originally set for its SOA. RailCo wanted to create an environment consisting of services with processing logic that is no longer specific to one customer. This would allow RailCo to pursue new clients without having to develop new services for each one.

The extent to which application logic has been abstracted resulted in a purely reusable application services layer. These planned application services can facilitate a variety of requests from business services, including the processing of invoice and purchase order documents from other customers. However, because they are business-agnostic, they can be reused by additional types of business services as well.

RailCo has therefore taken the first step to producing an inventory of reusable services that can be leveraged by a variety of future solutions. This is demonstrated by the fact that we began with separate processes that shared no common logic and ended up with a set of abstracted service operation candidates that can be shared by these and other processes.

SUMMARY OF KEY POINTS

• Modeling services is fundamentally a process of gathering and organizing business model information.
• Business process logic can be decomposed into a series of granular steps that represent candidate service operations.
• Candidate service operations are grouped into logical contexts that represent candidate services.