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] rough non-UML orchestration and choreography figures


I agree with Ken. 
The difference between orchestration and choroegrpafy types of collective work is, in essence, in that who holds and how applies the Rules of collective work - centrally or in distribution.

And one more thing: again - SOA assumes that a combination of services would not require changes in the services for the purpose of combination. This type of combination or joint/collective work is called cooperation, not collaboration. Ledo pieces do not collaborate, they cooperate and interconnect with no changes inside them.


I disagree with Boris about types of business process. Business process is defined in only one way - via its business execution logic. A representation of the process may be different. Choreography as the whole called a Global Process becuase it is a composition of separate and not necessary ditectly tied processes that together solve a common task.

Choreography is not one sequential process because more than one participant can start its own interaction processes at the same moment and more than one message can be sent in the same moment in the choreography. Majority (not all) of behaviour modelling math. solutions disallows multiple starters and more than one mesage at a time but it is only a math. modelling constraint. The choreography graph looks like a tree set up-side-down - flows stream down from more than one initial top-level points (in general); in some cases, however, a choreography may be a normal tree (sequential).

Choreography implementation via  FSM (IBM and MS have implementations) is nothing more than an implementation based on the behaviuor modelling approach (which fundamentally incomplete becuase it does not deal with the message load and interaction recovery). Some time ago I sent Rex a message where I claimed that I did have a choreography solution utilised behaviour modelling but made it complete and with assured results  regardless partial faulure of participants...

- Michael

 

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

From: Ken Laskey

Sent: 01/07/12 05:10 PM

To: 'Lublinsky, Boris', 'Mike Poulin', soa-rm-ra@lists.oasis-open.org

Subject: RE: [soa-rm-ra] rough non-UML orchestration and choreography figures


Boris,

 

 

 

 

 

I think a combination of the differences you point out are what discriminates between orchestration and choreography.  The semantic difficulty is you call everything orchestration, and I don’t see that in the rest of the world.  Typically, the point is orchestration is centralized and the controller does the coordination, choreography is distributed and the components perform in the context of a coordination.

 

 

 

 

 

I think the difference is illustrated in the following examples:

 

 

1.       I can hire people and build an organization and as the manager I direct the people.  Give me a project and I’ll tell who to do what.  If a project requires skills not in my organization, I hire more.

 

 

2.       I have a core staff and I arrange with other organizations who have interest in collaborating on a problem solution.  We agree on information to share and work products to hand off between us.  If we need additional skills, we find other organizations with those skills to bring into the collaboration.

 

 

 

 

 

Of course, we can have combinations of 1 and 2.

 

 

 

 

 

Now you can tell me this is all orchestration but I don’t think most folks would buy it.

 

 

 

 

 

Ken

 

 

 

 

 

From: Lublinsky, Boris [mailto:boris.lublinsky@navteq.com]
Sent: Saturday, January 07, 2012 11:52 AM
To: Mike Poulin; Ken Laskey; soa-rm-ra@lists.oasis-open.org
Cc: jeffrey.a.estefan@jpl.nasa.gov; Thornton, Danny R (IS); ellis@deccs.com
Subject: RE: [soa-rm-ra] rough non-UML orchestration and choreography figures

 

 

 

 

 

The more I am listening to this discussion the more I am getting confused. What are we actually trying to tell?

 

 

If I look at Ken’s picture, the only thing that I see is centralized vs distributed orchestration controller – implementation details, who cares. We said before that orchestration engine is an implementation approach, nothing else. So it can’t be distinguishing factor.

 

 

When I am looking at Mike’s picture, I am confused even more.

 

 

Here is a couple of suggestions:

 

 

·         There are two different types of business processes – sequential processes, the ones that was discussed all over the places, including BPEL and the ones that are defined as FSM (IBM and MS have implementations). Here the process is defined not in the terms of sequence of steps, but rather in the form of collection of states and states transition rules

 

 

·         There are two different types of service execution – complete and conversational. In the first case an execution is completely opaque, while conversational execution exposes its states that can impact further execution.

 

 

·         And finally we talked about message exchange vs execution sequence

 

 

So which one do we care about?

 

 

 

 

 

From: soa-rm-ra@lists.oasis-open.org [mailto:soa-rm-ra@lists.oasis-open.org] On Behalf Of Mike Poulin
Sent: Saturday, January 07, 2012 2:24 AM
To: Ken Laskey; soa-rm-ra@lists.oasis-open.org
Cc: jeffrey.a.estefan@jpl.nasa.gov; Thornton, Danny R (IS); ellis@deccs.com
Subject: Re: [soa-rm-ra] rough non-UML orchestration and choreography figures

 

 

 

 

 

Here is my idea of 'choreography' diagram.

Specifics:
1) choreography does not need to be sequential
2) preiminary  off-line agreement is required from every participant
3) every participant generates its own RWE
4) messages are less important than interactions


 - Michael

 

 

 

 

 

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

 

 

From: Ken Laskey

 

 

Sent: 01/06/12 10:48 PM

 

 

To: soa-rm-ra@lists.oasis-open.org

 

 

Subject: [soa-rm-ra] rough non-UML orchestration and choreography figures

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Have at it.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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]