Web Services Architecture Working Group
14-Feb-2002 meeting minutes

Working Group home page · Meeting records


		Mike Brumbelow
		Dave Orchard
		Gerald Edgar
		Igor Sedukhin
		Roger Cutler
		Sandeep Kumar
		Yin-Leng Husband
		Dave Hollander
		Timothy Jones
Digital Island/Exodus
		Joseph Hui
		Don Robertson
		Waqar Sadiq
		Nilo Mitra
		Zulah Eckert
		Heather Kreger
		Jim Knutson
		Joel Munter
		Sharad Garg
		Steve Vinoski
		Srinivas Pandrangi
		Glen Daniels
		Henrik Nielsen
		James Davenport
		Paul Denning
		Michael Mahan
		Abbie Barbir
		Jeff Mischkinsky
		Sinisa Zimek
		Nigel Hutchison
Software AG
		Mike Champion
		Chris Ferris
		Doug Bunting
		Anne Thomas Manes
W.W. Grainger
		Tom Carroll
W.W. Grainger
 		Daniel Austin
		Hugo Haas
		Darran Rolls
	Prasad Yendluri

Invited Guest
		Janet Daly

Not present
		Mike Ballantyne
		Eric Newcomer
		Alex Cheng
		Tom Jordahl
		Mark Hapner

		Krishna Sankar
		Kevin Perkins
Daimler Chrysler
		Hans-Peter Steiert
Daimler Chrysler
		Mario Jekle
		Marcel Jemio	
		Dorothea Beringer
 		Mark Baker
		Allen Brown



See agenda posted by the Chair.

Detailed minutes

1. Roll call, scribes for minutes/action items

2. Agenda review, and AOB

3. Approval of February 6 Feb telcon minutes

Minutes approved. Will be posted on web site.

Review of outstanding action items

5. April F2F planning update

	WSDWG is April 10-12, Cisco has offered to host, we'd like to be 
scheduled Back to Back.
	Proposed F2F date: April 8-10, in San Jose hosted by Cisco Systems 
for 2  days, ending Wed. at noon. 
	Chris will send out further specifics and arrangements.
	For those who cannot attend we will try to have conference call 

6. Process, deliverables and schedule discussion

	Discussion on the process we'll use to achieve our objectives,
review of the near-term deliverables and proposed schedule.

 	Chris: Process for moving forward. Daniel Austin had sent out an 
email with some suggestions with the idea that we would start with a 
mission statement, drill that into goals and major objectives with 
critical success factors for generating requirements. This seems like a 
reasonable requirement. Is it amenable to take this approach for moving 
	David Orchard: We need to be focused on time to market and create 
something usable for creating additional working groups. We need to get 
agreement to get requirements to not be a be all to end all' set of 
requirements and then be late on getting working groups formed. We need 
to discuss and agree on how far we should go on these things. 
	Comment: We should strive for this keeping the April timelines in 
	David Orchard: If the group wants fully fleshed out requirements, 
we'll miss that schedule. We'll have to pick  between hi quality 
requirements and coming up with a deliverable in a reasonable period of 
time. If the requirements causes the deliverable to be delayed we need 
to weigh that. 
	Henrik: we need to iterate on requirements with rev 1 in April and 
revisit as time goes on. 
	David: agree we will have to iterate on requirements. But what is 
the process for iterating. Mostly concerned with getting ratholed on 
requirements and watching for this so that we don't impact the schedule 
for the deliverable. 
	?: agree we can iterate and not necessarily define every detail.
	Dave Hollander seconds that.
	Chris: So in general we agree on the CSF analysis to go forward 
and identify requirements?
	Doug: is there a more complete description of that?
	Daniel: process was posted in the email. Can't sent attachments. 
Basically start with top level goals and go through reductionism till we 
come up with a finite set of requirements.
	Chris: is there general agreement in group for proceeding this 
	?: OK to proceed for now, but confirm this later after we've had a 
