Web Services Architecture Working Group
07-Mar-2002 meeting minutes

Working Group home page · Meeting records



Ayse Dilber
BEA Systems
David Orchard
Roger Cutler
Yin-Leng Husband
Kevin Perkins
Computer Associates
Igor Sedukhin
Dave Hollander
CrossWeave, Inc.
Timothy Jones
Marcel Jemio
Digital Island
Joseph Hui
Mike Ballantyne
Nilo Mitra
Eric Newcomer
Intalio Inc
Bob Lojek
Intel Corporation
Sharad Garg
Intel Corporation
Joel Munter
MITRE Corporation
James Davenport
MITRE Corporation
Paul Denning
Glen Daniels
Microsoft Corporation
Allen Brown
Microsoft Corporation
Henrik Nielsen
Michael Mahan
Nortel Networks
Abbie Barbir
Oracle Corporation
Jeff Mischkinsky
Planetfred, Inc.
Mark Baker
Sinisa Zimek
SeeBeyond Technology Corp
Alan Davies
Software AG
Michael Champion
Sterling Commerce(SBC)
Suresh Damodaran
Sun Microsystems, Inc.
Doug Bunting
Sun Microsystems, Inc.
Chris Ferris
Sun Microsystems, Inc.
Mark Hapner
Anne Thomas Manes
W. W. Grainger, Inc.
Daniel Austin
W. W. Grainger, Inc.
Tom Carroll
Hugo Haas
webMethods, Inc.
Prasad Yendluri


Mike Brumbelow
Don Robertson
Hewlett-Packard Company
Dorothea Beringer
Hewlett-Packard Company
Zulah Eckert
Srinivas Pandrangi
Steve Vinoski
Alex Cheng
Sybase, Inc.
Himagiri Mukkamala
The Boeing Company
Gerald Edgar
Waveset Technologies
Darran Rolls
Tom Bradford


Radhika Roy
Artesia Technologies
Dipto Chakravarty
Carnegie Mellon University
Katia Sycara
Cisco Systems Inc
Sandeep Kumar
Cisco Systems Inc
Krishna Sankar
DaimlerChrysler Research and Technology
Mario Jeckle
DaimlerChrysler Research and Technology
Hans-Peter Steier
Waqar Sadiq
France Telecom
Shishir Garg
Jim Knutson
Heather Kreger
Tom Jordahl
Software AG
Nigel Hutchison
T-Nova Deutsche Telekom Innovationsgesellschaft
Jens Meinkoehn
VeriSign, Inc.
Michael Mealling
Daniela Florescu


See agenda posted by the Chair.

Detailed minutes

2. Agenda review, and AOB


Chris: Krishna's not here, trying to map out F2F schedule for next few months.

3. Approval of February 21 & 28 Feb telcon minutes


Review of outstanding action items

ACTION: DanielA: post issues list into CVS repository and post pointer to it

5. Status

	- WS-CG report

No meeting this week, postponed until hopefully next week.

	- Editing team report

Daniel's report:

  Met Wednesday.

  Comments list started.  Getting new issues editors on board.
  Discussed current doc.

  Timelines for getting things done.... working backwards from
  publishing at end of April.

  Apr 1 publish for f2f, second publishing cycle on Apr 15, followed
  by comments cycle and hopefully publish draft at end of April

  Editing tasks were divided up

6. "What is a web service?" definition

Chris recaps the story so far.  Slight differences from version in the
req'ments doc.

Prasad: what is the real purpose of answering this question now?  Is
it premature to answer this before we go further defining the apects
which shape the architecture?

Chris: the intent is to have something that's reasonable ("close
enough") to put in the req. doc, which will be revisited later.  It's
a work in progress.

Eric: It's important to keep going, this is fine for now.

(various +1s)

Jeff: Once this is done, you can almost throw it away...

Daniel:  Disagree, this will help us a lot, but we're done with it now.

DaveO: URIs are in the definition now, this is good.  There's been discussion,
and that's good.  Also, people have reviewed the charter, which is good.
Comfortable with moving on, though there are a few tweaks I'd make.

Chris : POLL - any objection to publishing this in the req doc as a
working definition?

Suresh: delete the word "direct"

Glen: change it to "programatic"?

[some discussion, ending with Suresh removing his objection for now]


ACTION: Editors: include definition of web service and make it clear
that it is an interim working definition and may change over time

