JBossDeveloper

His name is Weston Price :-)

I agree with all the points Scott made regarding using JCA as an integrqation point for jBPM, at the very least, it bears worth looking into. I also want to add my 2 cents as far as some of the benefits:

As Scott pointed out, JCA 1.5 allows for controlling work management aspects of a adapter and it's associated underlying resource. Futher, this work can actually be scheduled and handled in a variety of manners that can give us a bit more control in offloading some of the tasks associated with jBPM. It is our goal on the JCA team to make the work management stuff more configurable than it is today, so, using jBPM as the impetus for these types of features may be quite beneficial.

If done properly, JCA (and again, Scott has pointed this out) allows for a standardized deployment format supported by all J2EE vendors. So, this avoids the MBean deployment mechanism that would otherwise pretty much tie us to JBoss.

Inflow, inflow, inflow :-)

Admin objects (also introduced in 1.5) allow for an objects that 'support' and adapter deployment to be easily deployed and managed along with the adatper proper which could, from what it sounds like from this thread, be a big win in configuring and managing the jBPM integration.

Unfortunately, I am not that familar with jBPM as a project, however, I plan to take a couple of days to look at some of the internals. After this I could give a timeline on how much it would take to do the work.

Agreeable with everyone?

Regards,

Weston

Hey Tom,
That would be great, I am trying to crank out the rest of some deployment stuff today. How about tomorrow or Wendesday. I have started review the doc set up on the project site and I should probably take a bit more time with this so I can at least ask some semi-intelligent questions.

IM, email, phone?

Let me know what works for you and thanks for taking the time.

Regards,

Weston

Update:

Tom and I had an extremely productive conversation this morning after the R&D call regarding the JCA solution for JBPM integration. The upshot of this is the following:

JCA should provide *one* of the deployment/configuration solutions for JBPM and not be exclusive in this regard. Being that JBPM is designed to support multiple execution environments (ie non-managed, managed), JCA makes sense as a integration point into JBossAS.

A JCA adapter will be developed to allow for this integration, first pass will focus on a proprietary API, second pass will encompass a CCI based implementation.

Certain aspects of transaction synchronization are still be worked out in JBPM which will allow for XA and Local txn support in the adapter.

All current implementation artifacts will go in HEAD under the connector project.

A prototye of an aspectized JCA adapter will occur concurrently in the jboss-jca project.

The JBPM project structure is being reworked, as a result, I can take this time to more fully understand the JBPM API, though the similarity to Hibernate, at least at the architecual level makes this ramp up time quite straightforward.

Tom, if I missed anything, don't hesitate...

Regards,

Weston

Sorry, forgot to follow up on one thing that was brought up in this thread:

The *-ds.xml deployment mechanism is going to go through an overhaul shortly. While the basic mechanism will still be in place. A meta data model is currently in development (connector project) that will effectively generate a binding between the *-ds.xml file and a Java POJO's. The underlying binding framework is of course XB. Doing this has a few benefits

1) This new deployment scheme will allow for programmatic *-ds.xml deployments.

2) This refactoring should open up some new avenues in getting away from the *-ds.xml/XSLT stuff in general.

So, whether or no the *-ds.xml fits with the JBPM stuff, we have some leeway in working around this.

For those interested, current implementations of this type of binding can be found in org.jboss.resource.deployment, org.jboss.resource.deployment.metadata, org.jboss.resource.deployment.ds, and org.jboss.resource.deployment.ds.metadata.


Regards,

Weston

Sounds like the restructuring of jBPM is done. I will start looking at JCA integration.

uuuhhhmmm.... none? But my knowledge on some of these things (jca etc) is limited. Although the work done in the singleton is limited, could it in one way or another become a performance bottleneck?

Singletons are non-standard and can generally cause issues in J2EE environments, especially one (us) where the classloading architecture allows for varying deployments and configurations.

Further, let's say the client want to make some form of modification to the Singleton. Now you are, at best, tinkering with XML configuration files in the JBPM deployment jars/structure that are not dynamic, require you to redeploy. JNDI is the recommended repository for objects in the J2EE environment. My question would be why the reluctance to use it?

Of course, there would be nothing to prevent you from writing a singleton to use outside of the container. Or, as we discussed on IRC, in this case you couse use the JCA connection factory in a two tier, non-managed environment.

Is the default behaviour still UCL? I thought that changed with 4.0.2. We should at least not depend on it, since it is JBoss AS specific

Any progress on this? Generating a hash is fairly simple with ant:

<target name="generate-checksum">
 <checksum algorithm="SHA1" todir="target/generated/hashes" totalproperty="archive-hash">
 <fileset dir="target/generated">
 <exclude name="**/hashes/**" />
 </fileset>
 <fileset dir="target/classes" />
 </checksum>
 <echo message="Archive-Hash: ${archive-hash}" file="target/generated/META-INF/archive-hash.sha1" />
 </target>