BPM Suites provide the option of generating EJBs, while themselves executing within the context of an EJB Container in a cohesive optimal manner.

BPMS have evolved significantly in recent years, to where they can reside and function within an EJB Container and thus leverage the benefits of the EJB Container. In addition, BPMS have evolved to where they can generate either generic EJBs or signature specific EJBs that represent process flows and/or rules. This feature enables ease of integration (locally or remotely) of process flow/rules into applications that need to compose such functionality. It is generally more advantageous to leverage signature based EJBs generated by BPMS, compared to generic EJBs.

This article shows how BPMs can leverage the underlying robust component architecture of application server containers. The article also discusses on-demand generation of EJBs that are specific to applications with the power of the EJB framework for distributed applications. Read Enterprise Java Beans for Building Business Process Management Applications.

Nice article that shows how functionalities offered by application servers can be leveraged by BPM systems. In the sketched architecture, this makes sense. But there are many java applications being written outside the context of a container. I believe that the current market has a lot of products that are only applicable in a certain 'niche' environments or specific architectures. Also, there are many process languages. I think that is a good thing. Different environments require different process langauges. Writing a new webservice as a function of other web services requires a different process language then coordinating tasks for people in a lightweight java web application. Also there is fragmentation in the architecture that these BPM systems operate in. The proposed environment is very well embeddable on an application server. But it would be really great if we could embed the whole engine inside our POJO/lightweight java application, and only bind to the services that are available. A BPM system should be implemented in such a way that it doesn't matter wether the services are coming from the JEE container directly, wrapped with spring, directly injected by the user or accessible in some other way. With JBoss jBPM we have build a single core engine that can operate in any environment and on which any process language can be implemented. The biggest benefits of this approach is mindshare. No matter what process language you need or which architecture is used in your next project you can work with the same core technology. In this reply i mainly wanted to sketch our direction and how it differs from the approach presented in the article. Because of the heavy weight nature of some BPM systems (as in the presented article) in the past many companies have started on their own home grown solutions. Now more and more people select open source engines for their project. But we (BPM community at large) are not there yet. The current problem is that with all this fragmentation and diversity, developers still write homegrown solutions for functions that they could very well leverage from the open source community. To free up the time of those developers that are still implementing homegrown solutions, there is one challenge we have to face: create a common understanding of BPM and workflow technology. Only then solutions can converge, mindshare starts to flow and less wheels are reinvented. regards, Tom Baeyens. JBoss jBPM

Hi Tom, looks like you're proposing a FormulaOne championship with every team using the same engine. It may be fun, the quality of the drivers would then matter a lot. Why such a constraint on the Java workflow landscape ? Your GOP approach isn't about BPM. We should focus on bringing added value to customers, they are in the end, business users : they'd like to design / discover / adapt their organizations' processes in a snap. They don't want an IT guy coming their way. Why should we get stuck with a java-tied library ? Our business users do not care, they want to be able to adapt their processes as quickly as needed / required. And yes, Microsoft is coming in, and with their workflow foundation directly tied to Office and SharePoint, they might be slightly ahead. Best regards, John Mettraux http://www.openwfe.org

We should focus on bringing added value to customers, they are in the end, business users : they'd like to design / discover / adapt their organizations' processes in a snap.

The process languages should be feature rich. That is correct. But it's a myth that your software project becomes agile by just using a BPM system. A process is just a part of a software project. Easy update of processes is one thing. But maintaining the relation between the process and your other software should not be neglected. For that we should be considering process languages as DSL's and focus on integrating the process language editors with the java refactoring capabilities.

They don't want an IT guy coming their way.

Why should we get stuck with a java-tied library ? Our business users do not care, they want to be able to adapt their processes as quickly as needed / required.

A java library is not the right solution in every case. In some environments that is perfect, in other environments, you want to develop processes and task forms graphically without writing code.

And yes, Microsoft is coming in, and with their workflow foundation directly tied to Office and SharePoint, they might be slightly ahead.

Microsoft's Windows Workflow foundation is exactly similar to what we call Graph Oriented Programming. One foundation framework with multiple process languages on top. In different environments. So the counterpart *is* available in Java. We can only hope that diversity and freedom of choice will win from the monopoly. regards, tom.

