Skip to main content

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

The first time you sign into developerWorks, a profile is created for you. Select information in your developerWorks profile is displayed to the public, but you may edit the information at any time. Your first name, last name (unless you choose to hide them), and display name will accompany the content that you post.

All information submitted is secure.

  • Close [x]

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.

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

All information submitted is secure.

  • Close [x]

Building SOA applications with reusable assets, Part 1: Reusable assets, recipes, and patterns

Grant Larsen, STSM, Chief Architect - Asset Management, IBM, Software Group
Grant Larsen Photo
Grant Larsen, Chief Architect - Asset Management for IBM Rational software, drives the asset-based development strategies through process, standards, tooling and reusable assets, such as patterns, to leverage software development investments.
Eoin Lane, Senior Solution Engineer, IBM, Software Group
Dr. Eoin Lane, Senior Solution Engineer, is the lead for harvesting and developing of application pattern from key IBM SOA engagements and driving those patterns through IBM pattern governance process to accelerate adoption. Eoin also specializes in Model Driven Development (MDD), asset based development and Reusable Asset Specification (RAS) to facilitate SOA development.

Summary:  This series demonstrates how reusable assets such as recipes, software patterns and models can accelerate the development of SOA solutions. The SOA Implementation and Optimization of Services recipe provides prescriptive guidance on how to develop services using a model-driven development approach to service construction and leverages other reusable assets, such as pattern and models in their construction. We introduce four new SOA application patterns harvested from a number of strategic IBM SOA engagements. These SOA patterns represent significant lessons learned from the development of these SOA solutions. The recipe also leverages a reference example application which demonstrates how applying these new SOA patterns to UML models can satisfy the quality of service requirements, such as interoperability and scalability, of the service -- and help to produce architecturally consistent SOA applications that are compliant with the best practices of code development.

View more content in this series

Date:  14 Mar 2006
Level:  Introductory
Also available in:   Chinese  Korean  Russian

Activity:  8878 views
Comments:  

Introduction

This first article of the series introduces reusable assets, recipes and patterns. Assets are collections of artifacts that provide solutions to problems. The Reusable Asset Specification (RAS) (see Resources.)

Software patterns are a repeatable solution to a problem in context. Rational® Software Architect takes a model -driven development (MDD) approach to software patterns. MDD typically allows transformation from one level of abstraction to another using set transforms. An example of a transform would be from an analysis model to a design model and then perhaps from the design model to code.

Multiple Rational Software Architect patterns, and other assets such as models or requirements, may be knit together to form larger-grained solutions. Recipes provide the process guidance, context and description of the ingredients, that is, assets and patterns.

The recipes, Rational Software Architect patterns and transforms, and other assets are packaged using RAS, and are stored in an asset or RAS repository. The RAS repository is an asset repository for development, and provides mechanisms for discovering assets and elements of particular solutions. We will focus on SOA solutions but the concept can be used ubiquitously.

The pattern recipe provides documentation on the use, organization and interconnection of the specified patterns. The recipe provides guidance for using patterns and the assets necessary for their implementation. The recipe can help align the outputs of one pattern with the inputs of another pattern. Recipes have the ability to substitute one or more patterns. This is useful as contexts may change over time.

The SOA Implementation and Optimization Recipe is a collection of Rational Software Architect patterns and transforms, as well as guidance on providing SOA solutions. The patterns that we discuss in the recipe will manipulate UML models to produce and optimize services. The Rational Software Architect patterns are implemented using the Rational Software Architect Pattern Engine. Each Rational Software Architect pattern and transform is implemented as an Eclipse plug-in and uses the Rational Software Architect pattern authoring and transformation API.

Introduction to reusable assets

Several years ago, a consortium of software industry leaders -- including IBM, Rational Software (before its acquisition by IBM), and Microsoft -- began exploring ways to help organizations re-purpose software investments. At this time the consortium defined an asset as: a collection of artifacts that provide a solution to a problem for a given context.

An asset has other characteristics as well. It may have variability points that allow users to customize the asset by setting various parameters. An asset that can be treated in this way is called a template. Today, IBM Rational tooling is implemented with this definition in mind.

Assets include instructions or rules for their use, to minimize the time developers need to discover, analyze, consume, and test the asset. Assets also describe the development and business context in which the asset can and should be reused.

The kinds of artifacts the asset contains depend on the reuse context. For a development context, the asset may contain requirements, models, source code, and tests. Those who build services should include these kinds of artifacts, to help other developers reuse the service efficiently.

