I do mean that sort of thing conceptually, as in the parties would agree on those goals and solutions but that doesn't mean that it would have to be implemented as a goal oriented technology solution. Now I did do some agent work a few years ago and conceptually we modelled it as a set of collaborating business services. Most of these used a proprietary Java to Java communication but the communication from the Agent system to the outside world was done via WS. So in other words the external feeds for the choreography were WS while the co-ordination was Java only. I used to think of it as having a conductor who brought together the various pieces and drove them through towards the goal.
Steve 2008/8/31 Michael Poulin <[EMAIL PROTECTED]>: > Steve, > by "goal oriented", do you mean an Active Agent-like model where each Agent > has a goal and recruits others, if needed, to fulfill it (this concept > surfaced some time around 2000/2001)? In such case, each Agent had to know > how to 'dance' with each other. However, I doubt the Agents were allowed > that time to be totally different entities... > > How a "goal oriented choreography" appears to you? > > - Michael > > ----- Original Message ---- > From: Steve Jones <[EMAIL PROTECTED]> > To: [email protected] > Sent: Sunday, August 31, 2008 6:31:41 PM > Subject: Re: [service-orientated-architecture] Re: Distinction between > "Choreography" and "Orchestration" > > There is nothing stopping a WS application returning a WSDL or even a > BPEL fragment to indicate its next valid call. So the fixed-endpoints > thing isn't a limiting thing of WS, it could be argued that in a goal > oriented choreography that a more formal document exchange is liable > to be more effective (e.g. vendor managed inventory) as it enables the > async exchanges which implies some form of long term commitment to > endpoints. > > Steve > > 2008/8/31 Alan Dean <[EMAIL PROTECTED] com>: >> Michael, >> >> I think that, from the perspective of REST, the statement that the >> participants "may not change the Internet locations of the end-points >> (w/o breaking the contract)" is incorrect. >> >> Whilst this may well be true of WS-*, the uniform interface constraint >> of REST means that the application state is surfaced via hypermedia - >> not fixed endpoints. >> >> Regards, >> Alan Dean >> >> On Sat, Aug 30, 2008 at 7:40 PM, Michael Poulin <[EMAIL PROTECTED] com> >> wrote: >>> I think Rob is right about "URI and HTTP verb semantics" (?) >>> >>> Now, if we get back to WS-CDL and its Global Contract, we end up with the >>> contract for entire choreography with frozen set of URI/Ls. That is, the >>> participants may not change the messages only but also may not change the >>> Internet locations of the end-points (w/o breaking the contract) unless >>> they >>> start to operate with DNS aliases. Am I right? >>> >>> - Michael >>> >>> ----- Original Message ---- >>> From: Rob Eamon <[EMAIL PROTECTED] net> >>> To: service-orientated- architecture@ yahoogroups. com >>> Sent: Saturday, August 30, 2008 5:18:56 PM >>> Subject: [service-orientated -architecture] Re: Distinction between >>> "Choreography" and "Orchestration" >>> >>> I'm not a REST practitioner, but would this be covered via a >>> combination of URI and HTTP verb semantics? URI would indicate the >>> appropriate resource, eg. Order, Payment, etc. PUT/POST would "place >>> order", "amend order" and "make payment" (I'm unclear on whether put >>> or post would be appropriate here), DEL would cancel. >>> >>> Minimizing/eliminat ing the mixing of the verb/action into the >>> document being exchanged would seem to be a good thing to strive for. >>> >>> -Rob >>> >>> --- In service-orientated- architecture@ yahoogroups. com, "Ashley at >>> Metamaxim" <ashley.mcneile@ ...> wrote: >>>> >>>> To bring this whole thing back to the REST vs. SOAP issue: >>>> >>>> All the approaches to choreography that I have seen, including but >>>> not limited to WS-CDL, require that the choreography integration >>>> infrastructure be able to identify the messages exchanged between >>>> the participants at the "business semantics" level: i.e., >>>> that "Place Order", "Amend Order", "Cancel Order", "Make Payment" >>>> etc. are distinguishable as such to the choreography management >>>> mechanism. >>>> >>>> Does this mean that REST, whose messages conform to a standardised >>>> vocabulary (GET, PUT, POST, DELETE) that does not expose the >>>> messages' business semantics, is incompatible with choreography? >>>> >>>> Any thoughts on this? >>>> >>>> Rgds >>>> Ashley >> > >
