The 2.0 final version of the open source workflow engine Enhydra Shark is released. Enhydra Shark is a flexible and extensible WfMC and OMG Workflow Management Facility compliant embeddable Java Workflow Engine. As its native workflow process definition format Enhydra Shark uses WfMC-XPDL (XML Process Definition Language) without proprietary extensions. XPDL process definitions can easily be created using the included graphical workflow editor (Enhydra JaWE). For execution of serverside system activities the WfMC Tool Agents API is supported. Many standard toolagents for common tasks are included. Every single component (persistence layer, assignment manager, etc.) can be used with its default implementation or extended/replaced by project specific modules. This way Enhydra Shark can be used as a simple "Java library" in servlet or swing applications or running in a J2EE container supporting a session beans API, Corba ORB or accessed as a web service. Distribution package includes an advanced Swing administration client and a web based worklist and administration client applications for managing workflows. Enhydra Shark has well defined client interface and well defined interfaces for plug-in components. In contrast to many other solutions on the market Enhydra Shark gives you the freedom to define your own GUI and to integrate existing system's components of YOUR environment! The project is hosted on ObjectWeb, it has a large community, very active mailing list and it is highly rated on ObjectWeb. For the professional users, commercial version called Together Workflow Server is now available. You can test it by downloading demo version from http://www.together.at/together/prod/tws/twsdemo/index.html Website: http://shark.objectweb.org/ ObjectWeb Project: http://forge.objectweb.org/projects/shark/

Is 'dfdsf dsfds' your intended nick?

Congratulations on the release! As a user of Shark (embedded in a larger application), I like the very modular and configurable architecture. However, it would be highly beneficial if the rather complex set of dependencies could be managed through Maven.

One more workflow engine? lol What benifits it provides over other workflow, like JBPM, or OSworkflow. sudhir http://www.jyog.com

One more workflow engine? lol
What benifits it provides over other workflow, like JBPM, or OSworkflow.

sudhir
http://www.jyog.com

JBPM and OSworkflow seems to be too much J2EE/SOAP oriented, while Shark can be used wherever you want: J2SE app, embedded in webapps, as a CORBA server (not yet in 2.0). You can easily write you custom code to perform extra operations related to WF actions. I could agree on LOL if it was YAWDF (yet another web development framework) but here it seems to be rather inappropriate. Guido.

"JBPM and OSworkflow seems to be too much J2EE/SOAP oriented, while Shark can be used wherever you want: J2SE app, embedded in webapps" jBPM is totally decoupled from SOAP;it's just a jar. You can place it in a webapp or a command line program.

JBPM and OSworkflow seems to be too much J2EE/SOAP oriented, while Shark can be used wherever you want

Just a correction for OSWorkflow. OSWorkflow is completely independent from J2EE and SOAP, and we can use it as a FSM library in any java application. It's very clean and has simple implementation in both Java and database table, that's why it's robust and we can create and support workflow very easily. Spring integration is a bonus.

One more workflow engine? lol
What benifits it provides over other workflow, like JBPM, or OSworkflow.

sudhir
http://www.jyog.com

JBPM and OSworkflow seems to be too much J2EE/SOAP oriented, while Shark can be used wherever you want: J2SE app, embedded in webapps, as a CORBA server (not yet in 2.0).
You can easily write you custom code to perform extra operations related to WF actions.
I could agree on LOL if it was YAWDF (yet another web development framework) but here it seems to be rather inappropriate.

Guido.

Tht LOL was nt to hurt any one. What i wanted to say is. why to reinvent a square wheel? Just improve d existing one like JBPM.

One more workflow engine? lol
target="_blank">http://www.jyog.com

As you can see by the "2.0", Shark is not a new workflow engine.

One more workflow engine? lol
What benifits it provides over other workflow, like JBPM, or OSworkflow.

sudhir
http://www.jyog.com

Before you post, you might actually want to look around. Enhydra has been around for quite a while.

As advertised Enhydra Shark is an XPDL implementation without proprietary extensions. Given this, and studies such as the one written up here: http://is.tm.tue.nl/research/patterns/download/ce-xpdl.v it seems as though XPDL itself is quite weak in the workflow pattern support: only 11 out of the initial 20 are suitably implemented with 3 of them either uncertain or with restriction. What good is the XPDL "standard" if it can't map to an arbitrary business process adequately? If your organization adopts XPDL, how can you convince the higher ups that you aren't being locked into a poor solution which might not be suitable for future workflow oriented applications? Then again, it seems as though many competing products and standards are just as poor. What does everybody else think? Any workflow experts here that have researched the issue or developers who've worked with more than one implementation here? Please comment.

