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 > > > 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 > > > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
