Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Modeling service-oriented solutions

This article discusses a framework that allows designers and architects to specify the right services with the right capabilities, and realize the potential benefits of an SOA.

In order to gain a competitive edge in today's rapidly changing business environment, many companies have sought the flexibility and interoperability benefits that come through the effective implementation of a Service-Oriented Architecture (SOA). An SOA is an IT framework that combines individual business functions and processes, called services, to implement sophisticated business applications. It considers these processes as reusable components or "services" that are independent of applications and the computing platforms on which they run.

As development teams strive to find the best way to construct an SOA, a model-driven approach must be considered. Long regarded as an effective means for raising the level of abstraction in software development, modeling is extremely useful for the creation of service-oriented solutions, which rely on a variety of underlying implementation technologies and standards.

The following article presents a framework for a model that allows designers and architects to specify the right services with the right capabilities, and thereby realize the potential benefits of a Service Oriented Architecture (SOA).

Specifically, we will look at the importance of service identification and specification, managing a service portfolio, and partitioning service-oriented solutions as necessary elements for any SOA development. We will then look at three different approaches to the development of services when using modeling, with hopes of providing readers with a practical guide for leveraging the power of modeling for service-oriented solutions.

Service identification and specification

First of all, key SOA concepts must be presented through the model as first class elements. Although one of the key concepts is the service itself, it actually becomes a secondary element in the model. To construct a model that reflects a WSDL (Web Services Description Language)-defined service, we have to first develop a a set of service specification elements –structural, behavioral and policy. For example, an order management service might include structural specifications that list "place order," "cancel order," and "update order," as available operations. The behavioral specification for this ordering service might then describe how you cannot update or cancel an order you did not place. A policy specification may require that certain elements of the order are to be encrypted, denoting the encryption techniques to be used, certificates to use, etc.

Another important aspect for the development of an SOA model is the identification of services.. This allows architects and designers to produce a model of specifications that describe "idealized" services, which would realize either a process or set of requirements. These services are then refactored to 1) fit with existing services, 2) fit within the framework of an existing functional architecture, or 3) be separated out to allow for more fine-grained or parallel development.

Managing a service portfolio

Once we have the set of identity services specifications, we then need to explicitly design, implement, and manage the set of services in our enterprise as a portfolio of available capabilities. Most importantly, the refactoring of services described above has to be supported by processes that guide practitioners in developing the right services the right way.

Traditionally, we have focused on the software development lifecycle as a process time-bounded by a project; in turn, a project was time-bounded by the development of some discrete part of a solution. In the case of the service portfolio itself, we see a lifecycle that cuts across the individual projects that use and contribute to it, as shown in Figure 1.

Figure 1: The service portfolio lifecycle

Partitioning service-oriented solutions

In managing the services portfolio, the organization of the model becomes an important challenge. The set of organizations that are useful to the line of business owner will be different to the set required by the software architect, designer, developer, operations staff, etc. We therefore recommend that the typical method for model management, packages, not be used as the primary mechanism for the management of views within the model, because once an element is placed in a single package, it may be accessed by elements in a different package but cannot be "placed" in more than one package.

Instead, we look to the composite structure notions of the UML 2.0 specification, which provides the ability to partition the managed services. Partitions can be used to represent groupings of services, and as service specifications are being developed, they can be placed into different partitions to visualize the relationships and dependencies between them, as shown in Figure 2.

Figure 2: Using partitions to organize according to logical classification schemes, without needing the services to be "owned" by any one partition

The entire services model (representing the UML Profile for Software Services) is depicted below. This model is an architectural abstraction for service-oriented solutions that allows for the development of models where the notion of a service and the specific concerns of an SOA are first-class model elements. The model is not a direct representation of any implementation technology, such as WSDL.

Figure 3: The UML Profile for Software Services

Three Approaches to the Development of Services

Finally, we outline three approaches to the development of services. While these are certainly not mutually exclusive, they are useful in illustrating different approaches and ideas when using modeling for SOA.

1. Message-centric design

In message-centric design, the focus is on the service domain. An example of such an approach might be in the traditional business-to-business arena, typified by Electronic Data Interchange (EDI) standardization. In EDI there is no real notion of a service interface, since EDI systems usually have a single global inbox and outbox for messages.

2. Service-centric design

In this approach, the designer is concerned with exposing functions expected of the business or application. An example of this approach would be the Web Services APIs presented by Amazon (AWS) and eBay. Such service interfaces do not impose a business process on the client, yet they expose the operations of their respective service providers in a clear and intuitive way to third-party developers.

3. Collaboration-centric design

In a collaboration-centric approach, 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. 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 common in terms of either business process design or in business integration activities in which the components of an IT system are exposed as services.


To conclude, the clarity and flexibility that techniques such as the partitioning of services can provide when modeling for SOA allows businesses to advance in today's competitive and evolving markets. The development of the right framework, from the identification of service specifications to the design of the UML services model, leads to a more effective implementation of sophisticated business applications. Finally, the three approaches to the development of services illustrate the different ways one can use modeling for SOA. Through adhering to the steps outlined in this article, the right level of abstraction for presenting a services model is developed in a way that allows businesses to successfully meet their IT challenges.

About the author

Simon Johnston works on the SOA tooling strategy team within IBM Rational Software, responsible for the development of business, design, and construction tooling convergence around SOA. He has undertaken a number of standards-related activities for both Rational Software and now IBM in the area of XML (W3C Schema working group), Web Services (RosettaNet architecture team), and Modeling (OMG UML and OCL teams). He has also written articles on the subjects of business modeling, software modeling, and SOA. In addition to his articles for IBM developerWorks and The Rational Edge, Simon has a weblog on developerWorks. He can be reached at skjohn@us.ibm.com.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.