Level: Introductory Grant Larsen (grantlarsen@us.ibm.com), STSM, Chief Architect - Asset Management, IBM
Eoin Lane (eoinlane@us.ibm.com), Senior Solution Engineer, IBM
14 Mar 2006 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.
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
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
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
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.
-
Name: the recipe's name
-
Description: overview of the recipe’s intent and purpose
-
Subject Matter Experts: skilled resources contributing to the recipe
-
Recipe authoring (meta data elements of the authors)
-
Subject Matter Experts: skilled resources contributing to the recipe
-
Recipe owner: responsible party for the recipe
-
Other recipe contacts: other recipe contributors
-
Recipe usage/consumption: (meta data elements to support consumption)
-
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
-
Input (artifacts, assets): insight, knowledge, assets, and so forth that serve as input to this recipe
-
Output (artifacts, assets): the output from the recipe, artifacts, even other assets
-
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
-
Anticipated level of effort: the expected effort the recipe user should plan on
-
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
-
Roles involved when applying the recipe: the process roles that are expected to be involved with using the recipe
-
Assets, patterns, artifacts to be used when applying the recipe: a summary of the assets that are used when applying the recipe
-
Profiles required by the recipe: the modeling profiles and asset profiles that must be available for the recipe to be used
-
Products and other tools to be used when applying the recipe: a summary of the tools required
- 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
- 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/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
- 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 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/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
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 | 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 |
|---|
Resources Learn
Get products and technologies
Discuss
About the authors | 
| | 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. |
Rate this page
| 
