WWW.VIDYARTHIPLUS.

COM

The service-oriented analysis process

The service oriented analysis is the process of determining how business automation
requirements can be represented through service-orientation.
The overall goals of performing a service oriented analysis are as follows:
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.
Ensure that the context of encapsulated logic is appropriate for its intended use.
Define any known preliminary composition models.
A high-level service-oriented analysis process.

WWW.VIDYARTHIPLUS.COM

V+ TEAM

WWW.VIDYARTHIPLUS.COM
Step 1: Define business automation requirements

Through whatever means business requirements are normally collected, their documentation is
required for this analysis process to begin. Given that the scope of our analysis centers around
the creation of services in support of a service-oriented solution, only 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. While a service-oriented analysis will not determine
how exactly Web services will encapsulate or replace legacy application logic, it does assist us in
scoping the potential systems affected.
The details of how Web services relate to existing systems are ironed out in the service-oriented
design phase. For now, this information will be used to help identify application service
candidates during the service modeling process described in Step 3.
Note that this step is more geared to supporting the modeling efforts of larger scaled serviceoriented solutions. An understanding of affected legacy environments is still useful when
modeling a smaller amount of services, but a large amount of research effort would not be
required in this case.
Step 3: Model candidate services

A service-oriented analysis introduces the concept of service modeling a process by which

service operation candidates are identified and then grouped into a logical context. These groups
eventually take shape as service candidates that are then further assembled into a tentative
composite model representing the combined logic of the planned service-oriented application.

WWW.VIDYARTHIPLUS.COM

V+ TEAM

WWW.VIDYARTHIPLUS.COM
WSDL language basics

The Web Services Description Language (WSDL) is the most fundamental technology standard
associated with the design of services. WSDL definitions are a central part of all aspects of
service design.
The structure of a WSDL definition.

The definitions element

This is the root or parent element of every WSDL document. It houses all other parts of the
service definition and is also the location in which the many namespaces used within WSDL
documents are established.
A definitions element of the Employee Service, declaring a number of namespaces.
<definitions name="Employee"
targetNamespace="http://www.xmltc.com/tls/employee/wsdl/"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:act="http://www.xmltc.com/tls/employee/schema/accounting/"
xmlns:hr="http://www.xmltc.com/tls/employee/schema/hr/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://www.xmltc.com/tls/employee/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
...
</definitions>

The types element

The types construct is where XSD schema content is placed. This part of the WSDL can consist
of actual XSD schema markup (an entire schema construct containing type definitions), or it can
WWW.VIDYARTHIPLUS.COM

V+ TEAM

WWW.VIDYARTHIPLUS.COM

contain import elements that reference external schema definitions.

The WSDL types construct populated by XSD schema types used by the message construct to
represent the SOAP message body.

The SOAP message body contains XML content that can represent anything from simple
parameter data to complex business documents. This content can be formally defined through
types provided by the WSDL types area. Therefore, XSD schema complexType elements are
commonly provided here, as they consist of groups of related types that can represent entire
message body structures.
In the following example, an entire schema construct is embedded within the WSDL types
construct.
A types construct containing an XSD schema construct in which a complexType is defined.
<types>
<schema
xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace=
"http://www.xmltc.com/railco/transform/schema/">
<complexType name="ReturnCodeType">
<sequence>
<element name="Code" type="xsd:integer"/>
<element name="Message" type="xsd:string"/>
</sequence>
</complexType>
</schema>
</types>

Use of the types construct is common in WSDL definitions with substantial content. However,
it is not a required element. Native XSD schema types can be referenced directly within the
message element, as explained next.
WWW.VIDYARTHIPLUS.COM

V+ TEAM

WWW.VIDYARTHIPLUS.COM

The message and part elements

For every message a service is designed to receive or transmit, a message construct must be
added. This element assigns the message a name and contains one or more part child elements
that each are assigned a type. message elements later are associated to operation elements to
establish the input and output messages of the operation.
part elements use the type or element attributes to identify the data type of the message part.
The type attribute can be assigned a simple or complex type and generally is used for RPC-style
messages. part elements in document-style messages typically rely on the element attribute,
which can reference an XSD element element. The name attribute is used to uniquely identify
part elements within a message construct.

