This article will show you how to develop custom mediation components using IBM® WebSphere® Integration Developer V6.0.1 and WebSphere Enterprise Service Bus V6.0.1 (hereafter called WebSphere ESB). The article will show you how to construct a mediation module, and describe the three types of custom mediation.
To make best use of this article, you should be familiar with Java™, and have some knowledge of the WebSphere Integration Developer development environment and IBM Service Component Architecture (SCA). The examples in this article were developed using WebSphere Integration Developer and deployed on WebSphere ESB. The examples can also be written for and deployed on WebSphere Process Server V6.0.1.
A custom mediation primitive enables a business integrator to add Java processing capabilities to a mediation flow. Although there are three ways to construct a custom mediation, they all function in a similar fashion. The custom mediation enables the flow to call out from the running flow to a Java component in the SCA assembly that contains the flow:
Figure 1. How a custom mediation works
In Figure 1, the mediation component (ProviderMediation) in the assembly diagram contains the "zoomed-in" flow in the lower part of the graphic. The mediation component makes a reference to the Java component (ProviderComponent), but it is the custom mediation primitive "within" the mediation component that makes use of the Java component via the reference.
As mentioned, there are three ways to create custom mediations:
- A custom mediation with a user-created interface and implementation. This type of custom mediation can have limitations unless it is carefully crafted.
- A custom mediation with a fully generated interface and implementation. This type of custom mediation lets you create code in situ using the Snippet Editor or the Visual Java Editor.
- A custom mediation with a generated interface only. In this type of custom mediation, you must create the mediation using a standard Java editor.
This article will show you how to use a user-created mediation in the DateProvider project.
This project will be used as though it were an external service in the DateService project, and this project
will demonstrate the use of the other two types of custom mediation.
Setting up your development environment
To follow the instructions in this article, you need to ensure that your development environment is configured correctly. In WebSphere Integration Developer, start by selecting Window => Preferences to open the Preferences dialog.
Workbench setup
Under the Workbench section, select Capabilities and ensure that all of the Web Service Developer options are checked. This is not required to develop custom mediations, but the Web Services Explorer will be used when testing the flow.
Server setup
In the Server section of Preferences, select Installed Runtimes and ensure that WebSphere ESB Server V6.0 is the default server.
JRE setup
Under the Java section, under Installed JREs, ensure that the default JRE is set to use the WebSphere ESB Server V6.0 JRE.
To show you how to use custom mediations, we will walk through generating each type of mediation, starting with the user-generated version.
To demonstrate this form of custom mediation, we will create a flow that accepts date based on java.util.Date and responds with
a number representing a day of the week, with 1=Sunday, 2=Monday, and so on to 7=Saturday. The project is made up of the following steps:
- Creating the library
- Creating the assembly
- Creating the flow
Creating the library
Before creating the assembly, we need to create a Library Project, which will be used to hold the interface we will use.
This interface will be reused in a later project; hence the need for a shared Library Project. To create it, right-click the Business Integration view and select
New => Library. In the New Library wizard, set the Name to DateLibrary and click Finish.
Having created the DateLibrary, right-click on the Interfaces section of the DateLibrary
and select New => Interface. In the New Interface wizard, set the Name to DateProvider and click Finish,
which will generate the new interface and open the Interface Editor.
In the Interface Editor create, an operation called getDayOfWeek. On the operation, set an input called
date of type date and an output called day of type int. The final result should look like Figure 2:
Figure 2. Date Provider interface.
Creating the assembly
To create the assembly, right-click on the Business Integration view and select New => Mediation Module. In the New Mediation Module wizard,
set the module Name to DateProvider, leave all of the other defaults, and click Next>.
In the next panel of the wizard, you can choose the libraries that the module references. In this case we need to be able to refer to the
DateProvider interface that we just created.
Check the box next to DateLibrary and then click Finish, which will create a new mediation module.
Double-click the assembly diagram and rename the mediation component from Mediation1 to
ProviderMediation. Then add the DateProvider interface to the component.
Add an Export component and name it ProviderExport, then again add the DateProvider interface.
Right-click it again and set the export binding to be an SCA binding. Now select a Java Component from the pallet and add it to the canvas, and again add the interface
DateProvider to the component. This time the dialogue will also show Java classes, so filter the view to Web Service Description Language (WSDL) files. Rename the component from Component1 to ProviderComponent.
Finally, select the wire tool and wire the ProviderExport to the ProviderMediation and the
ProviderMediation to the ProviderComponent.
A dialog will ask A matching reference will be created on the source node. Do you want to continue?.
Click OK. When the link is made, a box marked 1..1 appears on the ProviderMediation.
This box indicates the reference to a Java component is available to the mediation component. The resulting assembly should look like this:
Figure 3. Date Provider Assembly.
Save the assembly you have created so far. The blue circles containing exclamation marks on ProviderMediation and
ProviderComponent indicate that the Flow and Java components require implementations.
Creating the Java component
To create the implementation behind the ProviderComponent, double-click on the component.
When asked Would you like to implement the component now?, click Yes.
The next dialog has an option to create a package for the Java code that will be generated.
Click New Package and in the New Package dialog, set the package name to com.ibm.dateprovider.
On return to the Generate Implementation dialog, select the new package and click OK.
The generated class DateProviderImpl will open in the Java Editor. This class is simple and is referred to by the Java component.
Comments explain what the methods do. Here is the method that needs to be modified:
Listing 1. Date Provider method
/**
* Method generated to support implementation of operation
* "getDayOfWeek" defined for WSDL port type named
* "interface.DateProvider".
*
* Please refer to the WSDL Definition for more information
* on the type of input, output and faults).
*/
public Integer getDayOfWeek(Object date) {
//TODO Needs to be implemented.
return null;
}
|
Replace the contents of the getDayOfWeek method with the code in Listing 2:
Listing 2. Date Provider code
System.out.println("ProviderComponentImpl - getDayOfWeek : Mediation Called");
// Use a GregorianCalendar to get the day of the week
System.out.println("ProviderComponentImpl - getDayOfWeek : Setting GregorianCalendar to using date
[" + ((Date)date) + "]");
GregorianCalendar calendar = new GregorianCalendar();
calendar.setTime((Date) date);
System.out.println("ProviderComponentImpl - getDayOfWeek : Setting calendar is [" + calendar + "]");
//Return the day of the week
System.out.println("ProviderComponentImpl - getDayOfWeek : Returning the day of week as "
+ calendar.get(java.util.Calendar.DAY_OF_WEEK));
return new Integer(calendar.get(java.util.Calendar.DAY_OF_WEEK));
|
After saving and closing the Java Editor, the Java component will no longer be marked as requiring implementation.
Creating the flow
Double-click on the ProviderMediation flow component.
When asked The selected component is not yet implemented. Would you like to implement the component now?, click Yes.
The next dialog asks where to generate the implementation.
Click OK to accept the default location of the DateProvider project root.
The Mediation Flow Editor opens. It has two panes, with the properties view playing an important role in the lower pane.
The upper pane indicates the interface operation you are working on, and the lower pane shows the flows associated with that operation.
We will create a simple request/response flow for the single operation on the DateProvider interface.
Select the operation getDayOfWeek and the lower Request pane will show the two available nodes --
the Input node for the operation and the Input Response node.
Since we are not associating the operation with any external services, we do not see any Callout nodes to wire to.
For our purposes, this is all we need, as we will be "looping back" any incoming message after passing it through the custom mediation.
To add a custom mediation to the canvas, select a custom mediation from the flow pallet and click on the blank canvas.
Rename the custom mediation from CustomMediation1 to ProviderMediation.
Select the Input node's Out terminal and wire it to the In terminal of ProviderMediation.
Then wire the ProviderMediation Out to the In on the Input Response node. The resulting flow should look like this:
Figure 4. Date Provider Flow
Next, associate ProviderMediation with the interface we created earlier, which links the Java Component in the assembly diagram
to the custom mediation that we are creating.
Select ProviderMediation, and in the properties view below, select the Details tab:
Figure 5. Custom mediation properties -- Details.
The Details tab shows the error Service operation: cannot be empty.
To correct this error, click Define to open the Define Custom Mediation dialog,
In the first panel, set the option Choose an existing interface so you can set the interface we have made.
Click Next>, then click Browse to select the interface DateProvider.
Then select the Operation drop-down to select the operation getDayOfWeek. The Input Message
and Output Message displays are automatically set to the request and response messages found on the operation. Click Finish.
Now that we have defined the custom mediation and its interface, the flow is complete. Save the flow. The assembly is now also complete.
The mediation module we have just generated accepts a date as input and responds with a number representing the day of the week that that date falls on. Now let's put this "service" into a common context in which custom mediations are used. Assume that a Web client wants to use this service and will obtain the date information from a user in the form of an independent day, month, and year. The required response will be a string representation of the day of the week:
Figure 6. Message mismatch.
In order to resolve the mismatch of the message types in the above scenario, we can use WebSphere ESB and custom mediations. In order to implement this project, we will need to perform the following steps:
- Creating the interface
- Creating the assembly
- Mapping the operation
- Creating the request flow
- Creating the response flow
- Creating the component
Creating the interface
The first thing that is required is to create a mediation module project. Name it DateService and again ensure that it
has reference to the DateLibrary, as it contains the interface that we will be calling on.
After this is generated, create a Business Object data type to hold the input day, month. and year.
Right-click on the Data Types section of the DateService project and select New => Business Object.
In the New Business Object Wizard, set the name to DateBO and click Finish.
The Business Object Editor will open and display the DateBO object.
Select the Add as attribute to a business object icon and add the first attribute. A new attribute will be created.
Change the name from attribute1 to day and set the type to int.
Repeat this process and add the attributes month and year.
The final Business Object should look like this:
Figure 7. DateBO Business Object.
Now that the Business Object that will hold the input data has been created, generate the interface that will be used by the
DateService:
Figure 8. Date Service interface.
Creating the assembly
Now all of the parts are in place to begin creating the DateService assembly.
There are two stages, and in this first stage we will create the basic assembly shown below in Figure 9. Later we will generate the Java Components we need.
Double-click the DateService assembly to open it in the Assembly Editor.
Rename the Mediation component to ServiceMediation and assign it the DateService interface.
Then add an Import and an Export component to the canvas and name them
ServiceImport and ServiceExport respectively.
Starting with the Import, this needs to be configured to refer to the ProviderExport created in the
DateProvider project. First, assign this component the DateProvider interface from the shared library,
and set the binding for the component to an SCA Binding.
Now that this component has the same binding type as the Export that we wish to target, right-click the component and select Select Service To Import.
In the SCA Export Selection dialogue, select ProviderExport.
This import will now refer to the export we created earlier and will ultimately let us use the custom mediation in that module,
thus using the DateProvider as a substitute for an external service.
In a real world situation, you would probably not import an interface to an external service such as an existing Web service or JMS application.
The next item to edit on the canvas is the export. Assign the DateService interface to the component.
Then assign a Web Service Binding to the export. In response to the question
Should we automatically generate a WSDL file with binding/service/port elements defined inside for you?, click Yes.
In the Select Transport dialogue, select SOAP/HTTP as the transport. It is needed later to act as the client when we test the file using the Web Service Explorer. Note that the Web Service Ports section appears in the DateService project.
This section should now contain the file ServiceExport_DateServiceHttpPort.
The final task is to wire the assembly. Wire the export to the mediation component and the mediation component to the import. When asked about interfaces and references, click OK. When you are done, remember to choose the Selection tool on the pallet so that you get out of the wiring mode. Save the file and it should look like this:
Figure 9. Service Assembly Creation - Stage One.
Mapping the operations
After creating the assembly, we have wired together the incompatible interfaces. It is inside the mediation component that we will use custom mediations
in the request and response flows to transform the messages. From the Assembly Diagram, double-click on ServiceMediation and open
the Flow Editor. This time, the first thing to do is to associate the getDay operation with the getDayOfWeek operation on the DateProviderPartner reference.
To do this mouse over the getDay operation, select the Create Operation Mapping handle,
and drag it over to the getDayOfWeek operation on the DateProviderPartner reference.
This will result in an arrow indicating the mapping, as shown in Figure 10:
Figure 10. Service Flow Operation Mapping.
Notice that two things happen in the Flow Editor:
- On the canvas, the Callout
DateProviderPartner_getDayOfWeek_Calloutappears. - A second tab Response :getDay appears.
Save the flow before continuing.
Creating the request flow
Let's start with the request flow. Is this half of the mediation that will handle the transformation of the input message (day, month, year)
into the input message (java.lang.Date) expected by the service we will call out to. Ensure that the Request: getDay
tab is selected and add a custom mediation to the canvas with the name RequestMediation.
Wire DateService_getDay_Input to RequestMediation,
then wire RequestMediation to DateProviderPartner_getDayOfWeek_Callout.
The incoming message on the request half of its journey will pass through the custom mediation and then onto the input of the
DateProviderPartner, which in turn is a reference to import in the assembly diagram. The final flow should look like this:
Figure 11. Service Flow -- Request :getDay.
Ignore the warning marker on the input response node (DateService_getDay_InputResponse) -- it is just warning us that
the node's terminal has not been connected. In this case we want the message to pass on to the next module and not to be returned directly from this flow.
Now that the flow is configured, we can build the contents of the flow. Select RequestMediation
and then in the Properties view for the mediation, select the Details tab and click Define.
This time, leave Create a new interface with implementation selected and click Next>. In the following panel, you don't need to change anything. The request messages in input getDayRequestMsg and output getDayOfWeekRequestMsg
are the messages we need to translate. In the next panel, change the Name from CustomMediation1 to
RequestMediation and click Next>.
Finally, select Generate a default Java implementation class and define it using the embedded visual snippet editor and click Finish.
When the dialog closes, a RequestMediationPatner reference with the operation mediate
appears in the Operation connections panel of the Mediation Flow Editor. Also, the RequestMediation interface
appears in the Interfaces section of the DateService project in the Business Integration view.
Having set the interface that we will be using, we need to add the Java code to the Java Snippet. Select the Implementation tab of the Properties view, as shown in Figure 12 below. By using the Java Snippet Editor, this form of mediation indicates conceptually where the Java code resides, even though the code actually resides in a Java Component. The Snippet Editor has some restrictions worth noting. It does not indicate errors in the Java Code, and when you add code that requires an import, don't forget to press Ctrl+Shift+O to Organize Imports or fully qualify the classes you include.
While editing the code, if you need to get a better view of what is happening, click Open Java Editor to access the class containing this code.
Figure 12. Custom Mediation Properties -- Implementation.
In the snippet, add the code in Listing 3 to the code snippet section:
Listing 3. Java Snippet code
System.out.println("RequestMediation : Mediation called");
System.out.println("RequestMediation : Getting BOFactory");
ServiceManager serviceManager = ServiceManager.INSTANCE;
BOFactory bofactory = (BOFactory) serviceManager.locateService("com/ibm/websphere/bo/BOFactory");
System.out.println("RequestMediation : Getting dateBO");
DataObject dateBO = a_type.getDataObject("dateBO");
System.out.println("RequestMediation : Create date from [" + dateBO.getInt("year") + ", "
+ dateBO.getInt("month")+ ", "
+ dateBO.getInt("day") + "]");
GregorianCalendar calendar = new GregorianCalendar(dateBO.getInt("year"),
dateBO.getInt("month")-1,
dateBO.getInt("day"));
System.out.println("RequestMediation : Create DataObject
http://DateLibrary/DateProvider/getDayOfWeek");
DataObject getDayOfWeek = bofactory.createByElement("http://DateLibrary/DateProvider",
"getDayOfWeek");
System.out.println("RequestMediation : Set getDayOfWeek date attribute");
getDayOfWeek.setDate("date", calendar.getTime());
System.out.println("RequestMediation : Return date getDayOfWeek");
return getDayOfWeek;
|
At this point, save the flow created so far. An error marker appears on the project we are working on. What has gone wrong? The error is associated with the assembly diagram with the message "The mediation flow implementation 'ServiceMediation.mfc' contains a reference 'ResponseMediationPartner' that does not match a corresponding reference in the mediation flow component."
Recall that the introduction described the custom mediation within the flow using a reference to call out of the flow to a component in the assembly diagram. In the first part of this exercise, we generated a Java component and wired it to the mediation component to create a reference. In this case, we have generated the custom mediation, the Java code, and the reference. However, the component that the reference is looking for does not yet exist on the assembly diagram. You can ignore this error for now because we will correct it in the the last stage of the exercise.
Creating the response flow
Next, fill in the other half of the mediation flow. The job of this transformation is to take the response message from our "external" service
(an int representing the day of the week) and turn it into the response expected by our own interface
(a java.lang.String version of the day of the week).This time select the Response :getDay tab in the Mediation Flow Editor
and as you did above, add a custom mediation.
Name the mediation ResponseMediation and wire it into the flow. The resulting flow should look like this:
Figure 13. Service Flow -- Response :getDay
On the properties view of ResponseMediation, go to the Details tab and click Define.
Again, select Create a new interface with implementation => Next>. Click through the following panel, and in the next panel change
Name from CustomMediation1 to ResponseMediation. Then click Next>.
In the last panel, select Specify the implementation manually as Java component or Import in the Assembly Editor --
default Java Implementation will not be generated and click Finish.
ResponseMediationPartner appears in the Operation connections panel of the Mediation Flow Editor
and an associated ResponseMediation interface is generated in the project. Save the flow. You may notice
that another error similar to the one we had for the request flow appears. It is now time to fix these errors.
Creating the Java components
Open the Assembly diagram and right-lick on ServiceMediation and select Merge Implementation.
You will be asked Do you want to merge the new implementation with the existing one?. Click OK.
A dialog will open that shows the Reference being used, the interface that the reference uses, and a check box to indicate that a Java Component will be created.
Click OK again, which switches you back to the Flow Diagram. Return to the Assembly Diagram Editor and you should see two new components.
Click Arrange Contents Automatically and the diagram should look like this:
Figure 14. Service Assembly Creation -- Stage Two.
These two Java components are what the mediations we have created will call out to from the flow. The ResponseMediationPatner
is marked as requiring an implementation. Recall that during the flow creation, we added code to the request flow.
If the code had problems persisting, then you saw where the implementation for this Java component resides.
To implement the ResponseMediationPartner, follow the same steps as when implementing the
ProviderComponent, but this time set the package to be com.ibm.dateservice
and add the code in Listing 4 to the method public DataObject mediate(DataObject a_type):
Listing 4. Response mediation partner code
System.out.println("ResponseComponentImpl - mediate : Mediation Called");
StringBuffer dayOfWeek = new StringBuffer();
System.out.println("ResponseComponentImpl - mediate : Getting the day number");
int day = a_type.getInt("day");
//Decide which day of the week it is
System.out.println("ResponseComponentImpl - mediate : Decide day of week on value [" + day + "]");
switch (day) {
case 1: {
dayOfWeek.append("Sunday");
break;}
case 2: {
dayOfWeek.append("Monday");
break;}
case 3: {
dayOfWeek.append("Tuesday");
break;}
case 4: {
dayOfWeek.append("Wednesday");
break;}
case 5: {
dayOfWeek.append("Thursday");
break;}
case 6: {
dayOfWeek.append("Friday");
break;}
case 7: {
dayOfWeek.append("Saturday");
break;}
default : {
dayOfWeek.append("Day could not be calculated");
break;}
}
System.out.println("ResponseComponentImpl - mediate : Getting BOFactory");
ServiceManager serviceManager = ServiceManager.INSTANCE;
BOFactory bofactory = (BOFactory) serviceManager.locateService("com/ibm/websphere/bo/BOFactory");
System.out.println("ResponseComponentImpl - mediate : Create DataObject
http://DateService/DateService/getDayOfWeek");
DataObject getDay = bofactory.createByElement("http://DateService/DateService",
"getDayResponse");
System.out.println("ResponseComponentImpl - mediate : Set dayOfWeek string to ["
+ dayOfWeek.toString() + "]");
getDay.setString("dayOfWeek", dayOfWeek.toString());
System.out.println("ResponseComponentImpl - mediate : Returning getDay");
return getDay;
|
Save the Java code that you have just added and return to the Assembly Diagram Editor and save that as well. The implementation marker will disappear. The mediation flow is complete, and you are now able to deploy this flow and test it using the Web Services Explorer.
First, go to the Servers view in the Business Integration perspective. If you have not yet created a server, right-click the view pane and select New => Server. In the New Server dialog, select WebSphere ESB Server V6.0 and then click Finish.
WebSphere ESB Server V6.0 localhost will appear in the Servers View.
If the server you are targeting is remote, then it will say something other than localhost.
Select the new server and ensure that it is started. This may take awhile, but eventually in the Console View you will see:
[31/12/05 16:26:08:109 GMT] 0000000a WsServerImpl A WSVR0001I: Server server1 open for e-business |
In the Server View, the server should have a "started" status:
Figure 15. Started server
Return to the Servers View and select the ESB server. Right-click the server and select Add and remove projects, which will show you a dialog
with a view of the projects available for deployment and those deployed. Ensure that the DateProvider and
the DateService projects are added to the server. Click Finish.
Once the projects have been published on the server they are ready for testing. Switch to the Java perspective.
Recall that when we created an export for the DateService project, we created a Web service binding on the export
and set it to use the SOAP/HTTP transport. When this was done, a WSDL file was generated for us with all of the binding/service/ports defined.
We will use this WSDL file in the Web Service Explorer to test out our newly deployed flows.
In the Java perspective, use the Package Explorer to locate the DateService project.
In the root of this project, find the ServiceExport_DateServiceHttp_Service.wsdl file that we will use for testing.
Right-click the WSDL file and select Web Services => Test with Web Services Explorer.
The Web Service Explorer browser will open and will be looking at the file we selected.
In the operations section, click the getDay link to go to the Invoke a WSDL Operation page. Here each of the parts of the
dateBO are visible -- day, month, and year.
For each one, select Add and enter an appropriate value, such as day=1, month=1, year=1970.
Then click Go, which sends the date data to the server where the flow has been deployed.
After this data has been processed, the Status panel below will change and display the getDayResponse message
and the value of dayOfWeek. For example, given the date above, the response will be Thursday:
Figure 16. Web Service Explorer.
As further evidence of the flow running, in the console you will see the output from the System.out.println(); lines
in the Java code we added. These allow us to see the messages at various stages of processing:
Listing 5. Console output
[29/12/05 17:14:44:688 GMT] 00000051 SystemOut O RequestMediation : Mediation called
[29/12/05 17:14:44:688 GMT] 00000051 SystemOut O RequestMediation : Getting BOFactory
[29/12/05 17:14:44:703 GMT] 00000051 SystemOut O RequestMediation : Getting dateBO
[29/12/05 17:14:44:703 GMT] 00000051 SystemOut O RequestMediation : Create date from
[1970, 1, 1]
[29/12/05 17:14:44:703 GMT] 00000051 SystemOut O RequestMediation : Create DataObject
http://DateLibrary/DateProvider/getDayOfWeek
[29/12/05 17:14:44:703 GMT] 00000051 SystemOut O RequestMediation : Set getDayOfWeek date
attribute
[29/12/05 17:14:44:703 GMT] 00000051 SystemOut O RequestMediation : Return date getDayOfWeek
[29/12/05 17:14:45:156 GMT] 00000051 SystemOut O ProviderComponentImpl - getDayOfWeek :
Mediation Called
[29/12/05 17:14:45:156 GMT] 00000051 SystemOut O ProviderComponentImpl - getDayOfWeek :
Setting GregorianCalendar to using date
[Thu Jan 01 00:00:00 GMT 1970]
[29/12/05 17:14:45:156 GMT] 00000051 SystemOut O ProviderComponentImpl - getDayOfWeek :
Setting calendar is
[java.util.GregorianCalendar
[time=-3600000,
areFieldsSet=true,
areAllFieldsSet=true,
...
MILLISECOND=0,
ZONE_OFFSET=3600000,
DST_OFFSET=0]]
[29/12/05 17:14:45:156 GMT] 00000051 SystemOut O ProviderComponentImpl - getDayOfWeek :
Returning the day of week as 5
[29/12/05 17:14:45:188 GMT] 00000051 SystemOut O ResponseComponentImpl - mediate :
Mediation Called
[29/12/05 17:14:45:188 GMT] 00000051 SystemOut O ResponseComponentImpl - mediate :
Getting the day number
[29/12/05 17:14:45:188 GMT] 00000051 SystemOut O ResponseComponentImpl - mediate :
Decide day of week on value [5]
[29/12/05 17:14:45:188 GMT] 00000051 SystemOut O ResponseComponentImpl - mediate :
Getting BOFactory
[29/12/05 17:14:45:188 GMT] 00000051 SystemOut O ResponseComponentImpl - mediate :
Create DataObject
http://DateService/DateService/getDayOfWeek
[29/12/05 17:14:45:188 GMT] 00000051 SystemOut O ResponseComponentImpl - mediate :
Set dayOfWeek string to [Thursday]
[29/12/05 17:14:45:188 GMT] 00000051 SystemOut O ResponseComponentImpl - mediate :
Returning getDay
|
WebSphere ESB Server V6.0.1 comes with a good basic pallet of mediation primitives and has an easy-to-use interface which lets you quickly integrate different interfaces. However, there are always applications or interfaces that do not fit together as nicely as we would like. This article has shown how custom mediations let the Business Integrator add Java code to handle these cases. By creating the case where the interface does not match nicely, you have seen just how quickly and easily custom mediation lets you solve this problem.
I hope this article has let you see how powerful custom mediations are. In addition to the situation described here, custom mediations let you add code to manipulate messages in many ways, adding business logic as needed. For example, you can use them to call complex JDBC queries, generate new messages, or manipulate message body content or headers in ways that XSLT cannot manage. The possibilities are as diverse as the applications problems you need to solve.
| Description | Name | Size | Download method |
|---|---|---|---|
| Code samples in zip format | CustomMediations.zip | 269 KB | FTP |HTTP |
Information about download methods
- WebSphere Enterprise Service Bus product page
Product descriptions, product news, training information, support information, and more. - WebSphere Integration Developer product page
Product descriptions, product news, training information, support information, and more. - WebSphere Business Process Management V6 Information Center
Documentation for WebSphere Business Modeler V6, WebSphere Integration Developer V6, WebSphere Enterprise Service Bus V6, and WebSphere Process Server V6. - Specifications for Service Component Architecture (SCA) and
Service Data Objects (SDO)
In addition to IBM, contributors include BEA Systems, IONA, Oracle, SAP AG, Siebel Systems, Sybase, and Xcalia. - IBM Service-Oriented Architecture (SOA) page
General information and resources related to SOA. - Eclipse Modeling Framework documents
A great reference for SDO programming. - WebSphere Business Integration products
page
For both business and technical users, a handy overview of all WebSphere Business Integration products - developerWorks WebSphere Business Integration zone
For developers, access to WebSphere Business Integration how-to articles, downloads, tutorials, education, product info, and more. - Trial downloads for IBM software products
No-charge trial downloads for selected IBM® DB2®, Lotus®, Rational®, Tivoli®, and WebSphere® products. - Most popular WebSphere trial downloads
No-charge trial downloads for key WebSphere products. - Safari Bookshelf: e-library designed
for developers
Complete search and download access to thousands of technical books for a one-time subscription fee. Free trial for new subscribers. - WebSphere forums
Product-specific forums where you can ask questions and share your opinions with other WebSphere users. - developerWorks blogs
Ongoing, free-form columns by software experts, to which you can add your comments. Check out Grady Booch's blog on software architecture.
Nigel Daniels is a Staff Software Engineer at the IBM Hursley Software Lab in the UK, and Team Leader for WebSphere ESB functional testing. Prior to joining IBM Hursley in 2003, he had over 10 years of wide-ranging IT industry experience. His expertise includes object-oriented (OO) design and development of products and applications, Eclipse and Java development, and software testing. He is a certified software tester and holds a Masters degree in OO Software Technology from Brighton University in the UK. You can contact Nigel at ndaniels@uk.ibm.com.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
- Try: WebSphere Integration Developer (in the SOA Sandbox: Connect)
- Demo: Process automation, adoption pattern
- Webcast: Develop innovative applications efficiently using the right application foundation in today's economy
- Briefing: WebSphere flexible business processes
- Buy: WebSphere Integration Developer (in the SOA Sandbox: Connect)
My developerWorks community
Tags
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).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
