PowerFolder - OpenSource Workflow Server Announced

Discussions

News: PowerFolder - OpenSource Workflow Server Announced

  1. PowerFolder is open source, beta (0.5) workflow server and development studio. It can be configured to work on J2EE application servers and a variety of persistance stores. Workflow represents defined processes within businesses and elsewhere. The author of PowerFolder is offering free phone support.

    Check out PowerFolder.

    More info
    --------------------
    PowerFolder is an easy to use J2EE workflow server. It's as easy to install as jBoss and requires no relational database. (The download is actually a derivative of jBoss-Tomcat, but any app server can potentially be used.)

    It comes with a web-based administration console and studio. Applications can be made with very little Java code. The included demos required only JSP scripting with a single variable, 'client'.

    The demos take just minutes to install and complete - you can be finished all three well within an hour.

    At this time, free phone support is available to answer your questions and listen to your feedback. Take the test drive and let us know your PowerFolder experience!

    Threaded Messages (22)

  2. This looks very interesting. Does anyone know if it has a GUI tool to develop workflows? Also, is there a means to have steps in your workflow call applications outside of the Java world?
  3. Hi Mike,

    The actual workflow script can be created entirely by the Developer Studio. Just login, click 'Develop', then click 'Scripts', enter a new name under 'New Script' and click 'Create'. You may want to 'Edit' (really just view) an existing script to see how things work before creating your own.

    A script is really an XML file so it can also be created by hand. The Developer Studio is far more intuitive and user friendly.

    The tag set is pretty basic at this point, but more enterprise-like tags will be coming. What sort of non-Java communication do you have in mind? SOAP, JDBC, ODBC, PHP (instead of JSP) web pages. The first 3 involve the creation of new tags, while the last one would require a SOAP-wrapper around the 'client' variable.

    Enjoy,

    Gary
  4. Is it compliant with the BPMI and/or WfMC specifications?

    Julien Dubois.
  5. Hi Julien,

    At this point, PowerFolder uses its own XML to describe scripts. However, I am very interested in exploring this more.

    When the project first started, I explored ebXML as the script schema. One part of its specification deals with collabaration and workflow. However, after some investigation, it seemed like it was too high level. I briefly looked at WfXml and my impression was that it too was more on the high level. ebXML specifically appeared to address 'inter' organizational collaboration, not 'intra' organizational operations.

    Does BPMI, WfXml, or ebXML address things at a lower level? Sending an email, making a SOAP call, inserting into a database, waiting for accounting to approve, etc.?

    In the end, is there some possibility of just using an XSL transform to make a script spec compliant? Or do these specifications impose a discipline that prevents an overly specific script from being converted?

    Please let me know.

    Gary
  6. It might be that Jelly could be useful as the engine to implement your declarative XML workflow scripts.

    http://jakarta.apache.org/commons/sandbox/jelly/

    Jelly supports pluggable tag libraries (in the JSP sense) such as the JSTL tag library for working with beans, XPath, XSLT, SQL. Jelly also supports the use of Ant tags in scripts which makes it useful for scripting tests.

    Jelly implements a simple declarative XML processing language (like XSLT) called JSL. Its on our todo list to add tag libraries to support STX and MSV too (as well as HTTP, SOAP and JMS tag libraries).

    New Jelly tags can be defined easily using Java code or Jelly script, making it ideal to script web service calls in a simple XML based macro language.

    In addition Jelly supports other scripting languages to be integrated like beanshell, jython and JavaScript.

    The OSWorkflow guys are considering using Jelly for their workflow scripts, maybe you could as well?

    James
  7. Nope,

    WfMc is a standars body on interfaces a workfow server
    should have, like server-server, server workflow input,
    etc etc.

    Keep in mind though none of the interfaces have been
    really ratified but its a nice model though.

    Sincere greetings,
    Leo de Blaauw

    ps: let me know if you need any help on parts of the
    development, architecture etc. I have been involved in
    building and deploying workflow tools since 1993.

  8. WfXML is more for interoperability. XPDL however is a meta model for process definitions, and a very powerful one at that. Essentially things like sending emails, making SOAP calls, etc. are defined as tools which are part of an atomic activity. Activities can also represent sub flows, loops and routes. The more I understand what the WfMC has done, the more I appreciate how they have solved some of the more common workflow problems. Considering that they have been doing this for quite some time I don't find it suprising.

    You can use XSL to transform XPDL to your internal model and this is even suggested in the XPDL definition document as one solution. However, I have found that actually implementing the model definition in Java has made implementing the engine much less painful.

    Sincerely,
    Anthony Eden
  9. Great!
    Finally.... workflow is really a very important aspect in many J2EE projects.

    Keep it up, this could be the beginning of something unique
    (I don't know of any other OpenSource-Workflow, that has this abitions, done in Java, XML, GUI, ...)

    Joerg Winter
  10. Open Business Engine is another open source workflow server which is written in Java, uses XML for the workflow definition, includes a GUI designer. I am currently reworking it completely so that it uses the WfMC's interface 1 (XPDL) and interface 4 (WfXML) definitions. Hopefully I will have the redesigned engine in the CVS within the next couple of days. The next step is to rework OBEDesigner to conform to XPDL as well.

    Another workflow which is written in Java and uses XML for the workflow definition is OSWorkflow.

    I am really blown away with the number of open source workflow engines which happened to appear at around the same time (I now count 3). In addition to the Open For Business workflow engine, I see this space as really starting to become interesting.

  11. This is a very interesting discussion. It really is amazing that so many Java workflow engines have popped up.

    I am one of the founders of the Open For Business Project, and we were pushing workflow for quite a while late last year and early this year. Our current Workflow Engine is partial WfMC/OMG implementation that runs XPDL files.

    It is a bit different than some of the other efforts mentioned here. We haven't really done any major work on a graphical workflow editor, and we still haven't done much on the workflow repository maintenance tools. Right now you mostly have to just edit the XPDL by hand.

    It would be really neat to do some collaboration, especially if we can all start going towards XPDL as the standard for a file format, or at least support interchanging/transforming files to/from XPDL. We have a decent engine that is well integrated with our other "engines" like the Service and Entity engines, but it would still be great to collaborate on improving the various engines and getting both design and run time support apps in place.

    Lately we have been working a lot on our ecommerce piece and supporting back office applications, so the Workflow Engine hasn't seen much attention in the last few months. We are getting really close to the 2.0 release, and after that we want to push workflow some more.

    One of the big parts of this will be to implement some applications like order and fulfillment management and content creation and publishing management. Andy, the other main OFBiz guy, has implemented one big workflow app for a client, but we haven't had a chance to get some good demo workflow apps into OFBiz yet, and doing so will help our engine mature a lot and be much more useful (and better documented...).

    I'm sure that we'll all check out the various Java workflow projects and have informal collaboration that way, but is anyone interested in a more formal collaboration?

    The next big step for Open For Business is to form a number of these collaborations with other open source projects so we can take advantage of what has been done and so that those who have put a lot of work into one component can see it running with a larger suite and can be involved with the increased abilities offered by the combination of the many pieces. We are looking at thing for content management, portals, point of sale, accounting, other ERP stuff, and so forth.

    Later,
    -David Jones
    The Open For Business Project
    www.ofbiz.org



  12. Anthony and David,

    Great input. The emergence of multiple open source workflows is a natural evolution more than anything else. It's kinda like how Newton and Leipzig innovated calculus as the same time, but in different ways (if we are delusional enough to compare this to the discovery of calculus).

    PowerFolder started after a commercial J2EE workflow product burned a company I did work for. The $300/hour consultant, the numerous unacceptable bugs, the missed deadlines - surely the marketplace deserved better!

    I made a point to not look at other projects until this release - to increase the innovation and respect the innovations of others. At this point though, at least some collaboration makes sense.

    Workflow is a big ocean with many fish. A number of Fortune 500 companies have workflow products. Workflow means different things to different people and one size does not fit all.

    Gary
  13. Leo,

    Great to hear. Please send your contact info to support at powerfolder dot org.

    Thanks,

    Gary
  14. Gary,

    Did send my contact details to your support email
    adres, but not a word yet ? I bet you guys are just
    very busy..

    Greetings,
    Leo de Blaauw
  15. XPDL<->PD4J<->BPEL[ Go to top ]

    Leo,

    I'm trying to use WLI 8.1 (that uses PD4J, JSR-207) in a project but would be nice to import/export XPDL files. Do you know of any tool?. Feedback will be welcome!

    regards,

    xavier
  16. Try ARIS IDSScheer[ Go to top ]

    Leo,I'm trying to use WLI 8.1 (that uses PD4J, JSR-207) in a project but would be nice to import/export XPDL files. Do you know of any tool?. Feedback will be welcome!regards,xavier
    Hey Xavier,

    I have not actually tried this, however I know that they can import XPDL and then export to JPD. Might be worth investigating if you already have a large investment in WfMC XPDLs.

    -john
  17. Hi all,

    I'm working on BPMS development project called Business Conductor(BC). Its currently in planning & design phase but implementation will follow shortly.
    Generally speaking Its neither direct competitor to OSWorkflow or PowerFolder (because BC is BPMS) nor to ofbiz(because its not business application itself. But in future I plan to provide process libraries and templates).

    David Jones wrote:

    >> Right now you mostly have to just edit the XPDL by hand

    Before WfMS will be widely adopted there should exist tools that will provide a handy interface to the WfMS. Writing XPDL processes by hand is like writing each DD yourself or programming with assembler(goto instead of func() and while{}).

    Anthony Eden wrote:

    >> You can use XSL to transform XPDL to your internal
    >> model and this is even suggested in the XPDL definition
    >> document as one solution. However, I have found that
    >> actually implementing the model definition
    >> in Java has made implementing the engine much
    >> less painful.

    BC uses its own language(GBPM) based on HLPN (High Level Petri Nets) with numerous extensions like explicit data modeling and transaction support(including LLTs). Its superior to XPDL (I even can proof it formally).
    I plan to use XPDL only for process export/import(that was its original purpose) but its obvious that during conversion from GBPM to XPDL there will be loss of some important information.
    Furthermore BC uses EJB as underlying custom activity implementation model and currently aimed at declarative (container managed) part of EJB spec. This prohibits activity implementer from manually managing some aspects like transactions but allows extended transaction models to be implemented declaratively.
    There is also predefined graphical language for GBPM. In fact GBPM is complete package of methodology, graphical language, declarative language(s) and (soon)tools.

    Some flaws in WPDL/XPDL(IMO) and possible justifications (again, IMO) just to show that XPDL is not suffitient as core BPMS language:
    Q: Why XPDL does not employ well understood process
       model like Petri Nets?
    A: Maybe because XPDL process model is similar to a free
       choice Petri Net and It looks simpler..but does it?
    Q: Why there are no transaction support in WPDL/XPDL?
    A: Maybe because it has more to collaboration
       (human oriented)than to EAI(machine oriented)..
       But even in collaboration I think there is need for
       transactions(LLTs).
    Q: Integration with J2EE/EJB?
    A: XPDL/WPDL is process interchange model and does not go
       into details about activity implementation and
       data modeling
       or any specific platform.
    Q: Why not to use different XML files to describe process
       definition, process deployment, etc. like
       it was done in EJB?
    A: Again, XPDL/WPDL is only process interchange model..
       every server will have its own PDD analog.

    I also do not prefer BPML way(even more Qs) but since its more to EAI and B2B it recognizes the need for LLTs. Thats a nice fact about BPML.

    I will be glad if anyone wishes to collaborate or join the project.

    Regards,
    Basil
  18. Well,

    Again i have been dealing a lot with workflow and have done substancial implementations of commercial workflow products.
    I have allways found that as far as a drawing idea the simple flow charting model works best to build your workflows en even in interactive sessions with end users, prototyping workflows on the fly with business people and end-users in one room. Later a refinement of the workflows and technical integrations can take place.

    Just my personal expierience but I would say keep it simple as far as your modelling is concerned.

    Sincere greetings,
    Leo de Blaauw
  19. Also,

    A previous poster is absolutely right in stating that to some email is workflow as to others its notes, staffware, or even BEA weblogic integrator.

    Keep in mind that all of these tools have a different aim
    and do cover different technologies and different types
    of workflow !

    i.e. structured vs unstructured processes, Ad-hoc vs production level workflow, interapplication workflows etc etc.

    Allthough i have to admit that lately a lot of workflow tools, commercially in the market, have grown towards eachother in the middle ware arena.

    Therefore supporting application to application flows and interaction, as well as human user exception handling with not much programming.

    Sincere greetings,
    Leo de Blaauw
  20. i visited the powerfolder website
    i found no links for download
    how do we evaluate the product

    -panandk
  21. Try http://sourceforge.net/projects/powerfolder
  22. You can download it from:
    http://sourceforge.net/projects/powerfolder
  23. It's JFolder now.[ Go to top ]

    PowerFolder has been renamed to JFolder and it has many more sophisticated new features. Ready to be used. Go to http://www.jfolder.com