We are currently using the TIBCo Inconcert API thru JavaBeans for workflow

However, we are soon going to use MDBs to achieve parallelism in processing. The problem is that we have noticed that the Inconcert API does threading internally, so we do not want to run that code in the EJB container.
We dont know whether the threading takes place within the container, or within the system via some DLLs that it uses.
It would be ideal if we cud move it out of the EJB container.

One suggested solution is to use a JCA Adapter class (since the JCA container is apparently threadsafe..please correct me if i am wrong here) which will wrap the Inconcert calls so that the API calls happen outside the EJB container. However, this solution does seem a little dirty.

Btw, has anyone used the Inconcert API thru EJBs? Any problems faced with that?

/Ajay

My current client has built a workflow framework with EJBs on top of InConcert. I actually helped them build it 2 years ago or so. I dont think that InConcert does threading in the Java part of the API. (Have to check this up.) The server side of InConcert is threaded though. They have what they call "workers" that listens to requests. The number of workers can be an issue when tuning the application. We use it on HP-UX though so it may work differently on another OS. Anyway it has worked well for us to just access InConcert API directly from within an EJB container.

A more interesting problem when using InConcert APIs is the lack of transaction support. Maybe you use some new version where there are support for transaction. In IC 6.1 there is no support which makes you put the calls to InConcert at the end of methods. If you have heavy parallellism that accesses and changes the same process this may be a problem.

If you have many users or active flows you may find that performance will be an issue. It is hard to get a list of user tasks in better than linear performance if you have process instances with user defined attributes.

Whatever solution you choose I would suggest hiding the workflow engine behind a facade since (1) you might want to change engine one day and (2) if threading turns out to be an issue you just need to change the code behind the facade and not every call in the entire application and (3) it is just a nice thing to do.