Re: [service-orientated-architecture] Distinction between "Choreography" and "Orchestration"
- I do not see any benefits of choreography in Udi example but coupling R, S1 and S2. Moreover, to have the fixed set of exchange messages between them, none of participants MAY NOT change its state or re-arrange its resources. Otherwise, when R changes its resources but continues participating in the same choreography, pre-defined request from S1 to R may return/allocate something different than S1 expected.
From the example, I do not see in which way collaborative style is looser for high-level business services while it couples them. The power of orchestration, on the other hand, is in that its Action may be provided by any alternative service based on corresponding business logic, it is not pre-determined via fixed message exchange, it defines input and output only.
The business logic about maximising profit can be easily described in the policy or in the rule without coding it in the R (interesting, how many reservation scenarios exist and how the reservation pattern looks like?)
Then, what is the problem with different organisations/firms, which choreography can handle better than orchestration? In orchestration, the "orchestration engine/manager" is not a thing above all. We should not forget that in SOA service and process are interchangeable things: a service may be implemented as a process and a process may invoke services. This means, that requests from S1 and S2 just trigger the Resource Reservation processes in the R service. If each intercommunicating participant minds its own profit, it has to have its own profit-oriented process implemented in the service; how each process works is the business of the owner only. This is why one service/owner can loose profit and another one - gain it; this is the real business model.
The more interesting thing in the example is that R, S1 and S2 services look like maintaining the state of the conversations. Moreover, the R appears as capable to mix-and-match conversations; we are dealing with stateful services! Is this a new word in the service scalability discovered in choreography?
BTW, what is a "tentative confirmation"? Does it mean there is assumed another message exchange later on to finalise the reservation? Does this mean that choreography's Global Contract must know how long to wait before requesting the final response and how many times to repeat the request if each response brings the "tentative confirmation"? What does mean that "previous reservation cannot be completed" for S1? What if S1 has allocated its resources already? How the R knows that S1 is waiting for the final confirmation? Is this also is fixed in the Global Contract? ... and this is called "looser... style". I beg you pardon.
- The participants are not *required* to perform the actions exactly as
specified in a choreography description. The choreography description
simply describes the set of interactions that the various parties
expect to happen if the process goes as plan. If something unexpected
happens, the collaborating parties can improvise.
On Wed, Sep 10, 2008 at 10:47 AM, Michael Poulin <m3poulin@...> wrote:
> So, I can conclude that a composite or aggregate service is fully capable of
> collaboration in the choreography form because if has compromised
> Loose-Coupling and Autonomy principles already and, therefore, can use
> "formal *description* of a collaborative process" to deal with other to-be
> engaged services. At the same time, a self-contained autonomous business
> service has no chances to participate in the choreography because it does
> not know/care about other services (i.e. it cannot collaborate by itself
> while somebody else can use it in a collaboration keeping such service
> *blind*). I am fine with this.
> Obviously, the autonomous participants of orchestration do not collaborate
> but there may be composite or aggregate participants as well and the latter
> can collaborate easily (via choreography).
> About ad-hock and orchestration. If we use a process (represented as a
> service), the latter cares only about functionality required by the process
> activities (BPEL may not have such abstraction, which requires a search for
> the functionality provider; concrete provider may be not known at the time
> when the process is designed; this is why I call it ad-hock). At run-time,
> predefined set of steps does not exclude ability to find activity provider
> on-the-fly. If this is not implemented anywhere yet, it is still a strong
> capability of the process implementation.
> However, could you, please, comment on how "Choreography can be much more ad
> hock than orchestration" if every participant in the choreography has
> explicit and finite "*description* of a collaborative process"?
> - Michael
> ----- Original Message ----
> From: Anne Thomas Manes <atmanes@...>
> To: email@example.com
> Sent: Wednesday, September 10, 2008 12:59:53 PM
> Subject: Re: [service-orientated-architecture] Re: Distinction between
> "Choreography" and "Orchestration"
> Orchestration refers to an automated process manifested by a composite
> service, which is typically written using an orchestration language
> (e.g., BPEL, JPDL). At runtime, an orchestration engine executes the
> predefined set of steps (e.g., service invocations) specified in the
> orchestration language. (Variables can influence the process, but only
> to a degree.) The process is initiated by a single request to the
> composite service. I suppose you could say that the application
> invoking the composite service and the composite service are
> "collaborating" , but I wouldn't. It's typically a much simpler
> client/server style of interaction. From my perspective, orchestration
> does not involve collaboration- -at least not in the sense that
> choreography does, and certainly not in an ad hoc way.
> Choreography is a formal *description* of a collaborative process
> between two or more parties. I stress "description" because there is
> no "choreography engine" coordinating the collaboration. It's up to
> the collaborating parties to do their part in the collaboration.
> Choreography can be much more ad hoc than orchestration.
> On Wed, Sep 10, 2008 at 4:07 AM, Michael Poulin <m3poulin@yahoo. com> wrote:
>> In this case, would it be correct to say that orchestration provides a
>> description of ad-hock collaboration?
>> That is, choreography uses only preliminary dedicated coupled entities
>> orchestration can use either coupled or loosely-coupled entities that
>> unaware of their own participation in the collaboration?
>> - Michael
>> ----- Original Message ----
>> From: Anne Thomas Manes <atmanes@gmail. com>
>> To: service-orientated- architecture@ yahoogroups. com
>> Sent: Tuesday, September 9, 2008 10:14:09 PM
>> Subject: Re: [service-orientated -architecture] Re: Distinction between
>> "Choreography" and "Orchestration"
>> Consider it this way:
>> Choreography provides a description of a planned collaboration.
>> On Tue, Sep 9, 2008 at 9:30 AM, Michael Poulin <m3poulin@yahoo. com>
>>> Responding to last 3 messages from Steve Jones on this topic...
>>> Look what I did: I took pre-defined rules, i.e. SO Principles, and tried
>>> apply them to the concept of choreography. Logically, my conclusion is
>>> correct. However, if you start moving the start point - SO Principles -
>>> logical result might be different. But what the point of a discussion in
>>> this case?
>>> You are saying that Loose-Coupling and Autonomy are just theoretical
>>> Well, we do not really know where we live, we create models to describe
>>> SOA is one of such models and Loose-Coupling and Autonomy principles help
>>> lot to distinguish application from service, to define service and build
>>> whole architecture on this definition. If the concept of choreography
>>> not fit into this architecture, it does not mean the architecture has to
>>> change. I am saying so, because this architecture has another mechanism
>>> collaboration - orchestration.
>>> Plus, my and your arguments about known needs of collaboration clearly
>>> that the collaboration is the add-on to the service, an external thing.
>>> why service/SOA can be that flexible and capable to address multiple
>>> different collaborations w/o constant modification of the services.
>>> Sure, collaboration requires negotiation. To my knowledge, we are not
>>> talking about active services in SOA unless they are processes or
>>> services. Even in this case, the activity goes in only one direction: the
>>> organiser looks for potential providers saying 'I want certain business
>>> functionality' . All other self-contained lowest level business services
>>> announce their capabilities; they do not a feature/facility/ function to
>>> perform a negotiation. Correct me if I wrong here.
>>> The core meaning of service capabilities to fulfill business
>>> and provide for RWE precludes from negotiation feature in the manner of
>>> need somebody to work for me to fulfill my obligations' . This looks very
>>> simple to me.
>>> Another thing is that modeling business, we need to have a negotiation to
>>> combine different capabilities for the business task resolution. To me
>>> is the real task that by its nature comprises in two parts ( even in
>>> business): separate complete features/functions and the
>>> rule/process/ scenario that gets them together and uses in certain order.
>>> survival power of the business is in the art of re-combining those
>>> features/functions. This means, the less the features/functions depend on
>>> the particular composition, the more flexible the business is. The
>>> choreography, as it is defined today, does not meet flexibility
>>> because it assumes that each participant knows exactly about each
>>> choreography/ collaboration scenario it is used into.
>>> Nevertheless, SOA RM does not prohibit us from creating services coupled
>>> with either each other or with a process (the latter part is omitted in
>>> RM and not very much in SOA RA). I am not saying that collaboration is
>>> for SOA, oppositely, it is but collaboration and choreography are not the
>>> synonym. If an SO solution hits business flexibility (changeability) ,
>>> choreography does, this looks to me as a bad SO practice, that is it.
>>> - Michael
>>> ----- Original Message ----
>>> From: Steve Jones <jones.steveg@ gmail.com>
>>> To: service-orientated- architecture@ yahoogroups. com
>>> Sent: Tuesday, September 9, 2008 8:09:19 AM
>>> Subject: Re: [service-orientated -architecture] Re: Distinction between
>>> "Choreography" and "Orchestration"
>>> 2008/9/8 Michael Poulin <m3poulin@yahoo. com>:
>>>> Hi Ashley,
>>>> I am fully agree with your first paragraph about orchestration.
>>>> I understand your second paragraph about choreography but see a conflict
>>>> between this concept and SO Principles. Nothing more.
>>> Why? Independent services working together for a mutually inclusive
>>> goal set, to me its right at the heart of the SO principles.
>>>> Out of this, I am trying to find a business case where choreography
>>>> more preferable than orchestration in SOA, i.e. where me must violate SO
>>>> Principles to have choreograph- based solution. If we deal with
>>>> self-contained autonomous services, then any idea about their
>>>> is the external ised with regard to them. Thus, instead of modifying the
>>>> services by embedding the knowledge about other services for the
>>>> collaboration, I can easier (I think) create a new service to play an
>>>> orchestration manager (conductor) role.
>>> I'm really not seeing how SO doesn't allow choreography. Negotiation
>>> and collaboration are normal business service scenarios and they don't
>>> require a conductor.
>>> The Value Network work from the likes of Verna Allee has "Services"
>>> written all over it and its all about collaborating networks rather
>>> than orchestration.
>>>> Overall, it is not about choreography per se, it's about a mismatch
>>>> SOA and choreography (I know how unusual this sounds).
>>> It sounds more than unusual to me, it sounds wrong.
>>>> - Michael
>>>> ----- Original Message ----
>>>> From: Ashley at Metamaxim <ashley.mcneile@ metamaxim. com>
>>>> To: service-orientated- architecture@ yahoogroups. com
>>>> Sent: Monday, September 8, 2008 4:47:09 PM
>>>> Subject: Re: [service-orientated -architecture] Re: Distinction between
>>>> "Choreography" and "Orchestration"
>>>> Hi Michael
>>>> On the issue of "statelessness" :
>>>> It seems to me that if multiple participants (P1, P2, P3, ..) are
>>>> a collaboration but only one of them (say P1) holds a state, then the
>>>> situation is one of "Orchestration" rather than "Choreography" . Only P1
>>>> determine or impose any ordering on events in the collaboration, because
>>>> such determination/ imposition requires the maintenance of state. P1
>>>> "orchestrates" the collaboration and the other participants are
>>>> they are invoked to provide some service but, as they have no state,
>>>> "forget" they that have done it once they have done their job.
>>>> "Choreography" comes into play when state is held by multiple
>>>> and they all have their own sequencing rules/constraints. Choreogrpahy
>>>> about managing the collaboration in such a way that all their
>>>> are obeyed but without one distinguished orchestrator. In other words,
>>>> peer-to-peer between stateful participants.