You are on page 1of 61

CT30A8901

Chapter 12 Service Oriented Analysis Service Modeling


Prof. Jari Porras Communications Software Laboratory

Contents 12.1 Service modeling 12.2 Service modeling guidelines 12.3 Classifying service model logic 12.4 Contrasting service modeling approaches

Service Modeling

Fundamentally a process of gathering and organizing business model information Services Candidates + Service Operation Candidates = Service Modeling

Copyright Pearson Education, Inc. Figure 12.1: A sample service modeling process.

Step 1 Decompose business process Take a documented business process and break it down into a series of granular steps

Step 1 Case Study on Invoice Submission Process Create electronic invoice Issue electronic invoice Export electronic invoice to network folder Poll network folder Retrieve electronic invoice Transform electronic invoice document Check validity of invoice document. If invalid, end. Check if it is time to verify TLS metadata If required, perform metadata check. If metadata check fails, end process

Copyright Pearson Education, Inc.

Copyright Pearson Education, Inc.

Step 2 Filter out steps not suitable for service encapsulation Exclude manual processes and legacy component that is not fit for service encapsulation Leave processing steps that are most relevant to our service modeling process

Step 2 Case Study on Invoice Submission Process Filter out create electronic invoice manual process Filter out issue electronic invoice manual process

Step 3 Identify agnostic service candidates Use top down analysis (chapter 10) as a starting point Identify or create a set of contexts that is agnostic but relevant to business process in step 1 & 2 Group similar actions to the same service context accordingly

Figure 12.4.1: Our first set of agnostic service candidates.

Copyright Pearson Education, Inc.

Step 4 Identify process-specific logic

The actions remain after completing step 3 should represent logic that is specific to the task Examples:
Process specific business rules Conditional logic Exception logic Logic that dictates the sequence in which other actions should be carried out

Step 4 Case Study on Invoice Process Service candidate Invoice Processing Service Candidate Poll network folder for invoice Retrieve electronic invoice Transform electronic invoice to XML document Check validity of invoice document. If invalid, end process

Figure 12.4.2: The first versions of two task-centric business service candidates.

Copyright Pearson Education, Inc.

Step 5 Apply Service Orientation Principles

2 Significant Principles Reusability Autonomy

Step 5 Case Study

Using legacy system service candidate as an example, to improve reusability, it now include the following service operation candidates instead.
Export document to network folder Import and forward document to work queue

Copyright Pearson Education, Inc.

Step 6 Identify candidate service compositions

Help determine how appropriate the grouping of service operation candidates Demonstrate the potential relationships between service layers Figure 12.7 depicts the composition representing the Order fulfillment process Figure 12.6 depicts the composition representing the Invoice submission process

Step 6 Case Study on Invoice Process Service Using Invoice process service candidate as an example, Invoice process candidate is the preliminary parent business service layer and contain all of the process logic required to compose the underlying application service candidates Application service candidates are: Legacy System service Polling Notification service Transform Accounting Docs service Metadata checking service

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

Copyright Pearson Education, Inc.

Figure 12.7: A sample composition representing the Order Copyright Pearson Fulfillment Process. Education, Inc.

Step 7 Analyze application processing requirements Require us study the underlying processing requirements of each service operation candidate to abstract any further processing that could be potentially be added to the preliminary application service layer

Step 8 Identify application service operation candidates This can be done by breaking down each application logic processing requirement into one or more processing steps

Step 9 Define application service candidate The processing steps now need to be grouped according a logic context The primary context is processing-centric We are looking for a logical relationship derived from commonality between the processing functionality represented by the service operation candidates

Step 10 Apply service-orientation principles It is essentially a repeat of step 5 but specifically apply to the new application service candidates we have defined through step 7-9.

Step 11 Revise candidate service compositions

Run step 6 on the new application service and operation candidates

Step 12 Revise service operation candidate grouping Going through the motions of mapping the activity scenarios from step 11 will usually result in changes to grouping and definition of service operation candidates

