Skip to main content

Building SOA applications with reusable assets, Part 2: SOA recipe reference example

Clive Gee (clive@us.ibm.com), Executive Consultant, IBM, Software Group
Clive Gee is an executive consultant with nearly 30 years experience in the IT industry. For the past three years he has been focusing on SOA, particularly aspects of the services development process and its governance
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 explores how reusable assets, recipes and software patterns can facilitate the development of SOA solutions. This second article describes a reference example in which a recipe can be applied. Future articles will show how to apply SOA patterns to these reference example to satisfy non-functional requirements.

View more content in this series

Date:  23 May 2006
Level:  Intermediate
Activity:  2448 views

Introduction

The first article in this series, "Reusable assets, recipes, and patterns" introduced a recipe as a way to provide prescriptive guidance to create SOA implementations using patterns and a layered architecture. This recipe was called the SOA service implementation and optimize recipe. In this second article we examine this recipe in detail and explore the other reusable assets that it refers to. It should be noted that this recipe is by no means complete; rather, we use it to give a flavor of what is possible.

In the previous article we set up an IBM® Rational® Software Architect client to connect to the IBM Rational developerWorks RAS repository and imported the SOA service implementation and optimize recipe. This particular pattern recipe uses SOA patterns to implement and optimize services. The primary audience is architects and developers in an effort to provide prescriptive guidance in the development of a SOA application.

We use this recipe with a reference example to show how the recipe can be used. The recipe assumes a model-driven development environment, as provided by Rational Software Architect. The recipe also assumes the Rational Unified Process as an approach which implies a use-case-centric approach, including iterative envelopment and visual model.

We introduce the SOA implement and optimize services recipe first and the reference example, to show how the recipe can be applied to the reference example. The reference example uses a model-driven development approach and leverages the modeling capabilities of Rational Software Architect to develop a use case model, analysis model, design models and services models.

Implementation and optimization of services recipe

In the previous article we imported the SOA implementation and optimization of services recipe into Rational Software Architect. This particular recipe deals with how to apply and use a series of SOA patterns. The non-functional requirement of the system, such as performance scalability, interoperability can be used to determine which patterns are to be used. These non-functional requirements provide guidance on proper usage. This recipe is for architects and developers to provide prescriptive guidance in the development of a SOA application.

The recipe has two broad guidelines:

  1. Selecting implementation options
  2. Applying patterns to a service implementation

In this article we examine in detail the selecting implementation options. This will lay the foundation for the future series of articles where we will apply patterns to a service implementation.

Selecting implementation options

As the name implies, the recipe deals with two types of services:

  1. A green fields service: Typically, the service definition is known, perhaps through some business service analysis initiative. The recipe will also encourage the architect or developer to seek out previous implementations of services with similar non-functional requirements. This is to insure that the current implementation will have architectural consistency with the best practices of previous implementations.
  2. A service where a legacy application or service already exists. Typically, this is a legacy service or application and is immutable from the point of view of the developer or architect. This represents the vast majority of legacy applications or services that currently exist and need to be leveraged as part of larger SOA engagements. The non-functional requirements for the service must now be satisfied and this typically involves scalability and performance issues.

Figure 1, a diagram for the implementation and optimizing a service recipe, shows the sequence an architect follows to evaluate user requirements for use cases, as well as functional and non-functional requirements for the implementation and optimization of services.


Figure 1. SOA implementation and optimization of services recipe outline
SOA implementation and optimization of services recipe outline

This recipe assumes a model-driven development (MDD) approach and allows the modeler or architect to focus on different levels of abstraction to better architect the solution.

It is in the nature of the recipe to call out to richer sources of information where possible and since we are developing a SOA solution using a MDD approach, the first call of the recipe is to link to Rational Unified Process for SOA. The Rational Unified Process provides software development process guidance that has been distilled from the best practices of numerous developments.

The recipe shows that the use case is first analyzed to determine which of the use cases need to be built and which can leverage existing legacy services or applications.

  • In the case of an existing application, the non-functional requirements (NFRs) are analyzed and the appropriate patterns applied based on those NFRs.
  • In the case of services that need to be built, previous service implementations are analyzed for architectural consistency.