chance to review the methodology.
	Daniel: OK we'll do that. If anyone has any other ideas on how to 
proceed please do so.
	Chris: Then lets start that and refine what our mission is. And 
then work forward on our goals. 
	Daniel: of course sometimes this is a brainstorming process and it 
doesn't end up a perfect rendition of this approach. Shouldn't spend too 
much time on mission and try to gather goals.
	Chris: We will proceed with Daniels CSF approach. Deliverables are 
a requirements document by April, driving towards using F2F to resolve 
thorny issues and teleconference time for defining goals and initial 
requirements. F2F will be used to refine the requirements document and 
then publish it a few weeks later.  After that's done then a schedule 
needs to be set for the architecture document.

7. Refine goals and objectives

	Chris: Daniel can you review the suggested mission statement?

Daniel Austin has synthesized[3] the high-level goals and concerns
expressed in last week's telcon. We'll discuss this list and
refine it such that we can have as a baseline a core set of
goals that can be used to guide our work going forward.
Daniel's list is intended as a discussion starter.

a) interoperability and reduction of divergence among vendors
b) extensibility and modularity to encompass the future evolution of
web services
c) platform independence with no assumptions regarding communication
among architecture components
d) simplicity and ease-of-use that does not impose high barriers
to entry for users of web services
e) security and reliability of web services systems
f) evangelization of web services to larger community
g) co-ordination with other similar groups both within and outside
of W3C
h) coherence and consistency of the overall architecture
i) alignment with the semantic web and the overall existing web

From Daniel's note:
Proposed Goals for the Web Services Architecture Working Group

To develop a standard reference architecture for web services that:

AG001 ensures the interoperability of web services software 
products from
different implementors based on well-defined standards

AG002 provides modularity of web services components, allowing for 
a level
of granularity sufficient to meet business goals

AG003 is sufficiently extensible to allow for future evolution of 
and of business goals

AG004 ensures platform independence of web services components in 
a way that
does not preclude any programming model nor assume any particular 
mode of
communication between the individual components

AG005 provides simplicity and ease-of-use that does not impose 
high barriers
to entry for users of web services

AG006 addresses the security of web services across distributed 
domains and

AG007 is reliable, and stable, and whose evolution is predictable 
over time

AG008 is coherent and consistent in its definition

AG009 is aligned with the semantic web initiative at W3C and the 
existing web architecture

AG010 uses XML technologies in the development of the web services
architecture to the extent that this is compatible with the 
overall goals of
the group

AG011 is consistent with the existing web and its heterogeneous 
and distributed architecture to the greatest extent possible.

In addition, the Working Group will also act to:

AG012 evangelize and promote the benefits of web services to 
potential users, both consumers and producers

AG013 co-ordinate the development of web services within W3C, 
together with other W3C Working Groups where there is overlap 
among their problem domains

AG014 serve as liaison with groups outside W3C who are working on 
web services in order to achieve interoperability and reduce 
duplication of effort

	Hugo suggested that the last three were not the scope of this 
group and should be responsibility of the ws coordination group. 
	Comment: how can we do this job without working with other groups 
inside and outside the w3c.
	Hugo: concern that we were going to function as a liaison with any 
other web services standards group in the world. This is a big task the 
ws-cg group should evaluate this and decide who to liaise with. We should 
consider all those groups one by one. Considering the first one, w3c WGs 
interact with each other, and some of this coordination goos thru the
wscg. A12, 13, 14 is outside the deliverables of this WG and nothing
that will come up in documents as a result of this. 
	Daniel: Don't want to look at the last three as concrete 
requirements but rather as roles
	Glen Daniels: Thought comments may have created this requirement 
and wanted to clarify. There is a lot of tech stuff in other groups that 
is out of scope for xml-p group. Within scope of this group to produce 
guidelines to produce extensions on top of or below the xml-p and wsdwg 
outputs. A central point of guidance. How to build an extension so it 
interoperates with other extensions. Where to find best practices.
	Dave Orchard: second Glens point. Many situation where liaisons 
