Working Group home page · Meeting records
AT&T Mark Jones Carnegie-Mellon Katia Sycara Chevron-Texaco Roger Cutler Computer Assoc. Igor Sedukhin Contivo Dave Hollander HP Yin-Leng Husband HP Zulah Eckert IBM Heather Kreger Iona Eric Newcomer Nokia Mike Mahan Oracle Martin Chapman Progress Colleen Evans SAP Sinisa Zimek See Beyond Ugo Corda Software AG Mike Champion Sun Doug Bunting Thomson Hao He (remotely) Tibco Don Mullen Toshiba Frank McCabe W. W. Grainger Daniel Austin W. W. Grainger Tom Carroll W3C Hugo Haas W3C David Booth Web Methods Prasad Yendluri
See agenda posted by the Chair.
See meeting summary posted by the Chair
Morning of Jan 22 Scribe Katia Sycara Review of agenda items by Mike C Discussion of the recent WS-Reliability proposal Note: Various non-technical comments have been removed from the raw minutes. Eric: the ideal should be that one org would drive the web services standards. In wsa we should provide the framework and arch document as our greatest contribution. Francis: in wsa we should answer where reliability fits in Fragmentation is already happening. Martin: we don_t have control of where things will be happening. W3c or oasis or what not. I hope that oasis and w3c do not start the same activity at the same level. So, absolutely we need the framework and then asses do we need an RM group? MarkJ: fragmentation for me is that work starts in other places that do not have the same view so you get specs that do not fit with the w3c framework. DaveH; One consideration is our intent to provide an architecture for the industry at large. Doug: we should consider how a decision as to where it will go affects anybody. We should concentrate on the arch of how to deliver a reliaable solution no mater where the particular spec is done. MikeC: we are responsible for the w3c mgt as to keep it abreast of what is happening in the community regarding specs. Heather: we should have in our document a position of what rm means for the web services. Frank: w3c infrastructure focuses more on infrastructure specs and oasis more on the business stuff (this is an informal assessment) reliability is at the infrastructure level. Dave H proposes the following issues to be discussed 1. Arch Framework _ Definitions _ Scope and structure 2. Where _ Charter wg _ Urgency 3. Patents/RFK 4. Criteria _ Relationships _ Existing work _ Size _ Overhead _ Focus and level DaveH: nibleness is important. With 20/20 hindsight I do not see how we could have accelerated the process for choreography (following the w3c process). Martin: RM is small DaveH: not necessarily the case DaveH I have at least 4 internal models of rm. From getting a message from one pt to another to n-full scale transactions. So we need working definitions, meaningful ontology around reliable and identifiable deliverables for the wsa (tomorrow_s agenda) DaveH Discussions about where the work needs to take place and the urgency with respect to an approx scope of the ws-rel MarkJ: should we convey to the w3c about smallish sets of work that need to get done and perhaps the w3c can launch a different type of wg. DaveH: this fits into deliverables. . DaveH Develop criteria for evaluating these proposals. We could then inform other groups as a general framework for making decisions. After some discussion, there was the identification that there are problems out there that are (a) either too small to charter a whole wg or (b) fall within the scope of more than one wg so they _fall through the cracks_. We agree that this is a problem (consensus). ***Consensus vote to work on issue 1.(umbrella of reliability) In agenda tomorrow morning. MikeC should we make some response to w3c regarding ws-rel ? (issue 2) Issue 2 gets a -5. Zulah: let us have breakout session for issue 2. --* consensus vote not to enter patent discussion DaveH formulating a statement to w3c magt as to criteria for how our group reacts to different industry proposals eg ws-reliability, ws-policy DaveH: Additional issue of consistency and fragmentation (if there is time for the group to produce a statement) THE REST OF THE MORNING _joint session with WSD AFTERNOON (Jan 22) before the break Mike C. reviews the breakout sessions David O reviewed some of his proposals to wsd (see url) THE GROUP BREAKS INTO BREAK SESSIONS: 1. Reliability 2. wsa document 3. glossary Notes from the Reliability breakout session: ebXML - Contracts that the sender and receiver have to do in implementation with respect to persistent store and other protocol aspects. Make no assumption about reliability of transport. Acknowledgement-based protocols say a lot about what the two sides do about persistence. Some systems get reliability by sender storing message. Store and forward - store on the sender side. Either succeed because gets success within timeout or re-tries, or fails as far as it is concerned. Two bottoms of stacks - one is messaging, the other is transaction processing?? Want to get a mutual understanding that a message got transferred. Three levels - Transport, Soap Bindind, Applicaion Transport - some transport mechanism give some levels of reliability. TCPIP different from SMTP. No uniform reliability guarantee at transport level that applies to all types of transport. Add reliability at higher levels to compensate to problems in lower level. Minimum - Fire and forget. UDP. TCP slightly better - gives response. Two directions, success codes. Synchronous Request/Response, connection oriented, timeout. HTTP rides on TCP HTTPR SMTP - has retries, local storage, store forward, exponential retries - time frames can be long.to find out if there is failure. Managing the constraint on the time to report is important to business process. SMTP is the first in stack that introduces a highly variable response time. Message Oriented Middleware - MOM - in both transport and binding layer. Capabilities: Determination of delivery status: Acknowledgement of message reception. Timout - lack of ack in some defined time. Persistence: Retry capability - sender Delivery status to levels. Receiver -Duplicate handling - delivery of message to app even if receiver fails - Managing resources - security, time, receiver queues allocation Did not discuss message ordering. Four levels of ack if two layers. 1 - Sender app got message to sender transport 2 - Send transport got message to receiver transport. 3 - Sender app got message to receiver app 4 - Sender app to receiver app and receive app confirms business constraints on message content. - typically considered outside scope of RM. There things that can be done separating SOAP Binding from transport to make the transport mechanism itself more reliable. SOAP provides a well-defined place to put the stuff required for these features. Acks can also be cascaded - the ack can be acked. This is done in TCPIP but not often at the app level. Can be part of the business conversation, not typically considered in scope for RM. Does the ack imply persistence? In messaging systems not always. Statistical reliability - happy with schemes that provide this. Assumption that acks involved with persistence. *** Really an acknowledgement protocol, not a reliability protocol per se. The acknowledger can lie, for example. Really talking about an ack infrastructure. From top-down there needs to be some understanding that turns this ack infrastructure into real reliability, at least statistical. This ackinowledgement infrastructure is only one component of system reliability. Have not discussed intermediaries. Afternoon after the break OUTBRIEF David O presented discussions in the group. Goal is to get to the point to differentiate and show how web services can be done in a restful vs an rpc style. David O will work on this and publish to the group. David O : this will also be potentially useful in the tech plenary as a presentation for rpc vs rest for implementing web services with properties and advantages and disadvantages. OUTBRIEF MarkJ does the RM messaging breakout session He draws a diagram (note: Mark please send Katia the diagram) Goal: tease apart various notions of mep, binding, choreography, the transport level. E.g. how many messages in an asynchronous exchange? Resulting concepts: patterns and state machines: descriptions to various levels of state machines Mark goes through some examples. MarkJ: Wsdl gives you a service centric description of a service pattern. If a is a service and b and c interact with it but also themselves from a wsdl description a does not know about b to c interaction. So, you need a god-like view. Choreographic level can capture these interactions. Understanding of this whole thing is to understand the application. You can think of choreography as being the application. So choreography is a way of defining the application. Another element (box) is the MEP binding structure that is the soap/http bind that implements the mep. Is it asynchromus request response? Is it choreography or an MEP? We tried to tease it apart. Mep= flow+ correlation+ fault Response can be seen as a response to the original message request rather than a choreography ab followed by ac is a choreographic pattern rather than a mep. Transport: faults generated at the mep, and they could be faults of the binding level or the application level. The 3 levels in the stack (bottom to top) transport, mep+binding, application+ choreography) OUTBRIEF: EricN does the outbrief of the wsa doc session Eric: We looked at the wsa document from first principles. The wsa doc should give a def of what web service arch is so as to help industry-wide clarification. Goal: get to a stable draft to put under change control So, our breakout group decided to put a statement at the beginning of the document as to the approach we are taking to the document. This approach we are thinking about relies on the core concepts, their relationships, the properties of security etc., requirements and constraints. Coherent approach that allows us to reformat the document rather than just discuss how to redo the diagrams. This can help us also relate the wsa document to the requirements document. So, the breakout group decided to: Make the wsa arch prescriptive vs descriptive Put the glossary as part of the architecture This will allow us to have criteria for conformance OUTBRIEF: Hugo: Glossary breakout (a) Definitions not consistently used within the document, so glossary should be part of the architecture doc. (b) Went through the document and found definitions that must be changed or word smithed. David B may be a good person to talk about def of discovery. Def of synchronous Def of protocol and coupling Def of Choreography Def of Several management terms Some terms from the req document did not have definitions, for now just remove the terms till their definitions are needed. E.g. capability, evolvability, stability etc that appear in the requirements that right now are not used in the wsa document. Additional issue: definition of web service, the description of Web Description Group has a different definition than ours.
Please record new action items <strong> element.
Refer to previous meeting minutes. Please record status with <strong> element.
ACTION: MarkJ to summarize this discussion. ACTION: Frank, Katia Eric and Zulah to work on refactoring the wsa document ACTION: Hugo to identify terms in the wsa document to be included in the glossary ACTION: Daniel Austin to identify terms in the requirements document that are not in the glossary
Please report here a list of the new action items.
See also the list of pending action items.