Introduction

This is the first article in a five-article series on IBM's commercial solution for service-oriented systems design and development. This article provides some background on the SOA domain and introduces the solution, which includes service domain-specific best practices guidance in Rational SOMA 2.9 and service-domain-specific modeling and development tooling in IBM Rational Software Architect, Version 7.5.4 and higher (henceforth, "Rational Software Architect"). The guidance content and the tooling both strongly leverage and support the SoaML services modeling standard from the Object Management Group (OMG).

Back to top

Service orientation defined

Service-oriented architecture (SOA) is a way of organizing and understanding organizations, communities, and systems to maximize agility, scale, and interoperability. The SOA approach is simple - people, organizations, and systems provide services to each other.

A service is an offer of value to another through a well-defined interface. It is available to a community of service consumers (which might be the general public). A service results in work provided to one by another. SOA, then, is an architectural paradigm for defining how people, organizations, and systems provide and use services to achieve results.

SOA has been associated with a variety of approaches and technologies. The view expressed here is that SOA is foremost an approach to systems architecture, where architecture is a way to understand and specify how things can best work together to meet a set of goals and objectives. Systems, in this context, include organizations, communities, and processes as well as information technology systems. The architectures described with SOA can be business architectures, mission architectures, community architectures, or information technology systems architectures - all can be equally service oriented. The SOA approach to architecture helps with separating the concerns of what needs to get done from how it gets done, where it gets done, or who or what does it.

Back to top

SOA's promises and pitfalls

Promises

Numerous Internet-based discussions and white papers can be found that address some of the business benefits that possibly accrue from adopting an SOA approach for IT and for business/IT alignment. These benefits generally can be grouped into four business-relevant domains:

• Cost of ownership (lower)
• Revenue enhancement
• Time to market (reduced)
• Customer satisfaction (increased)

Additionally, IBM has found that one of the major benefits of moving to an SOA approach is improved communication between business stakeholders and IT. SOA facilitates a relatively easy translation between business concepts and IT concepts. As a result, there is an increased chance that what the business wanted actually will be delivered by IT.

Pitfalls

There are some issues and "pitfalls" in moving to an SOA approach. These include:

• Lack of effective SOA governance. Woolf introduces this subject and discusses why effective governance is essential. SOA governance isn’t a core part of this article series – but we would be remiss if we didn’t mention its importance!
• Knowing where and how to start. For organizations that are new to SOA, it can be tough to know where to begin. Common questions that can be difficult to answer include, "How do we identify good service candidates?", and "How do we determine which candidates to focus on?" Inability to answer these questions – and a host of similar ones – can stop progress with SOA before the effort really gets started.
• Service-enabling everything. Some teams might attempt to avoid answering the previous questions by trying to "service-enable" everything. They end up with many useless services, or poorly conceived services. And all these services have to be maintained...
• Getting lost in the details of a service solution. Teams can get lost in the details of defining and implementing service solutions. As services, service data elements, and service providers and consumers proliferate, people lose track of all the pieces.
• Lack of architectural thinking. The service paradigm facilitates loose functional coupling and an improved ability to reconfigure systems, but it doesn’t guarantee these things. Without investing in thinking through how to architect, design, and build loosely-coupled services, the promises of agility and effective reuse will not be fulfilled.
• Inadequate focus on non-functional requirements. Services still have to be scalable, secure, reliable, and meet necessary performance requirements. Focusing on functionality is not enough.

Back to top

How to address the issues?

Our experience is that an effective solution for creating service-oriented systems – what we will sometimes call service solutions -- needs to include 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!

Back to top

IBM's solutions for developing service-oriented systems

Proprietary solution

Consulting organizations, such as IBM Global Business Services (GBS), have developed proprietary solutions that their consultants use to enable them to effectively develop service-oriented systems. For example, GBS consultants commonly use SOMA (service-oriented modeling and architecture) as their method and they use custom tooling, layered on Rational Software Architect, to automate the method. This tooling – SOMA-ME (SOMA Modeling Environment) – was created before the enhanced service design tooling in Rational Software Architect was released in Version 7.5.4.

Commercial solution

During late 2008 and early 2009, it became clear to IBM that the time was right to deliver a commercial solution – including method, tooling, and advice on how to perform the method using the tooling – that could enable our customers to successfully design and develop service-oriented systems. The following factors had come into alignment:

• Enhancements to IBM's approaches to service solution design had been made since IBM's first commercial best practices offering – IBM RUP for SOMA 2.4 – had been published during 2006. It was time for a refresh of the methods content.
• The OMG was reaching closure on the SoaML standard meta-model and notation for service modeling. It was time to support this standard in our methods and tools.
• The Rational Software Architect capabilities for creating domain-specific modeling languages (DSLs), DSL tooling, and related model-driven development (MDD) transforms had matured substantially since the original product release in 2006. It now was cost-effective for IBM's Rational Software Architect development team to implement product capabilities that could robustly support a specific domain, such as service solution design and development.

