Shark is an extendable workflow engine framework including a standard implementation completely based on WfMC and OMG specifications using XPDL (without any proprietary extensions !) as its native workflow process definition format and the WfMC "ToolAgents" API for serverside execution of system activities.

The project is hosted on ObjectWeb, it has a large community, very active mailing list and it is highly rated on ObjectWeb.

The XPDL definitions executed by shark can be created using our graphical XPDL editor Enhydra JaWE

Website: http://shark.objectweb.org/
ObjectWeb Project: http://forge.objectweb.org/projects/shark/

Shark is an extendable workflow engine framework including a standard implementation completely based on WfMC and OMG specifications using XPDL (without any proprietary extensions !) as its native workflow process definition format and the WfMC "ToolAgents" API for serverside execution of system activities.The project is hosted on ObjectWeb, it has a large community, very active mailing list and it is highly rated on ObjectWeb.The XPDL definitions executed by shark can be created using our graphical XPDL editor Enhydra JaWEWebsite: http://shark.objectweb.org/ObjectWeb Project: http://forge.objectweb.org/projects/shark/

I have no idea what this means, but I am sure I will need to know soon as no doubt my manager will ask me to convert everything to shark tomorrow! With all those buzzwords, how could we pass up this opprotunity?

XPDL is the XML Process Description Language, and it is specifically an XML specification for the exchange of workflow process definitions between different engines, modeling environments, and simulation environments.

Compared to Java Business Process Management (http://jbpm.org) and other open source workflow engine, what is advantage and disadvantage of Shark?

Hi,
I downloaded and installed shark 1.0 successfully. I created a simple xpdl file but i dont know how i deploy this xpdl file and make workflow page by using jsp or servlet. Coluld you send examples about usage of sahek with jsp or servlet ?
Sincrely
Ercan YURT

Hi there,

I think i may be trying to do the same as you, basically making a simple .xpdl file in Jawe and loading this file in Shark using the API.

Now

1. I am trying to map the Users to Particiapnts but seem to be having a problem,

2. I also am having some problems running shark on Tomcat.

If you have any advice on any of this or if you feel like sharing the problems that i may face in the future can you let me know, Thanks

Too bad there ain't no de-facto standard in Workflow Management.
That's what XPDL is supposed to be but Bea and IBM pick their own by driving forward BPEL: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel

That makes interoperability so bad that one just doesn't know which horse to put a bet on.

Yet, Shark looks really cool and hey, it's OpenSource :)

I would argue that XPDL and BPEL have very different target problems. XPDL is for representing workflow processes (as defined by the WfMC), and BPEL is for web services orchestration (creating a new service out of existing services). The question is whether it makes more sense to model a given problem in terms of workflow constructs or in terms of message-passing among services.

(btw, I would also argue that XPDL is beyond de-facto in workflow management, it is the standard by de-finition.)

<quote>
The question is whether it makes more sense to model a given problem in terms of workflow constructs or in terms of message-passing among services
</quote>

the two approaches are different but there is a communality in the problems they try to solve. the thing in common between the workflow approach and the process execution languages is state management. both type of systems need to maintain a context between related events. there is no construct for state management in plain programming so we need an extension. i think it makes much more sense to take state management as the target problem domain for both type of systems and consider it in isolation of other responsibilities.

in my opinion, bpel tries to combine too many solutions into one rigid spec : state management, web-service API, correlation mgmt, process context management, persistence... state management is somewhat hidden in the bpel spec (receive and pick), but its there. so when our insights advance on how we can best model state into an application, i think the bpel standard will have a hard time.

one of the other problems with bpel is that it duplicates plain programming constructs. this originates from the idea that you have to write a piece of programming logic (in XML!) that specifies the systems behaviour when a message comes in. i think the java community has spent a lot of time in creating a fine programming language. why can't we use java for that ?

regards, tom.
http://jbpm.org

sorry if this post was almost out of topic. but i'll make it up : congrats to the enhydra team :-)

Standards are important, however, which is where something like Shark/JAWE comes in, IMHO. If worse comes to worse with the Shark codebase at some point in the future, then the XPDL artifacts can be readily moved to another runtime (and design) environment for re-use with a modicum of modification. The same cannot be said of a proprietary artifact, whether or not the platform is open source.

i think the java community has spent a lot of time in creating a fine programming language. why can't we use java for that ?

Maybe because the anslysts that will use BPEL for a business process / workflow description don't care about Java?

And while we're still at it, why not drop Web Services and XML altogether when we have Java?

These are the same guys who had an open source app server that everyone was contributing to until... THEY PULLED THE CODE BACK and went closed source!

I remember jumping off to JBoss when that happened. Anyone else remember that?

<quote>
These are the same guys who had an open source app server that everyone was contributing to until... THEY PULLED THE CODE BACK and went closed source!
</quote>

You can never pull the code back in Open Source :-) What you can do is just to stop the activity and continue from the code base to build your own closed source version (in some of the Open Source license types like Apache: Do whatever you want with that code).

