Web Services Architecture Working Group
24-October- meeting minutes

Working Group home page · Meeting records



AT&T Mark Jones
BEA Systems David Orchard
Computer Associates Igor Sedukhin
Contivo Dave Hollander
France Telecom Shishir Garg
Fujitsu Frank McCabe
IBM Heather Kreger
IBM Chris Ferris
MITRE Corporation Paul Denning
Nokia Michael Mahan
OASIS Hal Lockhart
Oracle Corporation Jeff Mischkinsky
Oracle Corporation Martin Chapman
Progress Colleen Evans
SeeBeyond Technology Corp Ugo Corda
SeeBeyond Technology Corp Steve White
Software AG Michael Champion
The Thomson Corporation Hao He
TIBCO Software, Inc. Scott Vorthmann
W. W. Grainger, Inc. Daniel Austin
W. W. Grainger, Inc. Tom Carroll
W3C David Booth
W3C Hugo Haas
webMethods, Inc. Prasad Yendluri


Apple Mike Brumbelow
Boeing Company Gerald Edgar
ChevronTexaco Roger Cutler
DaimlerChrysler Research Mario Jeckle
EDS Waqar Sadiq
Ericsson Nilo Mitra
Hewlett-Packard Company Yin-Leng Husband
MITRE Corporation James Davenport
Nortel Networks Abbie Barbir
SAP Sinisa Zimek
Sterling Commerce(SBC) Suresh Damodaran
Sybase, Inc. Himagiri Mukkamala
T-Nova Deutsche Telekom Jens Meinkoehn


See agenda posted by the Chair.

Detailed minutes


1.  Assign scribe.  We will be working down the list at [0]

[0] http://www.w3.org/2002/ws/arch/2/04/scribes-list.html

Scribe:  Paul Denning

2.  Approval of minutes [1] from last 2 week's' telcon

[1] http://www.w3.org/2002/ws/arch/2/10/minutes17October.html

(Time=0344 ET)
Minutes approved.  No objections.

3.  Review of Action items. 
ACTION: DaveO: Write text on use of URIs within DIME. [PENDING] [1]


ACTION: DanielA: will provide some information on meta-models. [PENDING] [2]

still pending

ACTION: DaveO: provide some pointers to Roy Fieldings Architectural


ACTION: Hugo to sort the MTF's situation out [4]
Zula has meeting minutes.  Work in progress.  Heather does not have a complete set.

ACTION: MarkJ to send wording to Hugo about attachment feature
implementation [5]


ACTION: Hugo to finalize and send response to the XMLPWG [6]


ACTION: Doug to send new wording re swizzling [7]


ACTION: Hugo to add some text asking to AF motivation [8]


