TSS Article: The State of Workflow

Discussions

News: TSS Article: The State of Workflow

  1. TSS Article: The State of Workflow (34 messages)

    Tom Baeyens explains what workflow management systems are and looks at the advantages of business process management. He explains why the workflow market is such a mess and concludes that selecting a workflow management system is the hardest task companies have to face. He describes the concepts and provides a guided tour of the specs and tools available.

    Read The State of Workflow

    Threaded Messages (34)

  2. J2EE dependancy?[ Go to top ]

    Do I have to use a J2EE container to use JBPM? What are the dependancies on the container in general (and JBoss in particular)?

    I did some research in this area about 18 months ago for a client and was pretty impressed with Dralasoft's product. I was impressed primarily b/c alot of the *commercial* workflow vendors didn't offer a pure Java solutions that was "embeddable". Alot were build on top of C++ implementations with a thin Java API bolted on. Others required a full-blown EJB deployments and the requirements I had didn't indicate the need for an EJB container. I was looking for something that was lightweight, w/ an expressive API, w/ minimal dependancies that I could run standalone, in a web container, or an EJB container-- at my option.

    Incidentally, Dralasoft was also one of the only vendors who allowed me to see the javadoc for their API. (after the signing an NDA, of course) Most of the commercial vendors who claimed to have a "Java API" didn't even know what javadoc was. The client never ended up implementing the solution, but I would have chosen Dralasoft's product for their requirements.

    Anyone care to share their experience with any of the BPM/workflow products mentioned in this article?

    -Ravi
  3. pi-calculus?[ Go to top ]

    Hm, nice article, seems I'll have to brush up on what I learned about petri-nets in university.
    One question though: a superficial scan of other information on workflow gave me the impression that pi-calculus is the mathematical model behind workflow. Now I'm confused. Any thoughts on that?

    groeten uit Nederland,
    Joost de Vries
  4. Re: pi-calculus?[ Go to top ]

    I guess that depends on who you ask.

    BPML and BPEL are based on pi-calculus.

    Pi-calculus is a way of modelling concurrent processes in terms of the interactions they make. In BPEL, you have these swimlanes each representing a process (actor, system process, etc). Inside these you have activites.

    AFAIK, employee, manager and the HR, will be modelled as swimlanes in BPML/BPEL. One could then model the employee process using two activities: 'request holliday' and 'reply' with aproval (yes/no). Manager will contain an activity 'evaluation' that are connected to 'request holliday' (to model that employee interacts with the manager), and so on. One can also use conditions and variables of course.

    I believe the main idea behind BPML/BPEL is that of modelling workflows spanning multiple companies/partners/applications (say over the internet). The participans interact by sending events (SOAP messages) to each other. Moreover, you can in fact create very complex workflows using pi-calculus way of thinking. For example, you can create workflows that evolve and stuff like that.

    Some people argue that pi-calculus is the The Grand Unified Theory of workflow. Maybe those folks might of got it right.
  5. J2EE dependancy?[ Go to top ]

    I'm not sure about jBPM outside of the J2EE container, but I spent some time last year looking into workflow solutions for a project I was then working on. We initially thought (or at least the business did), that the project had a very complex workflow, but it turned out there were about 5 states the workflow required.

    Our company invited loads of the vendors in to demo their products, and we got some rather large quotations of how much the product would cost. The demos mainly consisted of some sales person telling us how good their product was at integration and how easy the drag and drop interface was to use - so much so that even a non IT guy could do it. Now I'm not saying they couldn't but when I look back and think how complicated they thought a simple process was - I wouldn't let them near the workflow design!!

    Finally we settled on two products to have a look at, one being IBM's workflow and the other being OpenSymphony's OSWorkflow.

    IBM's workflow had the full drag 'n drop thing going on, and ran off some random version of Eclipse, called workbench, this was all fine and dandy until we realised to test and compile this thing you needed a monster of a machine to process all the files it created (everything used SOAP interfaces). And a simple change to the workflow diagram could literally take about 5 minutes to recompile (on a quite a beefy machine too!).

    So we started playing with OSWorkflow, which I found surprisingly easy to use. If you're not bothered about the whole drag 'n drop thing (although the Visual Designer is coming along nicely), it's way more simple. You rattle out an XML template for workflow tell it where you want to store the workflow's, code up some decisions by implementing some interfaces and bob's your mother's brother.

    So my advice would be, take a look at what your business really needs, check out a few of the open source workflows (OSWorkflow has a nice example with it), and ignore all the commercial ones which sell their workflow based on the designer!
  6. http://java-source.net contains an extensive list of Open Source Workflow Engines written in Java: http://java-source.net/Wiki.jsp?page=JavaOpenSourceWorkflowEngines
  7. i tried several of them. most of them are buggy and have no documentation.
    There should be some criteria to be listed on open source projects - like good documentation and a well written example or atleast a good read me to tell where and how to start. <br>
    I m not against any open source and like it & encourage it even contribute to some. But its just that there are tooo many of them these days and one ends up stuck somewhere half way thru and it just results in a waste of time. <br>
  8. i tried several of them. most of them are buggy and have no documentation.There should be some criteria to be listed on open source projects - like good documentation and a well written example or atleast a good read me to tell where and how to start.
    Haven't found a bug in OSWorkflow yet, and I've heard Werkflow is stable too. The documentation is good enough to get you going and the OpenSymphony wiki is a god send. I'd be interested to know which OpenSource workflows you have tried...
  9. i tried several of them. most of them are buggy and have no documentation.There should be some criteria to be listed on open source projects - like good documentation and a well written example or atleast a good read me to tell where and how to start.
    Haven't found a bug in OSWorkflow yet, and I've heard Werkflow is stable too. The documentation is good enough to get you going and the OpenSymphony wiki is a god send. I'd be interested to know which OpenSource workflows you have tried...
    Almost none of them have a getting started or new users guide. They just assume so many things about users and ALL of them have issues with their configuration documentation. They just assume things would always be in right directory and right file and start from there. There is not a single one including wiki to guide me as a new user to the site/tool.<br>
    I know that you would say "you have to know basics of work flow engines.. blah blah " . Well I do. But I cant spend hours in just trying to get a simple work flow running. I have writtent my own for internal use in my bank which are much better than most of these hi-fi headache tools and i can make it work for anyone and any one can maintain it as its well documentated. <br>
    I m sure you think I m complaining, but people dont understand how detail documentation really matters. If you want to be more accepted in the industry then you should have good stuff to attract new users. Not scare them away by starting "How to configure" in first paragraph of your documentation.
    <br>
    End of story <br>
  10. Hi,

    Although in some cases workflow projects are so complex for non experimented users, we don't have to forget that most of these users try to deal with workflow advanced configuration instead of use the typical configuration/installation instructions. I will clarify that taking the example of Bonita Workflow System.

    In this system, non-experimented users have different options to make running Bonita:

    - They could download either .tgz or .zip file and JOnAS application server and then follow the custom installation instructions (that only needs to configure the internal database manually).

    or

    - For Windows users, they can use .exe installation wizard. This installation set default local values and includes an embedded database.


    So, I think that a good stuff is done about Workflow open source and there still are many things to do but we need to hear from users...

    Miguel
  11. re: Open Source Workflow Engines[ Go to top ]

    I know that you would say "you have to know basics of work flow engines.. blah blah " . Well I do. But I cant spend hours in just trying to get a simple work flow running. I have writtent my own for internal use in my bank which are much better than most of these hi-fi headache tools and i can make it work for anyone and any one can maintain it as its well documentated.
    errr... exactly how long did it take you to write your own workflow engine? i'm sure it's a little longer than the hours you mention above...
  12. The link provided leads to a HTTP Status 500.

    Here are workflow components, from ObjectWeb:
    http://bonita.objectweb.org
    http://jawe.objectweb.org
    http://shark.objectweb.org

    Enjoy!
  13. J2EE dependancy?[ Go to top ]

    Ravi-

    Check out Oak Grove Systems' Reactor 5, it sounds like it may meet your needs:
      - Pure-Java workflow engine that is easily embeddable (customers include SAS, Sybase and Plumtree Software)
      - Fully leverages J2EE standards
      - The free evaluation ships pre-integrated with JBoss
      - No NDA or password is required to read the Reactor API javadoc goto: http://www.oakgrovesystems.com/support/documentationmain.htm
      - You can purchase source code access

    I hope this helps with your research.

    Steven Katz
    Oak Grove Systems - VP Marketing
  14. TSS Article: The State of Workflow[ Go to top ]

    Mr. Baeyens, thanks for sharing your experience. Yes, BPM is a serious issue. We have done a prototype with Open Symphony's OSWorkflow. I like the state-machine focus. Overall, it's a young product but the folks driving it are diligent (Peter Lightbody and Hani Suleiman).

    One of the features I'd like to see is a facility for handling complex state (i.e. state made up of multiple sub-states). I mean having operations that can be performed on a process (e.g. "Reset to step X") which transitions all of the sub-processes.

    Watching this problem space intently!

    - JTigger
  15. Reset semantics[ Go to top ]

    Resetting to a state is a re-occuring interesting subject. It is one of the "pros" for using the term "activity" after all ;-).

    Executing a workflow is a mixture of stepping through states and executing actions. While you can reset the state machine to an arbitrary state, you cannot simply rollback the actions. Think of an e-mail: sent is sent. Of course, you can send another e-mail requesting the previous one to be ignored (though it may already be too late and something irreversible may have happened: you need a confirmation whether cancelling was successful; and what if not?...). In general, compensation of previous actions requires more than calling some "undo" action corresponding to a previously executed action, it requires a carefully chosen sequence of new actions, i.e. a branch in your process that undoes "all harm" and (if undoing is possible) eventually leads back to the state you wanted to resume, then clearing the way for a retry (i.e. resetting the activities to "not executed yet").

    Eventually, this leads to the question of loop semantics, one of the most interesting questions we had to answer when we implemented WfMOpen (http://wfmopen.sf.net). We think, we have found a good solution, not to undoing actions, but to easily specifying compensation branches. Of course, we are always open for suggestions of improvements.

     - Michael
  16. Very nice and clear article. Recommended to anybody willing to understand what Workflow and BPM is.

    I just do not share your point of view on WS-BPEL (formerly BPEL4WS). I'd just like to remind that SOAP/HTTP is just an extension of WSDL, bindings can easily be defined for everything. Apache WSIF provides bindings for local java, EJB or JMS and many more could be defined. WSDL is just an XML IDL. So reducing WS-BPEL to plain SOAP/HTTP doesn't IMHO reflect the truth.

    Matthieu Riou.
    http://www.smartcomps.org/twister
  17. Your clarification is correct. But it doesn't affect the conclusion.

    In the article, I show that state management is an important part of workflow and BPM. State management is not covered by normal programming logic. So the purpose of a workflow management system is to define a declarative extension that adds state management to plain programming.

    In its essence BPEL defines a programming language that is expressed in XML and has WSDL services as primitive constructs. BPEL does not have a notion for state. We should use programming languages for what they are good in and extend it with a notion for state management. BPEL takes a fundamentally wrong direction because it duplicates the notions in which a programming language is good (e.g. sequential execution, if-then-else, looping, ...) and it does not define an extension for state management.

    This conclusion is not affected by the fact that you could map WSDL to plain java method calls (which I would still consider a heavy-weight approach).

    Regards, Tom.

    ps. due to misunderstanding between me and TSS, an old version of the article has been published. please, take the effort of going through the final version once TSS has straightened this out.
  18. I read the final version of your document and it's even better than the old one. More concepts are explained in details with an awesome clarity even if you have a little tendency to mix definitions and opinions (but who doesn't?).

    However I do not agree with your opinion on executional processes. I would like to see an explanation of why you think state-based descriptions are important and why no clear state definition is for you an important flaw. Besides message correlation is, for me, clearly better than a process instance id. Which business partner will gladly retain an instance id for you ?

    Thanks,

    Matthieu Riou.
    http://www.smartcomps.org/twister/
  19. why you think state-based descriptions are important and why no clear state definition is for you an important flaw
    because state is a concept *not* supported by programming languages. on the other hand, sequential execution, loops and if-then-else constructs *are* supported by existing programming languages. so creating a new language that redefines a subset of these constructs in XML does not add value.

    so BPEL should be replaced with a good (java-)API for calling WSDL services. then we would be able to write the control flow in plain java.

    Regards, Tom.
  20. UML 2.0 unsuitability?[ Go to top ]

    By some really weird twist of fate, OMG replaced the implicit merge by an implicit join in UML activity diagrams between versions 1.5 and 2.0. I really regret this move because it makes UML activity diagrams much less suitable as a basis for the process definition control flow
    Can someone explain the difference between an implicit merge and an implicit join, and how this makes it harder to use UML 2.0 activity diagrams for modeling the control flow?
  21. UML 2.0 unsuitability?[ Go to top ]

    By some really weird twist of fate, OMG replaced the implicit merge by an implicit join in UML activity diagrams between versions 1.5 and 2.0. I really regret this move because it makes UML activity diagrams much less suitable as a basis for the process definition control flow
    Can someone explain the difference between an implicit merge and an implicit join, and how this makes it harder to use UML 2.0 activity diagrams for modeling the control flow?
    Think of a join as AND, where all incoming transitions have to fire, and a merge as an OR, when any one of them can fire, for progress to be made. The concern over the change of behavior can be alleviated by not relying on implicit assumptions. Always be explicit: when you want to join, use the join node (the thick bar) and when you want to merge, use the merge node (the diamond). This way everyone (who can real UML Activity Diagrams) will know what you mean.
  22. More commercial examples of BPM[ Go to top ]

    Thank you Tom for a clearly written survey of workflow and BPM. I also recommend to your readers the Flash demos of the 20 workflow patterns found on the Wil van der Aalst site you referred to. An animation is worth a 1000+ words.

    Given that Gartner have identified 110 BPM vendors in a recent research note I understand that your commercial list would not be complete. However there are several more worthy of mention. Fuego is a native Java BPM engine highly regarded by analysts with significant market traction (disclosure - my company resells Fuego in Australia). You mentioned Ultimus, a successful Microsoft based BPM product. The other contender in this market category is Metastorm, a vendor with a larger market share. Among the BPEL based products Collaxa and OpenStorm are well worth a look.
  23. After working on two big enterprise projects I am sure WFMS is must have if a company want to smooth its process for business, operations and development. It can save millions of dollors.

    In typical organizations process are changed with change in managers or key employees. That leads to change in exiting procress and application supporting those processes and lot of time duplicate work. With WFMS in place that problem can be solved.
  24. draft version[ Go to top ]

    Due to a misunderstanding between me and TSS, a draft version of the article has been published instead of the final version. TSS is working to fix the problem. In the meantime you can find the final version at http://jbpm.org/2/state.of.workflow.html

    Regards, Tom.
  25. Not quite complete[ Go to top ]

    You've missed Tibco InConcert, originally a Xerox product...
  26. Not quite complete[ Go to top ]

    you're right. i should have stated that the section commercial vendors was not intended as an exhaustive list.

    Wil van der Aalst estimates the number of commercial workflow management systems at about 250 so i probably missed a few others too :-)

    Regards, Tom.
  27. It may not be 100% Java based,[ Go to top ]

    but has anyone heard of Lotus Notes/Domino? People have been doing workflow in that for quite a while now.
  28. Workflow vendors & open source...[ Go to top ]

    Hi,

    When we started looking for a Workflow product just over two years ago the market seemed to be roughly split in to two types of Workflow vendors. Those that approached the domain from a historical Workflow perspective, and those that approached the domain from a EAI perspective.

    The more typical Workflow vendors products tended to support constructs that focused on the automation of existing manual form based business processes. They usually came with some type of user Work Portal (web-based, fat client or both) with varying levels of customisation supported. Unfortunately, whilst they did a good job of handling form centric business processes they usually did a very poor job of integrating with existing systems. Some had simple adaptors, or scripting languages - but none that we looked at would support things like distributed transactions.

    The EAI vendors, on the other hand, usually had excellent EAI features - repository of existing adaptors, ability to write custom adaptors/connectors and support for distributed transactions - but tended to do a poor job of process modelling... just have a look at a screenshot of BEAs WLI process designer (http://e-docs.bea.com/wlintegration/v2_1/studio/ch1.htm#1246123), it looks like they got Fisher-Price to design the interface - "My First Swing App". In BEAs favour though, they supported distributed transactions and simple integration with their message bus.

    We needed a product that had strong features in both areas. Something that integrated well with EJBs, messaging, COM & Swing clients in order to form an integral part of our new provisioning system, but also a product that had strong process modelling/Workflow support that we could use to automate our more typical form based business processes. Whilst there seemed to be a general convergence towards the desired middle ground, no one vendor had quite made it - of the products we evaluated, the closest at the time was Fuego 4.0 (www.fuego.com), which we went for in the end. The next version of Fuego which we've been able to beta test has improved greatly on version 4 and now covers both areas of EAI and Work Flow comprehensively.

    As for open source projects, IMO for enterprises with diverse legacy/non-legacy systems the robustness of the automation of business processes sitting on top of these systems is arguably more critical to their business than the reliability of a particular app server. So they could arguably be even less likely to take any perceived "risk" associated with an open source project.

    Successful open source projects thrive on standards, it's hard to imagine JBOSS being so successful if they didn't support EJB, JSP, JMS, JTA etc. And whilst standards like BPML, XPDL tackle the definition of the process flow, this leaves significant parts of what actually needs to be specified in a real world business process unspecified. That's not to say that the specifications don't exist for the various parts, more that the specifics of how they interact with each other aren't specified ( although that hasn't always hindered J2EE ;) ). Until this is specified I don't think large enterprises will use open source Workflow products until they can have a back up plan along the lines of... well, if it doesn't work on OpenXYZ we'll stump up the cash and deploy it on IBM's Workflow engine.

    But then, I don't suppose it really matters if big enterprises don't go for Open Source projects... the fact that they are available will help to move more developers towards the marvelous world of business process orchestration :)

       Tim
  29. I agree with your good analysis.

    One of the major motivations to start with jBpm was to create a workflow engine that does a good job on both subjects : workflow *and* EAI

    In jBpm we have the following approach on combining workflow with EAI :
     * an open source project (as any reusable component) should do only one thing but do it good
     * for jbpm that one thing is state management
     * so we have focussed on defining a simple and powerfull language
     * for EAI we have designed a very elegant mechanism to couple plain java code to process events
     * process designers can include custom classes into their process archive
     * if jBpm is deployed in a j2ee-container (which is not required), the custom classes are also executed within the container. That exposes all the j2ee integration capabilities to the custom classes.

    Regards, Tom.
  30. There are already standards evolving for this area. There is on wfXML from work flow management coalition. http://www.wfmc.org/
    Many fo the workflow management system vendors already support these standards for interoperability among different systems.

    Vikranth
  31. None of the current standard specifications has found widespread acceptance the way that SMTP, HTTP, or even SOAP and WSDL are accepted. The work of the WfMC (disclosure: I'm a WfMC working group chair) served as a terminology framework in the 1990s, but there is no formal conformance testing in place, and if a vendor claims standards support, this statement is based on self-assessment. Wf-XML (together with its sibling ASAP, which is being standardized by a group in OASIS) have some adoption potential and have recently been successfully demonstrated in a live demo led by Keith Swenson at the BrainStorm BPM conference in Burlingame.
    BPMN seems to be a good bet for a graphical process notation (since UML activity diagrams don't contain a lot of the finer points of workflow modeling). BPEL4WS is a safe bet for system-centric, internal processes. Whether it will be succesful in inter-organizational settings is less certain, since its tight coupling characteristics require a very close collaboration between the interacting parties. OMG's workflow facility is dead, BPML seems to have missed the boat, but XPDL is enjoying a resurrection from the dead in form of support by JaWE and Enhydra, among others. There is talk that XPDL might become a persistency format for BPMN models, which might be an interesting proposition.
    Workflow standards are made by workflow vendors, and as long as they can achieve economic gain by selling proprietary solutions, they will do so. One domain-specific standards bodies (SWIFT, ACORD, HL7 etc.) become interested in workflow, the tables may turn.
    Bottom line: There is no independent workflow standard at the moment, and those that exist don't have formal certification and testing in place, to provide vendors with a "seal of approval". Looking at standards can be a very educational experience in terms of learning the basic thoughts behind workflow interoperability, but there does not exist a dominant standard for workflow products.
  32. More Articles / blogs on Workflow ...[ Go to top ]

    Another blog entry referencing this article
    OReilly Blog Entry on Windows workflow
  33. TSS Article: XML Workflow[ Go to top ]

    There's a new article by Dr. Michael Kay that discusses the development of XML Workflow applications.

    Sincerely,
    The Stylus Studio Team
    http://www.stylusstudio.com
  34. TSS Article: The State of Workflow[ Go to top ]

    In the original article the author writes: process instance id versus message correlation: One of the complexities that are introduced with executional business processes is message correlation. Part of the process description must specify how the BPEL engine can detect the process instance identification from the incoming message. It has to be based on a data item in the message.


    I would not say that this is true that there must be an instance ID or message correlation. With Kontinuum there is not a process id but there can be a collection of instance identifying information
  35. Hi All, I am looking an article or paper which is evaluated open source work flow engines. Please suggest any location or article to view this. BR Senaka