In the example below, we define request and response messages with two separate message
constructs. Each message contains a part element that is assigned a predefined XSD element
using the element attribute.
Two message constructs likely representing the input and output messages for an operation.
<message name="getEmployeeWeeklyHoursRequestMessage">
<part name="RequestParameter"
element="act:EmployeeHoursRequestType"/>
</message>
<message name="getEmployeeWeeklyHoursResponseMessage">
<part name="ResponseParameter"
element="act:EmployeeHoursResponseType"/>
</message>

In the next example the part element is simply assigned a native XSD schema data type using
the type attribute.
A simple parameter message requiring just a single integer value.
<message name="getID">
<part type="xsd:integer"/>
</message>

If all messages in a WSDL definition are assigned native (simple) XSD types, a separate types
construct generally is not required.
The portType, interface, and operation elements
Service operations are defined within the portType area of the WSDL definition. Hence,
portType constructs simply represent collections of operations. Individual operations are
defined using the aptly named operation element.
The portType construct hosting two operation constructs.
<portType name="EmployeeInterface">
<operation name="GetWeeklyHoursLimit">
...
WWW.VIDYARTHIPLUS.COM

V+ TEAM

WWW.VIDYARTHIPLUS.COM

</operation>
<operation name="UpdateHistory">
...
</operation>
</portType>

The portType element is defined in version 1.1 of the Web Services Description Language.
Version 2.0 of this specification changes the name of this element to interface. The examples
provided in this book are based on WSDL 1.1 and therefore continue to use the portType
element.
The input and output elements (when used with operation)
Each operation construct contains input and/or output child elements that represent the
request and response messages the operation is capable of processing.
In the example below, each operation has one input and one output message. The respective
input and output elements are assigned messages defined in the message constructs (explained
in the previous section) via their message attributes.
Example 13.11. operation elements with child input and output elements.
<operation name="GetWeeklyHoursLimit">
<input message="tns:getWeeklyHoursRequestMessage"/>
<output message="tns:getWeeklyHoursResponseMessage"/>
</operation>
<operation name="UpdateHistory">
<input message="tns:updateHistoryRequestMessage"/>
<output message="tns:updateHistoryResponseMessage"/>
</operation>

WSDL supports predefined message exchange patterns (MEPs). The presence of input and
output elements and the sequence in which they are displayed generally establishes the MEP of
the operation. For instance, the two operations defined in the previous example represent the
request-response MEP.
Placing a single input element within the operation construct expresses the one-way MEP, as
shown in the next example.
An operation element with a single child input element.
<operation name="Submit">
<input message="tns:receiveSubmitMessage"/>
</operation>

The binding element

The binding element begins the concrete portion of the service definition, to assign a
communications protocol that can be used to access and interact with the WSDL.
Upon first glance of the following example, the binding element appears similar in structure to
the portType element. As with portType, the binding construct contains one or more
WWW.VIDYARTHIPLUS.COM

V+ TEAM

WWW.VIDYARTHIPLUS.COM
operation

elements. However, you'll notice the additional soap:binding and soap:operation

elements interspersed within the construct syntax. These are what establish the SOAP protocol as
the manner in which this WSDL can be communicated with.

The binding construct hosting concrete operation definitions.

<binding name="EmployeeBinding" type="tns:EmployeeInterface">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetWeeklyHoursLimit">
<soap:operation soapAction="..."/>
...
</operation>
<operation name="UpdateHistory">
<soap:operation soapAction="..."/>
...
</operation>
</binding>

