My next post will probably be a book review – I was asked to review a new book on WAS 7.0 administration. Cool. Hopefully I’ll be able to read it in the next couple of days (did I ever mention I was a quick reader?)
In the meantime, I want to publish my findings on the use of EJBs in WebSphere ESB.
A customer of mine is using WebSphere ESB. For services, it developed EJBs (stateless, of course, but still – version 2.0).
The mediation module has imports for the EJBs.
This turns out to be a very bad architectural decision (I arrived to the project after this decision was taken 🙂 ) , and right now they are rewriting everything, to drop EJBs and use SCA Java components.
- SCA Java components are actual EJBs, so why have an EJB call an EJB? Not a smart move, performance wise.
- Mediation Module (6.1) EJB support is lousy. It fails generating good mapping between the Java bean parameters and Data objects. So my customer resorted into sending Strings to the EJBs, and then parsing them, at the EJB level, to POJOs, using XMLBeans. This is insane – and shouldn’t be done.
So what is the current (working!) recommendation?
Use SCA Java components, in the same module, or other modules, depending on your component visibility and deployment needs.
Inside the Java component, use a mapper to map the DataObject object into real Java POJO. and then pass it to your business logic, which is implemented in regular Java Classes.
The mapper is really easy to write:
1. Use JAXB or XMLBeans to generate mapping between the DataObject XSD and a Java class.
2. Write a method that has the following signature:
public static Object mapper(DataObject do, Class clz)
3. Use reflection on the clz – create a new instance of it, and for every field decide:
3.1 If its a primitive – transform it.
3.2 If its a Java Class – call yourself in recurssion
3.3 If its an array – run over all elements
It works fine, great performance, and the development barrier was lowered by more than a few inches.
Hope it serves someone well.