Task-centric business service design (a step-by-step process)

The process for designing task-centric services usually require less effort than the previous two design processes, simply because reuse is generally not a primary consideration. Therefore, only the service operation candidates identified as part of the service modeling process are addressed here.

Figure 15.15. Task-centric business services can comprise the business service layer, along with entity-centric neighbors.

 

15.4.1. Process description

As shown in Figure 15.16, this process starts off with a new kind of step in which workflow logic is mapped out. This is because task-centric business services are expected to contain and govern portions of business processes.

Figure 15.16. The task-centric business service design process.

Note that there is no step encouraging you to extend the service design beyond the feature set you already defined in the service modeling stage. As previously mentioned, providing a generic and reusable interface is not a priority for task-centric services.

Time now to begin our service design.

Case Study

The RailCo service modeling process identified the need for a task-centric business service to govern the processing of invoices produced by the legacy accounting system. This resulted in the Invoice Processing Service candidate shown in Figure 15.17.

Figure 15.17. The Invoice Processing Service candidate.

 

At first it appears as though this service does not contain much of anything. This is actually not unusual for smaller scale task-centric services. A service candidate with no operation candidates simply means that this service is a pure controller, solely dedicated to coordinating the underlying service composition. It also means that RailCo will need to define its service interface from scratch during this design process.

Fortunately, there is a starting point, provided by the composition model (Figure 15.18) produced during Step 6 of the service modeling process from Chapter 12.

Figure 15.18. The Invoice Processing Service composition.

 

It looks like the Invoice Processing Service actually will be quite busy, as it needs to compose up to four separate services to process a single invoice submission.

 

Step 1: Define the workflow logic

Task-centric services typically will contain embedded workflow logic used to coordinate an underlying service composition. Our first step, therefore, is to define this logic for every possible interaction scenario we can imagine. If you performed the mapping exercise in the Identify candidate service compositions step of the service modeling process in Chapter 12, then you will have preliminary composition details already documented.

Because we are designing our task-centric business service after our entity-centric and application service designs have been completed, we will need to revisit these scenario documents and turn them into concrete service interaction models.

Different traditional modeling approaches can be used to accomplish this step (we use simple activity diagrams in our case study examples). The purpose of this exercise is to document each possible execution path, including all exception conditions. The resulting diagrams also will be useful input for subsequent test cases.

Note

The workflow logic does not reside in the service interface we are designing in this process. We are defining workflow logic for the purpose of extracting the message exchanges with which this service will be involved. This provides us with information that helps us define types, operations, and message formats.

Case Study

RailCo generates activity diagrams for all foreseeable interaction scenarios involving the Invoice Processing Service. Let's have a look at two of these diagrams.

Figure 15.19 illustrates the conditions and message exchanges required to successfully complete the invoice submission.

Figure 15.19. A successful completion of the Invoice Submission Process.

 

Figure 15.20 shows how a failure condition stops the process dead in its tracks. In this case, the Transformation Service returns an error, perhaps due to receiving an invalid document.

Figure 15.20. A failure condition caused by an error during the transformation step.

 

Step 2: Derive the service interface

Follow these suggested steps to assemble an initial service interface:

1.

Use the application service operation candidates to derive a set of corresponding operations.

 

2.

Unlike previous design processes, the source from which we derive our service interface this time also includes the activity diagrams and the workflow logic we documented in Step 1. This information gives us a good idea as to what additional operations our task-centric service may require.

 

3.

Document the input and output values required for the processing of each operation and populate the types section with XSD schema types required to process the operations.

 

4.

Build the WSDL definition by creating the portType (or interface) area, inserting the identified operation constructs. Then add the necessary message constructs containing the part elements that reference the appropriate schema types.

 

Case Study

Because our service candidate provided us with no operation candidates, RailCo turns to the activity diagrams it created to derive the set of actions the service is required to perform (Figure 15.21):

  • Start RailCo Invoice Processing Receives the notification message sent by the Polling Notification Service, which kicks off the RailCo Invoice Submission Process.

  • Transform Invoice Issues a request for the Transform Service to retrieve the invoice document from the network folder and transform it into XML.

  • Check TLS Metadata Issues a request to the Metadata Checking Service for it to determine whether it's time to perform a metadata check (and then perform the metadata check, if required).

  • Start TLS Invoice Processing Forwards the invoice document to TLS, which initiates the separate TLS invoice processing process.

Figure 15.21. Identified requests and responses for the Invoice Processing Service.

 

Of these actions, the latter three require that the service act as a requestor to initiate a message exchange with other services. These actions therefore will be implemented as part of the service's underlying business logic.

The "Start RailCo Invoice Submission Process" action, though, is initiated by the Polling Notification Service, meaning that the Invoice Processing Service receives the request while acting as the service provider. This action therefore needs to be expressed in the service interface.

First, the naming is reconsidered to something more appropriate, as shown in Figure 15.22.

Figure 15.22. The Invoice Processing Service with a new operation.

 

Carrying forward with this naming change, RailCo begins by defining the data exchange requirements for this one operation. The service interface design needed to interact with the Polling Notification Service requires an ID value, along with the location path of the invoice document file to be supplied. (This is because the Polling Notification Service does not actually physically retrieve and forward documents; it simply notifies other services of the arrival of specific types of files in a particular folder.)

RailCo starts by creating a preliminary types construct with the following complexType to match these parameter requirements:

Example 15.15. A complexType construct designed to receive two parameters from the Polling Notification Service.

   

Next, it defines the operation and its associated message within the portType and message constructs:

Example 15.16. The remaining parts of the abstract Invoice Processing Service definition establishing an operation with just one input message.

<input message="tns:receiveSubmitInvoiceMessage"/>  

Note that because the message sent by the Polling Notification Service is based on the one-way MEP, the SubmitInvoice operation construct contains one input message element and no output elements.

 

Step 3: Apply principles of service-orientation

Before we get too far ahead in our service design, it is beneficial to take another look at the four service-orientation principles we covered in Chapter 8, which are not automatically provided to us through the use of Web services (service reusability, service autonomy, service statelessness, and service discoverability).

Reuse opportunities for task-centric services are much more rare than for entity-centric and application services. This is because task-centric services represent a portion of workflow logic specific to a business process. However, reuse still can be achieved. The Take into account the potential cross-process reusability of the logic being encapsulated and Consider the potential intra-process reusability of the logic being encapsulated modeling guidelines in Chapter 12 address this and still are applicable to this process.

Because they almost always act as parent controller services in compositions, the autonomy of task-centric services is generally dependent on the autonomy of the underlying child services. A consistent state of autonomy can therefore be challenging to maintain.

Task-centric services contain workflow logic that may impose processing dependencies in service compositions. This can lead to the need for state management. However, the use of document-style SOAP messages allows the service to delegate the persistence of some or all of this state information to the message itself.

It is always useful for services to be discoverable, but the need for task-centric services to be discovered is not as pressing as with other, more generically reusable services. Regardless, task-centric services can achieve reuse, and their existence should be known to others. Therefore, the Document services with metadata guideline provided at the end of this chapter also is recommended.

Case Study

There is no requirement for the Invoice Processing Service to be reusable, and autonomy and statelessness are also not considered immediate concerns. As with the RailCo Transform Service that was designed previously, this service design is supplemented with additional metadata documentation to support discoverability.

Example 15.17. The portType construct with an additional documentation element.

<documentation> Initiates the Invoice Submission Process.

Related

Категории

© amp.flylib.com,