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

• WS-Security: This is one of the secure standards used to secure Web Service at the message level, independent of the transport protocol. To learn more about WID and WS-Security refer to http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/topic/com.ibm.wbit.help.runtime.doc/deploy/topics/cwssecurity.html.
• WS-Policy: A framework that helps define characteristics about Web Services through policies. To learn more about WS-Policy refer to: http://www.w3.org/TR/ws-policy/.
• WS-Addressing: This specification aids interoperability between Web Services, by standardizing ways to address Web Services and by providing addressing information in messages. In version 7.0, enhancements were made to WID to provide Web Services support for WS-Addressing and Attachments. For more details about WS-Addressing refer to http://www.w3.org/Submission/ws-addressing/.

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