The value of "document" allows the SOAP message body to contain a fully definable XML
document structure. Assigning a value of "rpc" to the style attribute requires compliance to a
body structure defined within the SOAP specification, which primarily forces the root element of
the body to be named after the operation name.
The input and output elements (when used with binding)
Each operation element within a binding construct mirrors the input and output message
child elements defined in the abstract definition.
Within a binding construct, however, the input and output elements do not reference the
message elements again. Instead, they contain protocol details that establish how the messages
are going to be processed and interpreted by the chosen communication technology. In our
example, the service interface has been bound to the SOAP protocol.
input and output elements providing message processing information.
<operation name="GetWeeklyHoursLimit">
<soap:operation soapAction="..."/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
<operation name="UpdateHistory">
<soap:operation soapAction="..."/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
WWW.VIDYARTHIPLUS.COM

V+ TEAM

</operation>

WWW.VIDYARTHIPLUS.COM

This introduces the soap:body element from the SOAP language that defines the data type
system to be used by SOAP processors, via the use attribute. The use attribute can be set to
"encoding" or "literal".
The service, port, and endpoint elements
The service element simply provides a physical address at which the service can be accessed. It
hosts the port element that contains this location information.
The service and port elements establishing the physical service address.
<service name="EmployeeService">
<port binding="tns:EmployeeBinding" name="EmployeePort">
<soap:address
location="http://www.xmltc.com/tls/employee/"/>
</port>
</service>

Because we are binding to the SOAP protocol, the port element contains a child soap:address
element with the physical address information. Note that the port element is replaced with the
endpoint element in version 2.0 of the WSDL specification.
The import element
WSDL definitions support a similar form of modularity as XSD schemas do. The import
element can be used to import parts of the WSDL definition as well as XSD schemas.
The import element referencing a schema document.
<import namespace="http://www.xmltc.com/tls/schemas/"
location="http://www.xmltc.com/tls/schemas/employee.xsd"/>

The documentation element

This optional element simply allows you to add descriptive, human-readable annotations within a
WSDL definition. Developers can use this information when building service requestors or it can
be programmatically retrieved through a service registry to aid the discovery of the service.
The documentation element providing a description of the overall service interface.
<portType name="TransformInterface">
<documentation>
Retrieves an XML document and converts it into the
native accounting document format.
</documentation>
...
</portType>

WWW.VIDYARTHIPLUS.COM

V+ TEAM

WWW.VIDYARTHIPLUS.COM

Service modeling (a step-by-step process)

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, which may differ from the level of granularity at which the
process steps were originally documented.
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.

By filtering out these parts we are left with the processing steps most relevant to our service
modeling process.
Step 3: Abstract orchestration logic

If you have decided to build an orchestration layer as part of your SOA, then you should identify
the parts of the processing logic that this layer would potentially abstract. (If you are not
incorporating an orchestration service layer, then skip this step.)
Potential types of logic suitable for this layer include:

business rules
conditional logic
exception logic
sequence logic

We are only creating candidates. When we enter the service-oriented design phase, practical
considerations come into play. This may result in the need to remove some of the candidate
WWW.VIDYARTHIPLUS.COM

V+ TEAM

WWW.VIDYARTHIPLUS.COM

operations, which would also require that corresponding workflow logic be removed from the
orchestration layer as well.
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 you end up
with will depend on the types of business services you have chosen to build.
For example, task-centric business services will require a context specific to the process, while
entity-centric business services will introduce the need to group processing steps according to
their relation to previously defined entities. It is important that you do not concern yourself with
how many steps belong to each group. The primary purpose of this exercise is to establish the
required set of contexts.
Also it is encouraged that entity-centric business service candidates be equipped with additional
operation candidates that facilitate future reuse. Therefore, the scope of this step can be expanded
to include an analysis of additional service operation candidates not required by the current
business process, but added to round out entity services with a complete set of reusable
operations.
Step 5: Refine and apply principles of service-orientation

So far we have just grouped processing steps derived from an existing business process. To make
our service candidates truly worthy of an SOA, we must 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.
reusability

autonomy
statelessness
discoverability

Of these four, only the first two are important to us at the service modeling stage. The latter two
on this list are addressed in the service-oriented design process. Therefore, our focus in this step
is also to ensure that each service operation candidate we identify is potentially reusable and as
autonomous as possible.
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. For each scenario, follow the required processing steps as they exist now.
This exercise accomplishes the following:

