UNIT 3

Page 1
 UNIT 3

Service oriented analysis

Business-centric SOA
Deriving business services
service modeling
Service Oriented Design
WSDL basics
SOAP basics
SOA composition guidelines
Entity-centric business service design
Application service design
Task-centric business service design

Page 2
 service-oriented analysis

Business-centric SOA
Deriving business services
service modeling

Page 3
 service-oriented analysis
The process of determining how business automation
requirements can be represented through service-
orientation.

Goals :
Define a preliminary set of service operation candidates.

Group service operation candidates into logical contexts.

These contexts represent service candidates.

Define preliminary service boundaries so that they do not

overlap with any existing or planned services.

Identify encapsulated logic with reuse potential.

Define any known preliminary composition models.

Page 4
 The service-oriented analysis process
Every organization has developed its own
approach to analyzing business automation
problems and solutions, and years of effort
and documentation will have been invested
into well-established processes and modeling
deliverables.

From an analysis perspective, each layer has

different modeling requirements

Page 5
 Questions that should be answered prior to
proceeding with the service-oriented analysis
include:

What outstanding work is needed to establish the

required business model(s)?

What modeling tools will be used to carry out the

analysis?

Will the analysis be part of an SOA transition plan?

Page 6
The service-oriented analysis process is a
sub-process of the overall SOA delivery
lifecycle

Page 7
 Step 1: Define business automation requirements
business requirements are normally collected, their documentation is
required for this analysis process to begin. Requirements related to the
scope of that solution should be considered.

Business requirements should be sufficiently mature so that a high-level

automation process can be defined. This business process
documentation will be used as the starting point of the service modeling
process described in Step 3.

Step 2: Identify existing automation systems

Existing application logic that is already, to whatever extent, automating
any of the requirements identified in Step 1 needs to be identified.
This information will be used to help identify application service
candidates during the service modeling process described in Step 3.

Step 3: Model candidate services

A service-oriented analysis introduces the concept of service modeling
process by which service operation candidates are identified and then
grouped into a logical context.

Page 8
Benefits of a business-centric SOA

Business services build agility into business

models
Service-orientation brings to business process models
a structure that can significantly improve the flexibility
and agility with which processes can be remodeled in
response to changes.

When properly designed, business services can

establish a highly responsive information technology
environment

Page 9
Page 10
 Business services prepare a process for
orchestration
Moving to an orchestration-based service-oriented environment
anytime soon, modeling current processes so that they
eventually can be more easily migrated to an orchestration-
driven environment is recommended.

Business services enable reuse

The creation of a business service layer promotes reuse in both
business and application services, as follows:

By modeling business logic as distinct services with explicit

boundaries, business process-level reuse can be achieved. Atomic
sub-process logic or even entire processes can be reused as part of
other process logic or as part of a compound process.

The resulting business service layer ends up freeing the entire

application service layer from activity-specific processing functions.

Page 11
 Only business services can realize the
service-oriented enterprise
Business service modeling marries the principles of
service-orientation with an organization's business
model.

Applying business services forces an organization to

view and reinterpret business knowledge in a service-
oriented manner.

Altering the perspective of how business processes

can be structured, partitioned, and modeled is an
essential step to achieving an environment in which
service-orientation is standardized, successfully
consistent, and naturally commonplace.

Page 12
 Deriving business services

every business model is unique.

To properly derive business services that

best represent an organization as a
cohesive business entity.

Page 13
 Sources from which business services can be
derived

The inner workings of any organization,

regardless of structure or size, can be
decomposed into a collection of business
services. A business service simply represents a
logical unit of work, and pretty much anything
any organization does consists of units of work.

The service-orientation-aware analyst to

determine how to best map existing logic to
services.

Page 14
 Business Process Management (BPM) models
It is an industry-wide process modeling and remodeling
activity.

Process models have become a central form of business

analysis documentation in many organizations.

Business services can be derived from process workflow

logic.
Entity models
Primary entities represent the main business documents and
transaction areas of an enterprise.

Entity-centric services mirror the entity model by containing a

set of generic operations that facilitate the different types of
functions associated to the processing of the entity.

Page 15
 Types of derived business services