In both cases the service model and entity models, where available, are analyzed. In a MDD environment like Rational Software Architect these models will be Rational Software Architect models that are provided as part of the base install, and will follow the RUP in terms of their user experience. The recipe assumes n-tier architecture similar to that shown in Figure 2, where the SOA IF Patterns can be applied at the appropriate tiers.

SOA patterns

Before giving an overview of the SOA patterns it is helpful to think of an n-tier architecture as outlined below. A simple three-tier architecture will have a presentation tier, a business tier and and persistence tier. In a SOA environment we can break the business tier further into a service layer, a controller layer, and an entity/object management layer. This layering is shown in Figure 2. The core Enterprise JavaBean™ patterns such as the session facade, message facade, and the business delegate belong in the controller tier.

The SOA patterns used by the recipe are relevant to the business tier. All of these patterns were harvested from strategic IBM SOA engagements. Each one of these patterns was developed as a pattern specification and a pattern implementation using the Rational Software Architect pattern engine. See the Resources section for more information.

When we talk about patterns -- and let's use the Gang of Four "Design Patterns" as an example -- there are two different elements that people are interested in. One is the actual text that describes the pattern. This is what you would find in the book, say in the chapter on the adapter pattern.

Then there are the design tooling elements that implement that pattern. For instance, there are UML artifacts in Rational Software Architect that implement the different design patterns from the Gang of Four book. So, if you wanted to apply an adapter to one of your designs, you'd pull that element off the palette and make some manipulations in the tool to actually transform your design to use the pattern.

The first thing we've called a "pattern specification". The second thing we've called a "pattern implementation". The coming articles of this series we will cover these patterns in much more detail.

The following four patterns will be considered; they will be examined in greater detail in future articles in this series:

  • The WS Response Template Pattern (see Resources for the pattern specification) provides fine-grained access to a coarse-gained service and also provides flexibility in the service definition
  • The Requester Side Caching Pattern (see Resources for the pattern specification) provides request side caching capabilities
  • The Preferred Data Source Pattern is a microflow pattern for service aggregation
  • The Aspects Patterns combine aspects, AJDT and Model Driven Development

Figure 2: N-tier Architecture
N Tier Architecture

This type of elaboration of the business tier has many benefits:

  1. Decoupling the service definition from the business logic (controller) and from access to the data (entity) ensures that no business logic manifests itself in the entities.
  2. In a Web service implementation, the services can delegate to the controller for proper separation of concerns. The service is concerned only with the interception of the messages, but delegates to the controller to see that the business is done
  3. The controller implements the service business logic by accessing other services or accessing backend entities via their create, read, update and delete (CRUD) operations
  4. Now appropriate patterns can be applied at each layer to satisfy the non-functional and system requirements, and to produce architecturally consistent applications and services

In an effort to help the architect or developer to better understand this recipe, an example is also included.

Back to top

SOA reference example

The example has been integrated into the SOA implementation and optimization of services recipe for illustration purposes. In this section we step through the recipe to access assets that are used to construct the reference example. To do this we first need to set up a project in Rational Software Architect that can hold these assets. Typically these assets will be use case, services, analysis and design models. To create a simple project in Rational Software Architect, you can use this: File > Project > Simple > project call the project "Retail".

The example demonstrates how the SOA patterns work together in a composible manner and how they might interact with other patterns. This example is loosely based on a retail chain and focuses on a business service called 'Lookup Item'. Lookup Item would typically be used in a retail scenario where an item would need to be looked up in an inventory system before it could be sold. Typically 'Lookup item' is an example of a coarse-grained business service where we want to understand the corresponding IT services necessary to provision this business service.


Figure 3. Lookup item business service
Lookup item business service

Business process decomposition helps to better understand the complex process used to provision this business service. Figure 4 shows the intricacies of this business process. Two other services are used there, the catalog and inventory services.

  • The catalog service is used to find the part number, or SKU, of the item that is to be looked up.
  • The inventory service uses this SKU to see if the item is present in the inventory system. It first looks in a local inventory system. Failing this it will search in a warehouse inventory. The process could be continued by searching an outside supplier etc. We see this in more detail in Figure 4:

Figure 4. Lookup item business process decomposition
Lookup item business process decomposition

Business process decomposition separates business services from business processes. A business analyst can now think in terms of a lookup item service that would be part of some overall business process without having to understand the intricacies of the service implementation. Business process decomposition also helps understand the IT services that are necessary to provision this process and its services.

