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.
Why?
- 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.
When writing services for an SOA, typically XSD schema based data to ensure that the service is consumable by a variety of client programming models, Java, COBOL, and C++ or .NET is considered a best practice. Clearly java serialized objects don't really suffice for true SOA's -- you need to have discipline over the data you pass between services. That said, is that the point of your post? I think I like where you wound up, XSD described data, Java serialization between SOA services is not as flexible as we'd generally like. I think I like where you wound up -- its about language independent data over some standard protocol... that makes for an agile flexible SOA.
ReplyDeleteSteve Kinder
SOA Foundation Architect
Websphere Application Server
The point here is that XSD is great for SOA - but when you come to actually writing your service implementation - it's cool to have some automapping mechanism to map to your regular programming language.
ReplyDelete