Task-centric business services
These are Web services that have been modeled to
accommodate a specific business process. Operations are
grouped according to their relevance to the execution of a
task in support of a process.
examples of task-centric business services are:
VerifyInvoice
GetHistoryReport
Task-centric services usually result from modeling
exercises that are focused on meeting immediate
business requirements.

Typical sources include use-case models and BPM

process definitions.

Page 16
 Entity-centric business services
Entity-centric business services are produced as part of a long-term or on-
going analysis effort to align business services with existing corporate
business models.

entity-centric business services often are built as part of application

development projects centered around a particular business process, they
differ from task-centric services in that they do not provide an interface
specific to that process.

When the process logic changes, the context under which the services are
used and composed may change as well. This may invalidate the original
grouping of service operations and could result in the requirement for a
redesign and redevelopment effort.

Their use may become dependent on parent business controllers, such as

process services or task-centric controller services.

building a business service layer consisting of a series of entity-centric

services composed by a parent orchestration service layer establishes a
desirable SOA,

It promoting a high degree of agility and accurate business model

representation.
Page 17
Page 18
 Service modeling (a step-by-step process)

A service modeling process is an exercise

in organizing the information we gathered
in parent service-oriented analysis
process.

Process description
Process provides steps for the modeling of an
SOA consisting of application, business, and
orchestration service layers.

Page 19
Page 20
 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

Page 21
 Decomposing the Invoice Submission
Process

Page 22
Page 23
 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.

Page 24
 Step 3: Abstract orchestration logic
To build an orchestration layer as part of SOA, then It
should identify the parts of the processing logic that
this layer would potentially abstract.
Potential types of logic suitable for this layer include:
business rules
conditional logic
exception logic
sequence logic
These forms of orchestration logic may or may not be
represented accurately by a step description.

Example
some processing step descriptions consist of a condition and
an action. In this case, only remove the condition and leave
the action.

Page 25
 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 end up with will depend on the
types of business services have chosen to
build.

Page 26
 Step 5: Refine and apply principles of
service-orientation

grouped processing steps derived from an

existing business process.

It 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.

Page 27
 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.

This exercise accomplishes the following:

It gives a good idea as to how appropriate the
grouping of 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.

Page 28
 Step 7: Revise business service operation
grouping
Based on the results of the composition
exercise in Step 6, revisit the grouping of
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.

Page 29
 Step 8: Analyze application processing
requirements
This view could very well consist of both
application and business service candidates.

This next series of steps is optional and more

suited for complex business processes and
larger service-oriented environments.

It requires that more closely study the

processing requirements of all service
candidates to abstract any further technology-
centric service candidates
Page 30
 Step 9: Identify application service operation
candidates
Break down each application logic processing
requirement into a series of steps. Ideally, It 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
Page 31
 Step 11: Revise candidate service compositions
Revisit the original scenarios identified in Step 5 and run through
them again. Only, this time, incorporate the new application
service candidates as well.

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
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.

Page 32
 Service Oriented Design

WSDL basics
SOAP basics

Page 33
 Entity-centric business service
design
Entity-centric business services represent data
entities defined within an organization's business
models.

These services are built for reuse by any

application that needs to access or manage
information associated with a particular entity.

Design standards are applied equally to all

service operations and that all processing
requirements are accurately identified.

Page 34
Page 35
Page 36
 Step 1: Review existing services
The first step in designing a new service is to
confirm whether it is actually even necessary.

If other services exist, they may already be

providing some or all of the functionality
identified in the operation candidates or they
may have already established a suitable
context in which these new operation
candidates can be implemented

Page 37
 Step 2: Define the message schema types
It is useful to begin a service interface design with a formal
definition of the messages the service is required to
process that are defined within the WSDL types area.

SOAP messages carry data within the Body section of the

SOAP envelope. This data needs to be organized and
typed. For this we rely on XSD schemas. A standalone
schema actually can be embedded in the types construct.

In the case of an entity-centric service, the XSD schema

used to represents the information associated with this
service's entity.

The "entity-centric schema" can become the basis for the

service WSDL definition, as most service operations will be
expected to receive or transmit the documents defined by
this schema.
Page 38
Case study

Page 39
The Employee schema providing complexType constructs used to
establish the data representation anticipated for the "Get weekly hours
limit" operation candidate

Page 40
Page 41
Page 42
 Step 3: Derive an abstract service interface
Confirm that each operation candidate is suitably
generic and reusable.

Create the portType (or interface) area within the