Accordingly, IBM SOA subject-matter experts, IBM consultants, and the IBM Rational development organization collaboratively developed the solution that is presented in this series of articles. This includes:

• Service solution design content, found in Rational SOMA 2.9 (henceforth, "Rational SOMA");
• Domain-specific tooling for service-oriented design and development, found in Rational Software Architect Version 7.5.4 and later; and
• A tool usage model for performing the method. This usage model appears in Rational SOMA, in the form of tool mentors.

The close collaboration between IBM practitioners and the IBM Rational development organization resulted in tooling and a tool usage model that align very well with the solution design method.

The solution was initially released during the second half of 2009.

The following sections briefly describe the characteristics of the solution components. Subsequent articles in this series provide greater details.

Back to top

Process and method support – Rational SOMA 2.9

Availability

Rational SOMA 2.9 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 and organization

Rational SOMA 2.9 is provided to enable organizations to independently identify and specify their service solutions and to make decisions regarding how their services are to be realized. It also provides brief guidance that can be used to define some of the business-oriented artifacts that serve as inputs to service identification.

Rational SOMA is delivered as four "Practices" from the IBM Practice Library, those practices 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. The workflow for each practice is provided. Rational SOMA also provides an integrated Delivery Process for using the four practices in concert to design service solutions.

The method content in Rational SOMA is tool-independent. Specific guidance for performing the method using Rational Software Architect is provided in tool mentors, which are described later in this article.

Article 2 of this series provides more details regarding the Practices and Rational SOMA as a whole.

Sources of inspiration

Figure 1 illustrates the three primary sources of inspiration and content for Rational SOMA:

• RUP for SOMA 2.4 is IBM's previous commercial best practices offering for service solution design. It is based largely upon the core service solution design content found in IBM's proprietary SOMA methods, which themselves are based upon the results of over 6,500 IBM SOA-related service engagements.
• The IBM Redbook, "Building SOA Solutions Using the Rational SDP", provides an extended, detailed example of using previous Rational Software Architect versions to design and develop service solutions. Much of its advice regarding process details, approaches for structuring service models, and service design best practices still is valid.
• The OMG SoaML specification defines an industry-standard meta-model and notation for modeling systems using service-oriented approaches. The specification document also includes several SoaML modeling examples.

Although it is not illustrated in Figure 1, a fourth major source of guidance was Jim Amsden's 5 part article developerWorks series on modeling with SoaML.

We used these sources as follows during the authoring of Rational SOMA:

• We refactored RUP for SOMA 2.4 and used it to provide about 40 percent – 50 percent of Rational SOMA's content. In addition, the high-level structure of Rational SOMA – in terms of its three service-oriented Practices – derives from RUP for SOMA.
• We derived many of the service specification workflow details from the IBM Redbook. We also refined and reused the 12 architecture-level best practices ("SOA Architectural Patterns") that it describes, and we largely used the service model structure it recommends when we constructed the sample service model that we provide with Rational SOMA.
• We infused SoaML concepts and terminology throughout Rational SOMA. All of the service design examples are illustrated using SoaML notation. The service design process explicitly extends the Redbook's process to create specific architecture-level SoaML constructs.
• We used Amsden's articles as our primary reference for SoaML modeling practices. In addition, the sample service model that we provide with Rational SOMA (and which also ships with Rational Software Architect) is derived from the extended example Amsden presents in his articles.

Back to top

Tooling support – Rational Software Architect

Rational Software Architect, Version 7.5.4 and greater, provides the service-domain tooling that is the software product component of the solution. The tooling includes the following:

• Support for business modeling, based upon the current release of the BPMN2 (Business Process Modeling Notation 2) specification;
• A SoaML UML profile that enables UML-based service modeling using SoaML stereotypes;
• A SoaML-based service model template that regularizes the structure of service models;
• Drawing palette support for the major SoaML model elements;
• Right-click menus – available from the Rational Software Architect Project Explorer and from elements in diagrams – that automate the creation of context-relevant SoaML model elements;
• Right-click and drawing palette tools that enable the creation of SoaML elements from process model elements;
• Transforms that support top-down and bottom-up creation of SoaML elements from other artifacts. For example, SoaML elements can be batch-created from BPMN process elements and from relevant coding artifacts, such as Java interfaces, Session beans, and (in Rational Software Architect Version 8.0 and later) WSDLs;
• Transforms that generate SOA artifacts from SoaML service models. Generated artifacts include XSD, WSDL, and BPEL (Business Process Execution Language) files, and SCA (Service Component Architecture) projects and content that can be consumed by the SCA tooling in Rational Software Architect and Rational Application Developer.

The SoaML element creation tools are available for use with any Rational Software Architect UML model to which the SoaML profile has been applied. The profile is pre-applied to models that are created using the SoaML service model as their base.

