Web Services Architecture Working Group

12-Dec-2002 meeting minutes



AT&T Mark Jones
Boeing Company Gerald Edgar
Carnegie Mellon University Katia Sycara
ChevronTexaco Roger Cutler
Cisco Systems Inc Sandeep Kumar
Fujitsu Frank McCabe
Hewlett-Packard Company Yin-Leng Husband
Hewlett-Packard Company Zulah Eckert
IBM Chris Ferris
IBM Heather Kreger
Ipedo Alex Cheng
MartSoft Corp. Jin Yu
Nortel Networks Abbie Barbir
Oracle Corporation Jeff Mischkinsky
Oracle Corporation Martin Chapman
SAP Sinisa Zimek
SeeBeyond Technology Corp Ugo Corda
Software AG Michael Champion
Sun Microsystems, Inc. Doug Bunting
TIBCO Software, Inc. Scott Vorthmann
W. W. Grainger, Inc. Daniel Austin
W3C David Booth
W3C Hugo Haas
webMethods, Inc. Prasad Yendluri


AT&T Ayse Dilber
BEA Systems David Orchard
Computer Associates Igor Sedukhin
DaimlerChrysler Research Hans-Peter Steiert
EDS Waqar Sadiq
Macromedia Glen Daniels
Progress Colleen Evans
Sterling Commerce(SBC) Suresh Damodaran
Sybase, Inc. Himagiri Mukkamala
XML Global Duane Nickull


Detailed Minutes

1) Role Call and Selection of the scribe: Gerald Edgar - Boeing

2) Minutes were approved.

3) Discussion of the  XMLP issue.
From the push back on we saw as their issue. Did we get a response?
Mike Champion sent a revised version - received comments in return, but no chance to incorporate those comments. Generally the sense of the discussions, it is ok, but not clear..   (action item - to clean it up before next week)

4) Discussion about start and end times of the January Face to Face
Initially there was a proposal is to have a few hours of overlap in the morning Wednesday
There was a proposal to start officially at noon, but be available at ten for joint sessions with the description group. no objections were voiced.   Finally, there was a question on when people need to leave.
People expressed a preference for leaving early Friday. Intent to end before 4, and one voiced the need to catch a 2 PM flight. Question on if people object to starting at 9. The joint time would be determined later. Comment on if the joint work would be in the morning. Usage scenarios would be a candidate joint work item.
The for the January Face to Face will start at 9 AM Wednesday to end noon Friday.

5) Question for the management task force
For the Management task force (MTF) - is there anything to bring to the groups attention. They said they have not yet had a change to discuss what are the components of management. There was a question if this was too detailed for architecture.  The MTF should figure this out, Heather and Hugo are  to discuss this. Hug was reporting to Heather that the work may be too detailed and there is a need to stay at the architectural detail. The working groups concern that this groups effort was too detailed.  Heather will contact Hugo on this.  Question on if there is anything in the e-mail to address. The response was no- not at this point.

Issues list:  sent to the editors, but not posted publicly. There were questions on if there was a reason, or if there was simply a problem in posting it. Tom Carroll sent an e-mail to the editors about it's review.

6) SOAP Features / Extension framework status
On the issues list,  Mark's issue of limited number of methods.
Mike  asked- does anyone want more time? or can we just resolve it? Mike proposed that we were not inconsistent with the web architecture.. The architecture articulated by Roy Fielding not a normative constraint or principle of the web.  One speaker suggesting that we do not intend to look more carefully into this at this time. This is an issue for the TAG. A bit more background: the tag does not have enough time to address this.  If an individual raises an issue – this is not addressed at as high a priority as what is raised by a working group. The question is the TAG the appropriate venue for this issue?  There was a question of typing and abstraction. We use sockets as our interface. For the architecture document extract what applies. The architecture in its present form is get, put and post, but that we need more. Web services are about typing. If you call something a method or if you call something a type, it is equal in complexity.

There are three options:

1) do nothing as we go thought the issues list..
2) provide a technical response
3) a procedural response.
The suggestion is that we provide a technical response, but at the same time not spend too much time because there are other issues to resolve. David Booth commented  that get/put/post is not enough.     If there is no benefit in continuing this discussion –  from one speaker's comment Mark may be fine with any kind of a response. If we do not want this left open, just respond and close it.
Hugo: The one thing we should not do is ignore it. This may haunt us later.
??: the reason that mark drives this issue is that he wants to just raise the issue.
Hugo: when he said we should close the issue, but not just ignore it.
Rodger: we are in a place to say that we do not think it is relevant to web services.
Chris we should not let him dangle, but we do not have to close the issue. We can address it later. We have not addressed other issues. We should focus on working on the document, not on the number of methods. If we close it but we have not made our position clear, the TAG may just return that we have not articulated our position. We have enough on our plate.
One person suggested that this would  not be accepted by the TAG.
??: if I am in the minority – we do not have enough in the document.  If the TAG does take it up
Katya:  process clarification – different between leaving the issue open, or closing it, or other options on this issue. There is no clear procedure. He might have been told that the TAG likes to be a court of last resort.  If we use some form of his words – then he may be satisfied. If the TAG addresses this, we will be drawn in.: if we use a revised form of the his issue, he will still go to the TAG. - W/S needs an extension to Get/Put/Post.
Zula – voiced support for Chris, to leave this on the table, and not close it.
Abby – Mark may take it in to the TAG anyway. We need to make sure it is done right.
Roger- problems with the wording.  If we accept this – beyond Get/Put/Post but that this does not extend the web architecture
A poll posing two solutions:
A)  A polite note to say we do not feel comfortable closing this because it is not in the document
B) close it and discuss the wording.
Option A carried….
Katya made a comment: to spend a little time to close it to be able to but this issue behind us.
A still carries.

