- From: Gary Brown <gary@pi4tech.com>
- Date: Wed, 09 Aug 2006 09:59:14 +0100
- To: "L.G. Meredith" <lgreg.meredith@gmail.com>
- CC: Kohei Honda <kohei@dcs.qmul.ac.uk>, Marco Carbone <carbonem@dcs.qmul.ac.uk>, Steve Ross-Talbot <steve@pi4tech.com>, WS-Choreography List <public-ws-chor@w3.org>
Hi Greg Responses to your inline comments: > > > > The Role of Choreography in Model Extraction > > > > In the model extraction scenario an application developer writes in > > something like a C#++ or C## (= D?) and from this application we > > extract a model and check it against the endpoint descriptions. Now, > > in this scenario, what is the value of a public description of the > > specific model? As long as there is some algorithm derived from > > > > * a generic description of the modeling language and > > * the generic descriptions of the endpoint description language > > * and optionally a public description of the model extraction > > algorithm > > > > then there can be public confidence in a conformance check of an > > application against an endpoint description without ever > exposing the > > model extracted from the application. The application logic remains > > behind the firewall, the endpoint description is posted to a service > > discovery repository, but the model is never published anywhere. The > > upshot of this analysis is that in this scenario i believe there > is a > > question about the value of Choreography except as a public > > specification of the generic modeling language. No one ever need > > publish a specific choreography (= extracted model). > This scenario is focusing on the specific service endpoint, and > therefore the choreography is not as relevant. However, if we are > dealing with a service registry within an organization, then I am sure > that the organization (as part of its governance procedures) would > want > to ensure that any updates to that service endpoint did not affect > current clients of the service. The best way to do this is to have a > choreography description of your business processes and then > ensure that > the updated service endpoint description still conforms to the > endpoint > requirements associated with those choreographies. I think this > type of > validation will be essential to the adoption of SOA within > organizations > that may have a large number of services. > > > i do not find this argument particularly compelling under the > operating assumptions. If we continue to assume that > > * there is an automatic way to extract a model from a given > service implementation; > * there is an automatic way to calculate conformance of the model > to an endpoint description > > then if we update either an endpoint description in a discovery > repository, or a given service advertising to provide service > conforming to an endpoint description, then surely the model ( a.k.a > choreography) may safely remain hidden behind the firewall and > generated at the time of the conformance check, from the services > claiming or demanding conformance. The conformance check may be done > eagerly, at the time of the update to the discovery repository, or > lazily, at the time of service provisioning, or both. > > More to the point, a client to the service provider is only ever > interested in > > * the endpoint description, and > * whether the service conforms to that description > > and does not need (or want) to know the full details of the service > logic, or even as much detail as is offered in the model. > > For example, i am not interested to know whether Amazon uses > transactions or some kind of reflection-based computational model to > guarantee that my card gets charged only when the packaged gets > scanned before it goes on the plane. i just want to know that if my > card has been charged then the package is in the hands of the shipper. > This sort of assurance can be calculated from an endpoint description > like we find in usages. > I agree, generally the choreography would remain behind the firewall, because it usually will be in the control of the organization that owns the business process. However in some situations the choreography is describing a public business protocol between many organizations (no single owning organization) in which case the choreography would be public. However, to address your specific point, a choreography could be reconstituted from the service endpoint descriptions based on model extraction (of the observable behavior). This would be adequate for conformance checking - however it would not address the needs of an organization that wishes to use the choreography as a design that can evolve over time, where you then need to forward generate endpoint descriptions to understand the impact on the current deployed services (endpoint descriptions). Having a choreography may also be useful where the business process has to conform to specific regulations. If you only ever reconstitute a choreography from the endpoint descriptions, that may evolve over time, all you will be able to determine is that those services still operate correctly together. It may also be necessary to ensure that the choreography conforms to an abstract choreography mandated by a regulator. I take your point that conformance checking can be achieved based on an extracted model of the endpoint behaviors. However I believe there are other use cases that benefit from having a concrete description. > > > > The Role of Choreography in Executable Specifications > > > > A more radical approach to keeping model and application in sync > is to > > have them be one and the same thing. That is, we devise a language > > that is at once > > > > * semantically derived from our modeling language > > * semantically rich enough to write real applications > > * with an execution model performant enough to run them in the > > commercial setting (e.g. enterprise, desktop, gaming, etc.) > > > > With apologies to the community that originally coined the term, i > > commandeer the phrase executable specifications for applications > > written in such a language and call the language itself an > executable > > specification language. Terminology aside, with this approach > there is > > no model extraction phase as such (unless you see it as part of the > > conformance analysis -- which is throwing away tons of application > > detail). The model is the application. > > > > In some sense we are back in the world developers know and love > -- we > > don't need no stinking spec -- the code is the spec. Further, there > > are tremendous benefits from this approach, many of which have > to do > > with using the static analysis to directly aid development as > the code > > is being written, ala the way intellisense works, etc. > > > > This line of thinking is what has led many to try to develop a > > \pi-like language rich enough to do application development. > But, the > > question is, what is the role of Choreography in this scenario? i > > submit to you that it must ultimately give rise to such a \pi-like > > language either by becoming one or by helping to open the way > for such > > a language to develop and gain adoption in the market place. > > > > Note, however, that even in this scenario, application code (= > model) > > will certainly not be published. A public description of the > > executable specification language certainly needs to be publish, > this > > would be something like the ECMA spec for C#/.net or R^5 Scheme > spec. > > But for specific service offerings only the endpoint > descriptions will > > be published. > Interesting idea. Not sure it is suitable for the choreography to > provide such an executable specification - especially as it > represents > the global view. However, if such an executable specification was > available, then it would be easier to do conformance checking without > worrying about synchronization issues between the implementation > and the > endpoint's behavioral description. > > However, getting a new language adopted and used by developers is > not an > easy task. Therefore even if such a language was devised, we would > still > be left with many services written in .NET and Java. > > Do we not already have such an executable specification - i.e. BPEL? I > am sure it is nothing like the language you would prefer, but it would > be very easy to extract a model from it. Although for a similar > reason > as stated above, I don't see BPEL becoming the predominant service > execution language (plus it is currently limited to Web Services). > > > i see that my choice of terminology was unfortunate. In the case i was > outlining i was using the notion of executable specification more > along the lines of Haskell or OCaml. These are fully functional, > general purpose programming languages. People write real-world, > commercial applications in these languages. For example, Jane St. > Capital writes trading applications in OCaml. But, these languages > still enjoy a high degree of abstraction and discipline and carefully > designed applications in these languages can certainly claim to be > specifications -- especially Haskell. > > BPEL, on the other hand, does not enjoy sufficient detail to be a > general purpose programming language. No one in their right mind, i > would submit, would find this to be a suitable language for writing > commercially deployable applications. There's just not enough of the > usual language and execution infrastructure for that. Nor does BPEL > enjoy enough abstraction and discipline to qualify as a specification > language. There are too many semantic ambiguities and too many > competing programming models -- when last i looked at the spec -- to > take BPEL seriously as a specification language. > > i do see quite a wide niche for something like Haskell or OCaml, but > with much richer and more appropriate concurrency and distribution > models than these languages natively support. To wit, i would argue > that on the client side the popularity of AJAX is making the case for > a language-based approach to concurrency in a much more compelling way > than any academic argument. People find AJAX programming very > difficult, but are unwilling to live with the consequences of > sequentializing everything ala old-style web-based interfaces. And, on > the server side, i believe it easy to coopt all of the arguments your > group has made to support this position -- under the operating > assumption that it is essential to prevent drift between model and > service. > If you could get the right group of people (+organizations) together that were interested in doing such a new language, then I think there are a number of people on this group that would love to participate. However, from a commercial perspective, looking at the current state of the art (and adoption) we need to find a solution that will support Java and .NET services. The reason for mentioning BPEL was because it is probably the best candidate for model extraction out of the popular endpoint implementation technologies - however I don't know what the actual level of adoption really is in terms of deployed production BPEL services. > s > > > > > > On 8/3/06, *Gary Brown* < gary@pi4tech.com > <mailto:gary@pi4tech.com> <mailto:gary@pi4tech.com > <mailto:gary@pi4tech.com>>> > > wrote: > > > > Hi Greg > > > > Just to respond to your last point, I think there is > definitely a > > place > > for both 'full blown choreographies' representing a global > view of > > a set > > of interacting services, as well as a description of the > specific > > behavior associated with a service. They have different > roles to play. > > > > The global model provides a design approach to enable the > > responsibilities of each service to be understood with > respect to a > > particular business process. This global model can then be > used to > > derive the behavior of a new service, or ensure that > existing legacy > > services conform to the required behavior (using the service's > > observable behavior description). > > > > Similarly, as you have described, if a service has its own > endpoint > > behavior description, then it would be possible to do a > behavioral > > equivalence lookup within a service registry. However, the > required > > service behavior could be derived from the choreography. > > > > At the moment Marco and Kohei's type system addresses both > of these > > aspects, it is only WS-CDL that is lacking an endpoint > > representation - > > which as you have pointed out would ideally be a simple > extension to > > WSDL. But that was not within the charter of the working group. > > > > However, this is one area where potentially abstract BPEL may > > provide a > > solution, but that does not preclude other more compact > notations > > being > > associated with the WSDL in the future. > > > > Regards > > Gary > > > > > > L.G. Meredith wrote: > > > Kohei, > > > > > > Many thanks for the edifying remarks. i hope you will > allow me to > > > probe on a related front. > > > > > > Suppose we took a different approach to the architecture of > > WS-CDL in > > > which what is published is something like (collections of) > > Kobayashi's > > > usages, (an appropriately XML-ified version of) which could be > > seen as > > > a simple and direct extension of WSDL, leaving more detailed > > > descriptions of service logic (in which resides potentially > > > proprietary business value) behind the firewall, so to speak. > > > > > > i emphasize publish in this context because i want to call > > attention > > > to what's of general public interest in a service > description. i > > argue > > > that the primary function of a public service description is > > search. i > > > submit that in a world where SOA is the norm there will be > > billions of > > > services, and a service consumer will need to find > services that > > > > > > * do what they need them to do (a semantic question) > > > * do it in a way that is compatible with their own > needs and > > > practices > > > > > > Further, i argue that the former is far more important > than the > > > latter. Consider the case where there is only one > provider. The > > > consumer will adapt to any incompatibility. (Note that > just because > > > there is only one such provider does not alleviate the search > > burden. > > > The consumer may not know of the provider, even when there is > > only one.) > > > > > > i want to argue that a great deal of semantic information > can be > > > gleaned from information about behavior. i can provide some > > > interesting and illustrative examples, if you want them. One > > question, > > > however, is how much information needs to public to help the > > consumer > > > address their needs, and what needs to remain behind the > firewall to > > > protect hard won business value? > > > > > > Now, to bring this line of reasoning back to my question > above. Does > > > the market need a standard to capture full-blown > choreographies? > > Or, > > > is there another niche that is likely to see better > adoption? For > > > example, consider a small extension to WSDL, like Kobayashi's > > usages, > > > which can -- in Marco's words more powerfully and more > generally -- > > > ensure both compatibility issues (like eliminating > deadlock) and > > > increase the information available by which to conduct > > semantic-based > > > search one. > > > > > > Best wishes, > > > > > > --greg > > > > > > On 8/2/06, *Kohei Honda* <kohei@dcs.qmul.ac.uk > <mailto:kohei@dcs.qmul.ac.uk> > > <mailto:kohei@dcs.qmul.ac.uk <mailto:kohei@dcs.qmul.ac.uk>> > > > <mailto: kohei@dcs.qmul.ac.uk > <mailto:kohei@dcs.qmul.ac.uk> <mailto:kohei@dcs.qmul.ac.uk > <mailto:kohei@dcs.qmul.ac.uk>>>> wrote: > > > > > > Hi Greg, > > > > > > It is great to get reactions so quickly. > > > > > > L.G. Meredith wrote: > > > > Marco, Kohei, > > > > > > > > Thanks for clarifying. i was refering to the EPP > theorem > > on page 85, > > > > which i took as the central result of the work. > Sorry, if > > i was > > > a bit > > > > eliptical. My thought was that the end point > calculus is > > actually a > > > > type system and end point projection was like the > > calculation of a > > > > kind of minimal type. Then, you can see the EPP > theorem in the > > > light > > > > of subject reduction. > > > > > > I may rather say that the global calculus and the end > point > > > calculus are > > > two different description > > > languages, each with its own typing system, with > respective > > notions of > > > minimum typing. > > > > > > The type structures are common, but the way > descriptions are > > typed are > > > quite different. > > > > > > The idea is to project each "well-formd" global > description to a > > > collection of endpoint processes, > > > which are the code for the participants involved. > > > > > > What the EPP theorem asks is: > > > > > > Do these projected participants interact following a > > scenario > > > (choreography) which the > > > original global description has laid out? > > > > > > It turns out that, if a global description satisfies > certain > > > well-structuredness, or "healthiness conditions", > > > then > > > > > > (1) there is a very simple endpoint projection, and > > > (2) the correspondence in behaviour is as exact as can > be. > > > > > > There are three well-structuredness conditions we have > > identified. We > > > believe they offer a natural > > > way to do a well-structured global description. > > > > > > I will post a brief discussion on the engineering > meaning of > > this > > > result, but for the time being let us > > > say the EPP theorem offers a way to relate the global > > description > > > languages and the process calculi. > > > The latter gives rigorous theories of behaviours, their > > properties > > > and > > > composition, while the former > > > offers a useful engineering medium. > > > > > > > > i know that you have a separate notion of typing > laid out > > in the > > > > paper, but i tend to think -- much in the way Kohei > laid > > out -- of > > > > towers of typing of increasing strength. Abramsky > gives a good > > > example > > > > of such in his Marktoberdorff lecture with Simon Gay > and Raja > > > > Nagaranjan on types for concurrency. > > > > > > On this point I firmly agree: types and various analyses > > including > > > process/program logics are great toos > > > especially when we know how to integrate them > consistently. > > > > > > > > > > > > > > That said, i was trying to draw an analogy between > the EPP and > > > > Kobayashi's usages. More specifically, in my mind > there is > > > connection > > > > between the fact that EPP is a function and > Kobayashi has > > a type > > > > inference algorithm -- apart from the practical > > implication that the > > > > programmer doesn't have to write the type. > > > > > > So the EPP theorem is not so much about type > discipline or > > program > > > analysis but rather about a basic way > > > to relate two distinct ways of describing interactions. It > > is like the > > > result on encoding of some calculi into > > > the pi-calculus, saying the encoding fully respects the > > original > > > dynamics, under certain conditions. > > > > > > These "under certain conditions" are the > well-structuredness > > > (healthiness) conditions. > > > > > > I will discuss on the general picture further in my coming > > post. > > > > > > Best wishes, > > > > > > kohei > > > > > > > > > > > > > > > > > Best wishes, > > > > > > > > --greg > > > > > > > > On 8/2/06, *Marco Carbone* < carbonem@dcs.qmul.ac.uk > <mailto:carbonem@dcs.qmul.ac.uk> > > <mailto:carbonem@dcs.qmul.ac.uk > <mailto:carbonem@dcs.qmul.ac.uk>> > > > <mailto:carbonem@dcs.qmul.ac.uk > <mailto:carbonem@dcs.qmul.ac.uk> > > <mailto:carbonem@dcs.qmul.ac.uk > <mailto:carbonem@dcs.qmul.ac.uk>>> > > > > <mailto: carbonem@dcs.qmul.ac.uk > <mailto:carbonem@dcs.qmul.ac.uk> > > <mailto:carbonem@dcs.qmul.ac.uk > <mailto:carbonem@dcs.qmul.ac.uk>> > > > <mailto: carbonem@dcs.qmul.ac.uk > <mailto:carbonem@dcs.qmul.ac.uk> > > <mailto:carbonem@dcs.qmul.ac.uk > <mailto:carbonem@dcs.qmul.ac.uk>>>>> wrote: > > > > > > > >> This looks like a lot of work. i may be > misreading, > > because i > > > >> have only skimmed, but it looks as though the main > > theorem > > > is a > > > >> subject reduction-like theorem in which the > subject > > > reduction is > > > >> simulation-style (ala Kobayashi's type systems) as > > opposed to a > > > >> static subject reduction (ala Honda, et al's type > > systems). > > > Have > > > >> you seen, therefore, Kobayashi's 2006 types for > > concurrency > > > paper ( > > > > > > > > > > > > Just to clarify, the paper has three main theorems: > > > > > > > > 1) Subject Reduction for the global calculus > type system > > > (session > > > > types) i.e. when the system evolves it is still well > > typed ( > > > e.g. > > > > I evolves to I' and I is well typed then also I' is > > well typed. > > > > > > > > 2) Subject Reduction for the end-point calculus > > (similar to > > > point 1) > > > > > > > > 3) EPP Theorem, i.e. > > > > a) Type Preservation i.e. a well typed global > > description is > > > > projected to a well typed global interaction. > > > > b) Completeness i.e. if a global interaction I > evolves > > to I' > > > then > > > > its projection evolves to the "projection" of I' > > (EPP(I') ) > > > > c) Soundness i.e. if a projection EPP ( I ) > evolves to > > N then I > > > > can evolve to I' and the projection of I' is > "similar" > > to N > > > > > > > > 1) and 2) guarantee that working with typed > programs > > is safe > > > (you > > > > never evolve to untyped i.e. unwanted things). > > > > > > > > 3) shows that given a global description ( e.g. > a WS-CDL > > > > choreography), its end-point projection is good and > > respects > > > what > > > > the programmer wanted to specify in the > choreography. > > > > > > > > Hope this clarifies the key points of the paper. > > > > > > > > Best, > > > > Marco > > > > > > > > P.S. > > > > I didn't read the paper you linked but I believe > it is > > related > > > > with another of his works i.e. having CCS > processes as > > types. > > > > Session types are related to this but > Kobayashi's are > > much more > > > > powerful and lose. > > > > > > > > > > > > > > > > > > > >> > > > > > > http://www.kb.ecei.tohoku.ac.jp/~koba/papers/concur2006-full.pdf > <http://www.kb.ecei.tohoku.ac.jp/%7Ekoba/papers/concur2006-full.pdf> > > > <http://www.kb.ecei.tohoku.ac.jp/%7Ekoba/papers/concur2006-full.pdf> > > > < > > > http://www.kb.ecei.tohoku.ac.jp/%7Ekoba/papers/concur2006-full.pdf> > > > >> > > > > > > <http://www.kb.ecei.tohoku.ac.jp/%7Ekoba/papers/concur2006-full.pdf > <http://www.kb.ecei.tohoku.ac.jp/%7Ekoba/papers/concur2006-full.pdf> > > > <http://www.kb.ecei.tohoku.ac.jp/%7Ekoba/papers/concur2006-full.pdf>>)? > > > >> > > > >> Best wishes, > > > >> > > > >> --greg > > > >> > > > >> On 8/1/06, *Steve Ross-Talbot* < > steve@pi4tech.com <mailto:steve@pi4tech.com> > > <mailto:steve@pi4tech.com <mailto:steve@pi4tech.com>> > > > <mailto:steve@pi4tech.com <mailto:steve@pi4tech.com> > <mailto: steve@pi4tech.com <mailto:steve@pi4tech.com>>> > > > >> <mailto:steve@pi4tech.com > <mailto:steve@pi4tech.com> <mailto:steve@pi4tech.com > <mailto:steve@pi4tech.com>> > > <mailto: steve@pi4tech.com <mailto:steve@pi4tech.com> > <mailto:steve@pi4tech.com <mailto:steve@pi4tech.com>>>>> wrote: > > > >> > > > >> > > > >> Is at: > > > >> > > > >> > > > > > > http://lists.w3.org/Archives/Public/www-archive/2006Aug/att-0000/ > <http://lists.w3.org/Archives/Public/www-archive/2006Aug/att-0000/> > > > > > > <http://lists.w3.org/Archives/Public/www-archive/2006Aug/att-0000/ > > < > http://lists.w3.org/Archives/Public/www-archive/2006Aug/att-0000/>> > > > >> workingNote.pdf > > > >> > > > >> Please read and comment as soon as possible. > > > >> > > > >> Cheers > > > >> > > > >> Steve T > > > >> > > > >> > > > >> > > > >> > > > >> -- > > > >> L.G. Meredith > > > >> Partner > > > >> Biosimilarity LLC > > > >> 505 N 72nd St > > > >> Seattle, WA 98103 > > > >> > > > >> +1 206.650.3740 > > > > > > > > > --------------------------------------------------------- > > > > Marco Carbone > > > > > > > > Dept. of Computer Science > > > > Queen Mary University of London > > > > Mile End Road > > > > E1 4NS London > > > > United Kingdom > > > > > > > > Phone: +44 (0) 207 882 3659 > > > > Fax: +44 (0) 208 980 6533 > > > > email: carbonem@dcs.qmul.ac.uk > <mailto:carbonem@dcs.qmul.ac.uk> > > <mailto:carbonem@dcs.qmul.ac.uk > <mailto:carbonem@dcs.qmul.ac.uk>> > > > <mailto: carbonem@dcs.qmul.ac.uk > <mailto:carbonem@dcs.qmul.ac.uk> > > <mailto:carbonem@dcs.qmul.ac.uk > <mailto:carbonem@dcs.qmul.ac.uk>>> <mailto: > carbonem@dcs.qmul.ac.uk <mailto:carbonem@dcs.qmul.ac.uk> > > <mailto:carbonem@dcs.qmul.ac.uk > <mailto:carbonem@dcs.qmul.ac.uk>> > > > <mailto: carbonem@dcs.qmul.ac.uk > <mailto:carbonem@dcs.qmul.ac.uk> > > <mailto:carbonem@dcs.qmul.ac.uk > <mailto:carbonem@dcs.qmul.ac.uk>>>> > > > > home: http://www.dcs.qmul.ac.uk/~carbonem > <http://www.dcs.qmul.ac.uk/%7Ecarbonem> > > <http://www.dcs.qmul.ac.uk/%7Ecarbonem> > > > < http://www.dcs.qmul.ac.uk/%7Ecarbonem > <http://www.dcs.qmul.ac.uk/%7Ecarbonem>> > > > > < http://www.dcs.qmul.ac.uk/%7Ecarbonem> > > > > > --------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > -- > > > > L.G. Meredith > > > > Partner > > > > Biosimilarity LLC > > > > 505 N 72nd St > > > > Seattle, WA 98103 > > > > > > > > +1 206.650.3740 > > > > > > > > > > > > > > > -- > > > L.G. Meredith > > > Partner > > > Biosimilarity LLC > > > 505 N 72nd St > > > Seattle, WA 98103 > > > > > > +1 206.650.3740 > > > > > > > > > > -- > > L.G. Meredith > > Partner > > Biosimilarity LLC > > 505 N 72nd St > > Seattle, WA 98103 > > > > +1 206.650.3740 > > > > > -- > L.G. Meredith > Partner > Biosimilarity LLC > 505 N 72nd St > Seattle, WA 98103 > > +1 206.650.3740
Received on Wednesday, 9 August 2006 08:59:37 UTC