ServiceOrientedDesign Short 221231 200031

13/01/54
Service-Oriented Design
Service-oriented design
The process by which concrete physical service designs are

derived from logical service candidates and then assembled
into abstract compositions that implement a business
process.
Goals are
Identify design standards of the organization and industry standards.
Define abstract service interface designs.
Identify potential service compositions.
Assess support for service-orientation principles.
1
13/01/54
Service-oriented design process (1)
Service-oriented design process (2)
Step 1: Compose SOA

Performed early before analysis if top-down strategy (or agile) is used.
Define a standard set of service layers.
Choose open technologies in support of those layers.
Steps 2-4: Design services
Rule of thumb: agnostic reusable services first (i.e. can be composed).
Design entity-centric business services, application services, task-
centric business services.
Step 3: Design service-oriented business process
Design executable definition of workflow logic that glues services.
The design phase is the first in which real technology is touched.

The primary deliverable of this stage is a physical service interface/process definition.
A decision has to be made between
- design with hand coding (with text or XML editor), giving full control for enterprise standardization.
- auto-generation by development tools, probably inserting excess markup code not tied to W3C specs. 4
2
13/01/54
Case study revisited
TLS
Timesheet submission process (process)
Employee (entity-centric)
Timesheet (entity-centric)
Invoice (entity-centric)
Notification (application)
RailCo
Invoice Processing (task-centric)
PO Processing (task-centric)
Legacy system (application)
Polling Notification (application)
Transform Accounting Documents (application)
Metadata Checking (application)
5
Entity-centric business service design (1)
iterative
3
13/01/54
Step 1: Review existing services

Check if existing services provide some or all of the functionality
identified by the operation candidates .
Check if existing services already establish a suitable context in which
the operation candidates can be implemented.
to-be-designed existing
Checking names, service descriptions, and metadata of 7

existing services, TLS concludes that no overlap exists.
Step 2: Define entity schema

Define definition of messages the service is to process (i.e. WSDL
<types> area) using XML schema.
For operation “get weekly hours
limit”.
4
13/01/54

For operation “update employee history”.
Modular design for reusability.

Separate WSDL <types> from XSD schema.
10
5
13/01/54
Step 3: Derive abstract interface

Confirm that each operation candidate is suitably reusable and its
granularity is appropriate. Then, establish a set of operation names.
Define WSDL <portType> with <operation>.
Define WSDL <message> with <part>.
11
12
6
13/01/54
Step 4: Apply service-orientation

On reusability and autonomy
o Generally, entity-centric services are generic and autonomous as they
encapsulate processing logic of particular entities and will be composed
by a parent service layer.
On statelessness
o Generally, entity-centric services do not possess much of workflow logic,
so state management should be deferred as much as possible to a parent
service layer .
On discoverability
o Supplement with metadata
13
…
Step 5: Standardize service interface

Apply appropriately any existing design standards and guidelines.
o E.g. naming convention: Service name should be noun and reflect the
original entity model. Service operation should be verb-based and not
repeat entity name.
Consider quality service design, e.g. extensibility.
14
7
13/01/54
Step 6: Extend service design

Perform speculative analysis as to what other features the service,
within its context, should offer as a complete range of common
operations.
o Add new operations (e.g. get, update, add, delete are classic operations).
o Add new parameters to existing operations (even though too many
parameters mean requestors need to know too much to use the service).
Repeat steps 1-5. Possible extension
TLS is under time pressure and will not

extend the design.
15
Step 7: Identify other required services

Study processing requirements more closely to determine if additional
application services are required to carry out each exposed
functionality.
TLS:
Employee info is in an accounting system (along with payroll data) and in an HR system.
Employee service needs to manage employee information:

-Get weekly hours limit by querying an accounting database.
-Update history by updating an HR employee profile database.
However, employee info will be exposed through a Human Resource wrapper service only (i.e.
an additional application service) as it will also facilitate Timesheet service (entity-centric).
Accessing employee info in the accounting databases will be encapsulated in the logic of
GetWeeklyHoursLimit but not through another application service.
Invoice service (entity-centric) can be fulfilled by existing Accounts Payable Service.
Only an abstract definition of WSDL is shown here. A full WSDL has to be designed. 16
8
13/01/54
Application service design (1)
Best defined by those who

understand the enterprise
technical environments
the most (i.e. business
analysis expertise not
required).
Hardest to design
because technology is
constantly upgraded or
replaced.
17
Step 1: Review existing services