We can only hope that diversity and freedom of choice will win from the monopoly.

From wherever may they come, amen.

A very close , but easier to understand (and graphical alternative) is JBoss Workflow. (Link to blogpost on it)

Paul, as an alternative to what ?

Also, there are many process languages. I think that is a good thing. Different environments require different process langauges. Writing a new webservice as a function of other web services requires a different process language then coordinating tasks for people in a lightweight java web application.

I agree that web services orchestration engines are completly different than traditional workflow engines focused on people coordination, but the solution is not only to provide two different languages. In most of the real world applications there is a need for both features working together, i.e a BPEL process in which at any point we could invoke a traditional workflow process. To me the real issue that must be addressed is the way in which BPM solutions are supporting those processes: global view of the process (including also the subprocesses defined through different languages), global monitoring, graphical definition of those processes... Regards, Miguel Valdés http://bonita.objectweb.org

Nice article, in fact there a bunch of concepts here that match pretty well with my thoughts, developments and ideas around workflow solutions and application servers. Let me just disagree with the problems pointed in the article about the performance problems when using Entity EJB's and Stateful Session Beans. I agree that the use of those kind of entities is really complex if we want to reach a good performance but you now is just a matter of tuning expertise... Regarding the comment posted by Tom, I like your vision of having a workflow engine able to deal with different definition languages, the only point here is that the end user will lost in terms of simplicity of use because is really difficult to define a common user interface which will allow him to deal with either a BPEL process or a XPDL one. Regards, Miguel Valdes http://bonita.objectweb.org

I like Java and the open marketplace of ideas and products. Unfortunately, Microsoft is coming out with some workflow/BPM tools that are very innovative and far more appealing than J2EE Entity Beans.

The thing I really can't stand is when vendors build the BPM platform using EJB's. You create your process and then sit there for hours watching all these EJB's getting generated. What a mess!

jBPM and OpenWFE are the two leading BPM contenders in the Java open source world. It would be great if they had a common process definition language and api's.

Well, they are two very different beasts. OpenWFE is BSD and jBPM is currently LGPL. OpenWFE is not only about Java but comes with Ruby, Python, .NET and more. jBPM is Java oriented. OpenWFE process definition language is about processes (can't currently find a better way to say it, a way that would not imply that jBPM is not about processes, sorry), jBPM jPDL is about graphs. OpenWFE is independent (open source), jBPM is part of jBoss (commercial open source). jBPM seems more easily grokkable by the average Java Developer (there is also OSWorkflow on that segment), OpenWFE doesn't only target that audience. Fair competition is good. http://asay.blogspot.com/2006/05/strong-competitors-great-opportunity.html We, members of other open source workflow/BPM communities, have to get out of the woods and explain our version of the concept, we can't let it become a monoculture, at least not before submitting it to a strong [market] dialectic. John Mettraux http://www.openwfe.org

jBPM and OpenWFE are the two leading BPM contenders in the Java open source world. It would be great if they had a common process definition language and api's.

if you want a common process language, then you should probably give a try to one of the BPEL engines

jBPM and OpenWFE are the two leading BPM contenders in the Java open source world. It would be great if they had a common process definition language and api's.

May be the first thing would be to focus on standards, what about XPDL for human processes ?

May be the first thing would be to focus on standards, what about XPDL for human processes ?

what about BPEL 4 People ?

May be the first thing would be to focus on standards, what about XPDL for human processes ?

what about BPEL 4 People ?

That could be a patch :-) I mean this is just an extension for a common issue which is the impossibility to define human task in BPEL, it could be the solution in some cases, but you know there are a great number of applications in which an standard such XPDL is more adapted than BPEL (i.e: document management processes). Anyway, in some cases you could use both BPEL and XPDL in a global process in which an XPDL process will be invoked as a web service in BPEL... Regards, Migue Valdés

The Imixs Workflow Project focus on a different kind of usage. The Imixs JEE Workflow provides Java EE components (EJBs and JPA) to be used in any Java Enterprise project.
These components fit into the component model of Java EE and provide usefull functions from a BPM framework. The Imixs Workflow is not BPM Suite but it enables developers to implement BPM solutions in a much faster way.
See the open source project site: http://www.imixs.org