6 min read

This article will help you build your first HelloWorld WebSphere Enterprise Service Bus (WESB) mediation application and WESB mediation flow-based application. This article will then give an overview of Service Message Object (SMO) standards and how they relate to building applications using an SOA approach. At the completion of this article, you will have an understanding of how to begin building, testing, and deploying WESB mediations including:

  • Overview of WESB-based programming fundamentals including WS-*? standards and Service Message Objects (SMOs)
  • Building the first mediation module project in WID
  • Using mediation flows
  • Deploying the module on a server and testing the project
  • Logging, debugging, and troubleshooting basics
  • Exporting projects from WID

WS standards

Before we get down to discussing mediation flows, it is essential to take a moment and acquaint ourselves with some of the Web Service (WS) standards that WebSphere Integration Developers (WIDs) comply with. By using WIDs, user-friendly visual interfaces and drag-and-drop paradigms, developers are automatically building process flows that are globally standardized and compliant. This becomes critical in an ever-changing business environment that demands flexible integration with business partners. Here are some of the key specifications that you should be aware of as defined by the Worldwide Web Consortium (W3C):

What are mediation flows?

SOA, service consumers and service providers use an ESB as a communication vehicle. When services are loosely coupled through an ESB, the overall system has more flexibility and can be easily modified and enhanced to meet changing business requirements. We also saw that an ESB by itself is an enabler of many patterns and enables protocol transformations and provides mediation services, which can inspect, modify, augment and transform a message as it flows from requestor to provider. In WebSphere Enterprise Service, mediation modules provide the ESB functionality.

The heart of a mediation module is the mediation flow component, which provides the mediation logic applied to a message as it flows from a service consumer to a provider. The mediation flow component is a type of SCA component that is typically used, but not limited to a mediation module. A mediation flow component contains a source interface and target references similar to other SCA components. The source interface is described using WSDL interface and must match the WSDL definition of the export to which it is wired. The target references are described using WSDL and must match the WSDL definitions of the imports or Java components to which they are wired. The mediation flow component handles most of the ESB functions including:

  • Message filtering which is the capability to filter messages based on the content of the incoming message.
  • Dynamic routing and selection of service provider, which is the capability to route incoming messages to the appropriate target at runtime based on predefined policies and rules.
  • Message transformation, which is the capability to transform messages between source and target interfaces. This transformation can be defined using XSL stylesheets or business object maps.
  • Message manipulation/enrichment, which is the capability to manipulate or enrich incoming message fields before they are sent to the target. This capability also allows you to do database lookups as needed.
  • If the previous functionalities do not fit your requirements, you have the capability of defining a custom mediation behavior in JAVA.

The following diagram describes the architectural layout of a mediation flow:

 

In the diagram, on the left-hand side you see the single service requester or source interface and on the right-hand side are the multiple service providers or target references. The mediation flow is the set of logical processing steps that efficiently route messages from the service requestor to the most appropriate service provider and back to the service requestor for that particular transaction and business environment. A mediation flow can be a request flow or a request and response flow. In a request flow message the sequence of processing steps is defined only from the source to the target. No message is returned to the source. However, in a request and response flow message the sequence of processing steps are defined from the single source to the multiple targets and back from the multiple targets to the single source. In the next section we take a deeper look into message objects and how they are handled in the mediation flows.

Mediation primitives

What are the various mediation primitives available in WESB?

Mediation primitives are the core building blocks used to process the request and response messages in a mediation flow.

  • Built-in primitives, which perform some predefined function that is configurable through the use of properties.
  • Custom mediation primitives, which allow you to implement the function in Java.
  • Mediation primitives have input and output terminals, through which the message flows. Almost all primitives have only one input terminal, but multiple input terminals are possible for custom mediation primitives.
  • Primitives can have zero, one, or more output terminals.
  • There is also a special terminal called the fail terminal through which the message is propagated when the processing of a primitive results in an exception.

The different types of mediation primitives that are available in a mediation flow, along with their purpose, are summarized in the following table:

Service invocation

 

Service Invoke

Invoke external service, message modified with result

Routing primitives

 

Message Filter

Selectively forward messages based on element values

Type Filter

Selectively forward messages based on element types

Routing primitives

 

Endpoint Lookup

Find potential endpoint from a registry query

Fan Out

Starts iterative or split flow for aggregation

Fan In

Check completion of a split or aggregated flow

Policy Resolution

Set policy constrains from a registry query

Flow Order

Executes or fires the output terminal in a defined order

Gateway Endpoint Lookup

Finds potential endpoint in special cases from a registry

SLA Check

Verifies if the message complies with the SLA

UDDI Endpoint Lookup

Finds potential endpoints from a UDDI registry query

Transformation primitives

 

XSL Transformation

Update and modify messages using XSLT

Business Object Map

Update and modify messages using business object maps

Message element setter

Set, update, copy, and delete message elements

Set message type

Set elements to a more specific type

Database Lookup

Set elements from contents within a database

Data Handler

Update and modify messages using a data handler

Custom Mediation

Read, update, and modify messages using Java code

SOAP header setter

Read, update, copy, and delete SOAP header elements

HTTP header setter

Read, update, copy, and delete HTTP header elements

JMS header setter

Read, update, copy, and delete JMS header elements

MQ header setter

Read, update, copy, and delete MQ header elements

Tracing primitives

 

Message logger

Write a log message to a database or a custom destination

Event emitter

Raise a common base event to CEI

Trace

Send a trace message to a file or system out for debugging

Error handling primitives

 

Stop

Stop a single path in flow without an exception

Fail

Stop the entire flow and raise an exception

Message Validator

Validate a message against a schema and assertions

Mediation subflow primitive

 

Subflow

Represents a user-defined subflow


Subscribe to the weekly Packt Hub newsletter. We'll send you the results of our AI Now Survey, featuring data and insights from across the tech landscape.

LEAVE A REPLY

Please enter your comment!
Please enter your name here