[jboss-dev-forums] [Design of JBoss jBPM] - transactions, commands and packaging

tom.baeyens@jboss.com do-not-reply at jboss.com
Mon Aug 28 10:25:04 EDT 2006


i'm creating 2 packages:

* a plain POJO .war file targetted to be deployed on e.g. tomcat.  the idea is that most of the libs will be inside of the web application, including the configurations for a non-enterprise environment.

* a .ear enterprise application that has 3 components and the jbpm libs inside (referenced by the Class-Path entry in the manifests).  The components are jbpm-console.war, cmdlistener.jar (MDB) and cmdservice.jar (SLSB).  The configurations are packaged as a jar library that all components can 'see' and contains all settings for a enterprise environment.  So this package will contain a different version of the .war, one in which the libraries are placed differently and with different configuration files.

As for transactions, both will work in the same pattern:  one update transaction for user commands.  one read-only transaction to render the new view.  This is done with a JSF phase listener.  In the standard environment, the transactions will be delegated to hibernate.  In the enterprise environment, the transactions will be manipulated with the UserTransaction JTA API.

The command patter that we considered between the web app and the jbpm command service doesn't make much sense.   Especially since there is an overlap in transaction managmement there.  The JSF approach will call the backing beans once and a while for each item that needs to be rendered.  If all of these result in a transaction, it would be a completely different (slower) model then the one we envision with max two transactions.

Feel free to ask more info or challenge these insights.  These ideas have not yet had the time to stabilize...

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3967828#3967828

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3967828



More information about the jboss-dev-forums mailing list