OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[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


As far as I can see both figures are very similar. Adding 2 interfaces does not really do much for me, and I am not sure its worth a trouble

My suggestion from the call last week (year) stands:

·         Orchestration is coordination of activities’ execution

·         Choreography is a message exchange for activity execution

This provides a well defined delineation between the two.

Choreography, in this case can be viewed similar to BPEL’s public process – visible interaction between multiple entities each with its own private process implemented through orchestration.  

 

From: soa-rm-ra@lists.oasis-open.org [mailto:soa-rm-ra@lists.oasis-open.org] On Behalf Of Ken Laskey
Sent: Wednesday, December 28, 2011 8:26 PM
To: soa-rm-ra@lists.oasis-open.org
Subject: [soa-rm-ra] FW: issue 224 and previous proposal

 

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]
Sent: Tuesday, December 20, 2011 7:43 AM
To: Ken Laskey
Subject: Re: issue 224 and previous proposal

 

Ken,

I 've copied a few messages from th past about our discussion on choreography presentation in RAF. I tried to follow chronological order.
The groups of messages are divided by  @@@@@@@@@@@....

I can add that former Figure 46 and current 31 is a copy (or a slightly modified copy) from WS-CDL recommendation (which is highly critisised and could not make its way into the standard). I would stay as far from it as possible. This may be an issue for Rex but I am ready to give him 4 to 5 fatal reasons why choreography as stated in WS-CDL is a bad thing for industry and for "emergency" in particular. I have even noticed that term'choreography' becames a persona non-grata and in the process of replacement by the _expression_ "Multi-Party Business Conversations/Interactions/Communications in Service Networks" (I saw all three variations in the name somewhere in the Net)


Yes,  I've meant WS-CDL.

- Michael



@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

The discussion is about choereography but the diagram shows orchestrated and orchestrating services. Since this is shown within a an organization and not across an organizational boundary, is this supposed to show orchestration within choreography? 

I have no problem with the additional interfaces. I believe it was used only as an illustration, but it is more correct this way, though I don't know about the orchestration aspect. I wouldn't build and architecture that way, but I see no reason it couldn't work.

Cheers,
Rex


@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

As I mentioned before, I've reviewed section 4 with regard to orchestration and choreography. Here is one of my findings:

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 
 
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 
 





























 

----- Original Message -----

From: Ken Laskey

Sent: 12/18/11 11:31 PM

To: mpoulin@usa.com

Subject: issue 224 and previous proposal

 

Michael,

 

 

 

 

 

I was read issue 224 in the spreadsheet and your response says you provided a full explanation and a new diagram earlier this year.  Could you please either point to the email or send again.  Also, where you reference WS-CRL, do you mean WS-CDL?

 

 

 

 

 

Thanks,

 

 

 

 

 

Ken

 

 

---------------------------------------------------------------------------

 

 

Dr. Kenneth Laskey

 

 

MITRE Corporation, M/S H305              phone: 703-983-7934

 

 

7515 Colshire Drive                                    fax:        703-983-1379

 

 

McLean VA 22102-7508

 

 

 

 

 

 



The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]