Loading ...
Sorry, an error occurred while loading the content.
 

Re: [service-orientated-architecture] Distinction between "Choreography" and "Orchestration"

Expand Messages
  • Michael Poulin
    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
    Message 1 of 62 , Aug 31, 2008
      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.

      - Michael

      ----- Original Message ----
      From: Udi Dahan <thesoftwaresimplist@...>
      To: service-orientated-architecture@yahoogroups.com
      Sent: Sunday, August 31, 2008 10:05:43 PM
      Subject: RE: [service-orientated-architecture] Distinction between "Choreography" and "Orchestration"

      It’s been my experience that different kinds of services suit choreography than those that suit orchestration.

       

      I’ve found that high-level business services work very well with a looser, more collaborative style.

      Lower-level entity/activity/ infrastructure services work better with a more defined orchestration style.

       

      Consider the reservation pattern between business services often useful in the travel industry (also valuable in many environments where profitability comes from maximizing profit created by limited physical resources).

       

      In this pattern, one service is in charge of maximizing profit of resources – let’s call it R.

      Other services wish to use/reserve usage of those resources, let’s consider two independent services, S1 and S2.

      S1 sends a request to R requiring  ¾ of its resources for tomorrow. R, taking into account lead time, responds with a tentative confirmation.

      S2 sends a request to R requiring ½ of its resources for tomorrow. R, seeing that this request brings the same level of profit, tentatively confirms, and notifies S1 that its previous reservation cannot be completed and that it is currently holding ¼ resources for the next hour pending a confirmation. If no confirmation arrives, those ¼ resources will be de-allocated as well.

      S1 confirms the ¼ resource pull for tomorrow and sends a request for the remaining ¼ for the day after tomorrow.

      R tentatively confirms the remaining ¼.

       

      Modelling this kind of behaviour with orchestration is possible, but results in totally different services. Since the services above may be owned by different organizations, each seeking to maximize its own profit/turnaround time/whatever a “big thing in the middle orchestrating everybody else” isn’t organizationally feasible.

       

      Well, that’s what I’ve seen work anyway.

       

      And, for me, that’s the difference between orchestration and choreography.

       

      --

      Udi Dahan - The Software Simplist

       

      From: service-orientated- architecture@ yahoogroups. com [mailto:service- orientated- architecture@ yahoogroups. com] On Behalf Of Michael Poulin
      Sent: 29 August 2008 15:34
      To: service-orientated- architecture@ yahoogroups. com
      Subject: Re: [service-orientated -architecture] Distinction between "Choreography" and "Orchestration"

       

      I have started this discussion and, I think, we have got the understanding of service choreography vs. orchestration. I have not read those Chapters (mentioned in Jorge message) but I do not expect significant difference that Thomas Erl could describe in 2005.

      Thanks to Anne and Ashley, I have learned more about
      WS-CDL and its "Global Contract". All together, leads me to think that WS-CDL is driven rather by INTEGRATION than service orientation. If choreography is much different from the WS-CDL, it would be interesting to know. (Even Thomas Erl admits that choreography screws SO Autonomy and Loose-Coupling Principles, and couples services).

      Any thoughts?

      - Michael

       

       

      ----- Original Message ----
      From: Jorge Infante Osorio <jorgeio@uci. cu>
      To: service-orientated- architecture@ yahoogroups. com
      Sent: Friday, August 29, 2008 5:33:14 AM
      Subject: RE: [service-orientated -architecture] Distinction between "Choreography" and "Orchestration"

      Hello to all. 

      I know  that there are many big architects in this list, but never this of but to recommend a good book. 

      I recommend the reading of this book [1] of Thomas Erl. Chapter 6, Sections 6.6(Orchestration) and 6.7(Choreography) . It have an example very illustrative to solve this discussion.

      [1]Service-Oriented Architecture: Concepts, Technology, and Design.

      I hope it  helps in something.

      Jorge.
       

       

      No virus found in this incoming message.
      Checked by AVG - http://www.avg. com
      Version: 8.0.169 / Virus Database: 270.6.9/1637 - Release Date: 27/08/2008 07:01


    • Anne Thomas Manes
      The participants are not *required* to perform the actions exactly as specified in a choreography description. The choreography description simply describes
      Message 62 of 62 , Sep 10, 2008
        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.

        Anne

        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: service-orientated-architecture@yahoogroups.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.
        >
        > Anne
        >
        > 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
        >> while
        >> 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.
        >>
        >> Anne
        >>
        >> On Tue, Sep 9, 2008 at 9:30 AM, Michael Poulin <m3poulin@yahoo. com>
        >> wrote:
        >>> 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
        >>> to
        >>> apply them to the concept of choreography. Logically, my conclusion is
        >>> correct. However, if you start moving the start point - SO Principles -
        >>> the
        >>> 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
        >>> things.
        >>> Well, we do not really know where we live, we create models to describe
        >>> it.
        >>> SOA is one of such models and Loose-Coupling and Autonomy principles help
        >>> a
        >>> lot to distinguish application from service, to define service and build
        >>> the
        >>> whole architecture on this definition. If the concept of choreography
        >>> does
        >>> not fit into this architecture, it does not mean the architecture has to
        >>> change. I am saying so, because this architecture has another mechanism
        >>> of
        >>> collaboration - orchestration.
        >>>
        >>> Plus, my and your arguments about known needs of collaboration clearly
        >>> state
        >>> that the collaboration is the add-on to the service, an external thing.
        >>> This
        >>> 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
        >>> aggregate
        >>> 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
        >>> can
        >>> 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
        >>> functionality
        >>> and provide for RWE precludes from negotiation feature in the manner of
        >>> 'I
        >>> 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
        >>> this
        >>> 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.
        >>> The
        >>> survival power of the business is in the art of re-combining those
        >>> separate
        >>> 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
        >>> requirement
        >>> 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
        >>> SOA
        >>> RM and not very much in SOA RA). I am not saying that collaboration is
        >>> not
        >>> for SOA, oppositely, it is but collaboration and choreography are not the
        >>> synonym. If an SO solution hits business flexibility (changeability) ,
        >>> like
        >>> 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
        >>>> in
        >>>> 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
        >>>> would
        >>>> be
        >>>> more preferable than orchestration in SOA, i.e. where me must violate SO
        >>>> Principles to have choreograph- based solution. If we deal with
        >>>> stand-alone
        >>>> self-contained autonomous services, then any idea about their
        >>>> collaboration
        >>>> 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
        >>>> between
        >>>> SOA and choreography (I know how unusual this sounds).
        >>>
        >>> It sounds more than unusual to me, it sounds wrong.
        >>>
        >>> Steve
        >>>
        >>>>
        >>>> - 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
        >>>> engaged
        >>>> in
        >>>> a collaboration but only one of them (say P1) holds a state, then the
        >>>> situation is one of "Orchestration" rather than "Choreography" . Only P1
        >>>> can
        >>>> 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
        >>>> "slaves":
        >>>> 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
        >>>> participants
        >>>> and they all have their own sequencing rules/constraints. Choreogrpahy
        >>>> is
        >>>> about managing the collaboration in such a way that all their
        >>>> constraints
        >>>> are obeyed but without one distinguished orchestrator. In other words,
        >>>> it
        >>>> is
        >>>> peer-to-peer between stateful participants.
        >>>>
        >>>> Rgds
        >>>> Ashley
        >>>>
        >>>
        >>>
        >>
        >>
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.