Very practically, what is the conclusion of this discussion ? :) Matthieu.
On Sat, 23 Oct 2004 10:59:17 -0500, Aleksander Slominski <[EMAIL PROTECTED]> wrote: > i agree that TLP is very important and very good for visibility that > apache has now place for workflows but i look on it more like umbrella > TLP with many subprojects? the reason for this is that i have a > different opinion about BPEL. > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