It gives you a good idea as to how appropriate the grouping of your process steps is.
It demonstrates the potential relationship between orchestration and business service

WWW.VIDYARTHIPLUS.COM

V+ TEAM

WWW.VIDYARTHIPLUS.COM

layers.
It identifies potential service compositions.
It highlights any missing workflow logic or processing steps.

Ensure that as part of your chosen scenarios you include failure conditions that involve exception
handling logic.

Step 7: Revise business service operation grouping

Based on the results of the composition exercise in Step 6, revisit the grouping of your 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.
Step 8: Analyze application processing requirements

By the end of Step 6, you will have created a business-centric view of your services layer. This
view could very well consist of both application and business service candidates, but the focus so
far has been on representing business process logic.
This next series of steps is optional and more suited for complex business processes and larger
service-oriented environments. It requires that you more closely study the underlying processing
requirements of all service candidates to abstract any further technology-centric service
candidates from this view that will complete a preliminary application services layer. To
accomplish this, each processing step identified so far is required to undergo a mini-analysis.
Specifically, what you need to determine is:

What underlying application logic needs to be executed to process the action described
by the operation candidate.
Whether the required application logic already exists or whether it needs to be newly
developed.
Whether the required application logic spans application boundaries. In other words, is
more than one system required to complete this action?

Note that the information we gathered during Step 2 of the parent service-oriented analysis
process will be referenced at this point.
Step 9: Identify application service operation candidates

Break down each application logic processing requirement into a series of steps. Be explicit
about how you label these steps so that they reference the function they are performing. Ideally,
you would not reference the business process step for which this function is being identified.
Step 10: Create application service candidates

WWW.VIDYARTHIPLUS.COM

V+ TEAM

WWW.VIDYARTHIPLUS.COM

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

Various other issues are factored in once service candidates are subjected to the service-oriented
design process. For now, this grouping establishes a preliminary application service layer.
Step 11: Revise candidate service compositions

Revisit the original scenarios you identified in Step 5 and run through them again. Only, this
time, incorporate the new application service candidates as well. This will result in the mapping
of elaborate activities that bring to life expanded service compositions. 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

Going through the motions of mapping the activity scenarios from Step 11 usually will 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.
Optional Step: Keep an inventory of service candidates

So far, this process has assumed that this is the first time you are modeling service candidates.
Ideally, when going through subsequent iterations of this process, you should take existing
service candidates into account before creating new ones.
It can, however, be tricky to look for reuse opportunities when modeling documents. This is
because so much of the verbiage used to describe service and service operation candidates gets
lost when this information is later translated into concrete service designs. As a result, this step is
considered optional. The service-oriented design processes also provide steps dedicated to
checking for reuse opportunities.

WWW.VIDYARTHIPLUS.COM

V+ TEAM

WWW.VIDYARTHIPLUS.COM
Steps to composing SOA

Regardless of the shape or size of your SOA, it will consist of a number of technology
components that establish an environment in which your services. The fundamental components
that typically comprise an SOA include:

an XML data representation architecture

Web services built upon industry standards
a platform capable of hosting and processing XML data and Web services
The most fundamental components of an SOA.

However, to support and realize the principles and characteristics we've explored as being
associated with both the primitive and contemporary types of SOA requires some additional
design effort.
Suggested steps for composing a preliminary SOA.

WWW.VIDYARTHIPLUS.COM

V+ TEAM

WWW.VIDYARTHIPLUS.COM

Step 1: Choose service layers

Composing an SOA requires that we first decide on a design configuration for the service layers
that will comprise and standardize logic representation within our architecture. This step is
completed by studying the candidate service layers produced during the service-oriented analysis
phase and exploring service layers and service layer configuration scenarios.
Step 2: Position core standards
Next, we need to assess which core standards should comprise our SOA and how they should be
implemented to best support the features and requirements of our service-oriented solution. The
Considerations for positioning core SOA standards section provides an overview of how each of
the core XML and Web services specifications commonly is affected by principles and
characteristics unique to SOA.
Step 3: Choose SOA extensions
This final part of our "pre-service design process" requires that we determine which
contemporary SOA characteristics we want our service-oriented architecture to support. This will
help us decide which of the available WS-* specifications should become part of our serviceoriented environment. The Considerations for choosing SOA extensions section provides some
guidelines for making these determinations.

