Udi, when i said "bad model", it was not what I meant. The model was, probably, good but it modeled bad business case. That is, it modeled existing business parctice which was one of possible implementations of real business process and that implementation was not right for new capabilities.
This is common case - IT automates not real business process but its operational appearance which was created based on poor capabilities available that time. To get the most from SOA, the IT has to automate real business process/featuree/function. They are all written in the business model but the latter is almost invisible through the business operations. We can alk about this more when i return. - M. ----- Original Message ---- From: Udi Dahan <[EMAIL PROTECTED]> To: [email protected] Sent: Monday, September 1, 2008 1:19:13 PM Subject: RE: [service-orientated-architecture] Distinction between "Choreography" and "Orchestration" > we are dealing with stateful services Business services are responsible for their own state – whether they store it in memory, on disk, or wherever. I assume that you’re referring to the state of the conversation (from the perspective of each service – each maintaining its own state) as being something different – but the question is, why should it be any different? > What is “tentative confirmation”? I’ve received your request and, at face value, it looks like there won’t be any problems – however, I reserve the right to call you back at some later point in time to tell you that I can’t fulfil your request. This is better than arriving at the airport/hotel and finding out your seat/room has already been sold to someone else – allows you to perform your own internal compensation. > Does it mean there is assumed another message exchange later on to finalise the reservation? Yes. The time this message exchange occurs is usually derived from two factors – what is the provide_by of the reservation, and the needed lead time for that reservation. Manufacturing a million pencils has a different lead time than manufacturing ten thousand. Also, the type of product has an effect – manufacturing a pencil vs. a desk. > 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"? First of all, you can do choreography without a global contract. The contract of R defines all messages needed by parties in the conversation. Second, the message back from R (to S1, S2, or whoever) isn’t necessarily returned over the same channel – in other words, R will notify the service about changes to the status of its reservation. > What does mean that "previous reservation cannot be completed" for S1? R has half of its resources allocated to S2, and now cannot complete the previous reservation (for ¾ of its resources) for S1. As such, it notifies S1. > What if S1 has allocated its resources already? That’s life. Just to try to remove any ambiguity – resources here usually refer to real world things like hotel rooms, seats on planes, time on machines, etc. We’re not necessarily talking about threads, memory, etc – although when designing media servers it makes lots of sense to do similar things with technical resources to give the needed quality of service to higher paying customers. > How the R knows that S1 is waiting for the final confirmation? R doesn’t really care. If S1 decided to go ahead without waiting for final confirmation, that’s its decision. By the way, this DOES happen where each partner has different lead times – risk calculations are performed to see whether it makes sense or not. Also, the original reservation includes a confirm_by field. If R sees that it cannot confirm by that time, it sends a notification. What we’re trying to do is to model real world interactions where each party does its own risk management trying to maximize profit/turnaround time/or whatever its business goals are. Time is often a core element of these interactions and thus needs to be represented in the contract. What is often built upon this foundation are agreements between parties giving them priority over others – travel has a lot of this. Let me add that while this inter-business- service interaction is more choreographical in style, internally, their may be quite a bit of orchestration going on between existing backends. Hope that makes sense. -- Udi Dahan - The Software Simplist From:service-orientated- architecture@ yahoogroups. com [mailto:service- orientated- architecture@ yahoogroups. com] On Behalf Of Michael Poulin Sent: 01 September 2008 01:54 To: service-orientated- architecture@ yahoogroups. com Subject: 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. - Michael ----- Original Message ---- From: Udi Dahan <thesoftwaresimplist @gmail.com> 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 <[EMAIL PROTECTED] 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 No virus found in this incoming message. Checked by AVG - http://www.avg. com Version: 8.0.169 / Virus Database: 270.6.13/1642 - Release Date: 31/08/2008 16:59
