Skip to main content

Building mediation flows in WebSphere Integration Developer for deployment on WebSphere ESB or WebSphere Process Server

Andrew Ferrier (andrew.ferrier@uk.ibm.com), WebSphere ESB Consultant, IBM Software Services, IBM
Photo of Andrew Ferrier
Andrew Ferrier is a consultant with IBM Software Services, specialising in WebSphere ESB. He regularly works with customers across Europe and beyond to enable them to work effectively with WebSphere ESB and other IBM products. He writes extensively on these topics, particularly at the SOA Tips 'n' Tricks blog, which he co-founded.

Summary:  This article shows you a procedure for developing mediation flow components in WebSphere Integration Developer that helps you minimise development time, proceed in a logical order, avoid later rework, and create more maintainable artifacts.

Date:  19 Aug 2009
Level:  Intermediate
Activity:  4182 views
Comments:  

Introduction

This article shows you how to develop mediation flow components in IBM® WebSphere® Integration Developer for deployment on WebSphere ESB or WebSphere Process Server. It shows you how to build them in an order that minmises development time and rework, and facilitates refactoring, and debugging.

The article is based on extensive experience developing mediation flows. It assumes that you have some experience with WebSphere Integration Developer development and mediation flow development. It doesn't go into detail about terminology or building mediation flows -- it simply outlines some proven steps to make your mediation module development more effective and minimise rework.

Before you start, you need to understand:

  • What interfaces will you be working with? Are you designing them, or are they provided?
  • What binding types will you be working with? Will you expose your mediation flow as a Web service? Will it consume a JMS- or MQ-based service?
  • What will your service do? Do you know how you're going to build it? Which mediation flow primitives are you likely to use?

You may not know all of these details before you start, but the more of them you know, the less likely it is that you'll need to rework your mediation flow later. Reading this article before you develop your next mediation flow should further increase your understanding of the things you need to know before you start work.

Define or discover the interfaces that you'll be working with