WWW.VIDYARTHIPLUS.COM

V+ TEAM

WWW.VIDYARTHIPLUS.COM
Entity-centric business service design (a step-by-step process)

Entity-centric business services represent the one service layer that is the least influenced by
others. Its purpose is to accurately represent corresponding data entities defined within an
organization's business models. These services are strictly solution- and business processagnostic, built for reuse by any application that needs to access or manage information associated
with a particular entity.
Entity-centric services establish the business service layer.

Because they exist rather atomically in relation to other service layers, it is beneficial to design
entity-centric business services prior to others. This establishes an abstract service layer around
which process and underlying application logic can be positioned.
Process description
Provided next is the step-by-step process description wherein we establish a recommended
sequence of detailed steps for arriving at a quality entity-centric business service interface

WWW.VIDYARTHIPLUS.COM

V+ TEAM

WWW.VIDYARTHIPLUS.COM

The entity-centric business service design process.

All of these can be legitimate approaches. The key is to ensure that in the end, design standards
are applied equally to all service operations and that all processing requirements are accurately
identified.
Let's begin now with the design of our entity-centric business service.
Step 1: Review existing services

Ideally, when creating entity-centric services, the modeling effort resulting in the service
candidates will have taken any existing services into account. However, because service
candidates tend to consist of operation candidates relevant to the business requirements that
formed the basis of the service-oriented analysis, it is always worth verifying to ensure that some
or all of the processing functionality represented by operation candidates does not already exist
WWW.VIDYARTHIPLUS.COM

V+ TEAM

WWW.VIDYARTHIPLUS.COM

in other services.
Therefore, 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 candidatesorthey may have already established a suitable context in
which these new operation candidates can be implemented (as new operations to the existing
service).
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. To accomplish this we need to formalize the message structures
that are defined within the WSDL types area.
SOAP messages carry payload 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, wherein we can define each of the elements
used to represent data within the SOAP body.
In the case of an entity-centric service, it is especially beneficial if the XSD schema used
accurately represents the information associated with this service's entity. This "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.
Step 3: Derive an abstract service interface

Next, we analyze the proposed service operation candidate and follow these steps to define an
initial service interface:
1. Confirm that each operation candidate is suitably generic and reusable by ensuring that
the granularity of the logic encapsulated is appropriate. Study the data structures defined
in Step 2 and establish a set of operation names.
2. Create the portType (or interface) area within the WSDL document and populate it
with operation constructs that correspond to operation candidates.
3. 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.
Step 4: Apply principles of service-orientation

Here's where we revisit the four service-orientation principles we identified in Chapter 8 as being
those not provided by the Web services technology set:

service reusability
service autonomy
service statelessness

WWW.VIDYARTHIPLUS.COM

V+ TEAM

WWW.VIDYARTHIPLUS.COM

service discoverability

Reusability and autonomy, the two principles we already covered in the service modeling
process, are somewhat naturally part of the entity-centric design model in that the operations
exposed by entity-centric business services are intended to be inherently generic and reusable
(and because the use of the import statement is encouraged to reuse schemas and create modular
WSDL definitions). Reusability is further promoted in Step 6, where we suggest that the design
be extended to facilitate requirements beyond those identified as part of our service candidate.
Because entity-centric services often need to be composed by a parent service layer and because
they rely on the application service layer to carry out their business logic, their immediate
autonomy is generally well defined. Unless those services governed by an entity-centric
controller have unusual processing requirements or impose dependencies in some manner, entitycentric services generally maintain their autonomy.
It is for similar reasons as those just mentioned that statelessness is also relatively manageable.
Entity-centric services generally do not possess a great deal of workflow logic and for those
cases in which multiple application or business services need to be invoked to carry out an
operation, it is preferred that state management be deferred as much as possible (to, for example,
document-style SOAP messages).
Discoverability is an important part of both the design of entity-centric services and their postdeployment utilization. As we mentioned in Step 1, we need to ensure that a service design does
not implement logic already in existence. A discovery mechanism would make this
determination much easier. Similarly, one measure we can take to make a service more
discoverable to others is to supplement it with metadata details using the documentation
element, as explained in the Document services with metadata guideline.
Step 5: Standardize and refine the service interface