Check existing services for redundant features.
Check if the required feature can be purchased or leased from
vendors.
to-be-designed
Checking names, service descriptions and metadata of existing services (i.e. TLS Subscription Service),
RailCo concludes that no overlap exists. (The other existing two, i.e. Invoice Submission Service and 18
Order Fulfillment Service, are hybrid.)
9
13/01/54
Step 2: Confirm context

Reassess service context if operation candidate grouping from the
analysis phase is appropriate, e.g. operations may better belong in
other services.
Review of Transform Accounting Documents service against TLS Subscription service confirms that
grouping context is valid.
Step 3: Derive initial interface

Confirm that each operation candidate is suitably reusable and its
granularity is appropriate.
Establish a set of operation names and define WSDL <portType> with
<operation>.
19
20
10
13/01/54
Types for TransformToXML

are identical to those of
TransformToNative and can
be shared. But RailCo
decides to keep a separate
schema to have freedom to
change them independently.
21
22
11
13/01/54
23

Revisit reusability, autonomy, statelessness, discoverability.
On reuse potential, the two operations

TransformToNative and TransformToXML are
discussed to be combined into one generic operation.
But RailCo decides to keep them both for the
descriptive nature of the operations and freedom to
evolve each of them separately.
On autonomy and statelessness, no problem as the

logic required to carry out the transformation is
contained within the a particular underlying application
logic.
On discoverability, metadata are added.
24
12
13/01/54

o E.g. naming convention: Names should be generic for high reuse
potential and clearly communicate the processing context (verb+noun or
noun).
RailCo thinks service and operation names are

already appropriate. However, the names are
changed for future extensibility. The service
becomes a transformation utility that can be
extended in the future to offer other transformation-
related features (not only for use by an accounting
system).
25
26
13
13/01/54
27
Step 6: Add speculative features

Perform speculative analysis as to what other processing falls within
the service context.
Repeat steps 1-5.
RailCo cannot afford any extension at this time. But the design of Transform service already
gives future reusability opportunity.
Only an abstract definition of WSDL is shown here. A full WSDL has to be designed.
28
14
13/01/54
Task-centric business service design (1)
Less effort required than the

previous two because reuse
is not a primary concern.
29
to-be-designed
No operation candidates means

Invoice Processing is a pure
controller, coordinating the
underlying composition.
RailCo has to define service

interface from scratch.
30
15
13/01/54
Step 1: Define workflow logic

Document each possible execution path, including exception
conditions.
The composition model from the modeling stage is a starting point.
Involve those already designed entity-centric business services and
application services.
Traditional modeling approaches can be used, e.g. UML activity
diagram.
The workflow will help with extracting message exchanges and
defining types, operations, and message formats.
31
32
16
13/01/54
Failure perhaps due to receiving an invalid document. 33
Step 2: Derive initial interface

Use application service operation candidates to derive corresponding
operations (task-centric service is carried out by underlying application
services).
Consider the workflow logic for additional operations.
34
17
13/01/54
Service acts as provider. This action Service acts as requestor. These

is expressed in service interface. actions will be implemented as
part of the service’s underlying
business logic.
35
Polling Notification Service notifies an arrival of

document files in a particular folder. It does not
retrieve and forward documents.
Notification is one-way message.
36
18
13/01/54

On reusability
o Not a priority but since task-centric service represents a portion of
workflow logic of a business process, there is a potential for cross-process
and intra-process reuse of logic.
On autonomy
o Dependent on autonomy of child services in the composition.
On statelessness
o Processing dependencies in the composition can lead to the need for
state management. RailCo has no concern
On discoverability on reusability,
autonomy, and
o Supplement with metadata statelessness for
Invoice Processing
service.
37

Apply appropriately any existing design standards and guidelines, e.g.
naming convention, granularity.
o A controller service can be coarse-grained while composed services
should be finer-grained.
Reuse schema of an invoice

document (defined as a result of
building a process logic for
Transform service).
RailCo foresees that Invoice

Processing Service should be
extended as it may accept an
invoice document as input in the
future. 38
19
13/01/54
By naming standard, change

“SubmitInvoice” to “Submit” as
to not repeat service name.
39
Step 5: Identify other required services

Determine if additional services (application, entity-centric, task-
centric) are required to carry out the task.
No need for additional services.
40
20
13/01/54
Service-oriented business process design (1)
Historically, there is a gap between a business process

modeled as a workflow logic diagram and the automated
solution that realizes it.
This gap is addressed by an operational business process
modeling language such as WS-BPEL.
The front-end is a workflow diagram expressing the business process.
The back-end is a computer executable process definition.
Modeling tools exist for modeling the business process and auto-
generation of the executable process definition.
A process service is represented by a WS-BPEL process.
41
42
21
13/01/54
to-be-designed
43
to-be-designed
44
22
13/01/54
Step 1: Map out interaction scenarios

