Guys,
On 22 Oct 2004, at 02:13, Geir Magnusson Jr wrote:
On Oct 21, 2004, at 4:20 PM, Sanjiva Weerawarana wrote:"Geir Magnusson Jr" <[EMAIL PROTECTED]> writes:Yah, well, I've been clear that I don't know much :) so I'm doing a bit more homework. I'll come back and apologize if I'm wrong, or else clearly explain what I think it's missing.I think that bringing the two concepts together - workflow and WS orchestration - would be a great goal :)So as a co-author of BPEL I have to say that that was indeed one of our objectives .. clearly we have failed at least by you :).
I must confess, I've always had the impression that BPEL is /capable/ of participating in full BPM, but that it is only a /part/ of the solution. Gier: I'd be very interested to know what your perception of what's missing is -- it's funny, every time I talk to people about BPM/workflow, I get a different definition of what's in and what's out of scope ;) My perception is that BPEL is capable of handling everything except human interaction, but I treat (and so do IBM, as it happens) human interactions as 'just another ASYNC service call', so BPEL fits nicely into BPM provided you provide a staff resolution architecture (who can do this task?) and an interface to allow tasks to be allocated to people and processed etc.
That said, while I believe that BPEL is capable of acting as the 'core' of a BPM project, I'm all for a layered architecture. I've not had a chance to look at Agila yet, but I'm assuming it's based on petri-nets or similar, so it should be perfectly possible to implement BPEL over the top of this (hopefully by merging in Twister, but replacing its execution core with Agila), and this gives us the opportunity to implement other BPM/orchestration languages in the future when this becomes desirable.
So maybe the idea of a separate effort for BPEL is not a bad idea. Dims, what do you think?
Personally, i would prefer the solutions to be merged -- my view is that they'll have such crossover functionally, it wouldn't make sense to treat them separately.
Right now, the Jakarta PMC has voted to accept us once we complete incubation.Geir, is the plan for Agila to go for a new TLP after incubation or go to one of the existing projects?
However, I think that this would be a stronger community and better software stack if we could bring all together into one project, and then apply for TLP. I'd really like to see Agila include BPEL, and make it such that a pure BPEL workflow is just an agila workflow w/o non-BPEL activities, if you get what I mean. Make it so that people who just want to write/use BPEL, people who want to mix, and people who don't want BPEL can all use the same thing. There's lots of commonality - with a full system, we'll all need the reporting, logging, administration, etc, and no need to duplicate...
I'm /so/ +1 for this (the TLP bit -- you /know/ I'm +1 the rest of it too!) it's making me late for work! My day job involves working for a large enterprise (the largest insurer in the UK). To large organisations like that, visibility is everything, and they would want to see that workflow is being taken very seriously by Apache before buying in (I know this is a bit of a stupid attitude, but such is the way with large companies). To give you an idea of how seriously /we/ take workflow, we currently spend several million pounds a year maintaining our own workflow system (developed before the rest of the world 'did' workflow). As you can imagine, we're currently looking to replace this. Right now, the likely candidates are commercial, but it'd be nice to have an alternative.
The other reason I'm for a TLP is that I can see a number of other projects that might spring up around this (an Agila plug-in for Eclipse, for example?), and it seems more cohesive to host these all under one well-focused TLP.
As ever, just my $0.10.
Paul -- Paul Russell E-mail: [EMAIL PROTECTED] iChat/AIM: [EMAIL PROTECTED]
smime.p7s
Description: S/MIME cryptographic signature