The first thing is to do is establish the interfaces you're working with, both on the front end (how the service you're building is exposed) and the back end (how the services you're calling are exposed). Good SOA principles dictate loose coupling and tightly-defined service interfaces, so the rest of your construction should be dictated by these interfaces. They may come from third parties, or you may be defining them yourself, in which case it is a good idea to define a wrapper type object for each chunk of request and response information, to avoid some subtle problems later on. Examples of these wrapper type objects are shown in Figures 1 and 2:


Figure 1. Example interface with wrapper types
Example interface with wrapper types

Figure 2. Example wrapper type
Example wrapper type

In general, it will make life easier if you spend time now getting your interfaces right. Although refactoring and change is always possible later, things will go more smoothly if you get strong definitions for the interfaces up front, so that you can minimise later changes to them.

Make sure that you add modeled faults wherever you expect that the interface may need to throw a fault -- it's always easier to work with modeled faults than unmodeled faults. Here is an example of an interface with some modeled faults:


Figure 3. Example interface with modeled faults
Example interface with modeled faults

Make sure the appropriate business or technical data is added to the modeled faults. (Modeled faults are sometimes called service business exceptions or checked faults. However, there is no reason to restrict them to business-type faults: you should use wherever you expect a fault could be thrown.)

Define exports and imports

Now, place the interfaces on an assembly diagram so that you can define imports and exports. Here are the ways your mediation module is going to communicate with the outside world:


Figure 4. Creation of imports and exports
Creation of imports and exports

If you don't like the generated names for the imports and exports, change them now. The more embedded they become in your environment, the more difficult it will be to change them later.

Define the mediation flow

Now place the mediation flow component itself on the assembly diagram, and connect it to the imports and exports. Don't forget to rename the component. This step enables you to define the interfaces and references on the component, and completes the high-level picture of your module, as shown in the assembly diagram:


Figure 5. High-level assembly diagram
High-level assembly diagram

The example above is a simple one with one export and import specified, but if you need more, add them now.

Define implementations for each operation in the mediation flow

Next, continue the top-down development approach by beginning to implement the mediation flow component by creating a new implementation. For each operation on the left-side (that you are exposing), define an implementation (the only exception is if you don't want to implement the entire interface now).

For each operation, you'll need to decide whether to use the callout feature of the mediation flow component to create a complete request and response flow for one of the back-end services, or whether to simply use a chain of Service Invoke primitives to invoke each of your back-end services. This choice is a conceptual and design matter more than a technical one. In general, it's best to drag across to one of the operations on one of the references, and therefore define a single callout, if there is one clear primary reference the mediation flow will invoke. Here's an example:


Figure 6. Single callout definition
Single callout definition

This situation can arise, for example, if the back-end service that corresponds to the callout is complex, and the rest of our mediation flow simply augments the message that is ultimately sent to it with data retrieved from other services via the Service Invoke primitive.

If the mediation flow will invoke several references, and none of them is obviously the primary one, then they should be considered peers and it's better to use Service Invoke primitives to invoke all back-end services. Here's an example:


Figure 7. Service invokes for peer back-ends
Service invokes for peer back-ends

There is no important technical difference between these approaches, but it makes the distinction clear to someone who later maintains or reads the flow between a service that is invoking one primary back-end and simply using calls out to other services to augment its behaviour, and one that is invoking several peer services to perform its task. The underlying behaviour of the mediation flow engine is very similar in both cases.

Define and specify the context objects you want to use

The next step is to define the mediation flow contexts (correlation, transient, and shared) you want to use. It's important to do this step at this stage, as the definitions get baked in to the XSLT or BO maps that you may define later, so defining them now minmises later rework. A good practice is to define a wrapper BO type for context you expect to use (probably stored in the module itself) that can contain the relevant chunks of data. Doing so is important because each context can contain only one object of one type. Also, the wrapper gives you some potential for adding fields to the context later. Here's an example of what such a wrapper business object looks like:


Figure 8. Wrapper object for correlation context
Wrapper object for correlation context

Consider the transient context to be a bit like a set of local variables in a programming language. Typically, you use it to store temporary data inside a flow that's created by one mediation primitive and used by another one. For example, when one mediation primitive will overwrite the /body section of the Service Message Object, and there is data in there you need to preserve, you can save it in the transient context. Therefore, you need to think about the fields you'll need ahead of time.

The correlation context is typically used for data shared between request and response flows in a mediation flow. You might use it, for example, when you require a unique ID for each message that's shared for logging purposes. Again, you need to understand your requirements ahead of time, so that you can define the correlation context wrapper type. The shared context is typically used when you are working with branching logic in a mediation flow. For more information, see the developerWorks article Aggregation functionality in WebSphere ESB V6.1.

Define the message-type flow of the mediation flow

Now it's time to start defining the flow itself by putting in primitives.

Firstly, you'll want to define the basic structure of the flow by adding all the primitives you're expecting to use and writing them together. During this phase, you don't generally set properties on the primitives. It's especially important during this phase to get the message types right: in other words, ensure that all the terminals of the various message primitives have their message types set as you expect them to end up. Defining the form of the flow and the types that will be used throughout will make it easier to come back later and define the properties on those primitives, rather than doing both in parallel. It will also provide some validation that the basic structure of the flow will hang together. Here are some rules to follow:

  1. Work from left to right: first create the first primitive you intend to use and wire it up to the input node. Then create the second primitive, and wire it up to the first, and so on.
  2. Whenever you create a primitive that can have a variable number of output terminals, create them as you go, to ensure that all possible paths of flow are apparent.
  3. Whenever you create a primitive where the output terminal type doesn't have to be the same as the input terminal type (such as the Custom Mediation, the XSLT or the BO Map), define the output terminal type manually as you go, ensuring that the types of the terminals are set.
  4. Whenever you create a Set Message Type or Type Filter primitive, define the Message Type Refinements table or Filters table as you go to make sure that downstream (logically, to the right) primitives are aware that part of the message is more or less specific than it was upstream. This rule is an exception to the above rule of not setting mediation properties during this phase.
  5. When you create a Service Invoke primitive in the flow, the tool asks you to specify the partner reference and operation that should be invoked. Specify this correctly, as it will automatically set the terminal types appropriately for you.
  6. During this phase, change the names of all primitives that you create as you go from the default name to a name that is meaningful to you or that satisfies your naming conventions. Doing so ensures that the names of any artifacts that you create later will be automatically derived from primitive names and match up accurately.
  7. You don't need to include any non-functional primitives, such as ones that do logging, as long as they don't change the message type. You can insert those later.

Sometimes, it's possible to work from the right instead or simultaneously from both directions. Doing so can be useful in simple flows, particularly when doing mapping: as the Mediation Flow Editor understands what the type of the output node is, it can set the output terminal types automatically on primitives that can have varied output terminal types. Here is an example:


Figure 9. Example of working from the right
Example of working from the right

The type of the highlighted terminal shouldn't be set manually, but instead just connected to the Partner callout, which causes its type to be set automatically.

Define maps

Now, define the maps on the XSLT and BO map primitives that you've placed in the flow. Because you've already defined the types of the terminals on all the mediation primitives in the flow, this task should be as straightforward as possible. You simply define a new map, and the input and output types of the map will be set automatically, as shown below:


Figure 10. Definition of XSLT Map, showing automatic type inference
Definition of XSLT map, showing automatic type inference

Set all properties

Now it's time to go through and set properties appropriately on all the remaining mediation primitives for which you haven't already defined the properties. Don't miss any!

Define primitives that don't alter message type

As mentioned above, some people use custom mediations for logging or other non-functional purposes. If so (and they don't change the message type), it makes sense to put them in last, perhaps even after an initial round of testing, and it is more straightforward to set the terminal types appropriately. As of Service Registry V6.2, it's easier to do this: simply drop the new primitive on a wire, and it will be inserted in the appropriate place. For primitives with flexible terminal types, such as the Custom Mediation, the output terminal type will still need to be set appropriately.

Testing

You've now completed the initial build of the flow you're going to use -- it's time to test! WebSphere Integration Developer has a unit test infrastructure that's ideal for testing the mediation flow you've just built. See the Resources section for more information.

Acknowledgements

The author would like to thank Kim Clark and Dave George of IBM for their feedback on and help with this article.


Resources

About the author

Photo of Andrew Ferrier

Andrew Ferrier is a consultant with IBM Software Services, specialising in WebSphere ESB. He regularly works with customers across Europe and beyond to enable them to work effectively with WebSphere ESB and other IBM products. He writes extensively on these topics, particularly at the SOA Tips 'n' Tricks blog, which he co-founded.

Comments

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=WebSphere
ArticleID=421930
ArticleTitle=Building mediation flows in WebSphere Integration Developer for deployment on WebSphere ESB or WebSphere Process Server
publish-date=08192009
author1-email=andrew.ferrier@uk.ibm.com
author1-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 WebSphere on developerWorks

Rate a product. Write a review.

Rate a product. Write a review.

Write a review for Rational products today!

Special offers

Rate and Review Rational products

WebSphere Application Server Hypervisor trial

SOA Tutorials IBM Book + DVD 35% off: IBM0402

More offers