RE: [soa-rm-ra] SOA-RA(F) reorganization-choreography-orchestration

[Rex Brooks <rexb@starbourne.com>]

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


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670