SOA terminology overview, Part 2: Development processes, models, and assets

Learn some basic SOA terminology. In this second part of the series, Bertrand Portier defines terms including development processes, models, and assets -- and explains why they are fundamental to the success of SOA. He also introduces key standards in this area.

Bertrand Portier, IT Architect, IBM

Bertrand Portier photoBertrand Portier is an IT Architect with IBM’s worldwide SOA Technical Sales organization. He used to work for IBM SWG SOA Advanced Technologies to help customers with strategic SOA transformations and create SOA assets for IBM. He is heavily involved in model-driven and asset-based development, and has extensive experience with Web services. A regular speaker at conferences and the author of several technical articles, he also co-authored a redbook on SOA solutions


developerWorks Professional author
        level

05 April 2007

Also available in Chinese Japanese

Introduction

Semantics are essential in any domain and especially in Service-oriented architecture (SOA). Since SOA spans teams and organizations, agreement upon relevant terms is crucial. This series provides a tour of SOA by defining terms and the key concepts behind them. You will learn the vocabulary necessary to communicate in the SOA field. For each term, you will understand why it is important for SOA, what it means in this context, what the relevant standards are, and how the term differs from others.

Part 1 in the series has a business focus and sets the stage by defining terms such as service and SOA. This article presents the software engineering methods and processes needed for successful SOA adoption, as well as the artifacts needed to deliver SOA solutions, such as models and assets.

Development processes and methods

Successful software development requires:

  • Principles to be understood and followed.
  • Formally described methods and techniques based on proven best practices.
  • Processes that can be tailored.

Method content

Method content describes what needs to be produced, how the work is performed, and by whom.

Method content artifacts include:

  • Roles: Defined skills and work product responsibilities. Software Architect is an example of a role.
  • Work products: Results of tasks, whether deliverables or not. Service Model is an example of a work product.
  • Tasks: The sequence of steps that specific roles perform. Tasks use input work products to produce or modify output work products. Identify Services is an example of a task.
  • Guidance: Documentation. Glossaries, templates, examples, and tool mentors are examples of guidance.

Process

A process is used to organize method contents into a development cycle and specify the sequence of the work to be done. The sequence of work to be done is independent of a development life cycle model (such as waterfall or iterative). Think of processes as workflows or breakdown structures. Processes enable project managers to see who is required and which work products are modified in each phase of the project. If you are familiar with the Rational Unified Process® (RUP), think of RUP disciplines such as analysis and design implementation as method content, and think of RUP phases such as elaboration and construction as process elements.

It is important to separate the two concepts of method and process and to have a framework that supports their independent modifications.

Rational Method Composer

IBM Rational® Method Composer (RMC) is an Eclipse-based method and process authoring platform used to integrate, tailor, codify, and publish processes. Out-of-the-box, RMC offers a catalog of processes that are ready to be used or customized, such as the Rational Unified Process (RUP). Project managers responsible for maintaining processes, project managers, and program managers typically use RMC, which supports the concepts described in this section.

The output of the work performed in RMC is a process that is published as HTML (usually in the form of a Web site). The organization meant to follow the process can then use the process site.

Software Process Engineering Metamodel

This section addresses the development processes. Software Process Engineering Metamodel (SPEM) is the standard specification that formally describes the software development processes. As an Object Management Group (OMG) standard, SPEM is vendor, method, and framework-agnostic. Version 1.1 was officially published in January 2005. Version 2.0, a major update, is currently being developed.

Rational Unified Process

Based on best practices adopted by thousands of projects worldwide, the Rational Unified Process (RUP) is a software development process that can easily be tailored for specific projects. RUP includes key principles around priority balancing, iterative development, visual modeling, software quality, and team collaboration. RUP defines disciplines (method contents) and phases (process), as shown in Figure 1.

Figure 1. The Rational Unified Process (RUP)
The Rational Unified Process (RUP)

Rational Unified Process for Service-Oriented Modeling and Architecture

The Rational Unified Process for Service-Oriented Modeling and Architecture (RUP Plug-In for SOMA) is built on top of RUP and provides guidance on developing service-oriented solutions. Version 2.4 (see Resources) provides a unified method that combines previous RUP for SOA content and the IBM Global Business Services (GBS) SOMA method. The RUP Plug-In for SOMA includes specific guidance for software architects and designers on the analysis, architecture, and design of service-oriented solutions.

