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