ACTION: DaveO, to write something about documenting best practice (fuzzy
action item wording, but David will know what it's about) [9]


MC   Should WSAWG review WS-I profile?
CF   Recommends reading it.
DO.  Formal WSAWG response to WS-I should be an option.
E.g., look at terms like metadata vs service description.
Different definitions would be bad. Both WSAWG and WS-I doing work in this area 
(defining terms).

Don't wait to send in comments.

5. David Orchard suggests [4] that it would be a good thing to ask the
OASIS ws-security tc if they could provide wsdl definitions as part of their
v1 output.  

[4] http://lists.w3.org/Archives/Public/www-ws-arch/2002Oct/0197.html

Hal OASIS Liaison
DO.  Potential issues.
WSDL definitions 
WS-Security elements in messages
See WS-QOP list 
Question of timing
BEA feels WSDL should be in scope of OASIS WS-Security TC.
Should WSAWG ask OASIS WSS TC to make WSDL in scope?

Hal concurs with DO summary.  Added that WSDL should not be gating items for 
publications of WSS spec.
WSDL should not be a dependency
Many views on scope.
Little or no operational experience.
Separate TC for just this issue is a possibility.

DO.  Narrow scope is easy to defend.  BEA concerns to address interoperability.  
WSDl would help ensure interop.  Can interop be assured without WSDL?  E.g., 
how to specify password info.
If runtime things in spec makes it hard to describe in WSDL at development time,
 may want to change WSS spec to better address WSDL usage.

BEA feels it is generally good to have WSDL in addition to a spec.

(Hal?) Need more specifics.  How long would you be willing to delay WSS 
spec in order to get WSDL?

SAML auth token?
What authorities do you trust?  Other questions.

What is minimum needed in a WSS WSDL?  More than just well-formed XML.

1.0 min should have non-normative description of WSDL, prefer normative.

Use  extensibility features already in WSDL, not changes to WSDL spec.

DO.  Want elements (e.g., username, password, X.509 cert). Particulars 
of business arrangements, values of attributes should be beyond scope.

Hal does not feel WSAWG views would be objectional to WSS TC, but can't 
guarantee they would take action either.

Does WSAWG believe WSDL is good for interop?

MC.  Any contrary views?

Hal, please indicate tradeoffs and use cases.  Everyone is in favor of 
"WSDL", need to say more than that.

DO.  Avoid meddling in WSS TC.

[ACTION]  DO, revise proposal based on Hal's feedback.  Try to give types 
of things that WSAWG 

MC.  Do nothing (no WSDL) is not acceptable or preferable.

(Speaking for Roger) August 2002 slides of real-world web services. (Doesn't need WSS?) 

Hugo.  Can be discussed at WSCG meeting next week.

DO.  How and when does WSAWG need to engage WSCG when interacting with non-W3C 
groups like OASIS.


Hal.  Only approx 12 of 60+ members of WSS TC have participated in QOP discussions.

MC. recap.  get concensus within WSAWG on DO's revised proposal.

DO. Ask WSCG if it is improper to send such a message to WSSTC.

Reviewing latest editors draft of WSA document [2] and glossary [3]

Please look over the latest editors copy of these documents and make
comments.  We will discuss what needs to be done and decided upon to go to a
public working draft by the end of the month.

[2] http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch.html


2 documents.

CF.  cc wsa-comments list.

Hugo.  Expect some people to be unhappy with some definitions in glossary. 
We'll need to agree that its good enough to publish without full concensus
on all definintions.  

CF.  Thanks to Heather.

??.  WSDL Primer contains some general web services discussion.  Should we 
draw from it to add to WSA glossary?

F2F agreed to postpone a WSA primer until later. (Scribe note:  
I don't think he was talking about a WSA primer, rather using info from the 
WSDL primer to populate the WSA glossary).

Need to meet external committments, especially, Architecture document.

BEA believes reliability is very important and should be one of the next 
topics addressed.

MC.  Everyone should think about 1-3 things that are most important to them,
 bring to F2F.  WSAWG will need to decide on priorities for near term work.

Choreography will be mute by next WSAWG F2F (AC will have decided by then).

DA.  WG members have to take responsibility for their own issues until they 
make it into document.

Next week telecon will be decision by WG.

Should send comments before end of business next Tuesday.

[ACTION]. CF to send message to admin list.


4. Choreography

There has been considerable discussion about choreography on the mailing
list this week, but no signs of consensus on what the scope of a
choreography WG would be.  We need to focus on:

1- A working definition of "choreography" and related terms.  

2 - Requirements for the choreography WG.

3 - How to fit choreography into our document to help the AC understand it.

4 - Realities: Is there a subset of the choreography space that is ripe for
standardization (e.g., by a one-year focused effort)? Could a common
choreography interface definition language be standardized and let multiple
execution languages contend? Or should we be preparing the AC for a
multi-year effort to standardize something on the scope of BPEL4WS? 

Triangle diagram discussion.
Does it have a place for choreography?

Need to show relationships between services.
Nothing explicit.

DO.  current diagrams do not show multiples of web services.
editor call Hugo action to diagram a group of choreographed web services.

FM.  2 aspects.  1. how to do choreography, 2. where does choreography fit in 
overall web service architecture?
Finite state machine diagram.  What problems should be addressed at different 
levels of abstraction.

DA.  We have good start.  Add recursiveness to address multiple web services.

FM.  Need to address what problems are solved by which diagram.

Audience now is AC.

Need AC to understand why new WG is needed in context of web services.

DO.  Choreography instances talking to instances.  triangle diagram okay 
if just trying to capture that a web service is also a client of other web 
services.  Need something more to address view of flows.

Can we harvest from the 100's of emails on this topic?

Roger Cutler started thread asking why are we doing this anyway.

Who should harvest?

Lots on what it is, little on why.

Need more rationale for doing more work on Choreography.

[ACTION] FM will take a stab at text to explain where choreography fits 
in and motivation for it.  He will draw from list.

Need volunteers.  General call for WG to take another look at archive and 
reflect on specific requirements that a Choreography spec would solve.

CF.  Email ettiquette, Change subject line when discussion fragments.

DA.  Encourage more time before sending to list.

MC.  Should suggest specific changes for specific document.

DO.  Use travel agent scenario for now rather than introduce lots of vertical 
industry scenarios.  Work at requirement level.

DA.  Counterproductive to be negative and contrary to WG concensus.  Support 
the will of the group.

Some mail from outside the WG, hard to control.

CF.  Focus on moving the document forward.


MC.  Anyone disagree with focus on travel agent?

FM.  Roger's use cases are not covered by travel agent.

DO.  Need architecture to support many use cases, but use travel agent to frame 
debate and talk specifics less abstractly.  Add uses cases judiciously.

MJ.  No trouble with a use case elaborated, but illustrate as many edge cases 
without overcomplicating it.  Also value in shallow usage scenarios.  Tradeoff.

DA.  Restaurant example, argued to the use case rather than the concepts that the 
use case was trying to address.

DO.  Likes MJ suggestion. Go deep with travel agent, plus shallow for others to 
get edge cases, lots of interations.

MC. Hugo action from editor meeting, will be picked up by DO.

FM.  During choreography, focus on stakeholders rather than message exchange 
patterns.  Need different players views.

MC.  Take it to email.

DA. Use "role" perspective.

MC.  Hopes we can make AC happy (narrow scope) but also address W3C members and 
broader web service community who may expect broader scope. 

AC meeting is on 18 Nov.

Draft to W3C in about a week.  Editor draft a few days before meeting.

DO.  Worry about this deliverable.

Doug.  Reduce scope to meet deadline.

MC.  Next 2 weeks is a good time to spend more time away from day job and help 
WSAWG get ready for this AC meeting.

DO.  Will attend AC meeting, so will be available to help with presentation if needed.

MC.  Focus on documents, and where we want to be by AC meeting.


Chair: Mike Champion <mike.champion@softwareag-usa.com>
Scribe: Paul Denning