Specialized Unified Modeling Language (UML) profiles exist for the modeling of domain-specific solutions, including SOA, and go hand-in-hand with specialized processes. For example, there is a UML 2.0 profile for Software Services that supports the RUP Plug-In for SOMA.

Note: Processes related to Management are addressed in subsequent articles in this series.

IBM techniques

As described in Part 1 of this series, Component Business Modeling, or CBM, helps organizations gain significant new insights into strategy, technology, operations, and investment alignment. CBM enables the identification of differentiating business components and the analysis of key business processes.

Service-Oriented Modeling and Architecture (SOMA) provides guidance on the analysis and design of SOA solutions. SOMA enables the identification, specification, and realization (at the design level) of business-aligned services. This topic is described in detail in a later section.


Models, UML, assets, and patterns

Metadata

Metadata literally means data about data. For example, metadata about a recorded song might include information about its artist, album, composer, length, or quality, whereas the data is the audio recording itself.

Depending on the context, the same data can be actual data, or metadata. Consider the example of development methods and processes, described in the previous section. When you codify a development method in RMC, you define content that is typed (backed-up by metadata). For example, you might define new instances of work products, tasks, and roles. At this level, work product, task, and role are metadata elements, and the metadata also defines what the relationship is between these types (tasks that are performed by roles). Now think about when designers defined the concepts around methods. Imagine that they were modeling the concepts of work product, role, and task using UML. At this level, work product, task, and role are the actual data, and UML is the metadata. This data will be later used as metadata in RMC. So, for this example, UML can be considered meta-metadata!

Model

RUP describes a model as an abstract representation or simulation of a system that provides a complete description of the system from a particular perspective. Models are often used to gain a better understanding of how the system works or to document design decisions for the actual implementation. Models are often made up of several different kinds of parts. These parts are categorized as model elements.

Models are targeted to a group of people who understand them. For example, system analysts and designers create and use analysis models, and database designers design and view data models. Models can be based on text or graphics or both. Because modeling is about being rigorous and complete while reducing complexity (such as describing at higher levels of abstraction), it is a good practice to use rich graphical design notations, such as the Unified Modeling Language (UML), described in RUP as visual modeling. A model is at a specific level of abstraction, and it can evolve into lower levels of abstraction. For example, analysis models typically evolve into design models.

Part 1 in the series explained that collaboration is even more important with SOA. For example, your company might have outsourced detailed design or implementation to another company. When you model, remember that it is for others to use. Also, your SOA design and development platform should be able to take a model and evolve it into another model.

Automations and transformations

An SOA design and development platform should allow for the semi-automatic transformation of models from higher to lower levels of abstraction, and eventually to code. For example, think of a UML-to-Java™ transformation that can generate Java code from a UML class diagram.

The underlying framework should also allow for traceability, which is basically going back to higher levels of abstraction. For example, imagine that you want to understand the impact that a change in a requirement would have on your design. You should be able to tell how the requirement was addressed in the design with the links (traces) that you added at the time you made design decisions to support that specific requirement. Then, during your impact analysis, you should be able to see all of the design decisions related (traced or linked) to that specific requirement, and you should start to understand what the impact of a change in this requirement is on your design.

A metamodel is a model about a model. It is the model of a specific domain, and it defines concepts and provides building elements to create models in that domain. For example, think of SPEM as the process engineering metamodel.

Eclipse Modeling Framework

As an open-source Eclipse project, the Eclipse Modeling Framework (EMF) includes a model metamodel (a metamodel in the modeling domain). Here is the definition from the EMF Web site:

"EMF is a modeling framework and code generation facility for building tools and other applications based on a structured data model. From a model specification described in XML Metadata Interchange (XMI), EMF provides tools and runtime support to produce a set of Java classes for the model, a set of adapter classes that enable viewing and command-based editing of the model, and a basic editor.

The core EMF framework includes a metamodel (Ecore) for describing models and runtime support for the models including change notification, persistence support with default XMI serialization, and a very efficient reflective Application Programming Interface (API) for manipulating EMF objects generically."

Unified Modeling Language (UML)