I botched the link in my previous post. Here is the correct one: http://is.tm.tue.nl/research/patterns/download/ce-xpdl.pdf

As advertised Enhydra Shark is an XPDL implementation without proprietary extensions. Given this, and studies such as the one written up here:

http://is.tm.tue.nl/research/patterns/download/ce-xpdl.v

it seems as though XPDL itself is quite weak in the workflow pattern support: only 11 out of the initial 20 are suitably implemented with 3 of them either uncertain or with restriction.

What good is the XPDL "standard" if it can't map to an arbitrary business process adequately? If your organization adopts XPDL, how can you convince the higher ups that you aren't being locked into a poor solution which might not be suitable for future workflow oriented applications?

workflow patterns have given a bit the wrong impression, imo. like one process language being better then another. much more difference between the process languages is the targetted features, functions and the environment. if the goal is to orchestrate web services on an ESB (like e.g. BPEL), you'll end up with a whole different process language then when you're targetting task management for people in a POJO Java environment (like e.g. jPDL).

Then again, it seems as though many competing products and standards are just as poor. What does everybody else think? Any workflow experts here that have researched the issue or developers who've worked with more than one implementation here? Please comment.

Don't expect any convergence in process languages. On the contrary. I get request for specific graph based execution Domain Specific Languages (DSL) on a weekly basis. The Process Virtual Machine describes what kind of process languages can be build on one set of concepts. On the engines and implementations, that is where I do see a consolidation period approaching. Currently most engines only support 1 language (i mean natively, not through import and export). And one language can only suit a small part of workflow/BPM/orchestration. That is why the market is so fragmented and many engines come and go. Apart from us, I only know of one other workflow technology (Windows WF) that has a decent solution for running multiple process languages natively.

Given this, and studies such as the one written up here:

http://is.tm.tue.nl/research/patterns/download/ce-xpdl.v

it seems as though XPDL itself is quite weak in the workflow pattern support: only 11 out of the initial 20 are suitably implemented with 3 of them either uncertain or with restriction.

What good is the XPDL "standard" if it can't map to an arbitrary business process adequately?

Good point that deserves two different answers: - From a workflow patterns prespective (taking as a reference the workflow patterns study from Van der Halst) XPDL can not address all those patterns directly because of its nature. As workflow patterns concerns the execution behaviour, there are a lot of issues more related to how a particular workflow engine "executes" an XPDL process definition. I agree that there are some missing pieces in XPDL (specially in the version 1.0) when defining a workflow process (i.e how to "define" that an activity must be executed by multiple users before go to the next one). However, with minor XPDL extentions (extended attributes) and a good engine implementation you can address most of those patterns in a proper manner. I suggest you to take a look to the Workflow Patterns review for the Bonita engine (http://is.tm.tue.nl/research/patterns/download/bonita_patterns.pdf) - My second answer is, do we really need a process language that covers all the workflow patterns and which can be used in every situation ? not sure. In fact, this has been the traditional approach in the Workflow and BPM world: let's first choose our process language (XPDL, BPEL...) then, let's build an engine that support it and final step let's build as much as extentions we need to fit in every process related use case :-) I'm more for using the language that better fit in each situation and even combine languages when addressing complex applications (i.e XPDL and BPEL can be used together in multiple uses cases). This is the reason why we decided to work on a new kind of Workflow and BPM engines/solutions that can leverage multiple languages implementations natively. Those concepts are explained in details in the following article (http://www.onjava.com/pub/a/onjava/2007/05/07/the-process-virtual-machine.html) and relates with a new concept that we call the Process Virtual Machine. regards, Miguel Valdes

"I'm more for using the language that better fit in each situation and even combine languages when addressing complex applications (i.e XPDL and BPEL can be used together in multiple uses cases)." The language that best fits a particular application is usually a custom workflow implementation just for that application since it will suit all of the requirements and not be any more complex that it needs to be. The only true competitor to this is a workflow solution that provides enough value to overcome its inherent complexity. This value includes supporting whatever business process you can throw at it, good administration tools, awesome documentation, support, etc. Otherwise with a "combine languages" situation, you just have enterprisey horribleness that developers spit in disgust at since it honestly isn't helping them do their jobs any better, which ultimately harms the business they're working for.

"The language that best fits a particular application is usually a custom workflow implementation just for that application since it will suit all of the requirements and not be any more complex that it needs to be. The only true competitor to this is a workflow solution that provides enough value to overcome its inherent complexity. This value includes supporting whatever business process you can throw at it, good administration tools, awesome documentation, support, etc. Otherwise with a "combine languages" situation, you just have enterprisey horribleness that developers spit in disgust at since it honestly isn't helping them do their jobs any better, which ultimately harms the business they're working for.

This discussion is becoming more and more interesting :-)
I completely agree that process language to fit the best a particular application requirement would be the one that was developed "thinking" on this particular requirement (for sure, related tools must also follow). BTW, this is one of the points we are highlighting with the "Process Virtual Machine" technology. With this approach you can always develop your own language on top of this common technology to better fit your requirements (i.e a dedicated language to handle document validation processes in a CMS application would be certainly more appropiate than use XPDL) However, in some situations, I still convinced that you can leverage multiple languages in a same application (i.e a language to handle pageflow execution can integrate pretty well with a human workflow language like XPDL). Again I see that happening, in a natural way, if there is a common technology behind those languages. Anyway, the most important thing I see is to let the choice to the developers and analyst about the language/s they want to use in a particular application and even to let them develop a new one that perfectly fit with their needs. best regards, Miguel Valdes

