The Service-Oriented
Analysis Process
|
|
Service-Oriented
Design Processes
|
|
|
|
Service-Oriented Design Processes
|
Design Processes and Service Models
As shown in the previous figure, there is a suggested sequence in which services can be designed,
based on their respective service models. Entity services have the most independence
because they derive their functional
context from predefined business
entities. Prior service modeling
efforts will have ideally established
refined and balanced entity service
candidates with appropriate levels of
service and capability granularity.
Utility services are typically designed
next. Even though they don’t have
the benefit of pre-defined functional
contexts and are therefore more difficult
to create, they still can be delivered
independently due to the fact
that they typically encapsulate agnostic
functionality.
A further benefit to designing and
even delivering entity and utility
services first is that they can be tested
independently as generic, reusable
resources. When task-centric services
are delivered thereafter, they can
immediately be designed to bind to
the agnostic service contracts to finalize
the required composition logic.
This sequence is only suggested
and not required. There may be
circumstances during which it makes
more sense to change the order in
which services are designed or to
design and deliver a group of services
simultaneously.
During service design, many specific considerations are taken into account, shaping a service contract in support
of standards, principles, and practical constraints.
When building services as Web services, these processes essentially advocate defining
the required XML schema complex types first to ensure consistency with other service
contracts that may be using the same set of standardized schemas. An abstract WSDL
definition is then built around the complex types and further adjusted and optimized by
the application of service-orientation principles and design standards.
For agnostic services, these processes raise special considerations associated with the
extension of planned service logic in support of increased reusability potential. Finally,
other services required to carry out the defined Web service operations are also identified,
as per previously modeled composition candidates.
Each service model has unique design requirements, which is why each deserves its
own design process. Task-centric service design processes have less emphasis on exploring
reusability and are more concentrated on the service’s role as parent controller.
Design processes for orchestrated task services tend to be distinct in that they generally
require the design of service-oriented business processes which, in the Web services
world, usually involves the creation of WS-BPEL process definitions.
|
|
