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

[Ken Laskey <klaskey@mitre.org>]

Michael,

You are assuming more coupling than I believe is needed.  This email  
thread is a choreography.  Its purpose is to come to some  
understanding on the activities that can be identified as  
orchestration and choreography.  This email is directed to you but  
also posted to the list.  People who can see the message can interpret  
it and respond.  Some people will hold off because others are covering  
the points they would make.  Some jump in when something additional is  
needed.  No one runs the discussions but there are known expectations  
both in personal behavior and underlying technology.

But, again, we debate on hypotheticals without the opportunity to  
really test our assumptions.

Ken

On Apr 15, 2009, at 8:55 AM, 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
>

-----------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305      phone: 703-983-7934
7515 Colshire Drive                         fax:       703-983-1379
McLean VA 22102-7508