[Design of JBoss ESB] - ESB DB setup
by sacha.labourey＠jboss.com
Hello,
I've seen that as part of the ESB configuration, multiple compile-time options are available to either work on a PostgresSQL or HSQLDB database. While this is all fine if you are about to build your own ESB from the source, it might be benefitial to offer options for the pre-packaged ESB.
By default, I imagine we are going to provide a pre-packaged ESB working on a minimal MK (or MC in the future) that doesn't required any further configuration (much like the AS). To that end, the only real possibility is to offer an HSQLDB default setup with additional optional configuration files available for other DB.
Optional configuration files are usually found in the JBOSS_HOME/docs folder for the AS, the same could be done for the ESB.
For the base behaviour we could either i) provide the ESB with a preconfigured ESB or ii) setup a mechanism to setup the DB at runtime.
I am not a fan of i) as DB files (especially HSQLDB) might get dirty and then the users will not be able to fix that issue easily (excpet if you are able to read proprietary binary formats on the fly and write them as well).
For option ii), one easy option is to keep providing the Beanshell deployer currently available in JBoss AS (or any other script deployer) and provide a setup-esb.bsh script that would perform all necessary duties. For example:
- test that no ESB table exist yet.
- if that is the case, create the table
- populate it with basic/example data
- etc.
None of these checks (or any additional setup steps) are necessarily trivial when simply relying on a SQL script (useless at runtime btw), but are really trivial when running them from a beanshell script that can rely on JDBC, JNDI, the ESB itself, JVM options, OS information, etc.
Some sample scripts are available as part of the AS and, at least in the past, available for the Portal setup that uses such scripts so setup its default DB environment as well.
Cheers,
Sacha
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988570#3988570
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988570
19 years, 4 months
[Design of JBoss ESB] - ESB configuration
by sacha.labourey＠jboss.com
Hello,
Part II of my discussion with MarkL: the configuration of the ESB.
Today, it seems that most of the behaviour is wrapped inside an EAR and that some configuration parameters are set at the JVM level using some System Properties put in the conf directory.
However, it is extremly easy and much more convenient to put these parameters inside MBean attributes i.e. setup an MBean per object to be configured and put these MBean definitions inside the SAR file of it corresponding class files. ALSO, most of the additional behaviour (like setting up a transformation, etc.) could be done as part of a specific MBean instead of relying on custom code/script. Such MBean definitions could be put in sample files in the /deploy directory (all entries would be commented/disabled) so that setting up a new ESB behaviour could be done in a very efficient way without relying too much on the documentation: just follow the examples. It is worth mentionning that MBean properties are not limited to primitive type: they can be any XML snippet. The new Microcontainer provides further improved features in that regard.
Also, in order to make it easy for developers to change the default behaviour, it would certainly be usefull to use "unpacked SAR" i.e. do not put the JARs and their corresponding META-INF/jboss-services.xml file in a SAR file but, instead, but them in a xxx.sar DIRECTORY: that way any configuration item can be changed without having to go through an unpack-repack cycle of the archive.
Concerning the MBeans, it would certainly be usefull to provide both a POJO and a related MBean: that way, the same code could be re-used both to work on the microkernel and the new microcontainer.
A side effect of this is that you could setup two completely different ESB bus as part of the same JVM: they would not have to share their configuration (i.e. System Properties) anymore (i.e. JVM-wide vs. MBean-wide).
I would be surprised if any of the ESB configuration would be restricted to code: most behaviours should be available as an MBean definition/POJO API that would cover the public API of the ESB.
Cheers,
Sacha
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988569#3988569
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988569
19 years, 4 months
[Design of JBoss ESB] - ESB Packaging
by sacha.labourey＠jboss.com
Hello,
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
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988532#3988532
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988532
19 years, 4 months