i think there is a clear need *now* for apache-licensed BPEL specific engine (there is more than one LGPLed)
moreover building a complete BPEL engine is challenge enough - this observation is based on my own experience building BPEL-like engine but i think Mathieu and Sanjiva may agree based on their experience?
it seems to me that building BPEL engine on top of another workflow execution model (mappings!) that has no web services support looks like a very large task so the question really is: what is expected timeline?
should apache have BPEL engine implementation now or next year (or later...)?
just my .02c
thanks,
alek
Paul Russell wrote:
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:
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 :).
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 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.
Geir, is the plan for Agila to go for a new TLP after incubation or go to one of the existing projects?
Right now, the Jakarta PMC has voted to accept us once we complete incubation.
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
-- The best way to predict the future is to invent it - Alan Kay
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
