Introduction
This section outlines guidance on how the Software Architect or Designer can identify services. This
process of service identification and clustering into Service Specifications and Service Providers can be approached from a number of perspectives
and the choices below may be used alone or most likely in combination in any particular project. The identification of
services is most likely one of the first tasks in the modeling of a service-oriented solution. Therefore, errors made
during identification can flow through detailed design and implementation tasks.
The following diagram demonstrates the differing approaches to service identification. These are not mutually
exclusive, but the choices of which ones are appropriate will need to take into account wider process and project
concerns. Each of the colored ovals represents one of the techniques described below. There are two forms of
collaboration-based identification where the collaboration may be identified using business-process modeling or
use-case modeling.
However, one of the first decisions to make, and it is independent of the approaches above, is whether the
identification is purely based on the understanding of Operations which are later aggregation into services or whether
a set of services are already known and Operations are added to services as identified.
Service-first; this technique is common to both object-oriented and component based development where the
Classes of objects or components are identified first, presumably using an analysis technique to identify the classes
of "things" in some business or technical domain. Then, as collaborations between objects are analyzed, the operations
(responsibilities of the object) are identified and added to the classes. In the same way, Services may be identified
from Domain Analysis and augmented by the Operations identified in the approaches
below.
Operation-first; however, some critics have pointed out that services are not like classes and objects or
components. Services may manage a set of resources, but the service/resource relationship is fundamentally different to
the class/object relationship. As such, different analysis techniques are required and tend to favor the late
identification of services by aggregating a set of identified Operations into some logical grouping.
The examples below will demonstrate the use of a Service-first technique because it is more easily used by those
familiar with similar guidance in Rational Unified Process (RUP).
|
Top-Down, Business Process Driven
In the discussion of business alignment of services in the Service guideline, the
connection between business models and service identification was discussed. In general, this approach provides a very
tight connection between business stakeholders/users and the IT organization implementing services by allowing for
service operations to directly support the tasks identified in process models. In general, business-process models
focus on tasks performed by roles and/or resources in an organization to accomplish some task, usually to provide value
in the form of product or service to an external party such as a customer or partner. The process is an ordered set of
such tasks, possibly decomposed into sub-processes. It has associated organization, resource, and data models to
capture all aspects of the process including not only performing roles, but required/used resources, ownership of
resources, accountability, definitions of items passed into and out of tasks, and so on.
The following demonstrates a very simple process model using the IBM WebSphere Business Integration Modeler.
In this case, each horizontal swimlane represents a particular role performing tasks in the process. The process starts
with the green circle, ends with the red outlined circle, and does have data flowing between some tasks (in the form of
a loan request). This process, while obviously trivial and contrived, does demonstrate the high level of tasks. They
may be atomic actions from a business point of view, but obviously would require a number of steps when decomposed to
the IT level. In general, in object-oriented development of component based development, we would then treat each
individual task from the business view as a use case at the IT view and decompose into sets of components and classes
to form the implementation of the use case.
In a service-oriented solution, the service is identified at a similar level of granularity. It is commonly assumed
that the operations on a service specification will correspond 1:1 with the atomic tasks identified in a business
process model. While this is an attractive approach and may, if carefully done, achieve the right results, it also
tends to lead to the assumption that such once services are identified, they may be directly implemented as they are
described in the process model. Specifically each role (swimlane) will become a named service with each task within the
swimlane created as an operation on the corresponding service.
What this approach fails to take into consideration is that there are non-functional requirements that affect the kind
of service to be developed, the way operations are identified on services, and so forth. The level of detail usually
captured by such tools does not include enough for example to capture security, quality of service,or manageability
policies, for example. By transforming the process into a set of candidate service specifications in a service
model provides a starting point, but should be considered only as a starting point from which further analysis is
performed before the design model is developed which describes the actual implementation.
|
Top-Down, Use Case Driven
In the development of more traditional component-based and object-oriented solutions, there tends to be a set of
transformations across levels of abstraction and adding levels of detail from Use Cases down to system design. This is
especially true when you take a Business Use Case as the starting point, as demonstrated in the guideline Going from
Business Models to Systems; where the guidance demonstrates how to get from Business Use Cases to System Use Cases,
we still have to develop an actual design model from there.
The work product Business Use Case does describe the relationship between business processes and business use
cases. So, certainly some of the comments made in the last section are also relevant here. Fortunately, we can also
draw a parallel to the guideline provided for going to system-use cases in defining how a service model can be derived
from a Business Use Case Model, as shown below.
This more direct connection between the business-analysis model and the service model allows for not only services that
can be seen to support the business needs, but by having less transformations between the expression of business needs
and the solution, we can more effectively respond to change in the Business Use Case or Analysis Models. Another
important aspect is that as the Business Use Case model also includes the Business Goals that are driving the business,
it is now much easier to actually identify the alignment between Services and Goals. For example, it is now possible to
list, for any Service Specification, all the Business Goals to which it contributes. For any Business Goal we can list
the Services actually deployed in our IT organization that contribute to the goal , by following the connection from
service to service specification.
In modeling the example above, it is assumed that there is a traceable relationship between the service specifications
derived from the business workers. Such a relationship allows us to ensure that if the definition of elements in the
business analysis model change, the designer responsible for the service model can analyze the change and its
impact on the service specifications and message definitions.
|
Data Driven
Rule Driven
Certain classes of solutions tend to rely heavily on the use of Business Rules to extract the variability from
the solution and externalize such that the rules can evolve outside of the main application logic. From a Business
Analysis Model including Business Entities and Business Rules, it is possible to define services that encapsulate the
business rules, externalizing them from the rest of the logic of the solution. The following diagram demonstrates a
small, sample business-analysis model showing two business rules attached to the business entity named Order. These
rules, as they are attached to a business entity, are most likely to correspond to invariants on the entity and so will
be evaluated on any change in state of the entity. Rules may also be attached to actions or processes and are more
often evaluated as pre-conditions or post-conditions for the action.
In modeling the example above, it is assumed that there is a traceable relationship between the service specifications
derived from the business rules and between the message(s) derived from the business entity.
In many cases complex rules are aggregated into Rule Sets, these are much more of a match for the granularity of
service, allowing, for example, a document to be passed to the validation service where the set of rules are evaluated
and the results returned. From the example above, we can easily imagine that the validation services actually embody
quite a complex set of rules for validating the compatibility of items ordered, quantities, and so on.
|
Bottom-Up, Exposing Existing Assets
One must not forget that very few solutions are built without consideration to existing applications that either will
provide functionality to support the solution or with which the solution must interact. As such it is vital that
existing legacy applications that will be reused as part of any solution be cataloged and their functionality
identified. With a service-oriented solution, we are able to take a number of routes to integrate new services with
existing functionality. These are demonstrated in the figure below:
-
Wrap existing function as a service. In this case, we are looking to leave the function as-is, but use tools
or middleware to expose the existing function as a service. For example, IBM provides the capability to expose
legacy CICS transactions as SOAP Web services.
-
Wrap and replace existing function with a service. In this case, we wrap a function as above, but we use the
resulting service specification to redevelop the service at a later date, replacing the original service and having
clients redirected to the new implementation.
-
Use an adapter more amenable to service invocation. In some cases, it is not possible to wrap a function and
expose it as a service, but may be possible to wrap the function in something more able to integrate, such as a
message queuing interface or the Java Connector Architecture (JCA). This allows new services to access the function
in-place.
-
Integrate the function into the service. Obviously in some cases, it is possible for the new service to
access the legacy function in-place, simply using the function as a logical component within the implementation of
the service.
It should be considered that the third and fourth options provide the most flexibility because they use the existing
function but do not continue to expose the function as-is to clients. On the other hand, the first and second options
may introduce issues with the wrapping of existing functions as services because the performance of Web-service
protocols and mismatches between native data formats and XML may introduce performance concerns.
Wrapping Existing Assets as a Services Pattern
In some cases, however, it is expedient to develop a legacy service partition where a set of low-level legacy functions
are exposed individually as services. This partition is only accessible to higher level services that utilize them in
presenting a more granular business-aligned specification to consumers. This encapsulation of the legacy functions
should be seen as a temporary solution and should only be undertaken if the performance characteristics of the wrapping
technology is well understood. For more information see the concept Solution Partitioning.
One way to look at the wrapping of a legacy function is a very simplified form of the Service Provider model element, with a single service realizing a
single specification with only a single operation. The following diagram demonstrates this pattern for the legacy
function "UpdateCustomerAddress".
In tailoring this pattern, you may wish to do the following:
-
It is likely that a set of existing functions will be provided by the same component so the same service provider
should be used.
-
The pattern above was generated automatically; it might be preferable to rename the default operation name from
"exec${service}".
-
Similarly, it would be valuable to rename the default generated messages; also at this point, the message
structures should be modeled.
-
The default pattern assumes the operation takes a message input and return a message; it may be that the legacy
function returns no message or is a notification only and the signature of the operation generated should be
amended.
-
The architect/designer should ensure that the correct values are specified for the "allowedBindings" property on
the service provider.
|
References
[CBDI] Richard Veryard, Modeling for SOA, CBDi Journal February 2003.
[SOMA] Ali Arsanjani, Service-Oriented Modeling and Architecture, IBM
developerWorks.
|
|