Service modeling guidelines Help ensure that your service candidates attain a balance of proper logic encapsulation and adherence to service orientation principles

1. Potential cross-process reusability

Figure 12.8: Service logic being reused across processes. Copyright Pearson Education, Inc.

2. Potential intra-process usability

3. Factor in process-related dependencies Break the process into granular steps Look for input values upon which business rules, formulas, conditional statements, or other type of workflow logic are dependent

4. Model for cross-application reuse The more generic an application service candidate is, the more reusable it becomes A business-agnostic design allows it to fullfill numerous potential requirements through reuse by multiple business service candidates across different solution boudaries

5. Speculate on further decomposition requirement Even though immediate business requirements maybe satisfied by your existing service candidates, it may be worth determining if the business logic you are encapsulating can be broken down into additional, more granular service candidates

6. Identify logical units of work with explicit boundaries Golden rule of service modeling The boundary claims a level of independence from the underlying business or application logic

7. Prevent logic boundary creep Steps to prevent boundary creeping Check available metadata documentation of existing services prior to defining new service candidates Implement a set of standards to be used by all those that model services Raise an awareness of this issue among all of those involved with business process and service modeling

8. Emulate process services when not using orchestration

Create parent business service candidates to act like the process service that would normally form the orchestration service layer By creating a master controller business service that simulate a process service, you end up complementing this service with business and application services that fit nicely into the orchestration composition model

Figure 12.10: A parent business service layer acting as an orchestration Pearson Copyright layer. Education, Inc.

9. Target a balance model Influences by fundamental goal of SO introduce conflicting modeling requirements. It is most important to achieve a balance in your service candidates that accomplishes your goals, as you have prioritized them.

10. Classify service logic Be clear on how different types of service candidates relate to each other and on how you identify and compose service candidates This will prevent you model becoming confusing and inconsitent

11. Allocate appropriate modeling resources Technical architects and developers typically do not prossess the depth of business knowledge Business analyst often need to get involved in the service modeling process for it to be successful

12. Create and publish business service modeling standards It is highly recommended that you formalize guidelines you follow as office modeling standards.

Figure 12.11: This intentionally simplistic diagram highlights the type of expertise recommended for modeling service layers.

Copyright Pearson Education, Inc.

Classifying service model logic Building blocks Service modeling units SOE model Enterprise business model Basic modeling building blocks Activity Service Process

Figure 12.12: The SOE model. Copyright Pearson Education, Inc.

Case study TLS Timesheet submission system Three approaches Hybrid services Entity-centric services Mixing

Figure 12.14: The TLS Timesheet Submission Process.

Copyright Pearson Education, Inc.

Copyright Pearson Education, Inc.

Figure 12.16: An ad-hoc grouping of primitive business activities.

Copyright Pearson Education, Inc.

Figure 12.17: The Verify Timesheet Service candidate.

Copyright Pearson Education, Inc.

Copyright Pearson Figure 12.18: The Reject Timesheet Service candidate. Education, Inc.

Figure 12.19: A simple service composition consisting of two hybrid, taskcentric service candidates.

Copyright Pearson Education, Inc.

Figure 12.20: A TLS entity-model displaying entities pertinent to the Timesheet Copyright Pearson Submission Process. Education, Inc.

Copyright Pearson Figure 12.21: The Timesheet Submission Process Service Education, Inc. candidate.

Copyright Pearson Figure 12.22: The Timesheet Service candidate. Education, Inc.

Copyright Pearson Figure 12.23: The Invoice Service candidate. Education, Inc.

Figure 12.24: The Employee Service candidate.

Copyright Pearson Education, Inc.

Copyright Pearson Figure 12.25: The Notification Service candidate. Education, Inc.

Figure 12.26: A service composition controlled by an orchestration layer.

Copyright Pearson Education, Inc.

Copyright Pearson Figure 12.27: The Verify Timesheet Service candidate. Education, Inc.

Figure 12.28: The revised service composition incorporating a taskcentric service.

Copyright Pearson Education, Inc.

You might also like