7) The web services description group requirements document.
Does anyone think we should have a group response?
Frank: it would be good to have a group response. This has architectural implications.
Hugo: this is appropriate to look it over and bring up architectural issues to our attention.
Hugo proposed to make a one minute summary. This is accepted.
Hugo: on the web http methods have a clear meaning it would be a good idea for WSD if should use the web methods feature. People kind of agreed and started to stay that it would be interesting for choreography if the item was important, for reliability. Add this to description. Does this fit into the description . does WSDL and SOAP aligned for web methods. Hugo was not sure of the wording, but the description of the web methods was important in this. Mark Baker was involved. Architecturally this is an aspect of the description. But they were uncertain of the form to use.    A suggestion to add to WSDL 1.2 to express in their description on the importance or reliability of the service. Is this appropriate for the  specification. Need to reconcile SOAP 1.2 with WSDL 1.2 but not get too far into the safeness or idempotence   is beyond the scope of this. It is their responsibility to support soap 1.23 the web methods feature was Hugo’s thoughts on idempotence and safeness. One way to describe it was just to describe the features. there may be a need to inherit it from the HTTP level. Web methods have been done, and to address web idempotence  in the same way. As was discussed in the e-mail. When you are forced to use POST, the service may still be idempotent   Idempotence was discussed as far as how it applied here. To establish it at the SOAP level and have WSDL reflect the SOAP.  For post there is a need for additional information needed. Does the most current version of HTTP use reflect idempotence?  He is not as persuaded that it is a requirement for WSDL.
Hugo does not think we are ready to comment on the requirements.
There was a comment that we need to get our draft done. We would like to provide a response, but no one is stepping forward to go though the WSDL document and bring up architectural issues to the group.
(Action item) We are encouraged to go though the WSDL draft and bring up issues to the group.

Hugo: in order to not loose  "idempotence" we will draft a response and send it to the issues list.

8) Discussion about the two major threads in the e-mail list  reliability and semantics. Primarily by Frank Katya Mike
Both of these are items for the working group to address.
Summary of the discussion: there was confusion that the WSA should address the semantics issue.
Dave Hol.. Said we should not address this ourselves. this may be a new working group.
Frank: This was a useful discussion of semantics, and  to potentials start a working group. There is community support to doing something in this space. It is too early to create a new working group. There is no charter at hand to use. We  should continue this discussion at the F2F. (other comments?) this working group does do semantics. But is there willingness in the community as a whole. For this. To draw a box around semantics. Picking up on WSDL, it is not mentioned there at all../  we have to fit semantics into the Architecture. we have a first stab, but we need to revisit that. We need to have a language to do that. what are the semantics written in. ?
Katya  about  DAML and other European effort for semantics – a meeting in Innsbruck with two subcommittees, semantics and language. For those interested, contact Katya. One connection seen – the activity is already started (larry bird DAML project) this effort may result in a note to the W3C ??- owl language. May result in this being brought into the W3C not under any standards body at this time.   Comment on a pluggable semantic architecture. If is possible to define a pluggable architecture we may defer to other work to define the actual mechanisms. …. The answer is yes in tthat how semantic web  fit into web services is part of our work. As far as pluggable architecture, that is the intent. Currently there is not credible of a specification of a language that can be used to describe web services, there is research, but not anything concrete. WSDL is not the semantic description.
There was a question on procedure:   we have two roles- to build the specifications, and to charter working groups. This is a fair amount of work. What should we do to address these desires – a task force to look into this, or what? What should be the next step. The task force may be a good idea, but  people were not sure at this point.; there was uncertainty about starting up a new working group – but to at least establish a liaison with the existing groups.  What should the WSA do to track these semantic discussions… Frank Katya Mike (chair)

Other issue: reliability- has that discussion gone anywhere? Are we near resolution? We need to capture issues on reliability. How difficult is it to provide a real solution? We have not documented this very well.  To look at ebXML on this and To read it as a reference to existing work. There was a suggestion to have this at the face to face. There was a question on if they would accept this.; This was discussed in the XMLP – there might be light-weight issues to address.  Is this a lightweight issue they would address? There is an architectural issue on where reliability fits in. is may be protocol or in choreography. This may fit into the message exchange pattern, but other portions fit into orchestration. The intent was just to bring this op to make people aware of this.
(action item) Request to have a summary of the major issues raised in the mail exchanges regarding reliability - . Roger and Eric are to do this

Action Item Summary:

We are encouraged to go though the WSDL draft and bring up architectural issues to the group
Request to have a summary of the major issues raised in the mail exchanges regarding reliability - . Roger and Eric are to do this
Chair: Mike Champion <mike.champion@softwareag-usa.com>
Scribe: Gerald Edgar