Discussions

News: jBpm joins JBoss and becomes JBoss jBPM

  1. jBpm joins JBoss and becomes JBoss jBPM (33 messages)

    The jBpm open source workflow engine has joined with JBoss to become a critical piece of the JBoss Enterprise Middleware Platform. With the resources and commercial reach of JBoss behind it, JBoss jBPM can now capitalize on its technical strengths and popularity to become the de facto standard in today's fragmented BPM market.

    Together with this announcement, we also shipped the 2.0 version, which represents a major upgrade in functionality and documentation.

    Press release: http://jboss.com/services/press/jBPM.pdf

    Project page: http://jbpm.org

    Download: http://jbpm.org/download.html

    Regards,
    Tom Baeyens.

    Threaded Messages (33)

  2. Congrats!![ Go to top ]

    Tom cangratulation on this move !!

    For the people interested, Tom will be presenting jBPM at the JavaPolis conference (http://wiki.javapolis.com) See you all there ;)
  3. I have looked at jBpm about a year ago and at that time source code was so horribly tied to http and web that I decided it does not worth further looking because of such a discrepancy between theoretical level (very good) and implementation.

    Does jBpm still require Web container to work? Can v2 run standalone or as an EJB?
  4. JBoss jBPM does not have a dependency on EJB. JBoss jBPM only has a dependency on a java runtime environment and a JDBC database. Infact, our unit tests use the hypersonic in memory database which even eliminate the need to set up a separate database for development.

    But if you want, you can wrap the POJO session facades in stateless session beans for scalability. The download contains a 10 step instruction to deploy JBoss jBPM onto a clustered JBoss.

    Regards, Tom.
  5. I was really excited to see that JBPM 2.0 lost the EJB dependencies JBPM 1.0 had.

    Now it is a really neat little library to embed if you want workflow/bpm functionality.

    Now I have two more feature requests

    1) Strong Spring support
    The possibility to configure JBPM with Spring and participate in a Spring managed transaction.

    2) XPDL Support
    JBPM currently has no (active maintained) graphical workflow designer. If XPDL would be supported one could use some independent designer tool. This is mostly a marketing point but most customers expect to see a graphical designer if you talk about workflow.


    Ciao, Olli
  6. 1) Strong Spring support
    The possibility to configure JBPM with Spring and participate in a Spring managed transaction.

    JBoss jBPM has a complete POJO domain model that includes all the functionality. That model is persisted with hibernate. I think this should map quite well onto spring.
    2) XPDL Support
    JBPM currently has no (active maintained) graphical workflow designer. If XPDL would be supported one could use some independent designer tool. This is mostly a marketing point but most customers expect to see a graphical designer if you talk about workflow.

    Two fold answer. First about XPDL support. Our core engine is based on a directed graph. In the next version we will be separating the directed graph from the JPDL related implementation. Since all workflow models are based on a directed graph, the core engine will be able to support all models that become relevant. In the jBPM architecture, the nodes contain the behaviour. To add support for a model, we just need to implement the node behaviours. XPDL is not yet in our roadmap because it has got very limited acceptance. Especially from big vendors. BPEL is planned (in 6 to 9 months) and we are looking into YAWL.

    About a graphical designer. Currently, we are starting the development of a professional graphical designer tool. This tool will support all workflow models that will be supported by the engine.

    regards, tom.
  7. 1) Strong Spring support
    The possibility to configure JBPM with Spring and participate in a Spring managed transaction.

    Please say firm NO to Spring dependencies. Spring claims that it can integrate any POJO. As jBpm appears POJO it is Spring's job to integrate smoothly with it.

    (Dear Spring zealots please note: I have nothing against Spring dependencies in actual business application)
  8. That's great[ Go to top ]

    Two of key factors that I hesitate to use jBPM instead of its popularity are the accountability of the vendor/author and its lack of BPEL support. Now, jBPM joins JBoss and they announce that they will support BPEL just make me smile. :=)
  9. Components for orchestration[ Go to top ]

    People interested in workflow related tools may be interested in checking out the following ObjectWeb projects:

    - Shark and JaWE ; Shark is an extendable workflow engine framework including a standard implementation completely based on WfMC specifications using XPDL ; Enhydra JaWE is the first open source graphical Java workflow process editor fully according to WfMC specifications supporting XPDL as its native file format and LDAP connections

    - Bonita: Bonita is a flexible cooperative workflow system, compliant to WfMC specifications, based on the workflow model proposed by the ECOO Team, which incorporates the anticipation of activities as a more flexible mechanism of workflow execution.

    - COW: Cooperative Open Workflow is a flexible workflow engine that can handle cooperative work activities.

    These projects are developped in the framework of ObjectWeb, a consortium of 40 companies from around the world who altogether count more than 300.000 employees.

    Oh, last but not least: a BPEL engine has just been accepted by the ObjectWeb consortium. It's name is MOBE (MidOffice BPEL Engine). Source code soon available on ObjectWeb.

    Enjoy!
  10. Components for orchestration[ Go to top ]

    Don't forget OSWorkflow with a nice GUI to edit the workflow configuration:

    http://www.opensymphony.com/osworkflow/

    bye,
    Luca Garulli
    www.Pro-Netics.com (member of Orixo.com - The XML business alliance)
    OrienTechnologies.com - Light ODBMS, All in one JDO solution
  11. Components for orchestration[ Go to top ]

    if you want to give people pointers to other workflow engines, you should be fair and list them all.

    Carlos E Perez has done a great job of listing all open source projects in various categories.

    http://www.manageability.org/blog/stuff/workflow_in_java/view

    Keep up the good work Carlos !

    Regards, Tom.
  12. Components for orchestration[ Go to top ]

    http://flow4jeclipse.sourceforge.net/docs/index.html

    this one must be interesting, it goes with eclipse pluggin with graphical editor for diagrams.
  13. I just hope that I can keep on using jBpm without JBoss. It's a fairly good and solid product, documentation is a bit spartan, but since the whole idea behind jBpm, once you grasp the concepts is really intuitive that's not an issue.

    Iwan
  14. jBpm joins JBoss and becomes JBoss jBPM[ Go to top ]

    I just hope that I can keep on using jBpm without JBoss. It's a fairly good and solid product, documentation is a bit spartan, but since the whole idea behind jBpm, once you grasp the concepts is really intuitive that's not an issue.Iwan

    Hibernate, JBoss Cache, JGroups, JBoss AOP, Javassist, and now jBpm will work standalone as standalone products. What you will see though is tight integration of jBpm within the JBoss kernel when you want to run it with the application server.

    Some had the same fears about Hibernate and JGroups when they joined JBoss Inc. last year. Those fears were hollow though.

    Bill
  15. I just hope that I can keep on using jBpm without JBoss. It's a fairly good and solid product, documentation is a bit spartan, but since the whole idea behind jBpm, once you grasp the concepts is really intuitive that's not an issue.Iwan

    Iwan, please don't feel singled out. I just wanted to raise the following question:

    Does it make sense for JBoss to axe the good will of the Java community by integrating best of breed open source products and then keeping people from using them?

    There's no reason to keep jBpm from running outside of JBoss. Some might say vendor lock-in, but that doesn't make sense with the number of other Open Source options available.

    Let's not equate the JBoss Group with, say M$.

    Congrats Tom. I think jBpm is an a great piece of software and I'm leaning heavily towards using it on my next project. Also, I think it speaks volumes about you that you'd actually promote your competition. Nice!
  16. It's probably of some relevance to this thread to point out that up until 2 days before the date of this announcement and the release of jBPM 2.0, it was Apache 2.0 licensed, at which point it appears to have (somewhat silently) been changed to being LGPL licensed.

    From what I can tell Tom has worked incredibly hard on this project over the last couple of years, so he and JBoss Group should of course do what they think is best for them and jBPM. I'm sincerely not trying to start a license debate here (anybody wishing to join in on one can please just go add a message to one of the many past threads of that nature on TSS and elsewhere), but this change in license is probably relevant to anybody considering jBPM, at least given the existence of any lawyer types in the vicinity, or the desire to use the product in a way that the Apache license would have allowed, but the LGPL doesn't.

    Regards,
    Colin
  17. but this change in license is probably relevant to anybody considering jBPM, at least given the existence of any lawyer types in the vicinity, or the desire to use the product in a way that the Apache license would have allowed, but the LGPL doesn't.Regards,Colin

    Before you boast on the superiority of the Apache license or how LGPL limits the jBPM community, I think you need to first ask yourself, who would actually be limited with the LGPL license and who actually benefits from an Apache style license?

    The LGPL is friendly to both IT shops, and ISVs that want to embed jBpm. Where it is not friendly is companies that that want to embrace jBpm and extend it within their own competing proprietary products. It is also not friendly to open source organizations that are hostile towards FSF style licenses. The purpose of jBpm, Hibernate, JBoss, <insert your LGPL based OSS project here> is to allow people to build applications on top of these projects. LGPL does not hurt this type of community.

    Given that, there are certain business and altruistic advantages for FSF licenses over the Apache 2.0 style license.

    The Apache license can lead to fragmentation and forking. Case in point, is the Apache Axis project. IBM pulled its resources from the Axis project and forked the project internally for its own products. It left both the Axis project and the Axis community in limbo for awhile. Now, if the project had been LGPL AND committers retained exclusive copyright, it would have been much harder for IBM to fork Axis for their own products and may have forced IBM to stay in the Axis community. To some degree, I think GPL is one of the reasons for the success of Linux. Look at the failure of the industry to standardize Unix...It was forked so many times by some many different vendors that nothing was portable. Linux with GPL forces standardization because there is no monetary benefit from forking the source or adding proprietary extensions, because legally vendors just can't do it.

    The success or failure of an open source project largely depends on the success or failure of the project to create a community. GPL/LGPL adds legal incentive for open source communities to contribute back patches, fixes, and extensions to the open source projects they are working with instead of keeping their fixes/features/patches proprietary. That's not to say that Apache licensed projects can't build a community, but FSF style licenses have the legal protection popular open source projects need when they start threatening the bottom line of competing proprietary companies.

    Apache style license may be friendly to IBM, but it is not necessarily friendly to the open source community or the leaders of an open source project.

    Marc Fleury also talks about this on our blog here.

    Bill
  18. Bill, what part of
    I'm sincerely not trying to start a license debate here (anybody wishing to join in on one can please just go add a message to one of the many past threads of that nature on TSS and elsewhere),

    is not clear? While I have pretty strong feelings, based on past experience, as to potential issues w/LGPL vs. Apache/BSD style licenses, I was explicitly trying not to get into that here. The license stuff has been beaten to death already.

    What has not been beaten to death and was not really mentioned, was that the license was changed at the last minute, and changed from Apache 2 to LGPL. Whether you or I think LGPL is great or has issues or not is not the point (I was trying to make); the fact that the license changed and what that new license is, is of some relevant to at least some people.

    Now somebody is probably going to accuse me of stirring some shit here. Well, the reality is that I brought up the change because soemthing about the way it was done struck me as wrong. As a part author of another (well-known) open-source product, I would probably never consider doing this sort of license change to my users 2 days before a final release of a big version. If I ever contemplated changing the license (and I am not) I would probably in the same circumstances put out the release and _then_ change the license.

    Anyways, relevant or not, I'm sorry I even brought this up; I have no desire for another useless TSS debate...
  19. Bill, what part of
    I'm sincerely not trying to start a license debate here (anybody wishing to join in on one can please just go add a message to one of the many past threads of that nature on TSS and elsewhere),
    is not clear? While I have pretty strong feelings, based on past experience, as to potential issues w/LGPL vs. Apache/BSD style licenses, I was explicitly trying not to get into that here.

    JBoss also has pretty strong feelings on LGPL vs. Apache based on past experience as well. IMO, it is important to reiterate JBoss' position on licensing whenever it is challenged because not everybody is aware of the issues when they see pro-ASL posts. You will see similar verbose responses from me on the subject whenever it comes up again.

    Bill
  20. Relicensed!! Ouch!![ Go to top ]

    It's probably of some relevance to this thread to point out that up until 2 days before the date of this announcement and the release of jBPM 2.0, it was Apache 2.0 licensed, at which point it appears to have (somewhat silently) been changed to being LGPL licensed.

    Well this change completely rules the project out for my company, and for anyone who has any understanding of the legalities of licenses. It joins the long list of interesting but unusable technology. (Bear in mind that Apache will not allow any code on its servers in Java that even contains an import statement to LGPL code - this is a serious issue.)

    I understand that JBoss have strong views on the BSD style licenses and that is absolutely fine. What I object to is the use of the LGPL license, an extremely unclear license in the context of Java, and one specifically deprecated by its authors the FSF.

    What would satisfy users like me, and I believe the Apache Software Foundation, is not for JBoss group to accept the BSD license, but to adopt a license other than LGPL that meets your goals of keeping library source changes public, but being much clearer on what consititutes the library and what constitutes the application.

    This could be done by adding an addendum to the LGPL licence (but then it is no longer LGPL), or it could be done by changing to an alternate license, perhaps the CPL.

    At the moment the JBoss position, and that of all LGPL, relies on developer ignorance of the danger they place their bosses in by linking to and using code such as this, Hibernate and JBoss.

    Stephen
    Committer at Apache Jakarta Commons, speaking personally
  21. LGPL[ Go to top ]

    JBoss and jbpm decided to change to LGPL because:

    - We wanted to build a community that kept contributing back and not splitting off.

    - It assures users that JBoss will not split off the project and have a proprietary version.

    - LGPL is a well accepted and understood license along with the GPL.

    For those with questions, we have written extensively on this subject and had the opinion of outside counsel: http://www.jboss.org/company/opensouce_aboutlgpl and http://www.jboss.org/company/opensouce_aboutlgpl and http://www.jboss.org/company/aboutopensource/lgplfaq.

    In addition, many ISV’s and OEM’s bundle and support JBoss as part an integral part of their go-to-market strategies. These are companies like HP, Novell, Unisys and Computer Associates. These companies have done their due diligence and bundling JBoss software is a safe choice.

    For those of you who say you can not use FSF licenses, I guess that means you are saying goodbye to Linux and many other valid open source projects. Here are some stats from Sourceforge: http://sourceforge.net/softwaremap/trove_list.php?form_cat=14

    – GPL 38,811
    – LGPL 6,175
    – BSD 4,032
    – Artistic 1,132
    – Apache 1,130
    – MIT 1,003

    Please do not make this out to be something unusual or sinister. It is the opposite.

    Thanks,
    Bob Bickel
    JBoss
  22. Re: LGPL[ Go to top ]

    JBoss and jbpm decided to change to LGPL because:- We wanted to build a community that kept contributing back and not splitting off.- It assures users that JBoss will not split off the project and have a proprietary version.
    That is a fine and accepted intent, but it does not imply LGPL. (I favour the BSD style license only because it is open, honest and clear in its intent, which is not the case with LGPL)
    - LGPL is a well accepted and understood license along with the GPL.
    IMO, this is just untrue. The GPL is a well known, well understood license, and is highly usable for whole applications where there is a clear boundary between the GPL and non-GPL (ie. between Linux and non-Linux, or standalone programs).

    The LGPL on the other hand is a license deprecated by the FSF, and subject to multiple interpretations when in Java. The sad part is that most developers do not educate themselves on these issues. Most instead presume that the LGPL means that they can use it in proprietry code. But the LGPL license simply is not that clear. The issues are far worse when dealing with library style code where your proprietry code has to import or extend an LGPL class.

    In essence what we have is a herd mentality, with many smaller open source developers following the larger players, such as JBoss, by believing that LGPL is OK and does what is perceived.

    Let me state again, I have no problem with the intent of LGPL (source changes to library remain open, proprietry linking allowed). Its just that the LGPL license doesn't actually say that in the context of Java (or to be more accurate, not all legal counsel agrees on the matter, and the FSF refuses to clarify the position).

    JBoss, due to its size, could take a lead in the Java community by choosing a license that is more acceptable to all without compromising its aims. That you choose not to is very sad to all in the world of Java.
    Please do not make this out to be something unusual or sinister. It is the opposite.
    Fact: The licence changed. Fact: Not every business accepts LGPL. By all means try to downplay it, but it was a serious change, with serious implications.

    Stephen
    Committer, Jakarta Commons, speaking personally
  23. LGPL[ Go to top ]

    Bob Bickel :
    JBoss and jbpm decided to change to LGPL because:
    - We wanted to build a community that kept contributing back and not splitting off.

    It's a admirable intent, but there is no guarantee that LGPL in any way prevents forking, and maneuvers like this can inadvertantly *cause* a fork. Diversity and transparency of community is the best way to keep a project community together. It could happen to JBPM because of those that were dependent on the Apache License could continue with the pre-LGPL version somewhere else. It's their right as licensees. It's not a good thing, but it's possible. It happened to JGraph, when it did the swtich from Apache License to GPL to LGPL (unilaterally, in a very short period of time). People had enhancements and extentions, not to compete but for specialization or integration with their projects and products. Perfectly good community members, not splitting or competing, but dependent on the license were cut off from being able to use the software as they were before, and as they were made to expect.
    - It assures users that JBoss will not split off the project and have a proprietary version.

    This is a little confusing in light that JBPM just proved that under the right conditions, a license can be changed arbitrarily and without community input. JBPM changed from the Apache License to the LGPL, to the surprise of the community. Interesting aside - JBPM switch from LGPL to the AL some time ago, with very successful community dynamics as a result ;)

    I'm a member of the Apache community, so it's fair that I note that the ASF recently changed their license too, from the AL 1.1 to AL2.0 for the entire codebase. However, I think that there are some fundamental differences. The purpose was to enhance the license and protections for contributors and users, and it was done after extensive discussion in the community and with outside counsel, and the membership voting to make the change. The changes were also minor details in order to improve the license, rather than a wholesale revocation/change of rights afforded by the license, which is clearly what happens when you switch from AL to LGPL. With LGPL, developers are limited in freedom over their own IP because of the restrictions on their enhancements and improvements.

    So, it's conceivable (though not probable) that the license could change again. It could change to a proprietary version owned by Tom (or JBoss if he assigns copyright), or some kind of GPL+commercial dual license, a la MySQL. As copyright owners, it's their right to do so.

    - geir

    (speaking for myself, writing as an individual member of the Apache community)
  24. License Change (was LGPL)[ Go to top ]

    Geir:
    So, it's conceivable (though not probable) that the license could change again. It could change to a proprietary version owned by Tom (or JBoss if he assigns copyright), or some kind of GPL+commercial dual license, a la MySQL. As copyright owners, it's their right to do so.

    For me, the main issue here it's not the license itself, but the way it was changed. On a REAL open source project, this kind of strategic change should be largely debated with the community, not be an arbitrary decision (a good or bad one).

    - Bender
  25. Hi,

       I am new to this workflow engines. someone, please tell me the difference between workflow engine and rule engine.

    Thanks
  26. Apache BPM project: Agila[ Go to top ]

    http://incubator.apache.org/projects/agila.html
     
     http://incubator.apache.org/projects/agila/index.html

     http://www.gluecode.com/website/news/release-2004-10-04-agila.jsp
  27. Hi,

       I am new to this workflow engines. someone, please tell me the difference between workflow engine and rule engine.

    Thanks
  28. Hi,

       I am new to this workflow engines. someone, please tell me the difference between workflow engine and rule engine.

    Thanks
  29. There are some blurry lines here. My quick answer is:

    Workflow - typically a flow of information and actions associated with people. This term became popular 15-20 years ago with things like expense report approvals, or imaging systems that would route things like credit card receipts and problems to different people to take action on rather than sending paper around with a sign-off sheet on top.

    BPM - Business Process Management. This term became popular over the past 5-10 years and typically refers to a combination of people and system oriented processes. So say someone approves an expense report, but then it kicks off a series of actions in several systems like payroll and general ledger.

    BPM Engine - keeps track of the state of various items as they pass thru a graph of tasks and actions. Think of drawing a typical flow chart where the BPM engine keeps track of each items flowing thru the flow chart. Go to http://www.jbpm.org for some good overview docs and pointers.

    Rules Engine - allows for complex set of rules to be applied to a complex set of data to make decisions. From the http://www.drools.org web site: "Rule Engines and expert systems are a great way to collect complex decision-making logic and work with data sets too large for humans to effectively use. Rule engines can make decisions based on hundreds of thousands of facts, quickly, reliably and repeatedly."

    Bob Bickel
    JBoss
  30. I have visited some WF engines sites but have no previous experience using one. I have two questions you may help:

    1. How does the user ineract with the workflow process? It appears there is no necessarily UI component. It is not very interesting if you route the expense request to a manager but he has no easy way to approve it. If it has to ask a separated UI agent, say an e-mail client, to interact with the user, how does a generic WF engine know if the UI agent has done the step?

    2. A lot of times, it takes a lot of detail programming, like string/list manipulation, to realize a real-world workflow. But WF engines, in particular the ones with graphical WF editors, appears only do well for simple, naive kind of programming logic. I don't think it is very effective expressing tricky programming details. That's what Java and zillions of programming languages are invented for. In fact, all WF engine examples I went over appears to be extraordinary simple and useless. How effective is WF engine's approach in the real world?
  31. How does the user ineract with the workflow process? It appears there is no necessarily UI component.

    its a layered approach. the core engine does not need a ui component. its just an api to feed information into the process and to signal the end of a state. on top of that you can have interface components that provide access to the api's: a webapp plugs into jbpm and makes the api's available to humans. jbpm contains a simple webapp that uses some extra form-information inside the process definition to get the input from users for their tasks in the tasklist. the same mechanism can be done for exposing the methods of the core api to other systems with e.g. web-services.
    But WF engines, in particular the ones with graphical WF editors, appears only do well for simple, naive kind of programming logic. I don't think it is very effective expressing tricky programming details. That's what Java and zillions of programming languages are invented for.

    Exactly ! My vision is that you should use a programming language for sequential execution, and that you should only use a workflow engine for state management (and other interesting responsibilities related to state management). Programming languages are not good at managing state. The states in a process turn out to be a great way of improving the communication between the business analysts and the developers. A lot of the workflow languages try to combine the 2. That results in overloaded process diagrams and too limited sequential exectution support. So you still have to revert to programming quite regularly. In JBoss jBPM we have had the vision from the beginning that a workflow engine must support a combination of declarative specification of the state of a workflow and programming logic. I think we have done a good job at combining these 2.

    regards, tom.
  32. Exactly ! My vision is that you should use a programming language for sequential execution, and that you should only use a workflow engine for state management (and other interesting responsibilities related to state management). Programming languages are not good at managing state. The states in a process turn out to be a great way of improving the communication between the business analysts and the developers. A lot of the workflow languages try to combine the 2. That results in overloaded process diagrams and too limited sequential exectution support. So you still have to revert to programming quite regularly. In JBoss jBPM we have had the vision from the beginning that a workflow engine must support a combination of declarative specification of the state of a workflow and programming logic. I think we have done a good job at combining these 2.regards, tom.

    It saunds good, but state management is not so hard with imperative programming too. State design pattern can help, it is about the same, is not it ?
    I am not expert, but it looks like workflow is useless without tools for modelling,debugging, monitoring, log viewrs. Engine must be something as trivial as FSM, It looks like UI tools are more important than engine.
    Rule engines and deductive databases look more interesting, but logical programming is not popular for some reason.
    Probably the most interesting thing is integration of both and programming languages for actions.
  33. There are some blurry lines here. My quick answer is:

    Workflow - typically a flow of information and actions associated with people. This term became popular 15-20 years ago with things like expense report approvals, or imaging systems that would route things like credit card receipts and problems to different people to take action on rather than sending paper around with a sign-off sheet on top.

    BPM - Business Process Management. This term became popular over the past 5-10 years and typically refers to a combination of people and system oriented processes. So say someone approves an expense report, but then it kicks off a series of actions in several systems like payroll and general ledger.

    BPM Engine - keeps track of the state of various items as they pass thru a graph of tasks and actions. Think of drawing a typical flow chart where the BPM engine keeps track of each items flowing thru the flow chart. Go to http://www.jbpm.org for some good overview docs and pointers.

    Rules Engine - allows for complex set of rules to be applied to a complex set of data to make decisions. From the http://www.drools.org web site: "Rule Engines and expert systems are a great way to collect complex decision-making logic and work with data sets too large for humans to effectively use. Rule engines can make decisions based on hundreds of thousands of facts, quickly, reliably and repeatedly."

    Bob Bickel
    JBoss
  34. Waiting[ Go to top ]

    Im waiting for TSS cartoon with JBorg assimilating any remaining independent OS projects...