What amazes me is the quality of experience in developing software is so vastly different between smaller bpm's like jbpm and shark and big bpm's stellent and filenet. I'd love to hear a representative of Filenet, now part of IBM, explain the advantages of Filenet over jBPM. For me, working with Filenet was like trying to develop a website on a mainframe; everything was tied together, like a son of 10 mothers; it was big and clunky and a horrible experience. I'd rather develop with shark, jbpm or openwfe anyday.

Having worked with a variety of commercial & open source BPM/Workflow engines for our solutions - it is pretty clear that maximum productivity is attained by decoupling the process & content tiers. It's the reason why FileNET & Documentum BPM suites are so frustrating to work with. They couple every component in their stack so tightly that it leaves implementers with very little space to customize an experience to the customer's demands. For small processes - they are excellent at weaving together a couple of forms and moving them across a few approval sequences. It gets tricky when there are multiple data integration points, complex process routing & heavy payloads to transfer from one activity to the next. Deeply integrated stacks tend to always remind you that you are using an off-the-shelf solution and not something that truly reflects the needs of the customer. So we generally end up using the FileNET & Documentum stacks at the content tier (where they excel) and use a dedicated process execution tier on top. We've had some encouraging success using IBM's Process Server on the commercial side coupled with a leading content repository. Fujitsu Interstage, AquaLogicBPM (formerly Fuego) are good - along with jBPM & Intalio. Cheers,
Zubin Wadia
ImageWork Technologies
"Business Acceleration Through Process Automation"

Having worked with a variety of commercial & open source BPM/Workflow engines for our solutions - it is pretty clear that maximum productivity is attained by decoupling the process & content tiers.
It's the reason why FileNET & Documentum BPM suites are so frustrating to work with. They couple every component in their stack so tightly that it leaves implementers with very little space to customize an experience to the customer's demands.

Plain wrong. It is not coupling but integration issue. As concerns FileNet P8, BPM and CM layers are not coupled - they just integrated. Such an integration is a natural thing that adopter of the ECM platform expects from the vendor. No one wants to spend resources on making pieces of a single ECM platform work together. FileNet's BPM and CM suites are integrated - and that's a good thing. Another issue arises here - the integration with third-party systems. FileNet traditionally has a weak point here, since its BPM product has grown from workflow engine in contrast to integration-centric BPM products from IBM, TIBCO or Oracle. This very thing harms FileNet BPM customization; it is not coupling between BPM and CM.

For small processes - they are excellent at weaving together a couple of forms and moving them across a few approval sequences. It gets tricky when there are multiple data integration points, complex process routing & heavy payloads to transfer from one activity to the next.

That's right. But as I stated above, it has nothing to do with BMP/CM coupling.

So we generally end up using the FileNET & Documentum stacks at the content tier (where they excel) and use a dedicated process execution tier on top.

We've had some encouraging success using IBM's Process Server on the commercial side coupled with a leading content repository. Fujitsu Interstage, AquaLogicBPM (formerly Fuego) are good - along with jBPM & Intalio.

A valid option, but could you bring some details on the performance of these BPM products? We had a frustrating experience with jBPM in this regard. jBPM is far behind FileNet Process Engine when it comes to the high workload. FileNet Process Engine was designed to meet high performance standards - and it does!

Don't make me laugh - jBPM simply sucks comparing to FileNet Process Engine. Staring from the range of features and ending with horrible performance.

The following report might be of interest for people interested in a comparison between Enhydra Shark, jBPM and openWFE: http://is.tm.tue.nl/staff/wvdaalst/BPMcenter/reports/2007/BPM-07-12.pdf marlon