"The Unified Modeling Language (UML) is the industry-standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems. It simplifies the complex process of software design, creating a 'blueprint' for construction." Source: Object Management Group (OMG)

The good thing about UML is that it has broad industry support. Originally submitted to the OMG in 1997, it is fully supported in many vendors' design and development environments, such as IBM Rational Software Modeler (RSM) or IBM Rational Software Architect (RSA).

An OMG standard, the current formal version of the specification is 2.1.1. It defines 13 groups of concepts and diagram types organized into two categories:

  • Structure: Class, Object, Component, Composite Structure, Package, Deployment
  • Behavior: Use Case, Activity, State Machine, Sequence, Communication, Timing, Interaction Overview

A generic modeling language, one of the key strengths of UML is that it can be extended for domain-specific modeling using UML profiles.

UML profile

UML profiles provide a simple extension mechanism to the domain-independent UML. Profiles enable the definition of domain-specific entities and rules. UML profiles pair well with development processes. For example, there is a UML Profile for Business Modeling that supports the Rational Unified Process (RUP) for Business Modeling Plug-In.

Profiles consist mainly of stereotypes. A stereotype defines which UML class (meta-class) is associated with it, properties on that class, and constraints on how stereotyped elements can be associated with other elements. For example, in the UML 2.0 Profile for Software Services, the Service Specification stereotype extends the Interface UML meta-class. It defines a property named published to indicate whether or not the service specification has been published to a service registry. Finally, one of its constraints is that all Service Specification operations should be marked public.

UML 2.0 Profile for Software Services

The UML 2.0 Profile for Software Services is a UML profile that "allows for the modeling of services, service-oriented architecture (SOA), and service-oriented solutions. The profile (sometimes referred to as services profile) has been implemented in IBM Rational Software Architect (RSA), used successfully in developing models of complex customer scenarios, and used to help educate people about the concerns relevant to developing service-oriented solutions."

The profile defines stereotypes such as Message, Service Specification, or Service. It also provides distinctive graphical notations for these concepts. Figure 2 shows an example of UML diagram: a message design model in the insurance domain (from IBM Rational Software Architect). It is represented as a class diagram (a structural diagram) that uses the Message stereotype from the services profile.

Figure 2. A UML class diagram
A UML class diagram

Model-Driven Architecture

Model-Driven Architecture (MDA) provides an answer to having business and technology constantly changing by having independent models for both. Here is the definition from the OMG MDA user guide:

"OMG's MDA is a vendor-neutral approach to using models in software development. MDA provides an approach and enables tools to be provided for:

  • Specifying a system independently of the platform that supports it
  • Specifying platforms
  • Choosing a particular platform for the system
  • Transforming the system specification into one for a particular platform

The three primary goals of MDA are portability, interoperability, and reusability through architectural separation of concerns.

At the core of MDA are concepts such as system (as-is or to-be), platform (provides functionality such as J2EE or Web services), and viewpoint (an abstraction to focus on a particular concept).

MDA defines the following models:

  • Computation-Independent Model (CIM): The domain model used to define the requirements for functionality.
  • Platform-Independent Model (PIM): The business functionality and behavior model that is independent of (evolving) technologies on which it can be built.
  • Platform-Specific Model (PSM): Combines specifications of the PIM and how a specific type of platform is used.

MDA defines a transformation as converting the model of a system to another model of the same system (such as PIM to PSM). Transformations of one model to another are described with mappings.

One of MDA's primary goals is to enable the provision of design and development tools that support it.

Model-Driven Development

The things described so far in this section, specifically models and transformations, form the basis for Model-Driven Development (MDD), sometimes referred to as Model-Driven Software Development (MDSD), which is the software engineering approach for which MDA is a prescriptive standard. Model-Driven Development (MDD) is a software development approach based on models and transformations. MDD supports the semi-automatic generation of code, starting from high-level business analysis models to using a set of model-to-model transformations and eventually to using model-to-code transformations. This is made possible through the definition of a set of models, the completeness of model instances, and the mappings between elements of different models used in transformations. Also, MDD enables the analysis of the impact of changes.

