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

[mpoulin@usa.com]

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