Working Group home page · Meeting records
Present
-----------------------------------------
Apple
Mike Brumbelow
BEA
Dave Orchard
Boeing
Gerald Edgar
CA
Igor Sedukhin
ChevronTexaco
Roger Cutler
Cisco
Sandeep Kumar
Compaq
Yin-Leng Husband
Contivo
Dave Hollander
CrossWeave
Timothy Jones
Digital Island/Exodus
Joseph Hui
Documentum
Don Robertson
EDS
Waqar Sadiq
Ericsson
Nilo Mitra
HP
Zulah Eckert
IBM
Heather Kreger
IBM
Jim Knutson
Intel
Joel Munter
Intel
Sharad Garg
IONA
Steve Vinoski
Ipedo
Srinivas Pandrangi
Macromedia
Glen Daniels
Microsoft
Henrik Nielsen
MITRE
James Davenport
MITRE
Paul Denning
Nokia
Michael Mahan
Nortel
Abbie Barbir
Oracle
Jeff Mischkinsky
SAP
Sinisa Zimek
SoftwareAG
Nigel Hutchison
Software AG
Mike Champion
Sun
Chris Ferris
Sun
Doug Bunting
Sybase
Himagiri
Systinet
Anne Thomas Manes
W.W. Grainger
Tom Carroll
W.W. Grainger
Daniel Austin
W3C
Hugo Haas
Waveset
Darran Rolls
WebMethods
Prasad Yendluri
Invited Guest
--------------------------------------------------
W3C
Janet Daly
Not present
--------------------------------------------------
EDS
Mike Ballantyne
IONA
Eric Newcomer
Ipedo
Alex Cheng
Macromedia
Tom Jordahl
Sun
Mark Hapner
Regrets
--------------------------------------------------
Cisco
Krishna Sankar
Compaq
Kevin Perkins
Daimler Chrysler
Hans-Peter Steiert
Daimler Chrysler
Mario Jekle
DISA
Marcel Jemio
HP
Dorothea Beringer
Planetfred
Mark Baker
Microsoft
Allen Brown
See agenda posted by the Chair.
Minutes approved. Will be posted on web site.
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.
Passed.
Chris will send out further specifics and arrangements.
For those who cannot attend we will try to have conference call
capabilities.
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
forward?
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
mind.
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
way?
?: 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.
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
architecture
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
technology
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
platforms
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
overall
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
environment
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
Discussion:
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
discussion.
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
Sandip:
Darron:
Dave: also need test cases similar to use cases
Sankar: usu use cases are input to requirements rather than test
driving
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
applicability?
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
here.
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
need.
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
subgoals.
Chris:
: 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
marketable
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
standards.
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
promote.
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
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
evaluation.
WS-I:
There is a URI and description in the mail (#24 of member readable
archives).
High expectations of WS-I, somewhat misinterpreted from published
materials.
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
old.
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
group.
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.
None.