Case Study: TLS

• TLS example differs from the previous RailCo examples as follows: – TLS contrasts three separate approaches to modeling

their service candidates. – Two of the approaches considered involve establishing

an orchestration layer by introducing a new process service candidate.

– One of the approaches is based on the creation of entity-centric service candidates.

– TLS employs the use of the classification system, the terms used in this example differ from the RailCo example.

Copyright © Pearson Education, Inc.

Figure 12.14: The TLS Timesheet Submission Process.

This process is self-contained and has no dependencies on any other processes. Within TLS's service-oriented environment, it therefore is considered a primitive business process.

Expanding the TLS Timesheet Submission Process 1/2

• begin with the "Verify timesheet" step; – 2a. Compare hours recorded on timesheet to hours

billed to clients. – 2b. Confirm that authorization was given for any

recorded overtime hours. – 2c. Confirm that hours recorded for any particular

project do not exceed a predefined limit for that project.

– 2d. Confirm that total hours recorded for one week do not exceed a predefined maximum for that worker.

• Each of these steps is a simple action that is considered a primitive business activity

Expanding the TLS Timesheet Submission Process 2/2

• we discover that the "Reject timesheet submission" process activity can be decomposed into the following primitive business activities: – 4a. Update the worker's profile record to keep

track of rejected timesheets.

– 4b. Issue a timesheet rejection notification message to the worker.

– 4c. Issue a notification to the worker's manager.

Figures 12.15: The TLS Timesheet Submission Process, where each process activity is also a primitive business activity.

Copyright © Pearson Education, Inc.

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

These two groups adequately represent the collective business process logic and are therefore used as the source from which two corresponding service candidates are derived:

•Verify Timesheet Service •Reject Timesheet Service

Approach #1: Deriving hybrid services

Copyright © Pearson Education, Inc.

Figure 12.17: The Verify Timesheet Service candidate.

Figure 12.18: The Reject Timesheet Service candidate.

Copyright © Pearson Education, Inc.

Figure 12.19: A simple service

composition consisting of two

hybrid, task-centric service candidates.

Pros Minimal analysis and modeling effort. Results in the creation of simple and easy-to-understand service candidates. Cons No specialized service layers were created, therefore eliminating the benefit potential of service layer abstraction. No real reuse benefit is achieved, as services are very specific to a single process. No agility is achieved, as service logic is tightly coupled to process logic.

Copyright © Pearson Education, Inc.

Figure 12.20: A TLS entity-model displaying entities pertinent to the Timesheet Submission Process.

Approach #2: Deriving entity-centric services

to establish a layer of entity-centric candidates, along with a parent orchestration layer consisting of a single process service candidate.

TLS analysts study this model ...

• the following list of service operation candidates identified: – get recorded hours for customer and date range – get billed hours for customer and date range – compare recorded hours with billed hours – get overtime hours for date range – get authorization – confirm authorization – get weekly hours limit – compare weekly hours limit with hours recorded – update employee history – send message to employee – send message to manager

Copyright © Pearson Education, Inc.

Figure 12.21: The Timesheet Submission Process Service

candidate.

Figure 12.22: The Timesheet Service candidate.

more reusable by removing the requirement that a date range be the only query criteria

Copyright © Pearson Education, Inc.

Figure 12.23: The Invoice Service candidate.

Figure 12.24: The Employee Service

candidate.

Figure 12.25: The Notification Service

candidate.

“get billed hours for customer and date range”

“send message to employee” “send message to manager”

Copyright © Pearson Education, Inc.

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

Pros Allows for the creation of reusable service candidates. Establishes an extra level of abstraction via the orchestration layer. Highly extensible and agile. Cons Requires more analysis effort. Results in a more complex service composition. Requires the creation of additional services not yet identified (application services needed to carry out processing tasks for the Employee, Timesheet, and Invoice services).

Copyright © Pearson Education, Inc.

Figure 12.27: The Verify Timesheet Service candidate.

Approach #3: Mixing task-centric and entity-centric services

It has been discovered that there is reuse potential for the collection of verification tasks associated with the Timesheet Submission Process.

identify and group the verification tasks into a new service candidate called Verify Timesheet

Copyright © Pearson Education, Inc.

Figure 12.28: The revised service composition incorporating a task-

centric service.

Pros Similar benefits of agility and extensibility to the entity-centric only approach. If the Verify Timesheet sub-process is truly reusable, there may be a benefit to abstracting it from larger process workflow logic. Cons Results in an even more complex composition that introduces an additional layer of processing. Removal of workflow logic from the process service decentralizes control of the overall Timesheet Submission Process.