Service design overview

Entity – Centric business service design

Application service design
Service design guidelines
 The ultimate goal of these processes is to achieve a
balanced service design. Typically this constitutes a
Web Service that accommodates real – world
requirements and constrains, while managing to:
 Encapsulate the required amount of logic
 Conform to service – orientation principles
 Meet business requirements
 Entity – centric business service
 Application services
 Task – centric business services
 Process services
 It is important to note that a firm set of design
standards is critical to achieving a successful SOA.
Because the design we are defining as part of this
phase is concrete and permanent, every service
produced needs to be as consistent as possible.
 The sample processes in this section consist of
generic sets of steps that highlight the primary
considerations for creating service design.
 As part of each abstract service description we
create, the following parts are formally define:
 Definition of all service operations
 Definition of each operation’s input and output
messages
 Definition of associated XSD schema types used to
represent message payloads
 As explained in chap 13, our service design processes
approach the creation of the service interface from a
hand coding perspective. This means that many
references to the WSDL and XSD schema markup
languages are made throughout the process
descriptions
 It represent the one service layer that is the least
influenced by others.

 The purpose is to accurately represent

corresponding data entity defined within
organization’s business model.
 Entity-centric service established the business service layer
 Next is the step-by-step process description to
achieve a quality entity-centric business service
interface.
Step 1: Review existing service
Always verify the existing entity-centric service to ensure that some
or all of the processing functionality represented by operation
candidates that not already exist in other services.
The first step also to decide it is necessary to create a new one or
not.
Step 2: Define the message schema types
Begin a service interface design with a formal definition of the
messages the service is required to process is very helpful.
But to do that, we need to formalize the message structures
that are defined within the WSDL types area.
We can rely on XSD schema to accurately represent the
information associated with this service’s entity. This ‘entity-
centric scheme” can become the basis for the service WDSL
definition, as most operation will be expected to receive or
transmit the documents defined by this schema.
Step 3: Derive an abstract service interface
To define an initial service interface, we can use these following
steps:
a) Confirm that each operation candidate is suitably generic and
reusable by ensuring that the granularity of the logic
encapsulated is appropriate.
b) Create the portType (or interface) area within the WDSL
document and populate it with operation construct that
correspond to operation candidates
c) Formalize the list of input and output calues required to
accommodate the processing of each operation’s logic.
Step 4: Apply principles of service orientation
There is 4 service orientation principle that is not provided by the
web service technology set, such as:
 Service reusability
 Service autonomy
 Service statelessness
 Service discoverability
Reusability and autonomy are service that naturally part of the
entity-centric design model in the operation.
Statelessness is the service that governed by an entity-centric
controller that processing requirement of maintain their
autonomy.
Discoverability is an important part of both the design entity-
centric service and their post-deployment utilization.
Step 5: Standardize and refine the service enterprise
In doing the design task, we must fulfill some requirements that can
be a multi-faceted involving a series of design task. Those
design task can be done in several action, you can take to
achieve a standardized and streamline service design:
a) Review existing design standards and guidelines and apply
any that are appropriate.
b) Identified the unsupported SOA characteristic
c) Include the WS-1 basic profile requirements
Step 6: Extend the service design
The service modeling tends to focus on evident business
requirement. The step involves performing speculative analysis as
to what other types of features this service, within its predefined
functional context, should offer.
There are two common way to inclement new functionally:
 Add new operation
 Add new parameter to existing operation
The classic set of operation for an entity-centric is:
 GetsSomething
 UpdateSomething
 AddSomething
 DeleteSomething
Step 7: Identify required processing
While the service modeling process from our service oriented
analysis may have identified some key application service, it may
not have been possible to define them all.

If you do find the need of application service, you will have to

determine if they have already exist or if they need to be added
to list of service that will delivered as part of these solution
• Application services are the workhorses of SOA.
• 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.
1. Review existing services
 Avoiding redundancy within application services can
be more challenging than with other types of reusable
services.
2. Confirm the context
 When performing a service-oriented analysis it’s
natural to be focused on immediate business
requirements.
3. Devine an initial service interface
1. Using the application service candidate as your
primary input.
2. Document the input and output values required for
the processing of each operation candidate and define
message structures using XSD schema constructs.
3. Complete the abstract service definition by adding the
portType area.
4. Apply principles of service-orientation
 Services reusability
 Services autonomy
 Services statelessness
 Services discoverability
5. Standardize and refine the service interface
 Apply any existing design standards relevant to the
service interface.
 Review any of the contemporary SOA characteristic
you’ve chosen to have your services support.
 Optionally incorporate WS-I Basic Profile rules and
best practices to whatever extent possible.
6. Outfit the service candidate with speculative features
 For application services, speculative extensions revolve
around the type of processing that falls within the
service context.
7. Identify technical constraints
The types of details we are specifically looking for are :
• Security constraints related to any part of the
processing
• Response time of each processing function
• Availability of the underlying system performing the
processing function
• Administration requirements imposed by the service
 Service candidates with high cross-application reuse
potential should always be stripped of any naming
characteristics that hint at the business processes for
which they were originally built
 Application services need to be named according to
the processing context under which their operations
are grouped
 Application service operations need to clearly
communicate the nature of their individual
functionality
 Entity-centric business services need to remain
representative of the entity models from which their
correspondding service candidates were derived
 Service operations for entity-centric business services
should be verb-based and should not repeat the entity
name
 The trend to create interfaces for Web services that are
coarser than those traditionally designed for RPC-
based components has been encouraged by vendors as
means of overcoming some of the performance
challanges associated with XML-based processing
 If multiple functions are bundled into a single
operation, it may be undesirable for requestors who
only require the use of one of those functions
 Service characteristics such as reusability and
composability are thought throught when partitioning
logic as part of the service modeling process,
extensibility is more of a physical design quality that
needs to be considered during design
 Depending on the nature of the change, extensibility
can sometimes be achieved without breaking the
existing service interface
 Limiting a service design to fulfill immediate
requirements can inhibit its potential as a reusable,
adaptive, and interoperable unit of processing logic
 Advisable that any existing service design process
incorporate a speculative analysis of how that service
may be utilized outside its initial application
boundaries
 WSDL service descriptions can be assembled
dynamically at runtime through the use of import
statements that link to separate files that contain parts
of the service definition
 Incidentally, the WS-I Basic Profile requires that when
designing modular WSDL definitions, the import
statement be used to import other WSDL definitions
or XSD schemas
 There are two spesific attributes that estabilish the
SOAP message payload format and the data type
system used to represent payload data:
o The style attribute
o The use attribute