Articles 3 – 5 of this series provide details regarding these tools. We provide some overview comments on select aspects of the tools in the following paragraphs.

BPMN2 support

Business process models are a significant source of inputs for service identification. Accordingly, Rational Software Architect supports building business process models using the industry-standard BPMN2 notation.

Figure 2 illustrates a simple business process diagram from Rational Software Architect. The tool implements the common Eclipse paradigm for drawing diagrams – a drawing editor supported by a drawing palette, with right-click menu items also being available to create additional in-context model elements. Process model elements appear in the Project Explorer View.

We do not envision that an organization would use Rational Software Architect as an Enterprise solution for business process modeling, management, and optimization. Such solutions commonly include the ability to optimize business process models using automated process simulation capabilities. Rational Software Architect's capability supports the needs of the IT Solution Architect to sketch out business processes and use those process models as the starting point for IT solutions, such as service solutions.

SoaML element creation

SoaML elements can be created using several tools, including:

• Drawing palette tools
• Diagram action bars
• Context menus on model elements
• The "Service" tab on the Properties View.

Figure 3 shows two of the three major classes of tools that are available for creating SoaML elements by drawing.

• Elements can be created using drag-and-drop gestures from the drawing palette.
• Elements also can be created using a right-click context menu. The "Add Service Modeling" menu is available whenever a SoaML element is selected in a diagram. The menu also is available simply by right-clicking on white space on a diagram. In either instance, the menu enables the creation of SoaML elements that are relevant in the context of the element (or diagram) that was selected.

Figure 3 does not illustrate the third class of drawing tool that can be used to create SoaML elements – diagram action bars. Hovering the cursor over either diagram white space or a modeling element causes a bar to appear that contains the icons that represent context specific constructible elements. Selecting an icon enables the creation of a new element of the type that the icon represents.

Context-menu-based element creation also is available from the Project Explorer View. Context-specific elements also can be created using a Property View "Service" tab. This tab is available for many model elements in service models.

Service artifact generation

Rational Software Architect releases prior to Version 7.5.4 enabled the automated creation of XSDs, WSDLs, BPEL, and IBM-proprietary service components from UML models; see, for example, the Transformation to SOA developerWorks article series from 2007 and 2008. The new tooling updated the previous transformations to support SoaML models. We also added a new transform, to generate Open SCA Service Component Architecture artifacts, including Java implementation code and SCA composites, components, WSDLs, and XSDs, from SoaML service models. These artifacts and the SCA projects that contain them can be consumed by the SCA tooling that is provided with Rational Software Architect and Rational Application Developer.

Back to top

Rational Software Architect Usage Model

We have completed our service solution design offering by including a comprehensive Rational Software Architect usage model in Rational SOMA. This usage model comprises 15 tool mentors that provide explicit instructions for using Rational Software Architect to identify, specify, and realize service solutions using the Rational SOMA method. An additional four tool mentors describe how to create service artifacts from service models, using productized Rational Software Architect transforms.

Back to top

Summary

To recap, IBM's commercial solution for designing service solutions includes three major components:

• A service solution design method, Rational SOMA. This is about half-based on the proprietary SOMA method that is used by IBM consultants on their SOA engagements. Other substantial influencers include:
  • An IBM Redbook, which provided the detailed approach for service design, 12 useful architecture-level SOA best practices, and effective guidance on service model structure;
  • The new OMG SoaML specification for a service design notation and meta-model; and
  • Jim Amsden's 5-article developerWorks series on service modeling using SoaML;
• Effective business modeling and service design and development tooling, delivered in Rational Software Architect Version 7.5.4 and greater. This tooling enables the construction and management of SoaML-based service models; and
• A Rational Software Architect usage model for performing the Rational SOMA method using the new Rational Software Architect tools. This usage model is delivered in Rational SOMA as a family of 19 related tool mentors.

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.

Back to top

Coming up

The remaining articles in this series provide details regarding the components of our service design solution:

• Article 2 provides a deeper-dive overview of the content and features of Rational SOMA 2.9;
• Article 3 describes the new Rational Software Architect tooling for using Business Process Modeling Notation (BPMN2) to build business and business process models;
• Article 4 describes the new 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.

Resources

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.
  
  
• 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.
  
  
• 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.
  
  
• 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".
  
  
• BPMN (Business Process Modeling Notation) is the standard notation for describing business processes. Download the specifications from the OMG.
  
  
• Visit the OASIS Service Component Architecture (SCA) site to learn more about these open-industry specifications for creating service components using a wide range of implementation and run-time technologies.
  
  

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.
  
  

About the authors

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Service orientation defined
• SOA's promises and pitfalls
• How to address the issues?
• IBM's solutions for developing service-oriented systems
• Process and method support – Rational SOMA 2.9
• Tooling support – Rational Software Architect
• Rational Software Architect Usage Model
• Summary
• Coming up
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: Rational Software Architect
• Buy: Rational Software Architect

Dig deeper into SOA and Web services on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers