Re: [werkflow-user] BPEL support

Hi Brian,

Thanks for this. I've made some comments below...

On 24 Feb 2004, at 04:14, Brian Topping wrote:
>
>> [...] 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 not sure we're talking about quite the same thing here. Although 
IBM's framework /can/ use JMS as a framework for controlling the 
workflow container (including starting processes etc), it also uses it 
internally to schedule the transitions between activities for 
macro-flows. This allows one process to run across many nodes (although 
usually, the EJB container's affinity will prefer each activity to run 
on the same node as the last). If the node fails for any reason, the 
process will forward recover on another node, since the message that 
triggered the last activity will be 'rolled back' onto the queue.

>> 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.

You're absolutely correct that Werkflow shouldn't be directly involved 
in this. However, as it stands, as far as I know, a process can't be 
failed over half way through. This is fine for processes that take a 
few seconds to execute and return a result, but if a process takes 
weeks or even months, this is a bit of a killer for the application I 
have in mind.

>> * 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.

Yeah, that's absolutely the kind of thing I'm thinking about. I'm not 
sure XMI will cover it directly, since BPEL doesn't map as directly 
onto UML as some of the other 'flow' based languages (IBM's FDML, etc). 
One thing that occurred to me is that if we could implement some kind 
of traceability between the 'core' workflow language and the 
personality, it might be possible to derive the current node in the 
personality workflow based on that traceability.

>> * Support development tooling ;)
> Would generation from UML work?

It certainly could (should), although there is a bit of a mismatch 
here. UML Activity Diagrams (with a few extensions for supporting 
compensation etc) map pretty well onto the 'flow' markup within BPEL. 
The more procedural constructs like 'sequence' 'choice' etc don't map 
so well onto UML. You could conceivably use sequence or collaboration 
diagrams, but the match would be much more approximate than for <flow>.

>> 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?

At the moment, I'm in the investigation stage of a project (i.e. budget 
has not yet been allocated). Should a decision be taken to proceed, 
then funds would be available to directly contribute, assuming you guys 
are open to this.

> 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.

Agreed. I'm trying to work out what changes would have to be make to 
Werkflow to support what I'm talking about here, to work out whether 
it's viable to modify Werkflow, or whether the concepts are just too 
different. Right now, my instinct says Werkflow provides a good 
framework to build on, but that there might be quite a lot of work to 
do to make it do all the things I'm looking for.

> 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?

Certainly. Happy to help in any way I can. I'm about to send a separate 
e-mail outlining one of the things I've been thinking about in more 
detail. I'd welcome feedback, comments and common sense!!

Paul
-- 
Paul Russell
[email protected]