WSDL document and populate it with operation
constructs that correspond to operation candidates.

Formalize the list of input and output values required

to accommodate the processing of each operation's
logic. This is accomplished by defining the
appropriate message constructs that reference the
XSD schema types within the child part elements.

Page 43
Page 44
Page 45
 Step 4: Apply principles of service-
orientation
service reusability
service autonomy
service statelessness
service discoverability
operations exposed by entity-centric
business services are intended to be
inherently generic and reusable (the use
of the import statement is encouraged to
reuse schemas and create modular WSDL
definitions).

Page 46
Page 47
 Step 5: Standardize and refine the service
interface
Review existing design standards and guidelines and
apply any that are appropriate.

In addition to achieving a standardized service

interface design, this step also provides an
opportunity for the service design to be revised in
support of some of the contemporary SOA
characteristics .

Design requirements include WS-I Basic Profile

conformance, then that can become a consideration
at this stage.

Page 48
Page 49
Page 50
 Step 6: Extend the service design

There are two common ways to implement

new functionality:
add new operations
add new parameters to existing operations

Page 51
Page 52
Page 53
 Step 7: Identify required processing
While the service modeling process from our
service-oriented analysis may have identified
some key application services, it may not
have been possible to define them all.

Page 54
Application service design

Page 55
 Application service design
It represent the bottom sub-layer of the composed
service layer responsible for carrying out processing
demands by the business and orchestration layers.

The application service layer is a pure, service-oriented

abstraction of an organization's technical environments

real-world and technology-specific considerations that

need to be taken into account, application services can
be the hardest type of service to design.

The context established by these services can be

constantly challenged, as technology is upgraded or
replaced, and as related application logic is built or
altered.

Page 56
The application service design process.

Page 57
 Both application and entity-centric
services establish reusable service logic
and rely on parent controllers to compose
them into business process-specific tasks.

Application services are responsible for

implementing the processing details
required to carry out the business logic of
their parent business services.

Page 58
 Step 1: Review existing services
it is important to ensure that the functionality required,
as per the application service candidate, it is very
necessary to review existing inventory of application
services in search of anything resembling what are
about to design.

It provide such generic functionality, investigating

whether the features require can be purchased or
leased from third-party vendors.

Application services should be designed for maximum

reusability, third-party Web services can make a great
deal of sense, as long as required quality of service
levels can be met.

Page 59
 Step 2: Confirm the context
it is important that the operation candidate
grouping proposed by service candidates be
re-evaluated and compared with existing
application service designs.

Upon reassessing the service context, may

find that one or more operations actually
belong in other application services.

Page 60
 Step 3: Derive an initial service interface
Analyze the proposed service operation candidates and
follow the steps to define the first cut of the service
interface:

Using the application service candidate as primary input, ensure

that the logic partitions represented by the operation candidates
are appropriately generic and reusable.

Document the input and output values required for the

processing of each operation candidate and define message
structures using XSD schema constructs.

Complete the abstract service definition by adding the portType

(or interface) area and the necessary message constructs
containing the part elements that reference the appropriate
schema types.

Page 61
Page 62
The XSD schema types required by the TransformToNative
operation.

Page 63
The additional types for use by the TransformToXML
operation

Page 64
The message and
portType constructs
of the abstract
Transform
Accounting
Documents Service
definition.

Page 65
 Step 4: Apply principles of service-
orientation
This step highlights the four principles of
service-orientation
service reusability
service autonomy
service statelessness
service discoverability

Page 66
 Case Study
The Transform Accounting Documents Service
undergoes a review to ensure that it is properly
incorporating service-orientation principles.

First, the reuse potential of its two operations is

assessed:
TransformToNative
TransformToXML

it is agreed that to better accommodate future

discoverability, the service definition be outfitted with
additional metadata documentation

Page 67
The Transform Accounting Documents portType construct
with supplemental metadata documentation.

Page 68
 Step 5: Standardize and refine the service
interface
We accomplish this by ensuring that the resulting
application service WSDL definition is based on the
same standards and conventions used by others.

list of recommended actions can take to achieve a

standardized and streamlined service design:
Apply any existing design standards relevant to the service
interface.
Review any of the SOA characteristics chosen to have
services support and assess whether it is possible to build
support for this characteristic into this service design.
Optionally incorporate WS-I Basic Profile rules and best
practices to whatever extent possible.