The IBM Rational Software Delivery Platform (SDP) supports team development of end-end enterprise solutions, following an MDD (or other) approach, such as Business-Driven Development. "Business-Driven Development (BDD) is an integrated, role-based approach to software development that aligns business and IT, enabling the dramatic improvement of business performance." BDD uses models as well, and it focuses on the coordination of business and IT models across the SOA lifecycle (see Part 1 of the series). The IBM BDD approach supports roles such as Business Analyst, IT Architect, J2EE Developer, or Integration Developer, with the IBM Software Delivery Platform.

Refer to Resources for an IBM Systems Journal article containing an in-depth look at Model-Driven Software Development by IBM thought leaders.

Asset

Assets and patterns are key to the success of SOA, because they enable reuse. In fact, enterprises that adopt an asset-based business model have tremendous growth capabilities. They are no longer limited by the productivity or number of their staff, as in the traditional labor-based business model. The proper use of assets can dramatically change software investments. However, anyone who adopts this model can tell you that it is not straightforward, and it requires proper governance and infrastructure support.

Creativity can be counter-productive with SOA. Having architects, designers, and developers reinvent the wheel with each new project is undesirable. Similar requirements should lead to consistent architectures and designs. Assets and patterns allow the proper level or creativity, which enables you to reuse proven solutions wherever possible and then focus all of your time and effort on what needs to be invented, such as the business logic that is particular to the project.

An asset is a collection of artifacts that provide a solution to a problem in context. In this context, artifacts can be anything, such as a requirement, a design model, implementation code, or a test case. Think of an artifact as a file on the file system. Critical to their success, assets include instructions on how to use, customize, and extend the assets. See Reusable Asset Specification for more information about what makes an asset.

Pattern

A pattern is a solution to a recurring problem in a given context. A pattern is a specific type of reusable asset. You can make the distinction between the specification of a pattern (a description of the problem, context, forces, and solution), and its implementation, such as a Java bean. There can be many implementations of a single pattern specification.

Patterns fall into different categories, depending which phase in the development process they fit into. For example, the IBM Patterns for e-business classifies patterns into the following categories: business, integration, composite, application, and runtime. The Gang of Four (GoF) design patterns are also well-known.

When you use patterns, you can be sure that the solution they provide or codify is correct, useful, and has been validated. However, as with any type of reusable assets, adoption is possible only if a context and method are given on when, why, and how to use the patterns. Many patterns exist, and that context is necessary to get started. The patterns for e-business, for example, are presented with a process that, based on skills and environment, helps you identify the relevant patterns that address your business problem.

Finally, one of the goals of patterns is to provide consistency so that you end up with the same architecture based on the same set of requirements because you used patterns in your design.

Reusable Asset Specification

Adopted in 2005, the Reusable Asset Specification (RAS) is an OMG standard used to describe the structure, content, and description of reusable software assets. The goal of RAS is to provide best practices on how to package assets in a consistent and standard way. As defined in the specification, core characteristics of a RAS asset include:

  • Classification: The context in which the asset is relevant.
  • Solution: The artifacts contained in the asset.
  • Usage: The rules for installing, using, and customizing the asset.
  • Related assets: How this asset relates to other assets.

Artifacts can have a type determined by their file name suffixes, such as .xml, .txt, .doc, or .java; or by their purposes, such as use case model or analysis model. Because a software asset is a broad term, RAS also provides profiles used to describe specific types of assets. This is the same concept as UML profiles. There are UML profiles used to extend the domain-independent UML. Similarly, there are domain-specific (such as Web services) RAS profiles used to extend the domain-independent RAS.

RAS assets have a .ras file extension, and they are packaged like .zip files, meaning that they have a manifest and that you can open them using WinZip. Figure 3, from the RAS specification, illustrates the major sections of a core RAS asset.

Figure 2. The major sections of a core RAS asset
The major sections of a core RAS asset

Conclusion

This article defines the terms around software engineering processes and methods. It defines software artifacts used to build SOA solutions, such as models, assets, and patterns. Key standards are introduced, such as SPEM, UML, or RAS.

Future articles will define SOA terms related to analysis, design, implementation, runtime, and management. So, stay tuned to developerWorks!


Acknowledgements

I would like to thank my IBM colleagues who have contributed to Service-Oriented Architecture and the concepts described in this article. Special thanks to Grant Larsen for his insight on assets and services.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services
ArticleID=206871
ArticleTitle=SOA terminology overview, Part 2: Development processes, models, and assets
publish-date=04052007