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


More than just design choices, I see this as conceptualization choices that have a fundamental difference in the way they treat ownership boundaries. Our purpose should not be getting into implementation details but in distinguishing among the approaches to the fundamentals.  In my original diagrams below, the first model crosses boundaries between the Controller and each of the services; in the second model, the boundaries are between the services.  Both approaches have pros and cons, and I think it goes beyond implementation detail.

 

Ken

 

P.S. I think Controller as “specialized mediator” is a stretch.  I see a mediator as something bridging a disconnect where the disconnect is not part of the problem domain.  A Controller is doing more than bridging a disconnect.

 

 

From: Lublinsky, Boris [mailto:boris.lublinsky@navteq.com]
Sent: Saturday, January 07, 2012 1:35 PM
To: Ken Laskey; 'Mike Poulin'; 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

 

I would prefer not to use the word orchestration, but rather characterize those as different approaches to composition design, where composition is very close to join action. At the end of the day composition is an SOA feature, not orchestration or anything else. We are trying to talk about the fact that services can be combined, not necessarily orchestrated, the damn hands/foot coordination keeps getting in the way.

The important thing is not how they are implemented, I can implement all of the using orchestration engine or do it any other way (Yes, I am that good) but which design paradigm they implement – sequential, conversational, etc. The standard is not about implementation differences, but rather about design approaches, and when you talk about those controller is irrelevant. Think about controller as about specialized mediator. You will not start distinguishing two systems based on the fact that one is using mediator and another is not. Its implementation detail

 

From: Ken Laskey [mailto:klaskey@mitre.org]
Sent: Saturday, January 07, 2012 11:11 AM
To: Lublinsky, Boris; 'Mike Poulin'; 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

 

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.

 


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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature



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