JBoss jBPM 3.0: simplified workflow, BPM and orchestration

Discussions

News: JBoss jBPM 3.0: simplified workflow, BPM and orchestration

  1. Jboss has released jBPM 3.0, a workflow and BPM engine that enables the creation of business processes that coordinate between people, applications and services. With its modular architecture, JBoss jBPM combines development of workflow applications with a process engine. The JBoss jBPM process designer graphically represents the business process steps in order to facilitate a strong link between the business analyst and the technical developer.

    JBoss jBPM includes the following components: Runtime engine as a POJO library, a graphical desiger as an Eclipse plugin, persistence based on hibernate, a web console in JSF, a BPEL extension for orchestration, scheduler for timers, business calendar, and more.

    Graph Oriented Programming, a technique for solving problem of suspending and persisting a process, is at the heart of jBPM.

    In the JBoss jBPM downloads you can find the starters kit that includes everything to get started in one download.

    What do you think?

    Threaded Messages (53)

  2. Shark[ Go to top ]

    Who can compare it to Shark workflow?
    I think jbpm is more easy to use.
  3. The process model used by JBPM is simple and easy to work with. As opposed to other BPM models, it delegates some of the functionalities to external systems, keeping the process definition clean and precise.

    It will be great if there is a good design tool available. I've a quick look at the documentation for the Designer. It seems like a lot of the functionality is still missing (swimlane, task assignment and super-state). What is the roadmap for the Designer?
  4. How complete is the Process Designer[ Go to top ]

    The designer indeed does have full graphical support for all features of the core engine yet. Task assignment *is* supported, swimlanes and super-states are on the roadmap. Anyway, the features that are not graphically supported can be used by switching to the xml source tab of the processdefinition editor.
    More info on the roadmap can be found in JIRA (http://jira.jboss.com/jira/browse/JBPM).

    Regards,
    Koen
  5. How complete is the Process Designer[ Go to top ]

    It was of course meant to say 'does *not* have full graphical support.

    Regards,
    Koen
  6. Shark[ Go to top ]

    Who can compare it to Shark workflow?I think jbpm is more easy to use.
    What I appreciate from jbpm (as of version 2.0) is the ability to implement collaboration processes with just html and xml, and almost no code at all. And, if you have to create integration tasks you still can. That means: a simple way to implement simple things and, still, the ability to make complex things. That's a winning point over shark, osworkflow, openwfe and other frameworks, I hope they will keep an eye on simplicity.
    Does anybody know if the web example has been updated and/or enhanced?
  7. Re: Shark[ Go to top ]

    Raffaele,

    it's possible to implement collaboration processes with no [java] code at all with OpenWFE.

    Regards,

    John
  8. Re: Shark[ Go to top ]

    it's possible to implement collaboration processes with no [java] code at all with OpenWFE
    Ok, sure it is, and OpenWFE is also a full blown workflow suite with worklist management, web based (really, not an applet!) process designing, etc..., all things that jBPM _doesn't have_.
    Although I believe it's the most complete OS workflow suite it is not-so-simple and it lacks real world examples you can understand immediately, customize and use right away (all demos are like "flow x.y.z___.xml", "set(variable, 'abc')" and so on. Also: why do you have to "edit" a flow instance to make it "proceed"?
  9. Re: Shark[ Go to top ]

    it (OpenWFE) lacks real world examples you can understand immediately, customize and use right away (all demos are like "flow x.y.z___.xml", "set(variable, 'abc')" and so on.

    Point taken.
    Also: why do you have to "edit" a flow instance to make it "proceed"?

    Most people alter/edit a workitem and proceed it. Of course certain processes don't require such a thing : workitem are thus only 'notifications' that people still proceed.

    It's hard to implement things that suit perfectly the needs and the mindest of everybody.


    John


    P.S. congratulations to the jBpm team for its 3.0 release !
  10. Re: Shark[ Go to top ]

    It's hard to implement things that suit perfectly the needs and the mindest of everybody
    I totally agree, and, I would like to congratulate on you for the great job (OpenWFE) and for having contributed it to the community. Sorry for the criticism, I guess I'm just a lazy programmer who wants things ready without working too much ;)
  11. Re: Shark[ Go to top ]

    Thanks... And I just realized I wrote 'mindest' instead of 'mindset'...
    No problem, criticism is good.
    Ciao
  12. Does anybody know if the web example has been updated and/or enhanced?

    We developed workflow environment for JBOSS-JBPM that provides reach web interface including form player, work/task list, process definition and instance manager and actor/group manager as well. User interface was localized to several European languages.


    Authentication based on internal db, MS Active Directory or/and LDAP.
    Fine-grained authorization provided – every actor/group can have set of permissions on environment entities (process definitions, instances, actors/groups).

    Also we introduced the concept of bots - robots that act like Actors(Users).

    You can check our demo at
    http://wf.runa.ru/English/OnLineDemo/On_line_demo.html

    Or surf to project site to
    http://sourceforge.net/projects/runawfe/

    Best regards,
    Vitaliy
  13. We developed workflow environment for JBOSS-JBPM that provides reach web interface including form player, work/task list, process definition and instance manager and actor/group manager as well.
    Now _that_ is interesting and seems to be a nice and clean job, too.
    Only thing I don't like is the licensing (I *hate* GPL!), but I think that, being an end user solution this is more acceptable than in other cases. I would ask you anyhow to reconsider LGPL (same as jBPM) and I'm sure people will begin to use it widely. I would for sure.
  14. Now _that_ is interesting and seems to be a nice and clean job, too. Only thing I don't like is the licensing (I *hate* GPL!), but I think that, being an end user solution this is more acceptable than in other cases. I would ask you anyhow to reconsider LGPL (same as jBPM) and I'm sure people will begin to use it widely. I would for sure.

    Thank you for you feedback.
    Stay tuned, our release (coming soon) will be even more polished.

    Also we consider LGPL license as a replacement for GPL but so far we don't see how our clients would benefit from it.

    Best regards,
    Vitaliy
  15. Vitaliy,

    One definite advantage of licensing under LGPL would be a tighter integration with jbpm itself. We could potentially integrate your system as part of the jbpm web app. At the moment we can not use any of your code due to the licence incompatibilities between the LGPL and the GPL.

    manfred

    PS: Your site seems to be down so I couldn't check it out yet.
  16. One definite advantage of licensing under LGPL would be a tighter integration with jbpm itself. We could potentially integrate your system as part of the jbpm web app. At the moment we can not use any of your code due to the licence incompatibilities between the LGPL and the GPL.manfred

    Its very interesting idea. I think in this case we could donate our code to JBOSS JBPM on mutually beneficial conditions.

    Could you explain what target group jbpm web app is aimed at?

    E.g RUNA WFE is aimed at 4 kinds of end users.

    First of all it is an employee that participate in processes. For him RUNA WFE provides reach web based environment for task handling, process initiating and monitoring, etc.

    Second kind is a manager that writes process. For him RUNA WFE provides means to deploy/redeploy/undeploy, monitor and manipulate state of processes.

    The third kind is programmer. He builds forms, creates tasks for bots, writes action handlers for workflow events. For him RUNA WFE provides flexible API.

    The last kind is a system administrator. He performs Actor/Group management, he grants permissions to start/stop/deploy/undeploy processes, he defines who can login to environment, etc . All administrating tasks are performed via web interface too.
    PS: Your site seems to be down so I couldn't check it out yet.

    Sorry, maybe the link was broken check it out at
    http://wf.runa.ru/English/OnLineDemo/On_line_demo.html
  17. One definite advantage of licensing under LGPL would be a tighter integration with jbpm itself. We could potentially integrate your system as part of the jbpm web app. At the moment we can not use any of your code due to the licence incompatibilities between the LGPL and the GPL.manfred
    Its very interesting idea. I think in this case we could donate our code to JBOSS JBPM on mutually beneficial conditions...

    It's nice to see you people getting along... hope you'll find an agreement.

    Ciao,
       Raffaele
  18. Now using tiles and jsf[ Go to top ]

    The new web app is using JSF and tiles and has some monitoring and administration in it. It is currently being enhanced a lot in CVS as well..

    manfred
  19. RE: Shark[ Go to top ]

    Is Shark even being actively developed or used? I tried to find more information on it but the Shark site is stale and I was not able to find any active support / user / developer forums.

    I sent emails to two of the three developers listed in SourceForge, one email bounced back and no reply to the other...

    Now the jbpm site can be said to be stale too (www.jbpm.org) since it announces the availablity of JBPM Version 2 :)
    But the user / developer forums are very active and answers to posted questions are provided in a timely fashion by the developers.

    Is anyone actively using / developing Shark? If so, could you post links to current resources / forums etc.
  20. Hi!

    Just to introduce myself. My Name is Robert Zachajewicz and at Together I am responsible for services and support. Of course Shark is actively developed and used. Just some days ago we shipped the new version 1.1. All information and downloads at can be found at http://shark.objectweb.org/.

    There is a very frequently used mailing list: shark at objectweb dot org. So if you have any questions you will get answers very soon!

    And shark is used in many projects. Just to mention one supported by us: Shark is used in Austria for one of the biggest E-GOV Workflow Projects (300.000 named users!, up to 10 Mio. Process instances per day!). In this special use case shark is not only executing the process instances it is also used to control the application which is using shark as service.

    If you have any questions please feel free to contact me any time!

    Best regards,
    Robert
  21. But... I tried to get some ideas about different workflow engines (and i talked to that guys rom austria because i was interested in this topic for two reasons (shark and domain)) but failed to get some ideas on how to integrate shark in an own application.

    That was not such a problem using OSWorkflow or con:cern.

    Therefore i would like to ask you to give some examples on how one may use Shark.
  22. Tom - can you give some common examples of BPM? i.e. what types of problems is this particularly applicable to, and how easy is it to use these BPM tools to address the problems? I've read about BPM but I've never used any of the products that are out there, so I'm curious if it falls into the same problem domain that rules engines are in, or is it something else entirely?

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  23. rule engines v bpm engines[ Go to top ]

    Cameron, could you elaborate your reasoning that rule engines and bpm engines may live in the same problem space?
  24. rule engines v bpm engines[ Go to top ]

    rules engines are complementary to workflow engines. (workflow engines is too overloaded so i would prefer to use graph oriented programming).

    rules engines compute a set of output from a set of inputs and a set of rules that are recursively applied to the input. this is a one shot calculation.

    whereas graph oriented programming solves the problem of wait states.

    the way they work together is the following: in your process control flow, you might have a decision. to calculate which leaving transition to take in the graph you could use a rules engine. the decision could apply the process variables to a set of rules. depending on the output, one of the leaving transitions could be taken in the process. that is the most typical way of how workflow engines and rules engines work together.

    regards, tom.
  25. Not necessarily true[ Go to top ]

    rules engines are complementary to workflow engines. (workflow engines is too overloaded so i would prefer to use graph oriented programming).rules engines compute a set of output from a set of inputs and a set of rules that are recursively applied to the input. this is a one shot calculation. whereas graph oriented programming solves the problem of wait states. the way they work together is the following: in your process control flow, you might have a decision. to calculate which leaving transition to take in the graph you could use a rules engine. the decision could apply the process variables to a set of rules. depending on the output, one of the leaving transitions could be taken in the process. that is the most typical way of how workflow engines and rules engines work together.regards, tom.

    Rules engines like JESS, JRules, Blaze, haley, etc are finite state machines. Whether it runs in a "one-shot" mode or as wait states has nothing to do with the rule engine. It is the result of how one uses JRules, JESS or any other general purpose rule engine. A rule engine that implements RETE is all about maximizing speed, and scalability. It trades memory usage for speed. Many rule providers have modules for BPM, which define a base set of semantics and plugins for specific vertical sectors like insurance, mortgage, etc.

    There's a category of rule engines that are stateless and query driven. These types of rule engines would work in a "one-shot" approach. Each type of rule engine has strengths and weaknesses, so no single rule engine is right for all scenarios.

    peter
  26. Cameron,

    Here are some answers to your questions.

    BPM usually becomes interesting when you need as part of an application to model a flow (specially if that flow entails long-running steps, parallel steps, need for compensation is case of errors.

    Examples of flow:
    - DSL service provisioning (in that case the flow is the set of steps that happen behind the scene when an order is submitted. A step can be fully automated (create login account), long running (configure network) and/or represent a user task (call customer for more information).

    - Expense report (in that case the flow is the set of steps your expense report goes through to be approved and processed. Here again it is usually a mix of automated steps, manual steps, might include parallel processing, compensation etc.)

    How does a BPM systems helps developers implement those flows?

    Without a BPM system, developers have to write code to implement those flows. This becomes hairy when you start dealing with long running flows, parallel processing and compensation. The idea behind BPM systems is to create a higher level of abstraction/language that understands natively flow constructs and makes it much easier to implement those flows. Most BPM systems are composed of a language, a visual modeling tool to produce and edit that language, an engine that interprets that language and orchestrate the flow. The more sophisticated ones have strong support for clustering and management. The management is key becomes it allows you to monitor in-flight long-running flows.

    What about BPEL?

    In the last 4 years, the industry realized that the BPM problem can be further generalized through the use of XML and Web Services. The core of that approach is to think of each step in a flow as a service consuming or producing XML messages. In that context, it is possible to standardize the flow language (and this is what BPEL is). The benefit of the standardization is that as a developer you do not need to go and learn the proprietary flow language associated with each vendor's process engine. The second benefit is that it provides a foundation of tools from different vendors to interoperate (you might use one tool for design, another for documentation, another for testing and yet another one for execution - you are not locked in). The last benefit of BPEL is that it has very strong support for parallel processing, compensation, exception handling and non-linear flows.

    What about rules?
    Rules and BPM usually work hand in hand. For example in a BPEL flow, you can call out to a rules engine to execute logic and based on the result branch the flow. When used right, rules make flows much for flexible.

    Hope this helps,

    Edwin Khodabakchian
    http://otn.oracle.com/bpel
    Oracle BPEL Process Manager
  27. What about BPEL?In the last 4 years, the industry realized that the BPM problem can be further generalized through the use of XML and Web Services. The core of that approach is to think of each step in a flow as a service consuming or producing XML messages. In that context, it is possible to standardize the flow language (and this is what BPEL is).

    For an open-source BPEL engine, go to ObjectWeb MOBE: http://mobe.objectweb.org/
  28. mobe and shark[ Go to top ]

    Is there any collaboration between Shark And MOBE respective teams ?
  29. mobe and shark[ Go to top ]

    Is there any collaboration between Shark And MOBE respective teams ?

    AFAIK Shark and JaWE approaches are fairly different (WfMc workflow engine vs BPEL business process execution engine). BTW there's a third "orchestration" engine at ObjectWeb, named Bonita.
  30. mobe and shark[ Go to top ]

    this is the whole point as to why i think the concept of Graph Oriented Programming is so important: you don't need many separate engines for workflow and orchestration.

    Graph Oriented Programming specifies a simple model for executing graphs. That can be extended with features in different domains like workflow and orchestration. It is because of this model that JBoss jBPM is able to support multiple process languages: JPDL is more oriented towards workflow, task list management and integration of plain java code. And secondly BPEL: by extending the graph oriented programming core module with web service capabilities.

    regards, tom.
  31. BPM and rules[ Go to top ]

    I agree with Edwin that rules plus BPM becomes ever more powerful.

    In my experience the topology of a workflow or business process changes infequestly but the conditions that are used to choose alternate paths change frequently. This makes outboarding of rules (conditions) a good technique. We have been looking into doing this for WS-CDL and then driving down the rules into whatever the execution platform of choice happens to be (BPEL, Java etc).

    If you go to www.pi4tech.com you can download the slides I gave as keynote at the European Business Rules conference that alludes to all of this.

    Cheers

    Steve T
  32. Edwin,

    i think it is a marketing mistake to position BPEL in the areas of worklfow and BPM.

    BPEL is an integration technology. basically it is a scripting language to write new webservices as a function of other web services. i know that is a bit oversimplified, because bpel adds a lot of syntactic sugar on top. don't get me wrong, i am convenced that BPEL has its merits. but it needs to be put in the right context: an integration technology in the area of webservices.

    some marketing departments have succeeded to sell BPEL as a BPM and workflow solution and i think that will backfire.

    BPEL process DO NOT COME CLOSE to what business analysts are modelling. business analyst do not write software, they draw graph based diagrams like e.g. activity diagrams.

    in JBoss jBPM we have the vision that this should be similar as with UML class diagrams. the analyst draws an initial class diagram model, leaving out a lot of implementation details. then the techie adds more technical details like e.g. the method implementations. it is similar with jBPM processes. A jBPM process can be projected to only show the graphical part, leaving out all the technical details. basically in jBPM, the java code is centralized around the business analysts' graph. that is the motivation to call it Graph Oriented Programming. because it is yet another technique to structure code as e.g. structured programming, OOP and AOP. this time, code is centralized around a graph.

    BPEL does not deliver on that vision. it is simply not suited for decoupling the graphical representation from the implementation details. BPEL is a scripting language for technical people doing integration based on web services and it should NOT BE POSITIONED for BPM and certainly not for workflow.

    regards, tom.

    ps. i know you're at javaone, so you don't have an excuse to miss my talk tomorrow :-) i'm interested to discuss this over a few beers afterwards.
  33. Tom,
    This is representative of the type of fud we hear from vendors who have a half backed BPEL implementation.

    FUD #1: "BPEL is limited to web services"
    The truth is that WSIF and JBI extend the reach of BPEL to HTTP/SOAP service but also JCA adapters, POJOs, EJBs and even C# components. This level of interoperability is key in delivering the promise of BPM/composite applications.

    FUD #2: "BPEL is too complex for business analyst".
    The truth is that this is only a tooling problem. A good tool can offer all kinds of views on a BPEL process definition, some higher level than others. Creating a standardized notation such as BPMN is also another approach to addressing this requirement.

    FUD #3: "BPEL does not have support for user activities/workflow".
    The truth is that there are a lot of benefits in thinking of a user worklist as a service decoupled from the core orchestration engine. Benefit #1: it is much easier to deliver on the promise of central/universal worklist. Benefit #2: you can rev the worklist service separately from the orchestration engine. Benefit #3: you can create domain specific worklist services (the casual manager who reviews an expense report one a week has different requirements from the call center user who uses the application day-in and day-out.

    Don't get me wrong, BPEL is only at version 1.0/2.0 so there are still rough edges to be ironed out...but no need to create additional FUD around it.

    -Edwin
  34. definitely not my intention to create fud around BPEL. sorry if i gave that impression. i'm just speaking my mind and i'm open for other opinions.

    1) i never said that BPEL is limited to web services. i have heard that argument before that BPEL is based on WSDL, not webservices. while you *can* indeed address an ejb from a bpel process, this is not what it is targetted for.

    2) first, i think that tooling should not be used to compensate for the underlying complexity. we should always strive to not introduce complexity in the first place so that developers are not so dependent on tools. second, BPEL does not allow for support of decoupling the graph representation from the implementation. so you're business analyst is always forced to think in terms of concrete services, on an implementation level detail. i want to give the analysts the option of first drawing the graph *they* like. and then only afterwards the technician has to think about how do i couple the implementation level details to the graph that the business analyst has produced.

    3) first, BPEL does not define such a user activities service. second, i don't think such a service should be realized as a wsdl service. it should be primary a java component. i'm in favour of translating from web services to java at the edge of the server. i mean that i like translate webservice invocations as quickly as possible to java invocations when they arrive in the server. then do the maximum of calculations in plain light-weight java. then at the very end of the request, translate to xml/webservice again to send the response. BPEL on the other hand is one step in the direction of postponing that translation to java trying to make it unnecessary. adding a scripting language that operates on the WSDL level. so in my opinion, BPEL is good if you have a broad standardization on webservices (read: WSDL) in your organisation and if you want to create a new webservice that requires minimal processing of other webservices.

    to reiterate: i'm not against BPEL. i am only arguing that for me, BPEL is an integration technology and it should not be positioned for workflow and BPM.

    i see integration and BPM as complementary. for example, i can write a simple, plain java webapplication without any integration to support a business process. so i don't see the need to tie these two together in a 'hard coded' fashion.

    regards, tom.
  35. I am glad we agree on 1).

    Regarding 2), what you call an abstract graph is simply a set of tagged scopes linked together using links or other BPEL constructs. Intalio has been offerint this analyst view for more than 3 years. You could also very easily add other annotations to the process definition to capture this higher level view (similar to javadoc document in Java code). My point is that this requiremnt can be addressed without forcing developers into a proprietary orchestration/flow language.

    Regarding 3), I am not sure I understand what you mean: why should a user task be modeled as a Java POJO? The point that I was trying to make is that it was a good thing that BPEL did not define a <usertask> activity. It is much more powerful for BPEL when it needs a user to do something to call a task service (invoke "initiateTask", do stuff, wait for callback from task service: receive "onTaskCompleted"). Think of this task service as a "shared space/rendez-vous point" between the BPEL process and the JSF or other app driving the UI that a user used to complete the task. With this approach, the developer is free to 1)select any UI technology he or she wants to use and 2) plugin his own task service when needed.

    I think that the artifial walls you are describing between those technologies are limited: BPM, Workflow and integration have to converge to enable the next wave of composite applications. BPEL, although not complete, offers the foundation for driving that convergence.

    I will try to make it to your presentation...may be some beers will help bridge some of the gaps.

    Edwin
  36. I think both of you (Tom & Edwin) are right. The current focus of BPEL specification is certainly more towards EAI than human-centered workflows, but vendor implementations have their own extensions for the latter. That said, there is no spec on data transformations in BPEL that is essential for EAI.

    Regarding modeling languages and their closeness to how business analysts think, there is no generic language that will fit that need, IMO. The best language that can be offered to business analysts is always domain-specific. I doubt even the best tooling will enable a generic business user to work directly with BPEL or GOP or any other modeling language.

    JC Reddy
    http://www.bpmlabs.com/
  37. BPEL and Transformation[ Go to top ]

    JC,
    BPEL calls out to XPATH, XSLT and XQuery for transformation. There is no need for BPEL to re-invent the wheel in regarding transformation when there are already mature XML transformation standards available.
    -Edwin
  38. 3) it all depends in which environment you want to access and manipulate the tasklists. if you mainly access it from other services, it makes sense to have the tasklist component accessible as a service. if most of your programming is done in java, its best to have your tasklist component accessible as a java component. so if we exose a java tasklist component and expose it as a webservice (preferrably via the j2ee ws mechanisms), then we have it both our way. i think another issue resolved :-)

    i'm at the jboss booth tomorrow between 5 and 7 pm. come just before 7 to have those beers and we can settle on issue 2 :-)

    regards, tom.
  39. Worklist Service[ Go to top ]

    Tom,

    My point is NOT where you want to access the worklist from but rather the benefit of having a centralize Worklist service that can be accessed from N orchestration engine. This way if you use a packaged application, your own custom processes and a .NET application, they can all publish tasks to the same service and the user does not need to login to M different applications to see his tasks.

    But we can may be agree to disagree on 3) and see which approach gets more widely adopted.

    -Edwin
  40. Worklist as a BPEL service[ Go to top ]

    #3: "BPEL does not have support for user activities/workflow".The truth is that there are a lot of benefits in thinking of a user worklist as a service decoupled from the core orchestration engine. Benefit #1: it is much easier to deliver on the promise of central/universal worklist. Benefit #2: you can rev the worklist service separately from the orchestration engine. Benefit #3: you can create domain specific worklist services (the casual manager who reviews an expense report one a week has different requirements from the call center user who uses the application day-in and day-out.

    First I have to provide a disclaimer: I’m no workflow expert. That said I do have some practical observations.

    I’m currently evaluating workflow engines for a project that has a workflow component. I’ve looked at various engines including jBPM, Shark, and Twister.

    One engine I evaluated was a BPEL based engine that communicates with a worklist service much like Edwin is promoting. This all is very good in theory. In practice, however, it takes a lot of effort to implement.

    In order to create a single step in a workflow that communicates with a worklist you have to: create message types, define properties and aliases, create correlations, define a sequence, assign variables, invoke the service, receive a response, and assign some result variables. This results in 40+ lines of XML per step.

    I have over 30 processes to model with an average of 6 user interactions per process. 30 processes * 6 user interactions * 40 lines of XML = 7200 lines of XML! If you include the external services we need to call the total would be well over 10000 lines of XML for 30 simple processes. That is a lot of overhead.

    I’m not against Bpel. I know it has its place and is an important standard. For our project, however, it simply wouldn’t be a productive choice. Unless of course there is some really good tool I don’t know about or someone volunteers to come and write and debug 10000 lines of XML for us. :)

    Regards,

    Jeremy
  41. Hi, I think Rulesharp has hit it on the head. Some differences from jrules, blaze, haley authority, jess, drools, etc are as follow: It is only logic, you drive your services. It is database driven. It is cheap (excluding open source). Memory bound. Super fast. 100% reusability of rules. Great GUI. check it out: www.rulesharp.com randy
  42. BPM vs Rule engine[ Go to top ]

    Tom - can you give some common examples of BPM? i.e. what types of problems is this particularly applicable to, and how easy is it to use these BPM tools to address the problems? I've read about BPM but I've never used any of the products that are out there, so I'm curious if it falls into the same problem domain that rules engines are in, or is it something else entirely?Peace,Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java

    Here's my bias .002 cents worth on the differences between BPM and rule engines. A BPM engine is no different from a rule engine from a runtime perspective, since BPEL defines the semantics for declaring business process. A rule engine can be thought of as a symbolic processor, which matches patterns. Normally, a generalized rule engine doesn't care about the semantics of business process. I tend to think of BPEL and other BPM languages as a specific dialect of rules. Business process rules can easily be compiled to run in JESS, JRules, or any number of commercial rule engines. The primary difference between various products and approaches is scalability with respect to the number of rules and dataset size.

    Other factors that affect BPM engines is the ability to add/remove rules on the fly at runtime. Many rule and BPM engines are procedural, and do not scale well as the number of rules increase or dataset increases.

    peter
  43. Currently, the whole landscape of workflow, bpm and orchestration is one big mess. cause there is no common foundation, every product and spec is targeted towards its own mix of functionalities. it would be analogue as everybody trying to build a database without anyone knowing the relational model, the hierarchical or the object database model.

    jbpm focusses on providing a foundation (Graph Oriented Programming). think of the foundation as a few simple java classes like e.g. Node, Transition and ProcessInstance. features can be added to that foundation in every of the former domains: workflow, BPM and orchestration.

    graph oriented programming adds to java the capability of persisting an execution. in plain java, suppose you block a thread and wait for something to happen. when you reboot, you cannot rebuild that call stack. so you lost the context of where you were in the process. Graph Oriented Programming lets you express your process as a graph. Then your execution is a pointer to where you are in the graph. Now both the graph (process) and the execution can be stored in the database during wait states.

    So it enables you to write a process that spans e.g. user tasks, asynchronous invocations and other wait states.

    If you don't use Graph Oriented Programming, you must split that process up into the different requests to your server and manage the state yourself inbetween the requests.

    If you're at JavaOne, don't miss my talk tomorrow "Workflow, BPM and Java". alternatively, you can look at my jboss jbpm webinar http://jboss.com/services/online_education

    regards, tom.
  44. If you're at JavaOne, don't miss my talk tomorrow "Workflow, BPM and Java". alternatively, you can look at my jboss jbpm webinar

    Hi Tom, it was great to get to meet you, and thanks for the explanations. I was impressed by what you described, both what's happening in the standardization efforts and also in jbpm.

    Coincidentally, after we talked, I realized that it might be very similar to the "continuations" support that some people talk about. True?

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  45. yes. graph oriented programming is adding state management capabilities to java and having an easy mapping to a graphical representation.

    the state management part is for sure very similar to continuations.

    regards, tom.
  46. jBPM and WS-CDL ....[ Go to top ]

    It would be most interesting given the use of POJO and jBPM to see how this might work along side WS-CDL (Choreography Description Language) tool from Pi4 Technologies (www.pi4tech.com).

    I have had a lot of interest expressed recently about tying WS-CDL together with BPEL.

    Is anyone doing anything on this topic?

    Would anyone like to try?

    Suggest looking at www.pi4soa.org for open-source WS-CDL tools and www.pi4tech.com for examples.

    I shall certainly be trying out the jBPM stuff and shall report back to this thread.

    Cheers

    Steve T
  47. Graph-oriented programming...[ Go to top ]

    AKA petri nets (though this isnt mentioned at all in the chapter). There's decades of research behind petri nets and most of the major workflow products are based on them, so would I be right in saying "GOP" is another name for an old concept?

    Also, are you limited to just one input transition and one output transition to a place? This makes it an FSM which is fine, but there are problems that are more easily solved if you dont have that limitation.

    However, a HUGE congratulations on making the engine POJO-based. This is such a good idea and I hope other architects and designers of public projects take note. This is definitely the future.

    Kit
  48. Graph-oriented programming...[ Go to top ]

    No, GOP is definitly not similar to petri nets.

    You could create implement petri nets with GOP by implementing the petri-net-place and petri-net-transition as two node types. so those would be 2 node-sub-classes.

    (since a transition in petri nets is actually a node type in GOP, that would create a bit of a name clash)

    the petri net model has 3 very simple basic constructs: place, node and arc. and by combining them you can model really complex processes. but actually it turns out in practice that reasoning about business processes in terms of the petri net constructs is extremely hard.

    so for me, this also makes the (interesting!) research on petri nets a bit irrelevant. in JBoss jBPM we have replaced process validation with super support for test driven development. we think it is much more robust to specify what you expect from a process in a plain JUnit test as opposed to a validation algorithm asking "this is what you've modelled, are you sure?"

    regards, tom.
  49. Graph-oriented programming...[ Go to top ]

    No, GOP is definitly not similar to petri nets.You could create implement petri nets with GOP by implementing the petri-net-place and petri-net-transition as two node types. so those would be 2 node-sub-classes.(since a transition in petri nets is actually a node type in GOP, that would create a bit of a name clash)the petri net model has 3 very simple basic constructs: place, node and arc. and by combining them you can model really complex processes. but actually it turns out in practice that reasoning about business processes in terms of the petri net constructs is extremely hard. so for me, this also makes the (interesting!) research on petri nets a bit irrelevant.

    Tom, having implemented two versions of Petri net based BPM/workflow engines (which happened be very compact and very usable), I would completely disagree with you. The beauty of Petri nets lies in its simplicity and composability. A transition is not just a "node", because one can attach complex behaviors to a transition node. Throw in hierarchical nodes, one can model very complex processes fairly easily. In fact, I would argue that most nodes in jBpm GOP basically are variations of "transition" nodes in Petri nets. I hope to share the Petri net model I have developed at sometime in the future.

    JC Reddy
    www.bpmlabs.com
  50. Graph-oriented programming...[ Go to top ]

    Having been deeply involved in the AI "bubble" 20 years ago, I learned that what is most important is how easy it is for non-programmers to relate to process descriptions. The idealogy, paradigm and purety of the methodology means naff all to the person trying to explain how their world works.

    In those halcyon days, rules were king - we built rule engines that could do whacky process flows - but the people with the process knowledge in their heads couldn't map it to our twisted view of the world ;-)

    Needless to say, we extended the rule engines to have explicit procedural components (graph transitions) that invoked chunks of declarative deduction or decision making. Ended up doing the same with neural nets too.

    But this is the best thing about having a choice of OSS BPMs - you can pick the one most suits your user's mindset. Just remember that most people don't think like developers do.

    Well done to jBPM for getting this release out - we've been wiating for BPEL and designer.

    Cheers
    Paul.
  51. Graph-oriented programming...[ Go to top ]

    the petri net model has 3 very simple basic constructs: place, node and arc. and by combining them you can model really complex processes. but actually it turns out in practice that reasoning about business processes in terms of the petri net constructs is extremely hard.

    I have to disagree. Being able to see both state and behaviour and their interaction in one decomposable view makes (IMO) petri nets very complete and easy to use.

    But this is all just opinion I guess.

    Regards
    Kit
  52. Who is using jBPM?[ Go to top ]

    I've been playing around whith the jBPM starters kit. It looks quite simple! But I've been trying to find out who is actually using jBPM in a production environment.

    Anyone knows?
  53. Who is using jBPM?[ Go to top ]

    Hello Tom/Others,
    Offlate i have been looking/evaluating jBPM as one of the workflow products.
    I have evaluated one licensed product but it doesnt really fits in our requirements because of both hardware as well as software problems.

    Now i want to know whether workflow systems really fits into the space of Enterprise Application System.

    In other words,our organisation doesnt have much human intervention for any business proxcess and allmost all of them are automated.
    So was wondering whether iam looking at the right product/technology for EAI??
    Do people use workflow for 100% automated EAI tasks??

    Many Thanks
    Prashanth
  54. jBPM in production project[ Go to top ]

    If it is not too late, I know a few jBPM projects.

    One, I am allowd to talk about, its a full blown ERP system with jBPM, see the germen press release: http://www.camunda.com/pressemeldung.php?newsitem_id=800

    Best regards
    Bernd