Note that the definition of an asset is strikingly similar to that of a pattern. This is by design, as the fundamental concepts behind both pattern and asset pull together context, problem, and solution. The difference is in the details. An asset is a more general concept than a pattern. The variability points of an asset are at the artifact level, whereas a pattern will have parameters and participants -- kinds of variability points --that apply to the entire pattern, and not necessarily to any particular artifact.


Introduction to RAS

How do we organize and structure an asset? What information do we need to know about it? The Reusable Asset Specification (RAS) provides a structure to answer these questions. This is an Object Management Group (OMG) standard, adopted in 2005.

There are many types of software development artifacts, and these may exist in many forms and reflect a variety of styles. This diversity can increase the costs of discovering, comprehending, and reusing other authors' artifacts. By specifying a way to organize structure, describe, and package these artifacts, RAS provides consistency and predictability across assets, which significantly reduces the costs of asset management and consumption.

To illustrate the value of standardizing asset packaging, consider how standardization has helped overnight shipping companies. By providing standard envelopes and boxes to customers and requiring consistent information on the shipping label, these companies were able to build sophisticated tracking systems. In addition, these policies facilitated better planning and decision-making across the business, from determining the width of conveyor belts, to estimating how many packages can fit on a plane, and how many flights are required.

Asset standardization promotes efficiency in a similar way, enabling greater efficiency and automation in software development tools and improving productivity for the teams that use them. Using RAS, developers can package each asset in a meta-data wrapper that includes top-level attributes, such as the asset’s name, version, and description (see Figure 1).


Figure 1: The RAS meta-data structure
The RAS meta-data structure

As Figure 1 shows, a RAS asset has a classification section that facilitates searching and browsing; this section might include simple name/value pair descriptors, and a declaration of contexts, such as a specific domain, development, or deployment context.

The solution section shown in Figure 1 is the "meat" of the asset; it describes the collection of artifacts that provide a solution.

The usage section provides guidance on applying and customizing the asset, using variability points. Some usage information may be automated using scripts and wizards, which are stored in the solution section with the other asset artifacts.

The related assets section defines the asset’s relationships to other assets and helps to create collections or families of assets to form larger-grained solutions.

To support varying degrees of reuse, formality, and process maturity in organizations, many of the RAS asset sections are optional. RAS can also be extended and customized via a profile. The OMG currently offers three profiles: the Default profile, the Default Component profile, and the Default Web Service profile

The default profile is used to package any kind of software asset, while the other two profiles are intended for use with components and Web services, respectively.


Introduction to patterns

The term "pattern" can evoke a variety of responses and definitions. The casual observer may not notice the use of a pattern while in the very presence of it being applied. This is both the beauty and danger of patterns. On the one hand, the observer may remain casual and participate in the seeming simplicity of the benefits of the applied pattern. On the other hand, without realizing the reason and purpose for applying the pattern, the rationale itself, the knowledge and benefit of a pattern may be missed and ultimately forgotten and not used. In short, abstraction can be both our friend, as well as our enemy.

A definition, or perhaps several

But first, what is a pattern? For our purposes here we will borrow from the good work already done in this space by some leading thinkers:

James Coplien writes a pattern is “...a recurring structural configuration that solves a problem in a context, contributing to the wholeness of some whole, or system, that reflects some aesthetic or cultural value." [Organizational Patterns, p. 4, Pearson Prentice Hall]

Christopher Alexander writes: "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem [Alexander, 1979]. He also writes: "Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution." [Alexander 1979, p. 274]

Booch writes: "A pattern provides a good solution to a common problem in some context."[The Unified Modeling Language User Guide, p. 370, Addison Wesley]

Though the room is crowded with various flavors on this definition, we will opt for the commonly held version of the definition for the purposes of this article:

A pattern is a solution to a recurring problem for a given context.

What is model-driven development?

Model-driven development is basically software-related abstractions for specifying and implementing solutions. Models may be used at various places throughout the software development lifecycle. And, at any point in the lifecycle the model is expressed at a certain level of abstraction.

For example, a business process model describes the tasks, conditions, resources, costs, and timing. As that model is refined it may describe the nature of the resources to be specific IT systems or services. This kind of refinement can reduce the level of abstraction.

Another example is a model of use cases, outlining the actors. As that model is refined it may describe the nature of the use case realization, identifying components and services used to implement the use case. Again, this kind of refinement can reduce the level of abstraction.

Abstraction can go the other direction as well, by increasing the abstraction, thereby reducing the level of detail found in the model.