It was the time of Lutris with Enhydra Enterprise (J2EE license, Lutris has its own license type - EPL Enhydra Public License). It was 4 or 5 years ago, I still remember since I wrote some articles about this stuff for the German JavaMagazin. (Gee, I think I've been too long in this area ;-))

This won't happen now since all the Enhydra projects (Enhydra Server, Shark, etc. see http:://www.enhydra.org) use LGPL for their licenses (just the same as JBoss). Thanks to Together (Alfred and the team http://www.together.at) who bought all the licenses from the old Lutris... Enhydra projects are now managed under the ObjectWeb consortium (http://www.objectweb.org).

<quote>
I remember jumping off to JBoss when that happened. Anyone else remember that?
</quote>

You could not jump from from Enhydra (at that moment it was from Lutris) to JBoss, since Enhydra was only an extended servlet container and JBoss already an EJB container ;-). Enhydra Enterprise should be the counterpart of JBoss + Tomcat but it was never finished - only in beta version or so - because Lutris was out of business. Enhydra Enterprise should use JOnAS as an EJB container.

But now Enhydra Enterprise will be reality, since the next generation of Enhydra 6.x will have 2 versions:
- Enhydra Light, which will just the same as today. Servlet container with XMLC presentation layer, POJO business layer, DODS OR/Mapper data layer and Kelp IDE for Eclipse, NetBeans, etc. development.
- Enhydra Enterprise, which will plug JOnAS as a J2EE container, so Enhydra Light + J2EE container.
They are now in the 1. beta test.

So, don't worry, you can use Enhydra Shark and be happy! And congrats to the Enhydra Shark team for the new release!

Hope this helps!
Lofi.
www.openuss.org
ejosa.sourceforge.net

These are the same guys who had an open source app server that everyone was contributing to until... THEY PULLED THE CODE BACK and went closed source!I remember jumping off to JBoss when that happened. Anyone else remember that?

Come on. This sounds like plain old "fear, uncertainty & doubt", curiously related to "jumping off to JBoss" in addition. We don't need this same ol', same ol' here any more again...

As explained by Lofi, these components (Shark & JaWE) are ObjectWeb projects licensed in LGPL. Actually, the Enhydra story is an example of open-source successfully increasing projects lifespan!

These are the same guys who had an open source app server that everyone was contributing to until... THEY PULLED THE CODE BACK and went closed source!I remember jumping off to JBoss when that happened. Anyone else remember that?

Come on. This sounds like plain old "fear, uncertainty & doubt", curiously related to "jumping off to JBoss" in addition. We don't need this same ol', same ol' here any more again...As explained by Lofi, these components (Shark & JaWE) are ObjectWeb projects licensed in LGPL. Actually, the Enhydra story is an example of open-source successfully increasing projects lifespan!

Oops. I should have known not to method JBoss around here. I am not Mark Fluery...

I was not trying to spead FUD. I just remeber the outrage when it happened. I should have thought more about the LGPL and the EPL license they used at the time.

Glad to see some redemption.