Document all possible interaction scenarios between process and
partner services, including exception conditions.
The composition model from the modeling stage is a starting point.
Involve those already designed entity-centric business services, task-
centric business services, and application services.
Traditional modeling approaches can be used, e.g. UML activity
diagram.
The workflow will help with extracting message exchanges and
defining types, operations, and message formats.
45
46
23
13/01/54
47
Step 2: Design service interface

With process modeling tools, WSDL of the process service is typically
auto-generated. But revising the markup code or importing a WSDL
should be possible.
Consider the workflow logic to identify operations.
Define WSDL <documentation> for metadata.
Less opportunity to incorporate other steps as with other kinds of service, e.g. statelessness is difficult
to applied, given that the process service maintains state so that other services do not have to.
48
24
13/01/54
One client partner service, four partner services.
49
50
25
13/01/54
“tns:Submit”
“TimesheetSubmissionServiceProvider”>
51
Step 3: Formalize partner service conversations

Define partner services and assign each its role within a message
exchange.
Add <partnerLinkType> to the end of WSDL of each partner service.
Create <partnerLink> for each partner service within WS-BPEL
definition of the process service.
Define <variable> within WS-BPEL to represent incoming and
outgoing messages exchanged with partner services.
52
26
13/01/54
“EmployeeServiceProvider”>
Also, <plnk:partnerLinkType> is added to WSDL of Invoice, Timesheet, and Notification.

53
In WS-BPEL
TimesheetSubmissionType”
“TimesheetSubmissionServiceProvider”/>
54
27
13/01/54
In WS-BPEL
name of <message> in
Employee service
WSDL.
55
Step 4: Define process logic

Implement the workflow logic via WS-BPEL (see listing).
56
28
13/01/54
57
Step 5: Align interaction scenarios and refine process

definition (optional)
Review the interaction scenarios in step 1 and WS-BPEL for
optimization opportunities.
o Interaction scenarios are part of the solution documentation and should
be aligned with WS-BPEL.
o Review may introduce new or augmented process logic.
o Review may lead to activity restructure for performance improvements.
58
29
13/01/54
“Compare billed hours”, “Get

authorization”, and “Compare
weekly hours limit” have no
dependencies and can be
executed in parallel (use <flow>
instead of <sequence>).
“Update history” and “Send

notification” in <faultHandlers>
can be executed in parallel too.
59
30

ServiceOrientedDesign Short 221231 200031

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ServiceOrientedDesign Short 221231 200031

Uploaded by

Copyright:

Available Formats

13/01/54

The process by which concrete physical service designs are

Service-oriented design process (1)

Service-oriented design process (2)

Step 1: Compose SOA

The design phase is the first in which real technology is touched.

Case study revisited

Entity-centric business service design (1)

Entity-centric business service design (2)

Step 1: Review existing services

Checking names, service descriptions, and metadata of 7

Entity-centric business service design (3)

Step 2: Define entity schema

Entity-centric business service design (4)

Entity-centric business service design (5)

Modular design for reusability.

Entity-centric business service design (6)

Step 3: Derive abstract interface

Entity-centric business service design (7)

Entity-centric business service design (8)

Step 4: Apply service-orientation

Entity-centric business service design (9)

Step 5: Standardize service interface

Entity-centric business service design (10)

Step 6: Extend service design

TLS is under time pressure and will not

Entity-centric business service design (11)

Step 7: Identify other required services

Employee service needs to manage employee information:

Invoice service (entity-centric) can be fulfilled by existing Accounts Payable Service.

Application service design (1)

Best defined by those who

Application service design (2)

Step 1: Review existing services

Application service design (3)

Step 2: Confirm context

Step 3: Derive initial interface

Application service design (4)

Application service design (5)

Types for TransformToXML

Application service design (6)

Application service design (7)

Application service design (8)

Step 4: Apply service-orientation

On reuse potential, the two operations

On autonomy and statelessness, no problem as the

On discoverability, metadata are added.

Application service design (9)

Step 5: Standardize service interface

RailCo thinks service and operation names are

Application service design (10)

Application service design (11)

Application service design (12)

Step 6: Add speculative features

Task-centric business service design (1)

Less effort required than the

Task-centric business service design (2)

No operation candidates means

RailCo has to define service

Task-centric business service design (3)

Step 1: Define workflow logic

Task-centric business service design (4)