[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm-ra] FW: issue 224 and previous proposal
|
On the orchestration/choreography question, take a look at my notes covering message, action and activity. I think we can pull relevant elements from that to
answer the question. Peter F Brown Independent Consultant P.O. Box 49719, Los Angeles, CA 90049, USA Tel: +1.310.694.2278 From: soa-rm-ra@lists.oasis-open.org
[mailto:soa-rm-ra@lists.oasis-open.org] On Behalf Of Ken Laskey I agree with Rex in that
1.
We should not be defined by WS-CDL; and
2.
We should be careful about muddying definitions. I like Rex’s choreography as “mediated by choices made by active participants according to agreed
upon rules; e.g. people, though bots could handle transactions up to the point where their programming fails to anticipate some choice, and choices can't then be made.”
In essence, if you send me Message X, I’ve agreed to do (e.g. generate real world effects) A, B, and C. As part of this, I may send messages to other parties as I feel are needed. Neither you nor anyone else tells me what other messages I will send; this
is my decision made as I feel necessary at the time to provide A, B, and C. I interpret Rex’s “automated” when defining orchestration as someone initiates a defined process (which may include branching)
and that process is executed by some controlling entity. That controlling entity may be between all the services that take part in the process, i.e. it not only acts as a controller but also as an intermediary. This predetermined intermediary/controller
is typically not part of a choreography. Now to Boris’ points that choreography is the message exchange and orchestration is the sequence of activities, I feel
this generates more confusion. I agree with Boris’ remarks during the last call that orchestration and choreography are different aspects of the same thing; as you go through a complex process you can see the distinctions blending into each other.* But many
see orchestration as a BPEL engine and this locks us down from the flexibility of a series of defined message exchanges that can be put together on an ad hoc basis as needed for a situation. * If I start Service M and it sends a message to Service N and then invokes a Discovery Service to find Service P for
the next step in its internal process, if Service M is executing off a BPEL script, does that make the process an orchestration? As I reread this email, it is far from clear. We need to discriminate between orchestration and choreography in a way
that highlights the controller/scripted approach vs. a non-controller following of pre-agreed actions/effects. That should satisfy most of our audience. It would be good to capture that this may not be a hard and fast distinction; that should address the
other concerns. So, what can we agree on and then how can we state it? Ken From:
Rex Brooks [mailto:rexb@ncoic.org] Please let me be clear: Here is Michael’s email with some previous discussions and proposed models for choreography and orchestration. We will pick up with
issue 224 next week. Ken --------------------------------------------------------------------------- Dr. Kenneth Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508 From: Mike Poulin [mailto:mpoulin@usa.com]
Ken,
2442 <Comments only: I have re-drawn the diagram below adding services and interfaces between interacting processes> >>see attached diagram<< > To my knowledge, the diagram on Figure 46 in RAF and followed comments
sound simply scary: as drawn in RAF, two businesses make their internal processes depending on each other for the purposes of choreography. This is a business nonsense though I know some organisations that did so and... terribly failed. First, there must be
Interfaces between the organisations – external interfaces – to exchange Resources and messages. Second, each participant has to appear (in SOA ecosystem) as a consumer and/or provider for another one, which has nothing to do with an integration of internal
processes. I believe, we have to show business choreography examples in line with the Best Business Practice> 2443 Figure 46 Abstract example of choreography of service-oriented
business collaboration. - Michael
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
I would add to Danny's observation: in WS-CDL standard recommendation, choreography also requires "a global idea or goal" named Global Contract.Also, in deterministic systems, the final result of a set of "actions defined by the laws of physics" depends on _willingness_ and _capabilities_ of participant and may be predicted with only certain probability (e.g. described with Fuzzy Logic).
Saying this, I occupy a position "between the computer science and the natural worlds". Particularly, SOA is not about psychology and mechanisms of situational human behaviour. SOA _models_ natural world and can do it a bit better than pure programming (e.g., CORBA). This means that if we dig into subconscious levels, the practical outcome of this may and will be questioned.
I agree with Ken in that we have to "provide the architectural underpinnings by using the vocabulary of our readers but focusing it on elements of SOA we believe are often misunderstood and misrepresented". If the texts are not-readable or require too much efforts to comprehend because of unusual lexicon (well, for the well-educated people), we loose the audience and miss the goal, I think.
- Michael
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Hi Michael, We're right in the middle of this situation with situation reporting. Unfortunately, as with health informatics, we don't have the kind of governmental mandate that would make orchestration feasible. We may at some point in the future be able to do that, but I would then be concerned if we were setting ourselves up to have a few major nodal points of failure where reliance on orchestration could cripple large scale responses. That's why we need to work from the local level up, building mutual aid agreements and establishing, if we can, the kind of distributed datacenter to datamart systems of systems that can handle multiple fail-over situations. If at some point our local choreographies have matured to the point where they can be automated by multiply-instanced orchestration engines to handle those fail-over contingencies, then I'd be happy to go that route, but not until then. Cheers, Rex
At 12:55 PM +0000 4/15/09, mpoulin@usa.com wrote: >Rex, > If we interpret Choreography as direct service-to-service >communication only, i.e. as all needed message exchange to make one >dance figure, and interpret Orchestration as the full dance >sequence of the figures, I am with you on this topic. If >Choreography is crossing the boarder into Orchestration and tries to >manage the figure sequence, I would stay away from SUCH Choreography. > >For Emergency, there is still a set of assumed and supported >scenarios but each participant has to provide for robustness. This >means that in a Choreography model each participant has to know >several next step participants in case if one appears unavailable >or incapable to perform this step. > >Since nothing is stable in our life, all participants change (their >capabilities change) all the time and management of Choreography >model becomes quite difficult task. The crucial risk in it is in the >case where all next step participants fail the Emergency chain gets >broken. There is no one who can fix it in timely manner (i.e. find >alternative provider) and who is responsible for the overall >execution and result of the Emergency Process. > >If Government creates a mandatory Emergency Service Registry where >all participants of all scenarios of Emergency Process would >register and re-register their (or assigned) capabilities, then it >is the place for centralised responsibility for the final result, >and the point of Orchestration Mediator. For an organisation, it >does not make a difference where a request/command for next >emergency step comes from either from another organisations service
>or from centralised registry. The organisation (in the Emergency >scenario) sill have all its right, nobody manages it, to execute >assigned step or deny it (this is the subject of Government Policy >regulations) > >- Michael > > > > >-------------------------------------------------------------------------------- >Subject: RE: [soa-rm-ra] SOA-RA(F) reorganization -choreography-orchestration > >From: Rex Brooks <rexb@starbourne.com> >To: "Mike Poulin" <mpoulin@usa.com>, "Ken Laskey" ><klaskey@mitre.org>,"Ellinger, Robert S \(IS\)" ><robert.ellinger@ngc.com> >Date: Mon, 13 Apr 2009 17:49:19 -0700 > >-------------------------------------------------------------------------------- > >Hi Michael, > >I just got the tons of material for the Emergency Data Exchange >Language Situation Reporting submission to the EM TC vetted by a >Practitioners Steering Group and Standards Working Group involving >the Dept. of Homeland Security (DHS) and the Emergency >Interoperability Consortium (EIC) and even though it is only a >coincidence, it illustrates the point: this (ER Service >Orchestration) just isn't feasible in Emergency Management. I am
>simultaneously working on an Integrated Emergency Response Services >SOA Pattern for the net-Centric Operations Industry Consortium >(NCOIC), where the best chance exists to attempt to automate the most >simple responses in an orchestration, and all indications are that >even that will be beyond our capabilities for the foreseeable future. > >Despite more examples than I'd care to count, people still attempt to >build master lists for such things as event/incident types and run >into the same problem: no one is willing to give up their control >over their own terminologies. If you can't get that, you can't even >start building an orchestration engine. > >Cheers, >Rex @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]