[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm-ra] SOA-RA(F) reorganization
This discussion has been out there for a while http://www.infoq.com/news/2008/09/Orchestration
with no good resolution. Should we stick with service composition and leave choregraphy/orchestration
debate aside From: Ken Laskey
[mailto:klaskey@mitre.org] Michael, It's been a while since I looked at the WS-CDL draft so I
can't comment on specifics. However, I think the problem is not in choreography,
per se, but in the way you see WS-CDL implementing it. In my mind, I can set up a choreography for an emergency
scenario that has a series of agreements on how one should respond to a
understandable piece of information, and I can see a very flexible response as
the situation unfolds. Part of the problem with orchestration is it requires *all*
participants to work under a single orchestration engine. This is fine
under the notional "enterprise" but what about peer resources that
can exchange messages but are otherwise independent? What happens when a variation of the scenario is not covered
by the specifics of pre-programmed orchestration logic? I am not arguing for one over the other but I see the
combination as being more powerful than either alone. However, this
requires SO composition rather than a traditional integration mindset. Ken On Apr 13, 2009, at 10:38 AM, Mike Poulin wrote:
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. The … 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. If you need more information on this topic, please, look at ‘Does
SOA need a choreography or it can dance by itself?’ (http://it.toolbox.com/blogs/so-enterprise-blog/does-soa-need-a-choreography-or-it-can-dance-by-itself-27775).
----- Original Message ----- 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. Ken 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 -----
Be Yourself @ mail.com! ----------------------------------------------------------------------------- Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7515 Colshire Drive
fax:
703-983-1379 McLean VA 22102-7508
Be Yourself @ mail.com! ------------------------------------------------------------------------------------------ Ken 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]