Unfortunately, Ken, this is the principle point because Choreography constantly screws SO model.
Choreography is classical application integration centric model where each change in the integration requires change in each participant of this integration, code modification, re-compilation and re-deployment. This relates as to the change in the invocation order as to the change in the participants of particular Choreography.
The WS-CDL standard under W3C makes the life even worth it defines so-called Global Contract, which freezes all participants. If you need to modify any participant due to new business requirements, you have to re-construct the Global Contract and affect all (innocent) participants.
standard is so bad that Mr. Ashley McNeile with his university colleagues tried to construct a mathematical model which externalises choreography scenario from the participants and build it around centralized dispatcher (very similar to Orchestration).
Orchestration is real antipode to Choreography.
As of Dave Ellis will tell you related to emergency response, where the choreography pattern is vital because you do not know in advance the location and extent of the emergency and thus do not know the resources you will need to orchestrate, I can say that you do not know where your resources (participants) for choreography will be as well. Emergency is NOT the argument. If you construct a set of choreographies they are solid, monolithic and incapable to be quickly changed in the case of emergency. You have to pre-build all choreographies up-front wasting resources (because you do not know the location, right?)
Orchestration, in the contrast , is absolutely dynamic, if you approach it with a service-oriented mind. As IBM Dynamic Process Edition has proved, Orchestration does not need to know Who and How/Where performs the orchestrated functions. It needs only to know What functions are and Why/Which order of invocation has to be applied. Whatever service meets requirements to the business functionality declared by the Orchestration, it may be used. It also may be reused in absolutely different Orchestration at the same time (due to the match of offered business functionality) because the service does not know where it participates in.
Choreography, as it is defined in the WS-CDL standard under W3C, is an application-oriented, not service-oriented mechanism.
----- Original Message -----
From: "Ken Laskey" <firstname.lastname@example.org>
To: "Mike Poulin"
Cc: "Rex Brooks" , "James Odell" , "email@example.com"
Subject: Re: [soa-rm-ra] SOA-RA(F) reorganization
Date: Sun, 12 Apr 2009 20:44:01 -0400
There are problem, such as Dave Ellis will tell you related to emergency response, where the choreography pattern is vital because you do not know in advance the location and extent of the emergency and thus do not know the resources you will need to orchestrate.
I also don't see the need to change the service with a change in the choreography. I expect the choreographies are externally maintained patterns.
On Apr 12, 2009, at 7:11 PM, Mike Poulin wrote:
I am in favour of Orchestration for SOA 10 times more than for Choreography because the latter requires services modification for each new choreography it participates in and this decreases SOA flexibility in adopting business changes. Everything Rex said about events and policies is applicable to Orchestration as well but Orchestration is much cleaner from SO perspectives and much more dynamic. In Yahoo! SOA User group, we have discussed this topic a few times and always concluded the advantage of Orchestration over Choreography for service-oriented environment.
----- Original Message -----
From: "Rex Brooks"
To: "James Odell" , firstname.lastname@example.org
Subject: Re: [soa-rm-ra] SOA-RA(F) reorganization
Date: Sat, 11 Apr 2009 16:47:14 -0700
If we had spent more time on Choreography, where events trigger
policy-based rules for transactions and/or communications, it would
be somewhat easier to pull together a stand alone Policy
subsection. Of course, Orchestration also employs policy-based
rules, but resorting to a Conroller Application removes the
requirement for either human intervention based on judgment
required by rules and assessing state, or some heuristic algorithm.
I'd still just add the standalone policy subsection rather than
eliminating the Policies and Contracts which I think we need for
more reasons than just continuity from the RM.
At 7:03 PM -0400 4/11/09, James Odell wrote:
> Hi Frank,
> Hmmm. While the two "the enforcement of the two is fairly
> closely aligned" -- contracts are not necessary for Policies,
> only the other way around. Policies, IMO should stand alone on
> their own. The CEP folks argue that policies and events are
> "fairly closely aligned". I can name a half dozen other areas
> that could say the same. The bottom line is that: Policy is a
> concept that may be necessary, but not sufficient for other
> areas. Therefore, I strongly support its own sub-section.
> On 4/11/09 6:11 PM, "Francis McCabe" indited:
> Hi Jim
> Thank you for taking a look.
> As far as policies go, we have havered a little (to use a
> Scottish-ism) on how to organize it. In the RM work we closely
> identified the two -- with the distinction being that contracts
> are agreed to and policies are asserted. Once you have either
> one, the enforcement of the two is fairly closely aligned.
> On Apr 11, 2009, at 2:46 PM, James Odell wrote:
> Hi all,
> After yet another reading of the SOA-RA (Foundation?) and having
> sat through the recent spate of meetings, I have the following
> say about the reorganization of the SOA-RA:
> Overall, I think that the chapters and topics are sequenced in a
> coherent and logical manner. Perhaps, it is because I read it
> too many times now. But, I don't think so.
> Also, I understand the need to minimize the amount of work
> needed on the SOA-RA at this point in its development. We need
> to get it released for public comment - without compromising
> quality and understandability, of course.
> Having said this, the only thing that bothers me enough to
> suggest a reorganizational change is the area of Policies:
> 1) Policies, in general, are depicted in document far earlier
> than they are finally addressed (by 40-50 pages). Since policies
> - IMO - are an important ingredient in the SOA-RA, I would like
> to see them addressed earlier. (My personal opinion is that
> policies are not mentioned anywhere near the amount that they
> should. For example, they are used in events, composition of
> services, roles, and organizations. However, since this would
> involve additions to the current document, I will not push this)
> 2) I strongly dislike grouping the entire topic with contracts.
> While policies are used for contracts, Policy is a standalone
> concept - which neither depends on nor is used solely with
> Contract. (Even the OMG and W3C treat policies as a separate
> notion.) Why is this reasonable? Because policies are used in a
> variety of situations - only one of which is contracts. By
> placing Policies in lock step with (and almost subordinate to)
> with Contracts is not appropriate, IMO. 3) My suggestion:
> separate Policies and Contracts into two distinct subsections
> (e.g., 4.4 and 4.5). In short, this would provide clarity for
> the notion of Policy and not require much change to the current
> All the best,
-- Rex Brooks
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free
Account at www.mail.com
MITRE Corporation, M/S H305 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508