At the moment i’m busy with a migration of an alsb 2.6 enviroment to an alsb 3.0 enviroment.
In the alsb processes extra functionality is invoked by making use of the java call outs.
Nothing wrong with this if you ask me, the only thing which i’m wondering is, wont these java call outs mess up the transactional context of alsb processes itself.

At the moment the libraries which are being used are deployed with every servicebus process itself.
So we have/had some sort of default structure like

• business services
• proxy services
• lib
• wsdl

Works fine, but not really the ideal situation if you have reusable resources over servicebus projects.
You’re able to reuse the components from other projects and link to them by using relative links (for example when you want to reuse xsd’s from other projects) or link to the library of an other servicebus project.

These situations force you to create dependencies between the projects, something we don’t want either.

Solutions

First solution

The solution we implement at the moment to keep everying on-going is the next.
We created a ‘Shared Resources’ servicebus project with folders for libraries/wsdl/xsd/business services/etc. Every resource which will be reused by other projects will be created in here. Every servicebus project itself which is going to use a resource will link to this project and the resource it needs.

This works great if you’re working with components which exists only in the servicebus itself.
When integration is happening and for example applications from vendors are integrating with our servicebus projects they could use certain resources from the ‘shared resources’ project. But in this case my servicebus project will be some sort of repository of resources available for not only the servicebus projects. So i’m creating an extra dependency between the servicebus and the other applications.

Better solution (imho)

Remove all the re-usable resource from the servicebus itself. We need to bring those to some higher level of sharing of which both the servicebus and the other applications will make use. In this case a product like ‘Oracle Enterprise Repository’ could be used.
In this repository we can store all the resources and artifacts which will be used enterprise wide.

To make use of a java call out, we need to create the resource in the servicebus project itself. So we can’t store these libraries on the repository.
Maybe a short coming which is ok for this situation.

If we want to store these java libraries on a repository we have the intention to share these enterprise wide. But in these situations we must investigate if a plain java class is the best way to make the functionality available or should we ‘service enable’ the java classes so they can be used more easily for integration in other projects.
The userguide / Usage Guidelines gives as a few situations/best practices when to use ejb functionality instead of plain pojos.

Do we have functionality delivered by the java classes which is only used in the servicebus projects to support the servicebus process itself then we could just registrate the libraries in the shared resources servicebus project (jar resource) and reuse it from here.

Conclusion

For reuse of resources and artifacts in servicebus projects we could use the next setup.

Shared Resources servicebus project for storing the business services/proxy services/servicebus-only used java libraries/etc.
Enterprise Repository for storing resources like xsd/wsdl/etc
Service enable java classes which are used enterprise wide,so we don’t need to store functionality on several places

Any of you doing osb/alsb projects and have a better ‘solution’ for these situations ?

Original blog