Depending on your requirements, this can be a multi-faceted step involving a series of design
tasks. Following is a list of recommended actions you can take to achieve a standardized and
streamlined service design:

Review existing design standards and guidelines and apply any that are appropriate. (Use
the guidelines and proposed standards provided at the end of this chapter as a starting
point.)
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
If your design requirements include WS-I Basic Profile conformance, then that can
become a consideration at this stage. Although Basic Profile compliance requires that the
entire WSDL be completed, what has been created so far can be verified.

Step 6: Extend the service design

The service modeling process tends to focus on evident business requirements. While promoting
WWW.VIDYARTHIPLUS.COM

V+ TEAM

WWW.VIDYARTHIPLUS.COM

reuse always is encouraged, it often falls to the design process to ensure that a sufficient amount
of reusable functionality will be built into each service. This is especially important for entitycentric business services, as a complete range of common operations typically is expected by
their service requestors.
This step involves performing a speculative analysis as to what other types of features this
service, within its predefined functional context, should offer.
There are two common ways to implement new functionality:

add new operations

add new parameters to existing operations

While the latter option may streamline service interfaces, it also can be counter-intuitive in that
too many parameters associated with one operation may require that service requestors need to
know too much about the service to effectively utilize it.
Adding operations is a straight-forward means of providing evident functions associated with the
entity. The classic set of operations for an entity-centric service is:

GetSomething
UpdateSomething
AddSomething
DeleteSomething

Security requirements notwithstanding, establishing these standard operations builds a consistent

level of interoperability into the business service layer, facilitating ad-hoc reusability and
composition.
If entirely new tasks are defined, then they can be incorporated by new operations that follow the
same design standards as the existing ones. If new functional requirements are identified that
relate to existing operations, then a common method of extending these operations is to add input
and output values. This allows an operation to receive and transmit a range of message
combinations. Care must be taken, though, to not overly complicate operations for the sake of
potential reusability. It often is advisable to subject any new proposed functionality to a separate
analysis process.
Also, while it is desirable and recommended to produce entity-centric services that are
completely self-sufficient at managing data associated with the corresponding entity domain,
there is a key practical consideration that should be factored in. For every new operation you
add, the means by which that operation completes its processing also needs to be designed and
implemented. This boils down to the very probable requirement for additional or extended
application services. As long as the overhead for every new operation is calculated and deemed
acceptable, then this step is advisable.
Step 7: Identify required processing

WWW.VIDYARTHIPLUS.COM

V+ TEAM

WWW.VIDYARTHIPLUS.COM

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.
Now that we have an actual design for this new business service, you can study the processing
requirements of each of its operations more closely. In doing so, you should be able to determine
if additional application services are required to carry out each piece of exposed functionality. If
you do find the need for new application services, you will have to determine if they already
exist, or if they need to be added to the list of services that will be delivered as part of this
solution.

WWW.VIDYARTHIPLUS.COM

V+ TEAM

WWW.VIDYARTHIPLUS.COM
Application service design (a step-by-step process)

Application services are the workhorses of SOA. They represent the bottom sub-layer of the
composed service layer, responsible for carrying out any of the processing demands dictated to
them by the business and orchestration layers.
Application services establish the bottom sub-layer of the service layer.

Unlike services in business-centric layers, the design of application services does not require
business analysis expertise. The application service layer is a pure, service-oriented abstraction
of an organization's technical environments, best defined by those who understand these
environments the most.
Because of the many real-world and technology-specific considerations that need to be taken into
account, application services can be the hardest type of service to design. Further, 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.
Process description
Figure provides a proposed service design process for creating application service interfaces.
Note that all references made to "application services" in this and remaining chapters imply that
they are reusable utility application services.

