--- In [email protected], "Anne Thomas Manes" <[EMAIL PROTECTED]> wrote: > > On 1/13/07, Steve Jones <[EMAIL PROTECTED]> wrote: > > Which is fine for certain elements, but there is another scenario and > > that is where an application is calling a bunch of things in a similar > > manner to straight Java code and where BPEL is a more sensible > > _programming_ language than Java, for instance if there is quite a bit > > of async. > > But do we really need something as complex as BPEL to do this type of > simple app? > > > > > That is where I've tended to see BPEL used very successfully. Surely > > the question here on the various different solutions is what works for > > a given scenario, elements such as non-repudiation and debugging are > > going to become more tricky in a rules/state scenario I would expect > > which may be justifiable for certain project areas but not for others, > > the other challenge is that of tooling and product support. While > > there might be architecturally more elegant answers these are pretty > > mute until their is the tooling and support to make those choices > > economically feasible for the majority. > > I totally agree. The majority requires product implementations. I just > wish that the vendors had invested their effort into something a bit > different. As you say, BPEL works pretty well for simple apps, but as > soon as you try to do something a bit more complicated, you get into > proprietary extensions. So why even bother with BPEL? I don't really > see that the BPEL standard adds any value. You use a modeling tool to > define the process, and for the most part people use either BPMN or > UML as the modeling notation. So these standards are valuable. > Unfortunately, BPEL cannot express the richness of the modeling > notations. Therefore it fails to meet the basic requirements of a > XML-based model exchange language (as in XMI). > > Anne
So, Anne, what sort of features would you like to see in a replacement of BPEL? Gervas > > > > > > > On 13/01/07, Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > > > Not really. Orchestration and choreography are different. > > > Orchestration defines a process, while choreography defines an > > > interaction between two or more parties. > > > > > > My preferred approach to orchestration is one based on state and rules > > > versus an execution plan. e.g., "Given the current state, what should > > > happen next?" versus "This step just completed (or failed to > > > complete), so this is supposed to happen next." > > > > > > A state/rules-based system has no requirement for a centralized engine > > > to manage the process. > > > > > > Anne > > > > > > On 1/12/07, Stefan Tilkov <[EMAIL PROTECTED]> wrote: > > > > So Anne, would it be fair to say that you think "orchestration" is > > > > fundamentally flawed, and only "choreography" is useful? > > > > > > > > Stefan > > > > -- > > > > Stefan Tilkov, http://www.innoq.com/blog/st/ > > > > > > > > > > > > On Jan 12, 2007, at 4:03 PM, John Evdemon wrote: > > > > > BPEL is an orchestration language you seem to be describing > > > > > choreography. > > > > > > > > > > > > > > > From: [email protected] > > > > > [mailto:[EMAIL PROTECTED] On Behalf > > > > > Of Anne Thomas Manes > > > > > Sent: Thursday, January 11, 2007 4:57 PM > > > > > To: [email protected] > > > > > Subject: Re: [service-orientated-architecture] Re: Forrester Create > > > > > a Long Acronym > > > > > > > > > > I think BPEL is fundamentally flawed. > > > > > > > > > > > > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > > Yahoo! Groups Links > > > > > > > > >
