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 <[EMAIL PROTECTED]> To: [email protected] 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 <[EMAIL PROTECTED] 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 <[EMAIL PROTECTED] 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 >> > >
