RE: [werkflow-user] BPEL support

Hi Paul,

I'm in the same boat with you, but I've gone a bit further down the path
understanding the system.  I'll take a stab at answering your questions,
hopefully someone can correct me where I get it wrong.

> I was pondering trying to start up an open source project (probably 
> apache licensed) to build an open source implementation of a BPEL 
> engine, and tools. A friend of mine kindly pointed me towards 
> Werkflow 
> as something playing in this space. I have to say, it takes 
> an approach 
> I've not seen before, which is refreshing: I come from a websphere 
> process choreographer background, which works using database-based 
> persistence to store state, and JMS + Message Driven Beans to provide 
> activity scheduling and dispatch - I was kind of /assuming/ a similar 
> architecture for implementing BPEL.

Wrapping Werkflow with this functionality should not be difficult.
Repository interfaces exist inside the system, so it's really just a matter
of extending your persistence mechanism to include them on the back end.
Adding the MDB transport on the front end should be a couple dozen lines of
code.

> I'm currently trying to understand the Werkflow architecture in this 
> context. Process Choreographer implicitly supports clustering, for 
> example, because of its use of messaging to dispatch activities. I'm 
> trying to get to the bottom of how Werkflow might achieve the same 
> thing.

If things were wrapped in MDB, you are correct that clustering would be taken
care of.

> I guess what I'm trying to assess is how far off being 
> production ready 
> for werkflow is, both in a generic sense and in a BPEL sense. So for 
> example, for me to consider this production ready, I'd expect it to:
> 
> * Support running in a multi-node environment
> 	* At least with High Availability.
> 	* Preferably with load balancing and high availability.

This probably depends more on your container than Werkflow.  If you had a set
of routines that you wanted to do this, how would you do it?  Werkflow just
provides the entry points for you to call.  It's very independent of
container, so you don't have to worry about all the headaches of the engine
playing with the container state.  

> * Support Compensation (although I /think/ this could be achieved by 
> including it in the appropriate personality.

Not sure...

> * Support graphical debugging through development tooling.

This is one that I am particularly interested in myself.  It's not there yet.
I'm looking at generating my source files from XMI, and I could imagine that
there would be a way to have a fat client that could graphically trace the
UML that was in the XMI.  I have some ideas here, but I don't really
understand what ought to happen because I've never seen a commercial workflow
engine in operation.

> * Support development tooling ;)

Would generation from UML work?

> Do you guys have any thoughts as to whether these are things you were 
> expecting to support as part of werkflow? If so, do you have 
> a road map 
> to get there? I'm quite willing to help if you can point me in the 
> right direction!

I can't speak for the rest of the team, but I am working on these as a part
of my project.  It's just a matter of time.  But that still doesn't answer
your question.  Do you have the resources to help with this or are you
needing something that is more complete from the outset?  

I'm personally not that impressed by the other solutions out there, and feel
like I'd rather invest in Werkflow than try to fix what's broken in the
backend on the other tools. 

If/when I attack this, it will probably be as I described above.  It would be
great to have you help with rough text or graphic descriptions of what you
are looking for.  Can you provide some ideas?

-b

> 
> Thanks in advance,
> 
> 
> Paul
> -- 
> Paul Russell
> [email protected]
> 
> _______________________________________________
> werkflow-user mailing list
> [email protected]
> http://lists.codehaus.org/mailman/listinfo/werkflow-user
>