WWW.VIDYARTHIPLUS.COM

V+ TEAM

WWW.VIDYARTHIPLUS.COM
The application service design process.

However, there are key aspects in how the two processes differ. Note, for example, how the
confirmation of the operation grouping context is isolated into a separate step. Establishing
context for application services is an important and much less clear-cut part of service design.
Further, there is no step in which processing requirements are defined. This is primarily due to
the fact that application services are responsible for implementing the processing details required
to carry out the business logic of their parent business services. This, of course, does not mean
that processing requirements for application services do not exist. They do, only they are part of
the design of the underlying service application logic. Because we are only designing a service
interface at this stage, it is not considered part of the process.
Step 1: Review existing services

More so with application services than with other types of reusable services, it is important to
ensure that the functionality required, as per the application service candidate, does not, in some
WWW.VIDYARTHIPLUS.COM

V+ TEAM

WWW.VIDYARTHIPLUS.COM

way, shape, or form, already exist. So it is very necessary to review your existing inventory of
application services in search of anything resembling what you are about to design.
Additionally, because these services provide such generic functionality, it is worth, at this stage,
investigating whether the features you require can be purchased or leased from third-party
vendors. Because application services should be designed for maximum reusability, third-party
Web services (which typically are built to be reusable) can make a great deal of sense, as long as
required quality of service levels can be met.
Step 2: Confirm the context

When performing a service-oriented analysis it's natural to be focused on immediate business

requirements. As a result, application service candidates produced by this phase will frequently
not take the contexts established by existing application services into account.
Therefore, 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, you may find that one or more operations actually belong in other application
services.
Step 3: Derive an initial service interface

Analyze the proposed service operation candidates and follow the steps below to define the first
cut of the service interface:
1. Using the application service candidate as your primary input, ensure that the granularity
of the logic partitions represented by the operation candidates are appropriately generic
and reusable.
2. Document the input and output values required for the processing of each operation
candidate and define message structures using XSD schema constructs (which essentially
establishes the WSDL types construct).
3. Complete the abstract service definition by adding the portType (or interface) area
(along with its child operation constructs) and the necessary message constructs
containing the part elements that reference the appropriate schema types.
Note that as generic units of processing logic, application services will be used by different types
of business services. Each business service will be processing a different type of business
document (invoice, purchase order, claim, etc.). Therefore, application services need to be
designed in such a manner that they can process multiple document types. Depending on the
nature of the information being processed, there are several design options.
Examples include:

Create a set of operations that are generic but still document specific. For example,
instead of a single Add operation, you could provide separate AddInvoice, AddPO, and
AddClaim operations.
Application services can be outfitted to support SOAP attachments, allowing a generic

WWW.VIDYARTHIPLUS.COM

V+ TEAM

WWW.VIDYARTHIPLUS.COM

operation to issue a generic SOAP message containing a specific business document.

Step 4: Apply principles of service-orientation

Reuse was discussed in the service modeling process and is addressed directly in Step 5, where
we look at making our application service as useful to potential service requestors as possible.
However, the existing operation candidates also should be reviewed to ensure they are designed
to be generic and reusable.
Autonomy is of primary concern when designing application services. We must ensure that the
underlying application logic responsible for executing the service operations does not impose
dependencies on the service, or itself have dependencies. This is where the information we
gathered in Step 2 of the service-oriented analysis process provides us with a starting point to
investigate the nature of the application logic each service operation needs to invoke. Step 6
provides an analysis that covers this and other technology-related issues.
Statelessness also may be more difficult to achieve with application services. Because they are
required to interface with a variety of different application platforms, these services are subject
to highly unpredictable implementation environments. Sooner or later, application services are
bound to encounter challenges that impose unreasonable or inconsistent performance
requirements (outdated legacy systems are known for this). Therefore, the best way to promote a
stateless application service design is to carry out as much up-front analysis as possible.
Knowing in advance what the performance demands will be will allow you to investigate
alternatives before you commit to a particular design.
As with entity-centric services, discoverability can be an important part of evolving the
application services layer. To guarantee that this design does not overlap with the logic already
provided by other application services, a discoverability mechanism is useful. This becomes
more of an infrastructure requirement that can be planned as part of an SOA implementation.
However, the Document services with metadata guideline still applies, as application services
should be supplemented with as much metadata as possible.
Step 5: Standardize and refine the service interface

