Web Services Architecture Working Group
22-Jan-2003 meeting minutes

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

Detailed minutes

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)

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
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.


Determination of delivery status:
Acknowledgement of message reception. 
Timout - lack of ack in some defined time. 

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.

Review of outstanding action items

Refer to previous meeting minutes. Please record status with <strong> element.

Summary of new action items

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.

Chairs: Mike Champion <Mike.Champion@SoftwareAG-USA.com> and Dave Hollander <dmh@contivo.com&gt
Scribe: Katia Sycara