ESB Packaging
slaboure Nov 25, 2006 7:40 AMHello,
Mark and I discussed a few things around JBoss ESB in Berlin, and I wanted to make sure to have them written somewhere. I'll probably put each in a different thread to make it easier.
The first item is about the packaging of the various ESB JARs. AFAICS, the 4 main ESB JARs are packaged inside a EAR. Is there a good reason to do that i.e. are we really interested to use an EE-specific packaging? If not, I'd suggest to either drop each JAR in the lib folder directly (the deploy folder would work as well) or, better, package them inside a SAR. That way, once we migrate to the microcontainer, we could simply drop any EAR/WAR/EJB-JAR specific deployer and only keep the service/POJO deployer.
Inside the SAR, it is then possible to not only specify/load them in the jboss-esb.sar/META-INF/jboss-service.xml but also to include various configuration parameters. More on this in another post.
Now the question is: are these four JAR one standalone thing or not? If not, I'd suggest to separate them in as many SARs as needed. This means that it is then possible to deploy/undeploy a specific SAR as needed, depending on which functionality is needed.
Last point, if we are going to SHARE some classes between any of these SARs (like some basic ESB classes, such as the Message interface, etc.) I see several options. First, the simplest, we put that jboss-esb-common.jar (I am making up names on the fly in case you are wondering what these names come from :) ) in the /lib folder of the specific server configuration. That means that we won't be able to dynamically load/unload that code, but I imagine that these classes are very stable as they would represent the lowest common denominator of the ESB. The other option, is to deploy that JAR directly in the /deploy folder and put appropriate tags in the other SARs. Last option: put these classes in the SAR that represents the core set of services without which any other plugin is useless anyway.
Bottom line: I think it is very important to have a fine-grain granularity in our deployments and be able to express between those and not rely on any EE-specific behaviour. Thoughts?
I'll write another thread around the configuration of the ESB soon (have to go for now...)
Cheers,
Sacha