Task Descriptor: Identify Services
This task identifies the design elements of a service-oriented solution in terms of services and partitions and documents the initial specification of those services.
Relationships
Performing RolesMain: Additional: Assisting:
InputsMandatory: Optional: External:
Outputs
Steps
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.

Diagram is described in the textual content.

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.

Diagram is described in the textual content.

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.

Diagram is described in the textual content.

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

For most business-driven IT organizations, understanding and managing data in the form of complex  Business Entities is key to the analysis and design of solutions. As such, many solutions will include services that act as data-management services and the identification of services will tend to focus more on the Data Model,  Domain Model or  Business Analysis Model. In terms of application reengineering to service-oriented solutions, data models have to be developed from the existing applications that can be used to identify coherent subsets that can be treated as autonomous services.

This topic is dealt with in more detail in the guideline  Service Data Encapsulation.

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.

Diagram is described in the textual content.

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.

Diagram is described in the textual content.

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

 Diagram is described in the textual content.

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.

Properties
Multiple Occurrences
Event-Driven
Ongoing
Optional
Planned
Repeatable