Use cases

This use case model is stored as a reusable asset specification (RAS) asset on the dW RAS repository and can be accessed from the recipe. Figure 5 shows how to access and import the use case model from the recipe. Make sure to import the use case model into the Retail project previously created.


Figure 5. Importing the use case model asset from the recipe
Importing the use case model from the recipe

A use case model helps the architect or developer understand the software artifacts and service that need to be built. The use case model shown in Figure 6 is very similar to the business process model in Figure 3. In this example, there is close mapping between the business service and the IT service, but that is not always the case. The use case model shows the lookup item from an IT perspective


Figure 6. Lookup item use case model
Lookup item use case model

Back to top

Identification of services

In this case there is a one-to-one mapping between the business services and the IT service. This is not always the case. It is a common and dangerous misconception that IT services and business services are one and the same. There are two IT services that are of interest to the SOA pattern reference architecture. These are:

  1. The catalog service looks up the item number in the parts catalog
  2. The inventory service finds the number of those items in stock according to the inventory system.

The architect determines which use cases can be implemented by pre-existing applications or services and which use cases need to be constructed or extended. In the SOA pattern reference example there is a pre-existing catalog application that exposes a Java interface. The inventory system needs to be composed of a series of calls to existing backend databases, such as a local store database and a central warehouse database. In the next section the service definitions of each of these use case are reviewed in more detail from a UML and WSDL viewpoint.

There are a two routes to arrive at a service model. This is not an "either/or" issue, there are times when one approach is more appropriate. Let's look at these in more detail:

  1. Top-down approach: In a top-down approach, such as IBM Service Oriented Modeling Approach (SOMA), services are identified and prioritized using business analysis. Details of the services are determined from business process models. An example of a rich set of domain-specific models (such as business process models, business object models) for the insurance industry is IBM Insurance Application Architecture (See the sidebar.) Details of the services are determined from business process models.The WSDL that describes the IT services is generated from a business process model that is created in a tool such as WebSphere® Business Integration Modeler.
  2. Bottom-up approach: In a bottom-up approach the services are defined using knowledge of the existing application packages and their interfaces together with a process choreography approach to create composite services. WSDL for these services is frequently generated from class models.

The catalog service

This inventory service model, which contains both the catalog service and the inventory lookup service, is stored as a RAS asset on the dW RAS repository and can be accessed from the recipe. Browse the recipe to the location shown below and import the Ref Example Asset: SOA Inventory Service model into the Rational Software Architect Project Retail created earlier. The catalog service can be accessed from the recipe, as shown in the following:


Figure 7. SOA Inventory Design Model RAS Asset
SOA Inventory Design Model RAS Asset

The catalog service looks up the item numbers -- stock keeping units or SKUs -- in the parts catalog. In model driven development, services are UML models class models with the UML 2.0 Profile for Software Services applied. The UML 2.0 Profile for Software Services provides a common language for describing a model of services.

The UML 2.0 Profile for Software Services provides a common language for describing services, one which covers a number of activities through the development lifecycle and also provides views to different stakeholders. The UML profile for software services is a profile for UML 2.0 which allows for the modeling of services, SOA, and service-oriented solutions. The profile has been implemented in IBM Rational Software Architect, used successfully in developing models of complex customer scenarios, and used to help educate people about the concerns relevant to developing service-oriented solutions (see Resources).

IBM Insurance Application Architecture

The IBM Insurance Application Architecture is a comprehensive set of Information, Process and Integration models that represents best practice systems development in the insurance industry. It is an information architecture blueprint with detailed insurance business content that can be applied to initiatives on an enterprise-wide or specific project basis. It enables insurance companies to create detailed specifications and cross-enterprise architectures for information systems. These models represent over 300 cumulative years of development, incorporating input from many leading financial institutions (see Resources).

We now have a model for a detailed representation of how the service will be physically implemented. Using such a model, application and architectural patterns can be applied to satisfy the relevant non-functional requirements for performance, scalability and the like. The catalog service example uses patterns such as the WS Response Template pattern (see Resources) and security patterns. From the catalog service model, UML to WSDL transformations and a UML to XSD transformation can be applied to create the WSDL and XSD representations of the service, providing two different and complementary ways to visualize the service at different levels of abstraction. The transformations are beyond the scope of this article but will be included in the next article on the WS response template pattern.

  • The catalog service UML model: catalog service (See below)
  • The catalog service specification (WSDL): catalog service WSDL

