![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
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.
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
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.
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
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.
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
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
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.
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
- This will open a RAS perspective view.
Figure 5: 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
- 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/rasfolder 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
- We can now download the recipe. Again in the dW Rational Software Architect repository, browse to the
./design_soa/recipesfolder 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 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
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
- 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/requirementsin 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
Rational Software Architect has now been configured to read and write to this Requisite Profile.
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.
| Description | Name | Size | Download method |
|---|---|---|---|
| Requisite Pro file for the recipe | IBMAutomotive.zip | 167KB | HTTP |
| Flash movie for this article | Setup_RAS_and_ReqPro.zip | 2.9MB | HTTP |
Information about download methods
Learn
- More about the OMG standard for Reusable Asset Specification, version 2.2
by reading the specification
-
Visit the developerWorks SOA and Web services zone to expand your skills.
-
Visit IBM's Pattern Solutions and find out what IBM is doing around patterns and reusable assets.
-
Stay current with
developerWorks
technical events and Webcasts.
Get products and technologies
-
Download a free trial version of Rational RequisitePro
Rational RequisitePro V2003.06.15.
-
Download a free trial version of Rational Software Architect Rational Software Architect V6.0.
-
Build your next development project with
IBM
trial software, available for download directly from developerWorks.
-
IBM Alphawork provides a reference implementation of the RAS called
Reusable Asset Specification Repository for Workgroups, this reference implementation is available for download directly from alphaWorks.
Discuss
-
Participate in developerWorks
blogs and get involved in the developerWorks community.
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.
Table of contents
Next steps from IBM
Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.
- Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
- Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
- Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
- Buy: Rational Service Tester for SOA Quality
