![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
A service solution is a set of service-oriented software assembled to form a composite application -- an application built by combining multiple existing functions into a new application. As was described in the first installment of this series, a comprehensive approach for service solution design must provide the following components:
- A proven service solution design method. The method needs to have these characteristics and qualities:
- It is easy to use and understand
- It provides clear advice on how to start a service solution design
- It helps users identify the right, business-oriented services to work on
- It enables the creation of flexible service architectures that can adapt to changes in the business
- It helps users specify the component implementations that realize their services.
- Effective tooling that:
- Automates the approach
- Helps users keep their service solution design content organized
- Advice on how to use the tooling to perform the design approach.
IBM's commercial solution includes Rational SOMA 2.9 (henceforth, "Rational SOMA"), which provides the first and third of these components, and IBM Rational Software Architect for WebSphere Software, Version 7.5.4 and higher (henceforth, "Rational Software Architect"), which provides the service design and development tooling.
This article elaborates on the content of the first installment of this series, to provide a deeper description of Rational SOMA.
Briefly, Rational SOMA is a method for identifying services, specifying them, and making decisions regarding how to realize them. It also provides architectural-level advice regarding service design best practices and specific advice regarding how to perform the method using Rational Software Architect.
Rational SOMA is provided as a website that is published using IBM Rational Method Composer 7.5.0.1 or higher. It is available to users via download (see the Resources section of this article). It also is available to licensees of Rational Software Architect Version 8.0 or greater, as a Process Advisor method configuration.
Purpose, organization, and primary content sources
Article 1 in this series describes the purpose, high-level organization, and primary inspirations for Rational SOMA. Please refer to that article for this overview content.
Rational SOMA includes:
- Method content that describes how to identify, specify, and make realization decisions for services;
- A workflow that organizes the method content into a process;
- Architectural-level pattern descriptions for service design best practices; and
- Tool mentors that prescribe how to perform the process using Rational Software Architect.
We will first present the high-level Rational SOMA workflow. We then will describe the central concept of the service model and follow that with method content and workflow details. We will end with discussions of the architectural patterns and the tool mentors.
As is described in Rational SOMA, the method’s task descriptions and activities can be used to support either enterprise-scope or project-scope SOA initiatives. Rational SOMA includes a high-level workflow that is targeted at project-scope efforts. Figure 1 illustrates this workflow.
Figure 1. Project-scoped service solution design workflow
The main path through the workflow is illustrated as a sequential series of activities for identifying candidate services, specifying services that are selected for external exposure, and making decisions regarding how the services are to be realized. As Rational SOMA explains, real-world execution of the method is not necessarily linear. For example, some of the lower-level tasks that appear in the "Service Realization Decisions" activity also appear during "Service Identification". Further, work product refactoring can occur at essentially any point in the overall method, as new knowledge is gained regarding the service solution.
Business-oriented service solutions naturally require business-oriented inputs – this will be discussed in greater detail, later. In cases where such inputs are not available, the Rational SOMA workflow includes a light-weight activity, Use Case Driven Business Modeling, which can be used to develop some of the necessary business-related inputs.
Central concept – the service model
In the context of IT application of the service concept, the service model is an abstraction of the IT services implemented within an enterprise. It supports the development of one or more service-oriented solutions. It is used to conceive and document the design of the software services. It is a comprehensive, composite work product encompassing all services, providers, specifications, partitions, messages, collaborations, and the relationships between them. It is needed to:
- Identify candidate services (that is, capabilities that "might" be implemented as exposed services) and capture decisions about which services will actually be exposed
- Specify the contract between the service provider and the consumer of the services
- Associate services with the components needed to realize these services
Figure 2 abstractly illustrates the key aspects of the service model and the relationship between them and Rational SOMA's Service Identification, Service Specification, and Service Realization Decision activities.
Figure 2. Aspects of the service model
As was described in Article 1, the Rational SOMA method content is organized into four practices, those being
- Use Case Driven Business Modeling
- Service Identification
- Service Specification
- Service Realization
Each practice includes descriptions and detailed discussions of the tasks, work products, and roles that are involved in achieving that practice's specified purposes. Detailed guidance, in the form of concept descriptions, examples, and task performance guidelines, further illuminate the core method content. A workflow also is provided for each individual practice.
The following subsections address the three core service solution design practices. Please refer to Rational SOMA itself for information regarding the Use Case Driven Business Modeling practice.
Service Identification
This practice describes how to discover and define candidate services for possible inclusion into an organization's service oriented execution architecture. The practice describes seven complementary techniques for identifying services, with each technique attacking the service identification issue from a different perspective. Table 1 describes the seven techniques and the purpose that each plays during Service Identification.
Table 1. Service identification techniques in Rational SOMA
| Technique | Purpose |
|---|---|
| Goal-service modeling | Ensure that each considered business goal is supported by a candidate service, and that each identified candidate service supports at least one business goal |
| Functional model analysis | Identify candidate services using static models of an organization’s functional structure and the business functions that each business unit requires or provides |
| Business process analysis | Identify candidate services by mapping them to business tasks, roles, and processes found in business process models |
| Business rule analysis | Identify candidate services that encapsulate reusable business rules |
| Business use case analysis | Identify candidate services from business use case realizations |
| Domain model analysis | Identify candidate services that are needed to manage key information elements |
| Existing asset analysis | Identify candidate services that can be harvested from existing IT software assets |
Use of all seven techniques is not mandatory, but doing so can substantially reduce the chance that relevant candidate services have been missed.
Figure 3 illustrates the first level of decomposition in the Service Identification workflow.
Figure 3. Service identification high-level workflow
As the figure illustrates, goal-service modeling can be used both to jump-start candidate service identification and to ensure, at the end of the overall workflow, that the candidates are business-relevant.
The Domain Decomposition activity in Figure 3 collects various tasks that involve using the business-oriented, top-down identification techniques that are described in Table 1. See Rational SOMA for further detailed workflows that illustrate the time ordering of those tasks.
Similarly, the Existing Asset Analysis activity collects tasks that are performed to identify candidate services using a technology-driven, bottom-up approach.
Note that it is expected that the candidate service model – which is a subset of the service model – will be refactored throughout the service identification workflow. Rational SOMA provides advice regarding some useful refactoring techniques.
Service Specification
This practice describes how to specify services, the interactions in which they are involved, and their realizing elements. When used in the context of a services delivery process, the list of candidate services from the Service Identification practice provides the input to Service Specification.
Figure 4 illustrates the first level of decomposition in the Service Specification workflow. Refer to Rational SOMA for details regarding finer-grained workflow decomposition and step descriptions for each task.
Figure 4. Service Specification high-level workflow
Briefly:
- "Apply Service Litmus Test" is a governance task. The candidate services that were identified during Service Identification are filtered to determine which ones will be specified further and eventually realized as externally-exposed services.
- The "Specify Services" activity contains the core service specification tasks. The candidate services that passed through litmus testing are detailed. The results include service interface specifications, defined service providers and consumers, and descriptions of how providers and consumers interact to realize business processes and use cases.
- The "Perform Subsystem Analysis" task is performed to identify the conceptual IT subsystems involved in the service solution, identity their dependencies, and identify the subsystem components that will be involved in realizing the service model. This task marks the beginning of the transition from service solution specification into service realization design.
- The "Perform Component Specification" task, once performed, results in creating the external and high-level internal details of the software components that realize the services.
- As an acknowledgement of the importance of security, we provide an "Identify Security Patterns" task that ensures the level of security required by the system.
This workflow borrowed heavily from pre-existing work:
- Litmus testing, subsystem analysis, and component specification tasks were derived from similar tasks in IBM's proprietary version of SOMA;
- The detailed sub-process for service solution design owes its origin largely to the IBM Redbook, "Building SOA Solutions Using the Rational SDP;" and
- The service solution design sub-process was enhanced to use the Object Management Group's SoaML notation and concepts, following the advice provided in Jim Amsden's developerWorks articles on service design using SoaML.
Service Realization
Along with the service model, Service Specification produces logical descriptions of the system components that realize services. The Service Realization practice provides methods to help users decide how to realize these components, using either new-built or pre-existing system functionality. The results of the practice include the following:
- Detailed designs of the components that will realize the services, ready for implementation;
- Details of how the components will be integrated at run-time; and
- Details of how the components will leverage operational resources in the organization's IT environment.
Figure 5 illustrates the first level of decomposition in the Service Realization workflow. Refer to Rational SOMA for details regarding finer-grained workflow decomposition and step descriptions for each task.
Figure 5. Service Realization high-level workflow
The activity, "Make Service Component Realization Decisions," includes tasks that yield realization decisions for functional services and information management services. Along with these tasks, the activity provides a task for performing technical feasibility studies, to be performed when it is necessary to determine whether an existing run-time component can provide the QoS (Quality of Service) characteristics that are required of a service.
Performing the final task, "Detail the Service Components Layer", results in detailed design content that is sufficient to implement and deploy the service solution into the organization’s run-time environment.
Architectural patterns for service solutions
In addition to the prescriptive method content for service solution design, Rational SOMA describes 12 best practices related to designing and building more resilient, reusable SOA architectures. These are high-level, guiding principles that complement the foundational Rational SOMA method content. These best practices appeared previously in the IBM Redbook, "Building SOA Solutions Using the Rational SDP." The best practices are cast into software pattern format. Each pattern description includes a context, problem statement, description of the consequences of the problem, solution, and solution rationale. These patterns are referred to liberally within the method content, to remind Rational SOMA users of pertinent architectural issues as they use the content to guide their design work.
Figure 6 illustrates the patterns and their relationships. As the graphic shows, the patterns address such topics as:
- Separating service composition and business process logic;
- Re-factoring services for improved reuse;
- Ensuring that services are business-relevant;
- Using services to manage information;
- Designing services for easier maintenance; and
- Using services to represent business processes.
Figure 6. SOA architectural patterns in Rational SOMA
Rational Software Architect tool mentors
In addition to method content and architecture-level guidance, Rational SOMA includes a comprehensive suite of 19 tool mentors that provide detailed direction regarding how to use Rational Software Architect to design service solutions using the method. Figure 7 illustrates how the tool mentors are organized in the Rational SOMA content navigator pane.
Figure 7. Tool mentors in Rational SOMA
We authored the Rational SOMA tool mentors using a novel approach. The first tool mentor – "Build a SoaML Service Model Using the SoaML Template" – is used to organize access to all the other tool mentors. This tool mentor includes a narrative description of the overall service solution design process. Each of the other tool mentors is hot-linked into the process description, at the point in the process where a designer would be using Rational Software Architect to automate those particular process steps. We believe this approach – having a high-level tool mentor to choreograph access to all the others -- makes it easier for the Rational Software Architect user to understand the context in which the tool is being used and to access the appropriate tool mentor.
To recap, Rational SOMA is IBM's commercial method content for service solution design. It is one of the two major components of IBM’s solution for service design, the other component being the Rational Software Architect modeling tool.
- Rational SOMA addresses the core service solution design activities of service identification, service specification, and making service realization decisions.
- Rational SOMA also includes advice for creating business-oriented inputs to service identification, for use by organizations that don’t already have such inputs defined.
- In addition to design-level advice, Rational SOMA includes 12 best practices, described in the form of patterns, which address architecture-level issues that impact the reusability and maintainability of SOA artifacts.
- Finally, Rational SOMA includes a tool usage model, in the form of 19 tool mentors that guide the user through how to use Rational Software Architect to automate the process.
- Rational SOMA is available either as downloadable method content, which can be published using Rational Method Composer, or as a Process Advisor configuration within Rational Software Architect 8.0 and greater.
Our purpose in creating the solution was to enable our customers to design and build service solutions independently. We believe that these solution components, when used in concert, will enable many customers to do this.
The remaining articles in this series provide details regarding how to use Rational Software Architect to automate service solution modeling and development:
- Article 3 describes the Rational Software Architect tooling for using Business Process Modeling Notation (BPMN2) to build business and business process models;
- Article 4 describes the service design tooling in RSA and how this can be used to build business-aligned service models; and
- Article 5 describes how service models built using Rational Software Architect 8.0 can be used to accelerate the creation of valuable service solution artifacts. This article focuses on leveraging service models to create SCA-related content.
Learn
- SoaML (Service Oriented Architecture Modeling Language) is a specification of the Object Management Group. SoaML defines a notation and a meta-model for describing and specifying service-oriented systems.
- Learn more about SOA and service
governance in Bobby Woolf's developerWorks article, Introduction to SOA governance.
- IBM now delivers its commercial best practices content in the form of largely-separable, discretely-adoptable practices. Visit Welcome to IBM practices on
developerWorks to learn more about our Practices.
- To learn more about IBM Global Business
Service's proprietary method for service design and development, read SOMA: A method for developing service-oriented solutions.
- One of the major sources of inspiration
for the detailed service design method in Rational SOMA is the IBM Redbook, "Building SOA Solutions Using the
Rational SDP". The latest update to the Redbook occurred in 2008,
thus the tooling it illustrates is dated. Nonetheless, this is a good
service design resource to have on your "book shelf".
- Rational SOMA 2.9 borrows much of its
approach to service modeling using SoaML from Jim Amsden's 5-part IBM
developerWorks series, "Modeling with SoaML, the Service-Oriented Architecture Modeling Language".
Get products and technologies
- Download
Rational SOMA 2.9. This is
IBM's commercially-available best practices content for service solution design. The URL points to a pre-published evaluation version of Rational SOMA 2.9 and to a full version, which can be published using Rational Method Composer. Rational SOMA also is productized as a Process Advisor configuration that ships with variants of Rational Software Architect, Version 8.0 and higher, that include the service modeling tooling.
- Download a
trial version of Rational Software Architect for WebSphere Software. If you have a choice of versions, we recommend Version 8.0 or higher. To experience the enhanced service solution design capabilities of Rational Software Architect, you will need to use Version 7.5.4 or greater. If you download Version 7.5, then use IBM Installation Manager – which is installed along with Rational Software Architect – to upgrade to the current version of the product that is in the 7.5.x code stream.
Todd Dunnavant is a Principal Solution Architect in the Solution Delivery Assurance team of IBM’s Rational brand. He also is the primary author of the Rational SOMA best practices for service solution design. For the past 14 years, his professional passion has been enabling Rational and IBM clients to improve their ability to deliver business-relevant software and system solutions. His current focal areas of interest are service-oriented systems and collaborative architecture management.
Gary Johnston is a Senior Software Engineer and SOA Tools Architect in the Rational Software Architect development organization. For the past couple of years, Gary has been working to deliver and enhance support for SOA design and development in Rational Software Architect itself and to better integrate it with other SOA-related tools (both Rational and non-Rational).
Table of contents
Next steps from IBM
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
