On Oct 26, 2004, at 3:27 AM, Matthieu Riou wrote:
Very practically, what is the conclusion of this discussion ? :)
Not sure if one is required. I don't think solving the TLP problem is a good idea now because we're going to learn a lot more as time goes on. I'm optimistic that we'll go that way at the end, but lets decide that later. If we have enough size and strength to be a TLP, we do it. If not, we don't. Until then, lets try and build some really great software and a great community.
I do think that working to have BPEL implementation at the ASF is a great idea, and while I'm 100% committed to seeing it a part of Agila, it doesn't have to only be in Agila. For example, we could have a BPEL engine as part of the project that can be used standalone or inside Agila.
I've been staring at the BPEL spec, on and off, and I have to admit, I just don't grok it beyond the fundamental motivation to define processes. My major stumbling point is why this was done in XML. I'll start another thread so we can have a technical discussion. I'll do my best to get the mail lists setup so we can have the discussion there, rather than here on the general list.
geir
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]
-- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
