2008/9/6 Michael Poulin <[EMAIL PROTECTED]>: > Sorry for shaking almost dead fish - I have found a few points in Steve's > note thta, I think, very important for understanding of dynamic > orchestration: > > 1) "its important for the goal to be mutual" sounds like a pure > process-oriented thing to me. This is fine until we can convert process into > service and vise verse. Nevertheless, is this right understanding that the > mutual goal is expressed by the process-service exclusively; that none of > the participating/engaged services are aware of this goal?
How is this a process thing? Take VMI. There is a "mutual goal" of reducing stock in the warehouse/store and of decreasing out of stock errors. Its nothing to do with process its purely about the end state (or really steady state) to be achieved. Collaborative systems only work well when you have mutually inclusive goals. > > 2) if I combine my question from the previous post (see below) with Steve's > answer "Yes" and three things of the process, I feel I am missing something. > In particular: > > a) process I: "async options which can be called repeatedly" - why a > service, which "indicated "the next stages of the process flow"" would do > this? The process I does not require to call those async options which can > be called repeatedly, it only announces that they might be called. The > latter may be easily expressed via a Service Description; they doe not > enforce a process to move into this or that direction; they are functions, > not actions But at a given point in time only certain of those functions are valid and it might be that there is an ordering to the async piece. e.g. before committing an order you need a delivery slot. Async doesn't just have to mean a single action it can be a series of pieces that can be called repeatedly but which much be called in a specific order. > > b) process II - I agree, this one may be the process driver, i.e. > instruction on what has to be called after what. However, I am not sure why > a service would do this. If a service aggregates several cohesive > functions/methods/operations and still appears as stateless, it does not > make sense to dictate which operations has to be called after what (they are > independent and stateless). Stateless is a myth. Every service is expected to retain its state. If you commit an order then the service is expected to remember it. This is state. In terms of ordering. If there are two capabilities "fraud check" and "Take payment" then I want to make sure that someone has done a fraud check before doing take payment if the amount is over 2k. I want to tell the consumer to do this rather than doing it internally in my service (as the fraud and payment service might be independent). > Otherwise, the service has to be stateful. Services have to be stateful anyway. The question is on state management of a flowing interaction, which isn't required if you are enforcing an order. > Moreover, I do not see why a service that must perform particular series of > actions has to expose different operations. It may be one container-like > operation that can accept one message while the schema of the message can > carry all necessary operations in certain order and with all needed input > data. This, this becomes a managing service rather than a proposition to the > external process (I have an example of such service with extensibility in > Service Reuse and Entitlement - http://soa.sys-con.com/node/523434 ) Which is one way of doing it. It has the slight disadvantage of becoming a bottleneck, especially around bandwidth. > > 3) process III - a bit unclear to me. If one participant asks another > participant to "run this on my behalf", the asked participant has to have an > ability to re-negotiate all Service Contracts for the potentially engaged > (on-behalf) services. > If "run this on my behalf" is not about running other services on behalf of > the requester, it is OK but how the asked participant would know that non of > the accepted activities does not include a third service? All this becomes > quite complex to me. Oh yes, its certainly complex. The point is that yes you are in effect asking an infrastructure to execute a service on your behalf, so its a bit cloud/Jini but we didn't think that at the time it was just because bandwidth was becoming an issue with all the polling requests across the network. In terms of the impacts then that was about contracts and the level of liability that was accepted by the various parties. The solution was legal in other words rather than technical. > Plus, how one participant know about another participant in the first place > unless the first one performs a run-time search for certain functionality > (in a service registry/repository) and finds adequate service? Can we deploy > the first service with no guarantees that the second service can be found > when needed? That is, an external process-service, which is composed > up-front, becomes the necessary thing, doesn't it? We had a meeting. I know its not technical heaven but when you have a fixed number of suppliers and a fixed customer then its much easier to just sit down and bash out the answers than having some "clever" dynamic infrastructure. > > Once I designed and implemented a GRID with architecture comprising a > central dispatcher and multiple identical agents deployed on network nodes > with different computational capacities. None of the agents guaranteed it > was available for the task (to be dispatched to it) due to local resource > states. When resource became available, the agent reported to the dispatcher > and got its task for execution. This model looks similar to Steve's process > I and III. However, none of the agents indicated to the dispatcher what the > agent needed to be done by the dispatcher to address business goals of the > agent. That was my initial question! The agent stuff was doing in a different part, it did the forecasting so was effectively a service, that was proprietary technology. I'm not saying it was simple stuff. Just that this was what worked given the technology we had available. Steve > > - Michael > > > > ----- Original Message ---- > From: Steve Jones <[EMAIL PROTECTED]> > To: [email protected] > Sent: Tuesday, September 2, 2008 4:52:40 AM > Subject: Re: [service-orientated-architecture] Re: Distinction between > "Choreography" and "Orchestration" > > 2008/9/1 Michael Poulin <[EMAIL PROTECTED] com>: >> Steve, would it be proper understanding of your splendid example if I say >> that each participant indicated "the next stages of the process flow" that >> addressed its business goals? > > Yes. Or more explicitly indicated the interactions that would help > the participants reach the mutual goal. Basically the process would > be one of three things. Firstly a case where there are a number of > async options which can be called repeatedly (information sources and > triggering events) and secondly a case where things must have a > defined order (e.g. a fraud check before a credit card payment). > Where it got clever was the third case with these being exchanged > between participants often with one side having the fixed process and > the other the eventing, this gave some good performance boosts as it > reduced the amount of network traffic by shifting the processing onto > the other end. This third case was in effect "run this on my behalf". > >> >> I can imagine a policy/rule that might allow such dynamic construction of >> the process. However, if participants were really independent (?), who did >> you resolve potential situations of conflicts of interests (between just >> received response from participant A and other participants that were not >> called yet but assumed to be called (by BPEL) if participant A would not >> change the process flow )? > > Which is why its important for the goal to be mutual. In something > like vendor managed inventory you have such a thing. Thus there is no > reason to not follow the defined process. Despite what others have > claimed however its normal in enterprise and B2B environments for the > different sides in a negotiation to be active participants in the > whole project with all of the rules, and penalties, being laid down to > ensure conformance. > > Steve > >> >> - Michael >> >> ----- Original Message ---- >> From: Steve Jones <jones.steveg@ gmail.com> >> To: service-orientated- architecture@ yahoogroups. com >> Sent: Monday, September 1, 2008 12:33:10 PM >> Subject: Re: [service-orientated -architecture] Re: Distinction between >> "Choreography" and "Orchestration" >> >> What I'm saying is that I worked on a project where we used BPEL >> fragments as attachments to the content messages to indicate the next >> stages of the process flow. The BPEL doc was fixed after the point of >> negotiation but was effectively a state machine anyway. >> >> WS clients don't have to be compiled (I personally prefer it most of >> the time) and can be done dynamically, its only XML doc handling after >> all. >> >> So not theoretical, but definitely not a mainstream application. >> >> Steve >> >> 2008/9/1 Alan Dean <[EMAIL PROTECTED] com>: >>> There is something stopping it: Compiled proxy clients. >>> >>> Also, WS-* is designed to be agnostic of HTTP so it doesn't have a >>> redirection mechanism built-in (that I am aware of). The reality of >>> the WS-* toolset is a formalisation of fixed endpoints. >>> >>> Perhaps you are correct in saying that theoretically WS-* can be >>> dynamic (although it seems to me that doing so would require every >>> service invocation to be preceded by a WSDL request - which raises >>> WSDL<->invocation choreographic issues of it's own as they are >>> separate requests) but in practice, such services do not exist. >>> However, in REST, hypermedia is baked-in to the architectural style as >>> a formalised constraint. Very different. >>> >>> Alan >>> >>> On Sun, Aug 31, 2008 at 6:31 PM, Steve Jones <jones.steveg@ gmail.com> >>> wrote: >>>> 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 >>> >> >> > >