With some perspective, I sometimes ask, "are there others that have found value with models?". Models have been used for quite some time. According to Hermann Schichl in Modeling Languages in Mathematical Optimization, "The word ‘modeling’ comes from the Latin word modellus. It describes a typical human way of coping with reality. Anthropologists think that the ability to build abstract models is the most important feature which gave homo sapiens a competitive edge …" [History of modeling, p. 25]

Moving forward in time, Schichl further states: "By 2000 BC at least three cultures (Babylon, Egypt, India) had a decent knowledge of mathematics and used mathematical models." [History of modeling, p. 25]

Schichl identifies that one of the early graphical models used was in astronomy. In this domain Ptolemy created a model of the solar system in 150 AD using circles and epicenters. Apparently this model was used until 1619 when a better model was found, the fundamentals of which are still used today. [History of modeling, p. 26]

Models provide a means of communication, and when done well, they provide the proper abstractions that can last for quite some time. How many of our models will last nearly 1500 years, let alone one or two versions of an application?

Selecting the proper abstractions in a model for a specific context is critical.

Pattern specification and pattern implementation

With an eye towards tooling patterns we have separated the notion of pattern specification and pattern implementation. A pattern specification is the text describing the pattern; you will see it in a book, or on a Web page, and so on.

A pattern may be implemented in one of many forms; therefore, for each pattern specification there may be many pattern implementations. A pattern may be implemented as a UML model, as a component, or as a service.


Figure 2: Pattern specification and pattern implementation relationship
Pattern specification and pattern implementation relationship

The patterns we describe here are implemented using UML models, and have some transformation technology to refine those models. This requires a pattern engine or mechanism to accomplish this.


Introduction to recipes

As the number of assets grows in our repositories we are faced with the daunting task of trying to find the assets that will help solve our problems. Further we have the burden of determining how to combine one or more assets to create larger-grained solutions.

Reusing assets in a fine-grained manner has the benefit of modularity and asset versioning. However, the effort involved with pulling them together can bring into question the very value of using the assets.

As such there is value in providing a loosely coupled manner for combining assets, and, more importantly, for prescribing how the asset should be brought together for a given context.

To do so we use a metaphor, recipes. In the kitchen, the recipe provides a list of ingredients and some instructions on how to mix those ingredients together. The chef has some flexibility to substitute and to take the current context into consideration. In this sense a recipe is a template.

In the software world we can borrow from recipes and use them to create template solutions that architects and others can refine as needed. Here the ingredients are the fine-grained assets, and the recipe provides the process guidance for mixing these assets. Note that the recipe itself is an asset.


Figure 3: Recipe overview
Recipe overview

A Pattern solution knits many patterns together, using a recipe. The recipe describes the ingredients -- patterns and other assets -- and the approach to using them together to solve a problem. The Pattern solution implementation contains services, components, and other software artifacts, which implement the patterns, guided by the recipe.


Set up Rational Software Architect environment

Recipe template

Much of the value we gain from reusable assets comes from their ability to be used in concert with other assets. The ability to create customizable, loosely-coupled, coarse-grained assets through multiple finer-grained assets provides flexibility and productivity in our IT solutions.

The aggregate, composite asset which knits together the finer-grained assets is called a recipe. Just as there is meta data for fine-grained assets there is also meta data for recipes. RAS describes a common, extensible structure for asset meta data. This flexible meta data structure for assets of various types both enables tooling as well as provides consistency for asset consumers.

A brief introduction of some recipe meta data are introduced below. The RAS structure allows this to be extensible for your needs.

  1. Name: the recipe's name
  2. Description: overview of the recipe’s intent and purpose
  3. Subject Matter Experts: skilled resources contributing to the recipe
  4. Recipe authoring (meta data elements of the authors)
    1. Subject Matter Experts: skilled resources contributing to the recipe
    2. Recipe owner: responsible party for the recipe
    3. Other recipe contacts: other recipe contributors
  5. Recipe usage/consumption: (meta data elements to support consumption)
    1. Pre-requisites (assets, other recipes, constraints): may be tasks or activities that must be performed, or other constraints, before for the recipe is to be used
    2. Input (artifacts, assets): insight, knowledge, assets, and so forth that serve as input to this recipe
    3. Output (artifacts, assets): the output from the recipe, artifacts, even other assets
    4. Decisions to be made when applying the recipe: a summary of the key decisions a recipe user will need to make when using this recipe
    5. Anticipated level of effort: the expected effort the recipe user should plan on
    6. Existing process guidance used by the recipe: what process guidance should be referred to/used as part of applying this recipe, such as RUP or GSM
    7. Roles involved when applying the recipe: the process roles that are expected to be involved with using the recipe
    8. Assets, patterns, artifacts to be used when applying the recipe: a summary of the assets that are used when applying the recipe
    9. Profiles required by the recipe: the modeling profiles and asset profiles that must be available for the recipe to be used
    10. Products and other tools to be used when applying the recipe: a summary of the tools required
    11. High-level steps in the recipe / activity model of the recipe: a list of high-level steps the recipe user will conduct to apply the recipe

