RE: [soa-rm-ra] FW: issue 224 and previous proposal

[Peter F Brown <peter@peterfbrown.com>]

Ken,
I think that we shouldn't get hung up on defining/defending orchestration and choreography, instead we should pursue the points we've all raised around action and activity, and what factors affect how they are executed. I like your points and questions and should discuss the more on the call tomorrow...

Peter F Brown
Independent Consultant
www.peterfbrown.com
Twitter @PensivePeter

Sent from my phone - Apologies for brevity and typos: it's hard writing on a moving planet

---

From:
Ken Laskey
Sent:
03-Jan-12 21:11
To:
Peter F Brown; 'Lublinsky, Boris'; soa-rm-ra@lists.oasis-open.org
Subject:
RE: [soa-rm-ra] FW: issue 224 and previous proposal

Peter,



I’d say this is the trail I’m on except the “recipe” needs to be followed to the extent necessary to have the agreed upon effect. An orchestration may invoke service 1, then service 2, then service 3 to get the final effect of service 3.  A choreography could
 give me the same final effect but has the flexibility to take any path.



Now to stir the whole pot: how much flexibility needs to be built into an orchestration that it is indistinguishable from a choreography.  I don’t remember the details of BPEL, but I’m assuming it includes conditional branching.  Could the orchestration above
 invoke service 1a if service 1 isn’t available?  Is that any different from service 1 failing over to service 1a if there is a problem but not having any branching in the orchestration script?



Ken



From: Peter F Brown [mailto:peter@peterfbrown.com] 
Sent: Tuesday, January 03, 2012 11:35 PM
To: Ken Laskey; 'Lublinsky, Boris'; soa-rm-ra@lists.oasis-open.org
Subject: RE: [soa-rm-ra] FW: issue 224 and previous proposal



Ken,
Absolutely. When I stated "are we clear that...", I should have made this more rhetorical and underlined that this is a common (mis)perception of the two.
I think we're getting there.
So, from your note, are we distinguishing:
- some (external?) agency of activity execution that is responsible for how and which actions are executed (orchestration); from
- a pre-defined "recipe" of execution (with no agency at "runtime") that might be included in the activity (such as one might find in rules, a flowchart, etc.) (choreography)?

Peter F Brown
Independent Consultant
www.peterfbrown.com
Twitter @PensivePeter

Sent from my phone - Apologies for brevity and typos: it's hard writing on a moving planet

  _____  

From: Ken Laskey
Sent: 03-Jan-12 19:57
To: Peter F Brown; 'Lublinsky, Boris'; soa-rm-ra@lists.oasis-open.org
Subject: RE: [soa-rm-ra] FW: issue 224 and previous proposal

Peter,



I think I disagree with “orchestration is intended to be about managing contemporaneous actions, whereas choreography is about sequenced actions.”  I would say orchestration is about managing a set of actions (activities?) in sequence, parallel, or some combination
 to produce a well-defined “final” effect, where the communication mechanism from action to action is not specified (unless the action is embodied in a service and the communication is through message exchange).  Choreography is the exchange of pre-defined
 messages to initiate actions that produce a well-defined but possibly intermediate effect recognized by both parties in the message exchange.  The actions managed through orchestration may be implemented as a choreography; the action initiated through a choreography
 may be implemented as an orchestration.  An orchestration knows all the related actions; a choreography knows only the immediate initiated action.



This needs some work but captures pieces I think are important.



Ken



From: Peter F Brown [mailto:peter@peterfbrown.com] 
Sent: Tuesday, January 03, 2012 10:04 PM
To: Lublinsky, Boris; Ken Laskey; soa-rm-ra@lists.oasis-open.org
Subject: RE: [soa-rm-ra] FW: issue 224 and previous proposal



Boris:

Can I re-word these definitions a little? I’m assuming (somewhat presumptuously) use of the definitions of ‘action’ and ‘activity’ that I indicated in my earlier private note.



“Orchestration is a means of coordinating actions that are [simultaneously?] executed within an activity”

“Choreography is a method of using messages to plan [and|or] order the execution of actions within an activity”



My worries with your definitions are:

-          They are not formally or tightly enough worded;

-          They can be interpreted to read that choreography is simply an implementation of orchestration using messages, or just the messaging part of orchestration – which I am sure is not your intent.



Are we clear that orchestration is intended to be about managing contemporaneous actions, whereas choreography is about sequenced actions? If we use my proposal for activity and action, is this distinction important? Surely the key issue is whether, where,
 and how any ‘external’ agency coordinates/centralizes/manages actions within an activity, if and when the activity is composed of actions that require such external agency (for example with forking and branching actions within an activity).



Cheers,

Peter



Peter F Brown

Independent Consultant

www.peterfbrown.com

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 Lublinsky, Boris
Sent: Tuesday, 03 January, 2012 06:06
To: Ken Laskey; soa-rm-ra@lists.oasis-open.org
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 <http://service.mail.com/callgate-6.50.2.0/rms/6.50.2.0/mail/getBody?folderId=1 <http://service.mail.com/callgate-6.50.2.0/rms/6.50.2.0/mail/getBo

[The entire original message is not included.]