|
As is always the case when looking at modeling software systems, there is a plurality of entry points to any such
model, any number of representations that can be used, and of course many methodologies one might apply. In most cases,
these entry points are due to specific concerns in either the technology or business domains that have to be addressed.
These concerns are important enough to act as starting points because understanding them and the interaction between
them is critical to achieving success.
It was our observation that there are a small number of such concerns in developing service-oriented solutions; the
following diagram represents these primary concerns as specific design tasks. While noting that each of these concerns
can act as the starting point for service design, and that each approach tends to be well optimized for a certain class
of services, it is most likely that any large project would use a combination of approaches in the identification and
design of services.
For more information see the Activity: Existing Asset Analysis, which presents a set of detailed techniques
supporting these approaches.
In this approach, the focus is very much on the service domain. Techniques such as domain engineering or
object-oriented analysis and design provide much insight into the development of abstract domain models. This focus
generally produces highly reusable models for message schema. The service design is usually a secondary activity
although it is sometimes done in parallel. In Electronic Data Interchange (EDI), for example, there is no real notion
of a service interface because EDI systems usually have a single global inbox and outbox for messages.
An example of such an approach might be in the traditional business-to-business arena, typified by EDI standardization.
In this case, the focus of the design activity is the development of message schema agreed upon in some industry or
other scope and is deemed to be representative of the schema of a class of messages, for example, and industry
standards such as ACORD, SWIFT, and RosettaNet (see Task: Message Design).
In this approach, the designer is concerned with exposing, as a service or set of services, functionality expected of
the business or application. In this case, we do not necessarily know what the client of the services will choose to do
with our service, but we do know the kinds of interactions such clients will expect. Therefore, messages tend to be
secondary and are developed in response to the requirements of an operation.
An example of this approach would be the Web Services APIs presented by companies such as Amazon and
eBay. Such service interfaces do not impose a business process on the client. In most cases they do not even
impose required interfaces on the client, but they expose the operations of their respective service providers in a
clear and intuitive way to third-party developers.
As mentioned above, service-centric modeling often lends itself well to a use-case driven approach by understanding the
needs of actors, the external clients of the service, and providing operations that support these needs, operations
such as browsing catalogs, adding items to a shopping cart, checking out, and so on.
In a collaboration design, the focus is on the collaboration of two or more services; this is very much a process view
of the services and is related to more traditional business modeling than it is to a software development activity. In
this approach, services are seen as fulfilling roles in the collaboration and the service specification is therefore
the set of responsibilities defined for the role across one or more collaborations.
Such an approach would be recognizable to those that have been involved in the development of RosettaNet Partner
Interchange Processes (PIPs) or in the development of the OAGIS standards, although the collaborations are less than
complete in these cases. Such an approach would be common within a business in terms of either business-process design
or in business-integration activities where the components of an IT system are exposed as services.
In this case, it is usually the case that the service specification can be derived directly from the collaboration, but
this approach tends to focus less on message content leading to a requirement for a hybrid approach for completeness.
Policy is a broad term that we use here to cover statements or constraints that can be considered non-functional
requirements. At the level of this model, we have to realize that we do not want the model to be populated with
detailed statements about technical information but more realistically, we capture the intent of the system in regard
to these requirements. For example, we may know that a certain message has to be transmitted and kept private as our
customers' personal details are included; we want to capture the intent that the message be private, not that we
require data encryption using AES 128 bit encryption over a canonical XML data set with X.509 certificates for public
key encryption, mainly because very few people will know what this means, let alone be able to specify it in a model at
this level of abstraction (see Task: Identify Security Patterns).
The following diagram demonstrates the association of policy with the elements of the Service Model. Note that policy information may be attached to
information other than the specification components identified below, although this is the primary area of interest.
For more information on modeling security policy, see the white paper Modeling Security Concerns in Service-Oriented Architecture.
|
Purpose 
Reuse Enterprise Service Portfolio 