On 13/01/07, 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?
I'm not seeing a great deal of other solutions out there right now for async. Doing a quick 6 step BPEL that co-ordinates 3 async points isn't complex from the _developers_ perspective. BPEL only gets complex when people start using it for things that it shouldn't do. So far that has been trying to do rules processing in BPEL rather than the distributed process challenges (which are much rarer). > > > > > 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. You and me both, I'd like to have seen them concentrate on modelling abstractions for SOA at the business level. > 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. BPMN I'll give you, but UML to model _business_ process isn't something I'd like to walk through with business people. So while you do have to use proprietary extensions right now this is exactly the same as the early days of Java where each IDE, App Server Vendor, framework required you to use their extensions. Over time the successful extensions were rolled back into the standards. Neither BPEL nor BPMN are 100% there yet, but that doesn't mean we should start from scratch. > So these standards are valuable. > Unfortunately, BPEL cannot express the richness of the modeling > notations. But BPEL isn't a modelling notation its an execution language, I see it as the JVM to BPMN as Java. Standardisation of both pieces is required but there isn't anything that says they have to be _one_ thing. BPEL can suck, but I have seen successful projects using it and right now the alternative is to roll your own which is rarely a good idea unless you've got some of the people on this list working for you. > Therefore it fails to meet the basic requirements of a > XML-based model exchange language (as in XMI). And of course the interesting thing here is that in reality for SOA none of these really help anyway as BPMN relegates service to a secondary position and decides that process is the way forwards. For the state and rules based approach to work you will need a way of describing service first and then describing motivations for interactions, this means that the notation needs to deal with abstractions of interaction rather than ordering of steps, which is what both BPEL and BPMN do. BPEL and BPMN are 21st Century Visual Cobol, good for some implementations but a poor way to model and build a successful enterprise. > > 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 > > > > 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/