Even though the role and purpose of application services differs from other types of services, it is
important that they be designed in the same fundamental manner. We accomplish this by
ensuring that the resulting application service WSDL definition is based on the same standards
and conventions used by others.
Following is a list of recommended actions you can take to achieve a standardized and
streamlined service design:

Apply any existing design standards relevant to the service interface. (For a list of
suggested standards, review the guidelines provided at the end of this chapter.)
Review any of the contemporary SOA characteristics you've chosen to have your 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

WWW.VIDYARTHIPLUS.COM

V+ TEAM

possible.

WWW.VIDYARTHIPLUS.COM

Step 6: Outfit the service candidate with speculative features

If you are interested in delivering highly reusable application services, you 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.
Of course, before actually adding speculative extensions to the application service, you should
repeat Step 1 to confirm that no part of these new operations already exists within other services.
Additionally, when adding new extensions, Steps 2 through 5 also need to be repeated to ensure
that they are properly standardized and designed in alignment with the portion of the service
interface we've created so far.
Step 7: Identify technical constraints

At this point we have created an ideal service interface in a bit of a vacuum. Unlike our business
services, application services need to take low-level, real-world considerations into account.
We now need to study and document the processing demands of each service operation more
closely. 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 we are specifically looking for are:

The physical connection point of the particular function. (In other words, what
components need to be invoked, what API functions need to be called, or which adapters
need to be activated.)
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 (especially when exposing legacy
systems).
Administration requirements imposed by the service.
Potential SLA requirements.

After characteristics of individual processing functions have been gathered, they need to be
viewed collectively. For example, individual response times need to be added to calculate the
overall estimated execution time of the operation. The result of this study is typically a series of
constraints and limitations imposed by the technical environment onto our service interface. In
some cases, the restrictions will be so severe that an operation may need to be significantly
augmented.

WWW.VIDYARTHIPLUS.COM

V+ TEAM

WWW.VIDYARTHIPLUS.COM

WWW.VIDYARTHIPLUS.COM

V+ TEAM

WWW.VIDYARTHIPLUS.COM
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.
Task-centric business services can comprise the business service layer, along with entitycentric neighbors.

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

WWW.VIDYARTHIPLUS.COM

V+ TEAM

WWW.VIDYARTHIPLUS.COM

The task-centric business service design process.

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

WWW.VIDYARTHIPLUS.COM

V+ TEAM

WWW.VIDYARTHIPLUS.COM

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

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 potential cross-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. 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.
WWW.VIDYARTHIPLUS.COM

V+ TEAM

WWW.VIDYARTHIPLUS.COM

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.
Step 4: Standardize and refine the service interface

Although task-centric business services will tend to have more creative operation names,
existing conventions still need to be applied. Here is the standard list of recommended
actions you can take to achieve a standardized and streamlined service design:

Incorporate existing design standards and guidelines. (A set of recommended

guidelines is provided at the end of this chapter.)
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.

With regard to design standards relating to operation granularity, some leniency may be
required to accommodate the processing of the service's embedded workflow sequence
logic. Also, task-centric business services can benefit from reusing existing WSDL
modules, in particular, XSD schema definitions.
Step 5: Identify required processing

To carry out their share of a solution's process logic, task-centric services can compose
application and both entity-centric and additional task-centric business services.
Therefore, 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.
Because this is the last of our three service design processes, all required supporting
application 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. The design of process logic within the task-centric business service may also
reveal the need for additional application services that haven't yet been considered.

WWW.VIDYARTHIPLUS.COM

V+ TEAM