I fell in love with WebSphere mediations the first time I saw them. Okay, didn't fall in love but I did think... "Nice! What a cool way of going above and beyond what soap handlers offer!" For those who don't know, WebSphere mediations run in WAS runtime messaging engine, which treats any request or response flowing through as a message (could be a soap or jms message or even a request to an ejb) and any message consumer as a destination. Since we are [over] simplifying already, in simple terms WebSphere mediations are components that can intercept these messages, inspect them, route them to a different location or even change them.

Now, I wouldn't be writing this blog if everything about WebSphere mediations was so cool (yeah, I know, I have love hate relationship with IBM products!). Just note that the discussion in this blog entry refers to mediations available within WebSphere Application Server.

First of all, did you notice I call them WebSphere mediations? You won't see that term being used on any IBM website. I use that term because they use WebSphere specific APIs. You have to implement com.ibm.websphere.sib.mediation.handler.MediationHandler interface to create a mediation. This makes your code... well, not so portable. Mediations - woops, sorry - WebSphere mediations are very much like soap handlers. They can intercept the incoming requests and/or response and do things with it. There should have been some effort to make them part of the specification. I mean the whole concept of messaging engine is cool, even that should be part of the specification. The term 'messaging engine' doesn't refer to JMS messaging engine. It refers to the messaging infrastructure on which WAS runtime and service integration BUS are built. 

Second, they only support one method public boolean handle (javax.xml.rpc.handler.MessageContext context) method. Why can't they support both handleRequest and handleResponse like soap handlers do? Being able to handle response would be really convenient. For example, if I had a requirements to process an incoming message and forward it to a queue for further processing ONLY IF the initial processing was successful, I would catch the response message in the handleResponse method and then send the message for further processing. Without the ability to capture responses, you have to be little bit creative to implement this requirement (you can still do it though).

Third, they use SDO APIs. This is not a problem in itself but I don't like IBM's implementation of this API. Just try creating a soap header within mediation if no header exists already and you will know what I am talking about. In plain English, I find IBM's implementation of SDO very 'read' friendly as opposed to 'read and manipulate' friendly. It is not easy to create/add new elements.

Forth, they can't be developed. Seriously! You cannot create mediations in RAD 7.0 - not even after installing some fixpacks. Now, I know this is not a problem with the mediations themselves, it's a problem with the tooling but hey I am in the mood to rant. To develop a mediation, you create an ejb project, create a class [say] MyMediation and implement the interface, go to ejb deployment descriptor and click Add button in Mediation Handlers tab. A dialog box should pop up and the class you created should show up in it. You select the class and the necessary ejb code is generated automatically. In RAD 7, nothing happens if you click the Add button. When I used Application Server Toolkit at my last client, the dialog box popped up but my class never showed up in it. I had to create mediation project in RAD 6 (yes, it works in the previous version!) and then open it in RAD 7. Nice way to take away some functionality!

Fifth, you can't register your service in the SDO repository - something you have to do when you have an outbound service that you want to mediate using mediation. I have blogged about this in detail in this and this blog entries.

Sixth, you can customize the behavior of your mediations using mediation properties - that's a good thing. But, you have to define and change these properties using admin console. This is not flexible, and boring too if you have many properties to define. It requires a technical resource to make a change - doesn't sound like providing business agility to me.