The catalog service model

Figure 8 shows the catalog service model. The model has two operations:

  • The getCatalog() operation takes a primary key and returns Catalog
  • The getCatalogs() operation takes an array of primary keys and returns an array of Catalogs

Figure 8. Catalog service UML model
Catalog service UML model

The catalog data model

Figure 9 shows the catalog message model. The following is self-evident from this model:

  • Each Catalog message contains multiple CatalogItem messages
  • Each CatalogItem message contains multiple FeatureValue messages
  • Each FeatureValue message contains one Feature messages

Figure 9. Catalog message UML model
Catalog Data UML Model

The inventory service

The inventory service provides two operations. First, a query determines if the inventory contains enough units of an item to meet the quantity needed for an order. In the retail industry, the number of items available in stock is called the quantity on hand or QoH. The second operation records a change in inventory levels, either because an item had been sold or new stock has arrived: this is called a stock movement. This service can also be visualized at two different levels of abstraction, similar to the catalog service above.

  • The inventory service UML model: inventory service
  • The inventory service specification (WSDL)

The inventory service model

Figure 10 shows the inventory service model. Following on the service description above, the model has two operations:

  • The getQoH() operation takes a QoHRequest and returns QoHResponse
  • The inventoryMovement() operation takes an Integer and returns a Boolean

Figure 10. inventory service UML model
Inventory service UML model

The inventory data model

The inventory data model allows the request to specify the location of a source of inventory to be specified. An example might be a store or regional warehouse.


Figure 11. Inventory data UML model
Inventory data UML model

Back to top

Identification of legacy applications

Legacy catalog application design model

The reference example legacy catalog application design model can be accessed from the SOA implementation and optimization of service recipe in a similar manner to the way the SOA inventory service model and the SOA inventory use case model were imported into Rational Software Architect.


Figure 12. Accessing the legacy catalog application design model
Accessing the legacy catalog application design model

Figure 13 shows the UML class diagram of the legacy catalog application. This application is a Java™ component and exposes a Java interface. The getCatalog() and getCatalogs() operations are very coarse-grained since they return an entire catalog and a list of catalogs respectively.


Figure 13. UML class diagram of the legacy catalog application
UML class diagram of the legacy catalog application

Back to top

Conclusion

In the first article in this series, we introduced the use of Rational Software Architect as a RAS client to retrieve reusable assets in the form of a recipe. This article expands on this approach to demonstrate how services may be produced using these recipes, and how we may use patterns to construct those services to met specific non-functional requirements.

Services may be identified either through a top-down business analysis approach when constructing a green fields solution, or with a bottom-up approach when SOA is used for legacy system transformation.

To illustrate how patterns can be applied during service construction, we use a reference service example which is downloadable as a RAS asset: this reference example is bundled with the SOA implementation and optimization of services recipe as a step-by-step guide to using the recipe.

The next article in this series will show how to apply the WS Response Template pattern to the Catalog Service model (see Resources) to produce a more flexible and client-friendly interface.


Resources

Learn

Get products and technologies

Discuss

About the authors

Clive Gee is an executive consultant with nearly 30 years experience in the IT industry. For the past three years he has been focusing on SOA, particularly aspects of the services development process and its governance

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.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Close [x]

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

Close [x]

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, Multicore acceleration
ArticleID=123323
ArticleTitle=Building SOA applications with reusable assets, Part 2: SOA recipe reference example
publish-date=05232006
author1-email=clive@us.ibm.com
author1-email-cc=
author2-email=eoinlane@us.ibm.com
author2-email-cc=

Table of contents

Next steps from IBM

My developerWorks community

Interact, share, and communicate with developers worldwide.

My developerWorks overview

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.

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).

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).

 

Dig deeper into SOA and Web services on developerWorks

Rate a product. Write a review.

Rate a product. Write a review.

Write a review for Rational products today!

Special offers

No-cost WebSphere Application Server development

Free trial IBM TXSeries for Multiplatforms

Cloud computing for developers

More offers