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.
-
Article: Enterprise Java Beans for Building BPM Applications (17 messages)
- Posted by: Regina Lynch
- Posted on: May 18 2006 17:29 EDT
BPM Suites provide the option of generating EJBs, while themselves executing within the context of an EJB Container in a cohesive optimal manner.Threaded Messages (17)
- Re: Article: Enterprise Java Beans for Building BPM Applications by Tom Baeyens on May 19 2006 08:46 EDT
- Re: Article: Enterprise Java Beans for Building BPM Applications by John Mettraux on May 19 2006 13:57 EDT
-
Re: Article: Enterprise Java Beans for Building BPM Applications by Tom Baeyens on May 19 2006 03:46 EDT
-
Re: Article: Enterprise Java Beans for Building BPM Applications by John Mettraux on May 19 2006 03:53 EDT
-
Or you could use the more simple JBoss alternative by paul browne on May 20 2006 11:02 EDT
- Re: Or you could use the more simple JBoss alternative by John Mettraux on May 20 2006 11:13 EDT
-
Or you could use the more simple JBoss alternative by paul browne on May 20 2006 11:02 EDT
-
Re: Article: Enterprise Java Beans for Building BPM Applications by John Mettraux on May 19 2006 03:53 EDT
-
Re: Article: Enterprise Java Beans for Building BPM Applications by Tom Baeyens on May 19 2006 03:46 EDT
- Re: Article: Enterprise Java Beans for Building BPM Applications by Miguel Valdes Faura on May 21 2006 05:04 EDT
- Re: Article: Enterprise Java Beans for Building BPM Applications by John Mettraux on May 19 2006 13:57 EDT
- Re: Article: Enterprise Java Beans for Building BPM Applications by Miguel Valdes Faura on May 19 2006 11:29 EDT
- Re: Article: Enterprise Java Beans for Building BPM Applications by artful dodger on May 19 2006 12:33 EDT
- Re: Article: Enterprise Java Beans for Building BPM Applications by Joe Thompson on May 19 2006 15:14 EDT
- jBPM and OpenWFE by artful dodger on May 21 2006 15:36 EDT
- Re: jBPM and OpenWFE by John Mettraux on May 22 2006 05:23 EDT
- Re: jBPM and OpenWFE by The Ugly One With The Jewels on May 22 2006 07:24 EDT
-
Re: jBPM and OpenWFE by Miguel Valdes Faura on May 22 2006 08:14 EDT
-
Re: jBPM and OpenWFE by The Ugly One With The Jewels on May 22 2006 10:09 EDT
- Re: jBPM and OpenWFE by Miguel Valdes Faura on May 22 2006 11:14 EDT
-
Re: jBPM and OpenWFE by The Ugly One With The Jewels on May 22 2006 10:09 EDT
-
Re: jBPM and OpenWFE by Miguel Valdes Faura on May 22 2006 08:14 EDT
- Imixs Workflow simply provides BPM components by Ralph Soika on July 08 2010 16:05 EDT
-
Re: Article: Enterprise Java Beans for Building BPM Applications[ Go to top ]
- Posted by: Tom Baeyens
- Posted on: May 19 2006 08:46 EDT
- in response to Regina Lynch
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 -
Re: Article: Enterprise Java Beans for Building BPM Applications[ Go to top ]
- Posted by: John Mettraux
- Posted on: May 19 2006 13:57 EDT
- in response to Tom Baeyens
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 -
Re: Article: Enterprise Java Beans for Building BPM Applications[ Go to top ]
- Posted by: Tom Baeyens
- Posted on: May 19 2006 15:46 EDT
- in response to John Mettraux
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.
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.
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.
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. -
Re: Article: Enterprise Java Beans for Building BPM Applications[ Go to top ]
- Posted by: John Mettraux
- Posted on: May 19 2006 15:53 EDT
- in response to Tom Baeyens
We can only hope that diversity and freedom of choice will win from the monopoly.
From wherever may they come, amen. -
Or you could use the more simple JBoss alternative[ Go to top ]
- Posted by: paul browne
- Posted on: May 20 2006 11:02 EDT
- in response to John Mettraux
A very close , but easier to understand (and graphical alternative) is JBoss Workflow. (Link to blogpost on it) -
Re: Or you could use the more simple JBoss alternative[ Go to top ]
- Posted by: John Mettraux
- Posted on: May 20 2006 11:13 EDT
- in response to paul browne
Paul, as an alternative to what ? -
Re: Article: Enterprise Java Beans for Building BPM Applications[ Go to top ]
- Posted by: Miguel Valdes Faura
- Posted on: May 21 2006 05:04 EDT
- in response to Tom Baeyens
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
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. -
Re: Article: Enterprise Java Beans for Building BPM Applications[ Go to top ]
- Posted by: Miguel Valdes Faura
- Posted on: May 19 2006 11:29 EDT
- in response to Regina Lynch
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 -
Re: Article: Enterprise Java Beans for Building BPM Applications[ Go to top ]
- Posted by: artful dodger
- Posted on: May 19 2006 12:33 EDT
- in response to Regina Lynch
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. -
Re: Article: Enterprise Java Beans for Building BPM Applications[ Go to top ]
- Posted by: Joe Thompson
- Posted on: May 19 2006 15:14 EDT
- in response to artful dodger
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[ Go to top ]
- Posted by: artful dodger
- Posted on: May 21 2006 15:36 EDT
- in response to Regina Lynch
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. -
Re: jBPM and OpenWFE[ Go to top ]
- Posted by: John Mettraux
- Posted on: May 22 2006 05:23 EDT
- in response to artful dodger
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 -
Re: jBPM and OpenWFE[ Go to top ]
- Posted by: The Ugly One With The Jewels
- Posted on: May 22 2006 07:24 EDT
- in response to artful dodger
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 -
Re: jBPM and OpenWFE[ Go to top ]
- Posted by: Miguel Valdes Faura
- Posted on: May 22 2006 08:14 EDT
- in response to The Ugly One With The Jewels
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 ? -
Re: jBPM and OpenWFE[ Go to top ]
- Posted by: The Ugly One With The Jewels
- Posted on: May 22 2006 10:09 EDT
- in response to Miguel Valdes Faura
May be the first thing would be to focus on standards, what about XPDL for human processes ?
what about BPEL 4 People ? -
Re: jBPM and OpenWFE[ Go to top ]
- Posted by: Miguel Valdes Faura
- Posted on: May 22 2006 11:14 EDT
- in response to The Ugly One With The Jewels
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ésMay be the first thing would be to focus on standards, what about XPDL for human processes ?
what about BPEL 4 People ? -
Imixs Workflow simply provides BPM components[ Go to top ]
- Posted by: Ralph Soika
- Posted on: July 08 2010 16:05 EDT
- in response to Regina Lynch
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