Page 69
 Case study
Upon a review of the service design, increased extensibility is
achieved with the following adjustments:
The service name is changed again, this time shortened to just
"Transform."
The TransformXMLToNative and TransformNativeToXML operations
are renamed to something more generic. The new names are
ForAccountingImport and ForAccountingExport

Page 70
 Step 6: Outfit the service candidate with
speculative features
In delivering highly reusable application services, can
take this opportunity to add features to this service
design.

These new features can affect existing operations or

can result in the addition of new operations.

For application services, speculative extensions

revolve around the type of processing that falls within
the service context.

Page 71
 Step 7: Identify technical constraints

We now need to study and document the processing demands of

each service operation. First, for each operation, write a list of the
processing functions required for the operation to carry out its
processing. Then, for every entry on this list, find out exactly how
the processing of the function will need to be executed in the
existing technical environment.

The types of details are specifically looking for are:

The physical connection point of the particular function.
Security constraints related to any part of the processing.
Response time of each processing function.
Availability of the underlying system performing the processing
function.
Environmental factors relating to service deployment location.
Technical limitations of underlying application logic .
Administration requirements imposed by the service.
Potential SLA requirements.

Page 72
Task-centric business service
design

Page 73
 Task-centric business service
design
only the service operation candidates
identified as part of the service modeling
process are addressed here.

Business process-specific logic into task

services, the opportunity to increase the
amount of agnostic logic within services
based on entity and utility service models
is improved

Page 74
Page 75
 Process description
task-centric business
services contain and
govern portions of
business processes.

Page 76
Case Study

Page 77
 A service candidate with no operation candidates 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.

Page 78
 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 is to define this logic for every

possible interaction scenario we can imagine.

Page 79
 Case Study
RailCo generates activity diagrams for all
interaction scenarios involving the Invoice
Processing Service.

Figure illustrates the conditions and message

exchanges required to successfully complete
the invoice submission

Page 80
Page 81
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.

Page 82
 Step 2: Derive the service interface
1. Use the application service operation candidates to
derive a set of corresponding operations.
2. The activity diagrams and the workflow logic we
documented in Step 1 gives us a good idea as to what
additional operations for 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

Page 83
Case study

Page 84
Page 85
 by creating a preliminary types construct with the following
complexType to match these parameter requirements:
A complexType construct designed to receive two parameters from the
Polling Notification Service.

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

The remaining parts of the abstract Invoice Processing Service

definition establishing an operation with just one input message.

Page 87
 Step 3: Apply principles of service-orientation

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 cross-
process reusability of the logic being encapsulated and Consider the
potential intra-process reusability of the logic being encapsulated .

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.

Task-centric services contain workflow logic. 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 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 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 is recommended.

Page 88
 The portType construct with an additional documentation
element.
The portType construct with an additional documentation element.

Page 89
 Step 4: Standardize and refine the
service interface
Incorporate existing design standards and
guidelines.
Ensure that any chosen contemporary SOA
characteristics are fully supported by the
service interface design.
Take WS-I Basic Profile standards and best
practices into account.

Page 90
The revised types construct of the Invoice Processing
Service definition

Page 91
The documentation element contents also have been
changed

Page 92
Page 93
 Step 5: Identify required processing

The implementation of a task-centric service

interface requires that any needed underlying
service layers are in place to support the
processing requirements of its operations.

three service design processes, all required

supporting aplication services need to be
identified. They may consist of services that
already existed and/or services we just
designed during the previous application
service design process.
Page 94
 Case study

The final abstract service definition.

Page 95
 service candidate

The service candidate term is a

conceptualized service from an actual
implemented service.

Page 96
Introduction to service-oriented analysis ge :

Page 97
Second Page :
"Lorem ipsum dolor sit amet, consectetur
adipisicing elit, sed do eiusmod tempor incididunt
ut labore et dolore magna aliqua. Ut enim ad
minim veniam, quis nostrud exercitation ullamco
laboris nisi ut aliquip ex ea commodo consequat.
Duis aute irure dolor in reprehenderit in voluptate
velit esse cillum dolore eu fugiat nulla pariatur.
Excepteur sint occaecat cupidatat non proident,
sunt in culpa qui officia deserunt mollit anim id est
laborum."

Page 98