with other wg will be like a best practice described. 
	Sandeep: I brought up A012 around similar topics on best practices 
and accompanying documents to address these issues in a more 
comprehensive manner.
	: ties into reaction to A12. Says top level has to be a 
marketecture with descr. Of funct and capabilities less than an 
engineering blueprint. Esp if accept 12.
	Chris: the last three might be ways we achieve our goals but not 
our goals. Might be what the architecture is used for.
	Henrik: looking at document along same lines and that is 
terminology. If we start writing these terms down might get much 
	Chris: suggesting a glossary?
	Henrik: could be interesting, as part of document, what terms and 
components will mean.
	David: will need glossary in the ws arch.  We need to write down 
what we mean by these things. If we don't agree on that then we can't 
get an arch out. Most modeling exercises also have a glossary. Let's add 
a glossary
	?: Need a definition of a Web Service
	: that one should be delivered with the requirements.
	Roger(Chevron): in terms of liaison, charter talks about liaisons 
and not deviating in arbitrary ways from existing standards. 
	Chris: liaisons is used to achieve the goals, but it is not a goal 
itself. Have to understands whats around us so we can fit in. 
	:should arch doc define how liaison would work?
	Dave: arch doc should contain results of liaison's work, but not a 
framework for how to do liaise.
	Daniel Austin:
	Roger: charter talks about w/in w3c and outside w3c. 
	Daniel: that's why its two different activities A13 and A14. In 
w3c need to get agreement because its part of the prime directive, if 
working with outside groups, they won't necessarily agree with us.
	Dave: there are goals of the wg and activities of wg. The last 3 
are activities. Goals should be talked about it terms of results. Its 
hard to phrase activities so that they are measurable.
	Chris: do need to be measurable so can tell if achieved the goal. 
	Daniel: if coordinate liaison activity it will help ensure the 
other goals. 
	Chris: this is not an isolated group, we have a lot of cross 
pollination with membership of other groups. So, we may be able to do 
this informally. If something is going wrong, we may need to make it a 
more formal liaison. Would like to move on to another topic
	Darron: a clear example beyond stockquote would be most helpful. 
	Steve: interesting issue: maybe one of the artifacts is a set of 
usecases more elaborate than stockquote. Maybe not necessarily code and 
not sure how far to go. 
	Darron: it occurs to me with point 12, if we had a goal of 
producing usecases that would help evangelize, promote benefits and 
coordinate with other groups
	Dave: also need test cases similar to use cases
	Sankar: usu use cases are input to requirements rather than test 
	Paul: might be nice to have a goal of having an element of 
fairness so that one co. or industry is not favored over another. Xmlp 
wg may have some usage scenarios that you could start from
	Doug: unsure about fairness maybe you mean general 
	Paul: fairness should be a goal of the w3c.
	Sankar: not sure about concern.. if goal is interoperability then 
fairness will be part of that.
	Daniel: Security: suggested to split into 2 separate domains. Didn't 
understand them.. can that person explain?
	Sankar: what about the use cases?
	Chris: general consensus that it is a good thing.
        Joe: suggest keep AG006 as one goal, don't split.  Because security
problems are complex and solutions need to be comprehensive.  There's
no advantage in splitting AG006 into two main goals other than
complicating the task unnecessarily.  Refer to my example/use case in
the www-ws-arch mailing list for some detailed why.  If there must be
some splitting, then it should happen at the subgoal level.
	: suggest we don't want to rely on transport to implement security 
	Joe: there are things you can use at transport level (or
lower), such as TLS and IPSec, as shown in the example I gave in the
mailing list.
        Daniel: Can you refresh our memory what that exmample was?
        Joe: A transaction between two WS end points requires: confidentiality,
authentication, (mutual) authorization, integrity, and non-repudiation
The req can be satisfied by simply using XML-sig messages over
TLS with client authentication.  Note the five aspects of security.
They are basic needs for secured transactions.
	Gerald: IETF breaks it up into network and system. 
	Sandip: cannot expect ws to be over a secure transport layer. So 