Now that we've laid this out in theory, let's see this in practice. Throughout this article series we will use Rational Software Architect , so if you don't already have it, please install it now. (See Resources for a link). Rational Software Architect also needs to be updated to the latest fix pack 6.0.1.1 at the time of writing this article. Rational Software Architect can be easily updated by going to Help > Software updates > IBM Rational Product Updater and click on the find updates button.

Setup the RAS client

This first thing to do here is to set up a RAS client in Rational Software Architect. This RAS client will be used to access a remote RAS repository. The RAS repository we will use is a RAS repository that is hosted on dW. The reusable assets used in this articles series are stored on this repository and we will be continuously accessing this repository throughout this article series.

The following is required to set up the Rational Software Architect client:

  • Start up Rational Software Architect. IF this is your first time you will be presented with a welcome screen.
  • Go to Windows > Open Perspective > Other. Then select Rational Software Architect (Reusable Asset) Perspective (you may have to select Show All to see it ) as shown in the following figure:

Figure 4: Rational Software Architect perspectives
Rational Software Architect perspectives
  • This will open a RAS perspective view.

Figure 5: RAS Perspective view
RAS Perspective view
  • One of the nice Eclipse features that are available here is the ability to iconify this perspective.
    • To do this, right-click on the perspective window bar and select the fast view from the drop-down list.
    • This will iconify the Rational Software Architect perspective to the right of Rational Software Architect main window. It is also possible to iconify the bottom of the main Rational Software Architect windows.
    • Click on this icon to show a fast view of this perspective which will disappear when the focus on the window is lost.
    • This helps keep the workspace clean and clutter free, something you will appreciate as the article series progresses.
  • Next set up a remote Rational Software Architect repository to attach to. Right-click anywhere in the RAS perspective and select New Repository. Choose the 'DeveloperWorks Repository' option and the following values will be prefilled for the Repository name and the URL
    • Name: "IBM developerWorks Rational Software Architect Repository"
    • URL:http://www.ibm.com/developerworks/product/rational/rsa/ras

Figure 6. Creating the new RAS repository
Creating the new RAS repository
  • The Rational Software Architect client is now set up and we can browse the repository.
  • Since we will use recipes we must first make Rational Software Architect aware of what to do with recipes. In future releases of Rational Software Architect the ability to recognize recipes will be available out of the box. However, this gives a good example of how to use an RAS asset to extend the current capabilities of Rational Software Architect. In the dW RAS repository structure browse to ./tools/ras folder and select the 'Solution Guide' asset. Right-click on the assets and chose import. This will download and install the eclipse plug-in needed to make Rational Software Architect aware of recipes. Restart Rational Software Architect as soon as the installation completes.

Figure 7. Importing the Solution Guide to make Rational Software Architect recipe-aware
Importing the Solution Guide to make Rational Software Architect recipe-aware
  • We can now download the recipe. Again in the dW Rational Software Architect repository, browse to the ./design_soa/recipes folder and select the "SOA Implementation and Optimization of Services Recipe" asset. Right-click on the recipe and in the context there is an option to open in solution guide. (Note: due to a bug in the current solution guide plug-in you will need first to import the recipe into your workspace. To do this, right-click on the recipe and select Import. Once you have accepted the legal agreement, the entire recipe will be imported into the workspace. Next switch to the Navigator view and right-click on the recipe and choose Solution Guide > Open Solution Guide View. This will open the recipe and also let you browse the content and structure of the recipe in the workspace.) This feature is available because the Solution Guide needed to make Rational Software Architect aware of recipes has already been installed in the previous step.

Figure 8. The Open Solution Guide
The Open Solution Guide
  • The SOA Implementation and Optimization of Services recipe is now available to browse inside of Rational Software Architect. We will use this recipe through the rest of this series of articles to provide prescriptive guidance on how to develop services. It is often helpful to move this window to the bottom of the Rational Software Architect screen palette.
  • See Downloads for a flash movie demo with details all of the steps outlined above.