7. Glossary Terms

Chris summarizes the situation.

Chris: Any objection to incorporating these?


ACTION: Editors: include glossary definitions

8. Process

Chris : We should be assigning champions to the various goals we have,
members willing to drive discussion on these issues forward.

(discussion - March 4th editors draft is current)

Mike: I feel rather fated to be a "Champion" (:)), so I'll volunteer for 5

Dave O: Volunteer for 10

Joe : #6 (security)

Daniel : #2 (modularity)

JeffM : #1

Daniel : #1A

Nilo : #3

Abbie : #4

Suresh : #7

TimJ : #8

MarkB : #9

MikeM : #11

PaulD : #12

Hugo : #13

DougB : #14

DavidO : #15

Yin Leng : #16

Champions should:

Review what the goal currently says, start a cleary ID'ed email thread
which asks for discussion around each of these goals, collect feedback,
present proposal at next week's telcon

Dave : post status by Tuesday so it's easy to find?

Chris : Will generate agenda after getting these

Doug: How do we resolve crossover between goals?

Daniel: Don't worry about it until we've got things better defined, and
we know what the overlap is more precisely.

(discussion of formats)

Daniel : Let's publish in HTML.

ACTION: DanielA: Post HTML of current requirements doc by EOB today

ACTION: ChrisF: Annotate requirements document with names for each
goal (see earlier action items)

9. Refine goals and objectives

Chris: let's try to hash these out a little here

- DAG0001 - reference framework (see thread at [8])

Chris: This should be 1A, I think

Dave : basic idea is framework where we can build assurance, but not
define assurance ourselves.  We provide a well-defined enough spec that
you can build a conformance suite around it - shouldn't be underspecified.

Daniel: If we define a reference architecture, it's for defining conformance.

Dave : shouldn't force action for non-conformance

Daniel : +1, "assure" is too strong a word

- DAG0005 - simplicity and ease-of-use (see thread at [9])

Mike: this is not unacheivable, despite discussion to the contrary.  As
Tim Bray has pointed out, even though it might be hard to define, it's 
useful to have in there.  Re: ease-of-use, can't see how a ref. arch. could
control ease of use of products

Roger: Two different "simplicity" metrics, and we get mixed up between the two.
Architectural simplicity, then simplicity of use of the web service.  both are

Chris: new "ease of use" goal, separate from "architectural simplicity",
w/Roger as champion?

?? - Two classes of user - people reading the doc, and people implementing web
services.  Should make life easy on both.

Mike: Let's definitely not drop it as a goal

Glen : 3 classes, spec writers, implementors, and end-users

Mike: dealing with the first two, not the last

?? - end-users should be able to use + compose web services

Dave H : this is a deep subject, defining the user.  Let's not go there until
we've done the drilldown...

(discussion ensues)

Mike : will draft a more detailed statement, and send it via email

- DAG0006 - security (see thread at [10])

Joe: Need to define what aspects of security are important.  Trust model
is critical part of this.  Privacy is also important, we need to define that
as well.

Yin-Leng : Message vs Transport layer definition?

Joe: Message layer = XML messages, for instance XML DSig.  Transport level
is IPSEC, HTTPS, etc.

(will discuss more via email)

- DAG0010 - using XML Technologies (see thread at [11] and [12])

DaveO: Our charter says our stuff must be XML based.

Mike: Does it really say we must use XML, or just use it where appropriate?

DaveO: It's clearly a goal that we use XML.  Might be cases when we
can't/won't, but it's a goal

Mike: We should use it to the greatest extent possible within the limits of
good sense.

DaveO: We're trying to describe what we're targeting.  With each of
these goals, there certainly may be cases where we can't meet the

Henrik: "use XML technologies" means we'll look at, but not define, these 

DaveO: exact pieces will be filled in by other WGs, but the goal is for the
architecture to be based on XML

Daniel : binary objects are cases where it might not make sense

DaveH: goal to invent no new syntax?

DaveO: We can't meet all the goals at the same time.  I'm comfortable saying
"we shall use XML", and we weigh tradeoffs between the goals and the

Joe: Should use XML except where we can justify not using it, i.e. transport-
level security.


Chris: Let's aim to finalize goals by next call.

Summary of new action items

See also the list of pending action items.

Chair: Chris Ferris <chris.ferris@sun.com>
Scribe: Glen Daniels <gdaniels@macromedia.com>