If the diagrams Michael refers to are the ones we discussed in our last meeting, then yes I have seen them and given them considerable thought. If he means the stick figure actors in use cases (those ellipses), then I would have to insist that it be done in a way that does not cause problems between the way "actor" is defined in UML, and the way we describe actor. We have already made the point that we intend the dictionary definition unless we define a term and make bold and blue in all places where our definition is intended. We would have to clariy our use of rough, non-canonical UML "actors" is separate from blue and bold uses of "actor." I don't have a problem with the stick figure diagrams to show the use of "conductor" in orchestration and lack of such in choreography.
Again, we will still need to clarify in the text that aggregations may be composed of both orchestrations and choreographies.
Cheers,
Rex
On 1/8/12 9:57 AM, Mike Poulin wrote:
Rex, I talk about this problem since 2009 draft - nobody wanted to put attention. And this does not mean it is the right thing to do.
It might be useful to return back to the "foundational" approach if Rex explicitly defines it.
To me, the "foundational" approach to orchestration is about the conductor who organises, controls, is responsible and accountable for the collective work of independent participants/services and for the final expected outcome and RWE.
To me, the "foundational" approach to choreography is about the preliminary agreement on collective work between independent participants who later on follow their parts of the agreed responsibilities but nobody is responsible for the final collective outcome and RWE. In the case of participants=services, no changes in the service behaviour or interface, no internal implementation coupling may be allowed as well.
- Michael
----- Original Message -----
From: Rex Brooks
Sent: 01/08/12 04:35 PM
To: Ken Laskey
Subject: Re: [soa-rm-ra] rough non-UML orchestration and choreography figures
Hi Ken, Everyone,
Answer: None.
I also personally disagree with all of them unless non-sequential actually refers to asynchronous, with which I would then agree and my constituents would probably agree, too.
That doesn't mean that I don't personally have differences with some of my constituents on individual issues. I have to admit that I was definitely surprised by their reaction to the notion of deleting the diagrams.
I think Michael and Boris are both so focused on exceptions and individual business solution cases that they have forgotten the "foundational" approach. Also, the apparent use case diagrams are so informational that I would ask for a disclaimer, or else that they be done in visio and disclaimed so I don't have to attempt to include them in my single model of the whole SOA-RAF.
My last comment is that all of this needed to be brought up before, and I believe some of it may have been, but after five years I'm not willing to go searching back through our records to find them, especially when I thought we were finished with them long ago. I suspect that there are more parts of the SOA-RAF that I personally don't agree with that I could also now bring them up.
We should be finishing this up, not engaging in more endless discussions. Again, I suggest we note that in practice aggregations of services are likely to include orchestrations and choreographies. Also, we can say that our definitions are offered at the most general level for the purpose of making it possible to discuss some aspects of the overall processes involved in developing SOAs within the SOA Ecology. Probably we should also say that for the sake of clarity, we don't show a "controller" or "conductor" for Orchestration, but all interfaces are operated by that agency.
Cheers,
Rex
1/7/12 3:13 PM, Ken Laskey wrote:Rex,
Which of the changes proposed my Michael would *not* cause grief with your constituents?
Ken
From: Rex Brooks [mailto:rex.brooks@ncoic.org]
Sent: Saturday, January 07, 2012 4:36 PM
To: Ken Laskey
Cc: 'Lublinsky, Boris'; 'Mike Poulin'; soa-rm-ra@lists.oasis-open.org; 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
Hi Guys,
I weighed in with the results of my poll of my constituents which is that they are indeed using the current diagrams and not having headaches with it. So if we do not delete them, I'm okay. I'm not thrilled with more diagrams but I will consider it more fully.
Cheers,
Rex
On 1/7/12 11:04 AM, Ken Laskey wrote:
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.
-- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361 Addison #A Berkeley, CA 94702 Phone: 510-898-0670