have to rely on a message level to do these things.
	: agreed. Don't want to rely on transport. Want to specify what 
	Dave: xmlp working on transport bindings and functions. We can 
identify security functions and how to bind to underlying protocols but 
not dictate them.
	: agree not rely on transport layer. 
	Daniel: do we want to split into communication and system layers?
	Sandip: then have to figure out how to do the split should be 
	: my consider context sensitivity as a goal. Goal is to be able to 
provide appropriate level of security for the context of the service.
	Joe: The issue at hand is to split or not to split (AG006 into
two goals). I've already made my point -- not to split.
	Daniel: ok, then lets not split.
	Chris: lets start at the top and work our way down. Lets come up 
with some words for (12) that captures the evangelism and use case 
concepts David?
	Joel: architecture delivered will be marketable so that the 
deliverable to other teams will be easily mapped  don't have to create 
all use cases yourself. 
	Identify or create use cases
	Daniel: focus on deliverable rather than use cases making it more 
	Dave hollander: we're missing benefits

	New A012 Goal: The working group will identify or create the use 
cases that validate the requirements and the web services architecture 
and illustrate the benefits of web services. 
	A01 discussion: AG001 ensures the interoperability of web services 
software products from different implementors based on well-defined 
	Is this a test suite? We want to be this works for diff folks. How 
we do this is a result not a goal
	All we can do is enable
	Goal should be to identify the standards needed.  Or maybe say 
	Enable is best. Can't really ensure. 
	Is a subgoal the identification of key webservice s/w standards 
that don't exist?
	Chris: that is one of the goals of this wg.
	Not part of our charter to create the standards. 
	This group could identify multiple interop type standards and we 
can point to them and a framework around them. 
	New A01: Enable the interoperability of web services s/w prod

	Daniel: used ensure because if has 
	provide a ref arch  to ensure 
	test suites out of scope

	Running out of time

8. Information available on WS-I

Janet Daly, W3C Head of Communication, has sent an email[4] about W3C
and WS-I. She will be joining our call to answer questions.

Janet: as an aside; as part of every WG activity is quality assurance
with test suites based on w3c spec or set of specs where w3c is. Even
if this group doesn't create them, they would have a role in their

There is a URI and description in the mail (#24 of member readable 

High expectations of WS-I, somewhat misinterpreted from published 

Her understanding is that rather the goal of WS-I is to create profiles 
of standards from other bodies: other more vertically focused 
organizations, the W3C, or the IETF. Based on these profiles the
      stated goal is 
to build test suites. If they identified holes they indicated they would 
not build the specs themselves but would work with standards group who 
worked in that space asking if they would fill that hole.

This could be seen as complimentary efforts. but this group is one week
W3C has sent additional questions to WS-I organizers, which will need
answers before taking any formal action, such as the criteria for
choosing specs, criteria for liaisons, IPR mode, etc. We look forward
to getting those answers, and then we'll see what happens.
Daniel: what relationship do you see with w3c and particularly with this 
Janet: appears to be natural synergy between this group and WS-I. 
Believe there are folks in this working group and may also have 
responsibilities in WS-I for their own orgs. Whether that takes a more 
formal terms will have to be seen. Ws-I is working on terms for creating 
liaisons. There is an interest from them to create constructive 
relationship between the two.

Daniel: depends on how far we go with the discussion of that first goal. 
Depending on how far we take that will form how much overlap or how to 
work with them.

Dave Hollander: providing a reference framework and resolution for 
disputes would be a good territory to claim.

Chris: lets hope for a close and complimentary relationship.

Heather Kreger volunteered to take the minutes and will send them to 
Chris and Hugo.

We will be having a call next week and the week after even though the 
W3C plenary will be in progress.

Summary of new action items


Scribe: Heather Kreger <kreger@us.ibm.com>