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 |