[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm-ra] FW: origins and interpretation of RAF figures 30 and 31
|
On the substance – I would like to stop any further discussion for the moment, and pause to take time to agree to the formalization of action and activity and the role of actors (if necessary backed with formal
UML activity, collaboration and/or behaviour diagrams – I had hoped to have this ready by today but other projects have taken me away)– and
then see how the other elements fall into place – because I think they will. I believe it is own woolly use of ‘action’ and ‘joint action’ which is causing a lot of the (unnecessary) confusion…. My $0.02… Peter F Brown Independent Consultant 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 Ken Laskey Jeff – thanks for the information below. All – I pinged Jeff to make sure I was interpreting Figures 30 and 31 correctly, and Jeff’s response below confirms and expands my understanding. He also provides some other
useful tidbits. To this point, I don’t see us coming up with something fundamental that will deal once and for all with the accumulated ambiguity in the community. I suggest people submit
specific language for points they want section 4.3 to make and we will see about what is already there and what needs to be added. Guidelines:
1.
The terms orchestration and choreography stay because there is more confusion in them disappearing.
2.
The controller vs. no controller idea seems to be generally unsatisfying but widely recognized.
3.
The current figures (with possible modification) needs to remain. What we say about the figures is for you to suggest.
4.
The paramount idea is service composition and RAF scope includes concepts (foundational) of how composition can be accomplished but not details in areas of debate. Caveats and pros/cons
are welcome but only as suggested text in suggested locations. Solve the problem and let’s move on. 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: Estefan, Jeff A (3180)
[mailto:jeffrey.a.estefan@jpl.nasa.gov]
Hi Ken, These two diagrams I had to use Visio because I could not get MagicDraw to cooperate, even though these are normative UML. The source is a couple of places but I think one resource was loosely-based on paper on BPEL from Oracle and some input (which was cited) came from Bloomberg & Schmelzer’s “Service Orient or Be
Doomed!” The little squares represent ports just as you noted. In UML/SysML, a port is the boundary between the classifier (in this case, composite structure) and its environment. Sometimes, you’ll see
required and provided interfaces attached to ports (lollipop notation) and sometimes you do not. Ports got a big push up in UML 2 a few years back. The trick is to model only what you see as important, hence, model the right level of abstraction. In this
case, we care about the relationship between the classifier and its environment. We do not care about formally specifying the interfaces. In another model, we might want to care about interfaces and then we would include them in our visual model. The actions indeed represent process tasks and as you noted the rectangles the information used in between. Best to keep things simple and this is about as simple as I’ve seen to represent the
two concepts (orchestration and choreography). The following from Wikipedia’s description of BPEL (see
http://en.wikipedia.org/wiki/Business_Process_Execution_Language). Take it or leave it. I’ve yet to find a definitive standard differentiating the two concepts. You probably saw
my note on BPMN 2’s attempt to differentiate the two concepts and they also introduce the notion of a “collaboration.” Also note Wikipedia’s definition of Orchestration (computing) (see
http://en.wikipedia.org/wiki/Orchestration_(computers) ). “The primary difference between orchestration and choreography is executability and control. An orchestration
specifies an executable process that involves message exchanges with other systems, such that the message exchange sequences are controlled by the orchestration designer. A choreography specifies a protocol for peer-to-peer interactions, defining, e.g., the
legal sequences of messages exchanged with the purpose of guaranteeing interoperability. Such a protocol is not directly executable, as it allows many different realizations (processes that comply with it). A choreography can be realized by writing an orchestration
(e.g., in the form of a BPEL process) for each peer involved in it. The orchestration and the choreography distinctions are based on analogies: orchestration refers to the central control (by the conductor) of the behavior of a distributed system (the orchestra
consisting of many players), while choreography refers to a distributed system (the dancing team) which operates according to rules (the choreography) but without centralized control.” Cheers! - Jeff |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]