Figure 9. SOA Implementation and Optimization of Services recipe
SOA Implementation and Optimization of Services recipe

Rational Software Architect functionality has just been extended using a reusable asset that was downloaded from a remote RAS repository. A recipe used in constructing SOA services has also been download from a remote RAS repository and is available to provide prescriptive guidance, best practices and patterns to help build those services.

Requisite/Pro RSA/RSM integration

To get the maximum benefit out of these articles, you should also set up the integration of Requisite Pro with Rational Software Architect. To do this Rational Requisite Pro has to be installed on your system: (See Resources for a link.) Rational Software Architect also ships with a minimum of its functionality enable. To enable the more advance functionality of Rational Software Architect go to Windows > Preferences > Workbench >Capabilities and enable the Requirement Management box.

  • Start up Rational Software Architect. If this is your first time you will be presented with a welcome screen.
  • Go to Windows > Open Perspective > Other > Requirements
  • This will open a new requirement explorer perspective in Rational Software Architect.

Figure 10. The Requisite Pro View
Requisite Pro View
  • This requirements explorer can be used to open a simple Requisite Pro file that will be used for this article series.
  • This Requisite Pro file has also been packaged as a RAS assets and can be got at by browsing to ./design_soa/requirements in the dW RAS Repository. Again, right-click on the asset, but this time select the download option in the right click context. This is because as yet Rational Software Architect does not know what to do with Requisite Pro file. Instead you are downloading the zip file to a place on disk. This test Requisite Profile is attached below (See Downloads to download the code.)
  • Unzip the Requisite Pro project on the file system, point the Rational Software Architect Requirements explorer to this file and open it inside Rational Software Architect.

Figure 11. The Requisite Pro Window
Requisite Pro window

Rational Software Architect has now been configured to read and write to this Requisite Profile.


Conclusion

This has been a whirlwind tour of recipes, patterns, and reusable assets. The terms have been introduced and the relationship between them established. We've configured Rational Software Architect to browse a remote asset repository on dW. An asset was used to make Rational Software Architect aware of recipes. We accessed the SOA Implementation and Optimization Recipe asset from this repository. Rational Software Architect was also integrated with Requisite Pro and a test Requisite Pro file was downloaded as an asset and opened inside of Rational Software Architect for requirement/use case reading and writing.

The scene is now set to use this SOA Implementation and Optimization of a Service Recipe on a reference example in SOA application. This recipe will give prescriptive guidance on how to use nonfunctional requirements in a MDD environment to determine what patterns should be used to build an architecturally consistent application. The next article will introduce the reference example and show how using the Rational Unified Process and MDD approach can be combined with reusable assets.



Downloads

DescriptionNameSizeDownload method
Requisite Pro file for the recipeIBMAutomotive.zip167KBHTTP
Flash movie for this articleSetup_RAS_and_ReqPro.zip2.9MBHTTP

Information about download methods


Resources

Learn

Get products and technologies

Discuss

About the authors

Grant Larsen Photo

Grant Larsen, Chief Architect - Asset Management for IBM Rational software, drives the asset-based development strategies through process, standards, tooling and reusable assets, such as patterns, to leverage software development investments.

Dr. Eoin Lane, Senior Solution Engineer, is the lead for harvesting and developing of application pattern from key IBM SOA engagements and driving those patterns through IBM pattern governance process to accelerate adoption. Eoin also specializes in Model Driven Development (MDD), asset based development and Reusable Asset Specification (RAS) to facilitate SOA development.

Report abuse help

Report abuse

Thank you. This entry has been flagged for moderator attention.


Report abuse help

Report abuse

Report abuse submission failed. Please try again later.


developerWorks: Sign in


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. Select information in your developerWorks profile is displayed to the public, but you may edit the information at any time. Your first name, last name (unless you choose to hide them), and display name will accompany the content that you post.

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.

(Must be between 3 – 31 characters.)

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

 


Rate this article

Comments

Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and Web services, Rational
ArticleID=105743
ArticleTitle=Building SOA applications with reusable assets, Part 1: Reusable assets, recipes, and patterns
publish-date=03142006
author1-email=grantlarsen@us.ibm.com
author1-email-cc=
author2-email=eoinlane@us.ibm.com
author2-email-cc=

Tags

Help
Use the search field to find all types of content in My developerWorks with that tag.

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.

Use the search field to find all types of content in My developerWorks with that tag. Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere). My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).

Special offers