- From: Ugo Corda <UCorda@SeeBeyond.com>
- Date: Fri, 16 Apr 2004 12:28:08 -0700
- To: "Tony Fletcher" <tony_fletcher@btopenworld.com>, <public-ws-chor-comments@w3.org>, <public-ws-chor@w3.org>
- Message-ID: <EDDE2977F3D216428E903370E3EBDDC9032B8ABC@MAIL01.stc.com>
Tony, > I am fairly sure that abstract BPEL does not demand WSDL descriptions. Actually it does. Most of the BPEL spec applies both to executable and abstract processes. The differences for the case of abstract processes are detailed in sec. 15 and only relate to the way variables and assignments are defined. Ugo -----Original Message----- From: public-ws-chor-request@w3.org [mailto:public-ws-chor-request@w3.org] On Behalf Of Tony Fletcher Sent: Friday, April 16, 2004 4:54 AM To: public-ws-chor-comments@w3.org; public-ws-chor@w3.org Subject: Issue 662: specify at least two levels or types of Choreography description Dear Colleagues, Following on from the teleconference on 13 April 2004, I would like to emphasise that I consider this issue still open, and not closed by the discussion at the recent face to face. I do recognise the need to make forward progress - I have been critical of our slowness in the past and believe it is one of the factors in our loss of numbers over time. I would like to pay tribute to Nick and David and others for producing the draft specification and materially moving us on. However, I think it is even more important that we make sound decisions and are prepared to re-visit ones that may be unsound. Thus, I would urge the group to re-consider the decision made by those present at the F2F for the following reasons, which can be summarised as the decision is unnecessary and does not help our cause. Firstly the decision does not follow from the discussion. Decision: Bound to WSDL Discussion: premature to even establish this hierarchy/factoring .... there is a spectrum of "abstractness" (nothing bound --> fully bound) {Selective quoting deliberate} Secondly the decision does not meet the fairly obvious requirement that we should to enable a description of a basic message flow to be as simply as possible without requiring extraneous syntax. In raising this issue I put it like this (and this *requirement* should be clearly stated in the requirements document - if not please raise 662 as an issue against the Requirements document in addition to against the specification). One level could be called abstract or business process oriented or some such. It would support focus on the definition of the business exchanges. It would specify the allowed sequencing of messages and the nature of each message. It would not have to provide a precise specification (/schema) for each message nor how each message was to be transported. This it would allow agreement of the basic business 'protocol' but would be insufficient to enable interoperability on its own. Another level or type of Choreography description would provide a precise specification and schema for each message and how each message was to be transported. It would thus be a basis for interoperation or at least provide the interoperability specification of the upper layers of the protocol stack. Points for consideration: 1) The fact that this issue was raised on the 13 April 04 teleconference (and not by myself) and gave rise to a long discussion with at least 4 people speaking against the asserted resolution means that there is not consensus on the current solution amongst all those still active in the group. 2) When attempting to describe just the message sequencing of a choreography (what one might describe as a 'pure' choreography insisting on having WSDL descriptions as well brings nothing but extra complexity. Or to put it the other way around: what do WSDL descriptions add that is required in this case? 3) Imagine a choreography where one participant (A) exchanges messages with another (B) that exchanges messages with another (C) that exchanges messages with another (D) {i.e. four systems in a line). To describe this choreography using abstract BPEL would take a minimum of 2 abstract process plus the statement that there are only four participants (without that statement you need four abstract processes, otherwise you do not know that there is not something else connected to A or D). I am fairly sure that abstract BPEL does not demand WSDL descriptions. Surely our aim and differentiator from BPEL is that we need only one WS-Choreography XML document to describe this situation - at this level of detail. If we insist on having WSDL then you need 7 XML documents (1 WS-Choreography document and 6 WSDL documents) - and we loose! Proposal: That we allow several different versions of the same choreography (with differing amounts of detail) to be valid against the schema and against the text of the specification. At one end of the spectrum, the the simplest would be a single XML document that just described the allowed sequencing of messages of a stated nature (may just be stated in a comment or documentation element). There would be no requirement to provide WSDL descriptions or schemas for the messages. Another common point on this spectrum might be where there is the Choreography description plus the WSDL descriptions including the message schemas - as required by WSDL 2.0 - but no binding information. The other end on the spectrum would be to provide all the detail possible - Choreography description plus the WSDL descriptions plus bindings. The justification for this level of detail is that it is only this level of description that gets you anywhere near to interoperability. Notice to that it is my hope that you can start at the simple end and develop a description incrementally and have syntax and 'good practice' support as you do so. It should be possible to couple in WSDL descriptions naturally at the appropriate point in the development cycle. Different points on the spectrum can be used for different purposes and so it is advantageous to have them as valid and checkable. The simplest descriptions will be used in the initial design and to gain agreement to that design. That level and more detailed levels will be usable by developers (for instance) and the most detailed level will be useful for system administrators / system configuration. Sorry for the lengthy message, but I hope it makes the point. Best Regards Tony A M Fletcher Home: 35, Wimborne Avenue, IPSWICH IP3 8QW Tel: +44 (0) 1473 729537 Mobile: +44 (0) 7801 948219 amfletcher@iee.org (also tony.fletcher@talk21.com & tony_fletcher@btopenworld.com)
Received on Friday, 16 April 2004 15:28:39 UTC