All times are EDT (UTC minus 4 hours)
Wednesday 11 September
09:00 WSD meeting continues - WSA members may observe
10:30 Break
10:50 Joint WSA/WSD meeting - REST presentation
http://www.w3.org/2002/09/12-wsa-daveo/daveo_clean.htm
http://www.markbaker.ca/2002/08/Rest/
12:00 WSD meeting concludes
Lunch (participants are on their own but we'll try to facilitate continued
discussion over lunch somehow)
13:00 WSA meeting opens, welcome from DISA
Introductions, Roll, administrivia
Scoping / Vision / Process synchronization - what
can we hope to accomplish and how do we do it?
Presentation by Frank McCabe on how we should be
considering such ideas as P2P, agents, SLAs, accountability,
etc. to support business interactions on the Web.
http://users.rcn.com/geoff2/aws1.0.pdf
http://users.rcn.com/geoff2/f2f.pdf
Roger Cutler has disagreed with some of Frank's points
on the mailing list, and will be given a block of time
to respond. (Feel free to post your response to the
list Roger once you've reviewed Frank's materials)
Discussion of what all this means for the WSA -- do we
put this stuff in our requirements/usage scenarios, do
we try hard to come up with a simple architecture that
supports these things as "emergent properties" rather
than explicit components, or do we focus on the short
term needs common to all web services developers and
let this stuff take care of itself?
15:00 Break
15:20 Usage Scenarios -- document and strategy
Previous F2F meetings assumed a requirements-driven
strategy; the WG has actually been somewhat event-driven
and oriented towards "harvesting" other specs.
What do we want to do with the Usage Scenarios document?
Should it drive Requirements, or is it just a non-normative
list of web services scenarios we should keep in mind?
http://www.w3.org/TR/2002/WD-ws-arch-scenarios-20020730/
Requirements document cleanup (as time allows)
http://www.w3.org/TR/2002/WD-wsa-reqs-20020819
17:30 Adjourn for the day
Thursday 12 September
09:00 Requirements document cleanup (let's try HARD to finish!)
See the "championing" proposals:
http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0264.html
http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0266.html
http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0268.html
http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0269.html
http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0270.html
http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0291.html
10:30 Break
10:50 WSA Document Review / Discussion
The editors will walk us through the WSA document
itself as it exists at the time of the F2F,
pointing out areas where they think there
is already a rough consensus and highlighting
the most important areas to focus on.
http://www.w3.org/2002/ws/arch/2/08/wd-wsa-arch-20020821.html
Move on to Drill-Down topic as quickly as possible
12:00 Lunch
13:00 WS Architecture Drill-Down
Do whatever it takes to make progress on defining a
WSA framework or reference architecture. Consider other
reference architectures as a template and fill ours in?
Lots of drawing on whiteboards? Try to come up with an
agreed upon picture of how SOAP/WSDL work (in both RCP and
RESTful ways). Talk about how other things get layered on:
* Security (many aspects of this!)
* Reliability / Asynchrony / Routing
* Management aspects (championed by Heather Kreger?)
* Others from requirements and usage scenarios
Glossary definitions noted and discussed as they come up.
Refer to harvesting summaries as appropriate
http://lists.w3.org/Archives/Public/www-ws-arch/2002Jul/0365.html
http://lists.w3.org/Archives/Public/www-ws-arch/2002Jul/0349.html
http://lists.w3.org/Archives/Public/www-ws-arch/2002Jul/0160.html
http://lists.w3.org/Archives/Public/www-ws-arch/2002Jul/0209.html
http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0068.html
15:00 Break
15:20 Choreography Discussions
Try to find a consensus about what to do about this topic,
including whether to sponsor some sort of meeting/workshop
and whether to recommend the chartering of a new WG.
http://www.w3.org/TR/wsci/
http://www-106.ibm.com/developerworks/library/ws-bpel/
http://www-106.ibm.com/developerworks/library/ws-coor/
http://www-106.ibm.com/developerworks/webservices/library/ws-transpec/
http://lists.w3.org/Archives/Member/w3c-ws-arch/2002Aug/att-0054/01-part
17:30 Adjourn for the day
Friday 13 September
09:00 Overflow buffer for whatever needs more discussion.
We REALLY REALLY want to end this meeting having nailed down
the Requirements, decided what to do about Choreography,
and moved ahead on a common "picture" of the overall
WSA framework.
10:30 Break
10:50 Formal wrap-up
Votes on any issues for which obvious consensus has not
emerged
Plans for going forward, publication date commitments for
next official drafts of our documents.
Creation of task forces to dig into specific topics?
12:00 Lunch (WORKING lunch if we still have open issues)
13:00 - ? Informal discussions, "educational" presentations on
topics of interest by people with expertise, "task force"
meetings, etc. People will probably drift out as
travel and other commitments require.
See also: IRC log
Present:
AT&T Mark Jones
BEA Systems David Orchard
Carnegie Mellon University Katia Sycara
ChevronTexaco Roger Cutler
Cisco Systems Inc Sandeep Kumar
Computer Associates Igor Sedukhin
Contivo Dave Hollander
Ericsson Nilo Mitra
France Telecom Shishir Garg
Fujitsu Frank McCabe
Hewlett-Packard Company Yin-Leng Husband
Hewlett-Packard Company Zulah Eckert
IBM Chris Ferris
IBM Heather Kreger
Idokorro Mobile Mark Baker
IONA Eric Newcomer
MITRE Corporation Paul Denning
Nokia Michael Mahan
Oracle Corporation Martin Chapman
Oracle Corporation Jeff Mischkinsky
Progress Colleen Evans
Rogue Wave Software Jim Shur
SAP Sinisa Zimek
SeeBeyond Technology Corp Ugo Corda
Software AG Michael Champion
Sun Microsystems, Inc. Doug Bunting
The Thomson Corporation Hao He
W3C Hugo Haas
W3C David Booth
webMethods, Inc. Prasad Yendluri
Regrets:
Anne Thomas Manes (Systinet)
Himagiri(Hima) Mukkamala (Sybase)
Paul Denning (Mitre) [he did dial in for part of the meeting]
Scott Vorthmann (Tibco) [he did dial in for part of the
meeting]
Gerald Edgar (Boeing)
Srinivas Pandrangi (Ipedo)
Frank McCabe (Fujitsu) had to leave early, and gave regrets for
Friday
Chair: MikeC and DaveH
Scribe: MikeM
dbooth: It is helpful to identify context of the architecture - which part of arch affects which consumer of the arch: sysadmin, prog, management, the end user
mikec: note that the scope of SW arch grows over time ... as SW matures, the scope may expand
dbooth: it is helpful to acknowledge that fact
mikec: the architecture must be scoped appropriately towards its intended target audience
ericn: roger's doc discusses roles. This concept maybe better developed in a primer instead of a diagram
dbooth: should we do a primer, formally?
mikec: later in the agenda
Mark Jones presents his group's architecture ideas on
whiteboard
markj: presents his view - the triangle is
compelling
... triangle diagram as a broad statement, followed by
specifics
heather: I have the triangle
markj: the registery is too centralized a notion -
recommend 'discovery agencies'
... registry can be thru google, dynamic, static, decentralized,
human-driven
... it ends up being programmically accessible
unknown: change the triangle arc name from bind to interact
ericn: how about invoke instead.....
markj: arrows on diagram are misleading, especially if viewed dynamically
mikec: is this RESTful or neutral?
markj: neutral - these are just roles
markb: as long as any web page can contain or be the discover agency
mikec: is requester and provider sufficiently neutral?
chrisf: no, peer-to-peer model doesn't fit
markj: no MEP is implied in the triangle
heather: the roles are not locked in
ericn: this is a basic diagram - not showing the complexity of all situations
markj: the range of interactions and roles is broad
sandeep: this is a snapshot in time
markj: this is more schematic rather than
diagramatic
... start with this as the big picture
... blow out each section of the triangle (like National
Geographic Universe charts)
... interact arc details (blow up) would contain the stack (from
top - down): package, headers, bindings, transport
<dbooth> DaveH's slides are now available:
... http://www.w3.org/2002/09/12-wsa-daveh/daveh_clean.htm
(HTML)
... http://www.w3.org/2002/09/12-wsa-daveh/daveh.ppt
(Original PowerPoint)
markj: publish arc details (blow up): not as stack-like ... including wsdl, choreog, workflow, sla, bla, xmlschema, p3p
markj: find arc details (blow up): same flavor as publish arc..... containing uddi, google, xpath, wsil
sandeep: security?? management??
markj: those plus reliability are orthogonal
... still working on that picture
... this is a functional arrangement
ChrisF: metadata foundation - the publish stuff - soap
called features
... bucket of features can point to the separate functions
markj: extensibility model to describe features:
security, reliability
... this describes a laundry list rather than a clean arch
katia: proposal to differentiate the generic from a
specific architecture
... to instantiate a specific architecture, you duplicate the
general arch diagram -
... then fill in technologies to cover the abstact features
identified in the general arch
mikec: so glossary terms are on the 1st diagram
... the second has specific technologies
group: lots of chatting..... heather is about to show off
her slides
Heather Kreger presents her architecture slides
later posted at:
http://lists.w3.org/Archives/Public/www-ws-arch/2002Sep/0052.html
markb: logical model is good
... applying specs to specific things is where it gets
problematic
... http would be all over the architecture
mikec: you mean the mapping is difficult
heather: is there a particular spec issue
markb: uri for instance
heather: the req says uri are used all over for ID
markb: and http?
heather: explains how the logical model makes sense
... decomposes her original diagram in similar fashion to Mark's
early diagram
markj: stacks are less useful than 2D real estate with functions inside
roger: what is the diff between sla (service level agreements) and bla (business level agreements)
heather: sla cover strictly service oriented concepts
ChrisF: sla - qos, security
heather: whereas bla covers service metadata related to
business relationships
... for instance: price, trust
ChrisF: example of bla usage - two parties signing a bilateral contract to establish trust
dbooth: where is the semantics - in the top level?
ChrisF: semantic definitions is other metadata, not really the bl
heather: note that the diagram distinquishes between a service and collections of services
daveo: clarification request:
... does a service map to an individual wsdl endpoint?
scribe: <unclear response>
igor: systematically drill down the concepts in the
architecture. For example: 2 party interaction -> discovery
-> registration -> description -> WSDL
heather: agrees - but you need a comprehensive
doc
heather: (on her last slide) security and management shapes connecting the nodes of the triangle
zulah: how about using shadowing for sec & management?
markj: demostrate how to map arch styles to the diagrams - like REST...
mikec: any more pictures?
Hugo: yes but it is messy
... this diagram shows dependencies
daveo: wouldn't that be another view - like stacks, containment
<Hugo> My messy diagram: http://www.w3.org/2002/ws/arch/2/09/wsarchdiag
Hugo's diagram is a wild WS picture with lots of odd
connected shapes which relate their dependencies
mikec: lets transition the discussion to how to improve arch doc
roger: triangle diagram is useful - but it focuses on one MEP
ericn: I have another diagram showing intermediaries
Eric Newcomer presents his architecture slide
.. shows how intermediaries consume msg headers
roger: can we show more MEPs in the diagrams?
mikec: how do we help the editors use these diagrams?
daveo: I like heather's diagram because it shows a simple
& understandable view, but there are other views
... conceptual view, formats, ..... we have a choice between a
loose-goosey document
... is our output a disparate set of views, or a descriptive set
of rules (like the TAG arch doc)
... I see two distinct poles the group can follow: either very
descriptive or very perscriptive (just the facts maam)
mikec: for industry value - we have to constrain
things
... wsdl does this, WG2 does that....
roger: I sees 3 valid diagrams for our group
... 1 is a message based diagram
... 2 is technical stack diagram - nasty at the bottom, Semantic
Web on top
... 3 is role based diagram
mikec: how do we be descriptive and perscriptive simultaneously? Is that desireable?
markj: different communities will not allow us to be perscriptive
ChrisF: agrees (sortof) with mark, maybe use 'alternative common practices' rather than of a perscriptive rule set
mikec: output of the discovery agency is a wsdl document - without elaboration
markj: not necessarily a wsdl - something more general
katia: wsdl++
heather: not that the basketweave diagram (earlier daveH arch diagram) includes phasing
mikec: the content/format of the objects being sent around isn't in mark's diagram
markj: we can be perscriptive as we want to be
... the variability we address are the interactions and the
format
daveh: we should be able to describe the attributes of a description language
mikec: create placeholders for diff levels of metadata - like choreography
daveh: can we describe the properties of the desciption
space soas you can vary the properties and transition from wsdl to
choregraphy
... what is the arch functional boundary of wsdl?
<DaveO> I'd like to get on the freaking queue.
mikec: what are the attributes that define the wsdl boundary
daveo: here is a concrete proposal: but Heather's
diagrams into our document
... lets take the terms - choregraphy for instance - and define
them
... take the terms from heather, and her explainatory text
mikec: there is a rough concensus of diagrams between heather's and mark's
heather: I will submit the terms
mikec: can you submit the terms you have?
markj: follow up to daveo - do we combine the heather and mark diagrams?
daveo: friendly amendment to the proposal: the notion of
features
... security, reliability, etc and how they map to service desc
and runtime
... that integration is one of our specific functions
markj: is this appropriate for the arch?
daveh: shows a new circular diagram containing the feature set
mikec: drill into taxonomy of the feature set
heather: I want 10 min to talk about management stuff
zulah: seconds this
mikec: how do pour these diagrams into the document?
heather: will submit to editors
mikec: tomorrow do the taxonomy of the feature
sets?
... caucus to decide
... the doc will contain many views - the editors will organize
and transition
mikem: will there be a runtime view - along the lines of eric's arch demostrating the intermediary role
ChrisF: yes along with design time view
Heather Kreger presents her management slides
heather:
... goes over management goals and reqs
... support that somebody can define all the management
functions
... there is an OASIS Management TC
... DMTF kicked off effort too
... WSA role - give them context, guidance, keep deliverables
consistent, promote interop
... wants a management TF to satisfy WSA management
requirements
... manageable components: WS containers, WS themselves,
Registry
mikec: what is a container in this context?
zulah: it is a runtime env for the service
dbunting: what about management of the ditributed WS?
zulah: out of scope
igor: coordinating services will need to be managed, but as we go
dbunting: management of groups of web services is the original query
heather: will send the uri to the ppt
heather: I wants a vote to form a management
TF
... the deliverables - basic management data, asses to management
data, to dos and timelines, coordinate with other standard
bodies
daveo: wants management scenario to illustrate the problem space
heather: agreed, but perhaps after the timeline
deaveh: and glossary deliverable
heather, zulah: agreed
daveo:daveo: asking for a page for the UC/WS document. This is a low-bar effort - more of a context scoping effort. The bar should be about as low as possible, should not be a significant amount of time
daveh: glossary should explain domain specific terms
markj: where will this be rolled into?
heather: into the arch doc
mikec: this might be a template for how we attack other
areas of the WS arch
... establishes interest to participate in this TF from HP, CA,
IBM, and Thomson
roger: I like the precedent of requiring UC/UC and glossary from TFs
mikec: what is the Management Task Force (MTF) process?
daveh: use public ML - but expect a report
zulah: the pushback for UC/US/Glossary is a delivery time
issue only
... nominates heather to lead the MTF
prasad: I would also like to join the MTF
<zulah> ACTION: Chairs to Add report from MTF (Management Task Force) to the weekly agenda
daveh: there are a plethora of specs relating to
workflow, choreography,
... we have authored a set of statements detailing our position on
scoping new WGs
... lets push the statements into IRC
<DaveH> Proposed Statement 1:
... [[
... The WSA WG is committed to the creation an open common Web
Services
... architecture where customers, developers, and IT vendors build
solutions
... together--an architecture that takes the principles of
interoperability,
... vendor-independence, and openness into account.
... It has become clear that a critical next step in the evolution
of Web services
... will be the ability to compose and describe the relationships
between
... Web services to support stateful, long-running interactions.
Although
... differing terminology is used in the industry, such as
orchestration,
... collaboration, coordination, conversations, etc., the terms
all share
... a common characteristic of describing linkages and usage
patterns
... between web services. For this purpose, and without prejudice,
we use
... the term choreography.
... .
... The WSA WG encourages the formation of an open, industry-wide
working
... group with the aim of developing interoperable and open Web
services
... standard(s) that support stateful, long-running
interactions.
... ]]
<dbooth> DaveH's Statement 1 text is at: http://lists.w3.org/Archives/Public/www-archive/2002Sep/att-0129/01-junk.txt
daveh: we want 3 votes one on each of the statements
zulah: clarification: this is an action to gain consensus on statement 1 - which is an agreement on intent
mikec: Do we need an industry wide group focused on
choreography?
... Second, does the W3C form this WG?
... Third, irrespective of the other two, What else should we
do?
DaveH: This is a scoping statement. It is within our charter to develop scoping statements about work that needs to be done. We are looking for a decision on this statement.
DaveO: The paragraph that you are asking on now, does not predjudice the formation in a particular body.
DaveH: we are considering scoping work that needs to be
done.
... So first, does the industry need to do this, then,
second, should the W3C charter the WG.
Scribe: dbooth
Scribe: (Discussion of the potential process for chorography work in W3C.)
DaveH: Understanding the scope of arch areas is part of
our charter.
... Bringing a proposed charter is also something we've been asked
to do.
Suresh: I have a question about the WG. If it is chartered, when could it begin?
DaveH: We'd be lucky to have it chartered and operating this calendar year. The goal would be to start it in November, but I think that's unrealistic.
Martin: We already have something in our requirements doc. What's the relationship to this document? I.e.: http://lists.w3.org/Archives/Public/www-archive/2002Sep/att-0129/01-junk.txt
MikeC: This document encourages the formation of a group now.
Katia: Please add "... in a timely fashion ..." to the document.
DaveH: I consider that a friendly ammendment.
<zulah> Re-paste of the statement currently under
discussion:
... [[
... <zulah> Consensus on statmenet - just entered into IRC
which is an agreement on intent
... <zulah> MikeC Do we need an industry wide group focused
on choreagraphy
... <zulah> Second, does the W3C form this WG
... <zulah> third, irrespective of the other two, What else
should we do
... ]]
<DaveH> .
... The problems posed by the lack of a widely adopted
choreography
... specification, the current proliferation of overlapping
work,
... and the time required to complete this effort merit the
chartering
... a new WG now.
... .
RESOLVED: Unanimous support for statement 1: http://lists.w3.org/Archives/Public/www-archive/2002Sep/att-0129/01-junk.txt
<DaveH> Proposed Statement 2:
... [[
... The WSA WG encourages the W3C Web Services Coordination
... Group to recommend the creation of a working group to address
the
... choreography space. This WG should also coordinate with
other
... WGs within the Web Service Activity, with the aim of
developing an
... interoperable and open standard for Web service
choreography.
... Attached[1] is a charter proposal for a Choreography WG
that
... encompasses the WSA WG recommendation for the scope of
... this effort.
... .
... [1]
http://lists.w3.org/Archives/Member/w3c-ws-arch/2002Aug/att-0054/01-part
... ]]
Scribe: Quote from WSA charter ( http://www.w3.org/2002/01/ws-arch-charter#arch
):
... [[
... In particular, the Working Group will clearly delimit the
boundaries of each identified component, and model the interfaces
between them, so that the scope of new Working Groups created to
address each piece of is unambiguously defined.
... ]]
... More from the charter:
... [[
... The Working Group will describe a detailed architecture. . .
.Those descriptions will be used as input by the Web Service
Coordination Group <../ws/cg/> for the chartering of new
Working Groups at a later date.
... ]]
<Suresh> Clarification sought:
... Will this WG work be *after* the workshop or will the
chartering work continue?
DaveH: We will continue to move ahead in parallel.
ChrisF: The best we could do from this WG is to provide something to the CG, but they're the ones that draft the charter.
DaveH: Yes.
<jeffm> So the WSA WG's formal role in the chartering process ends once we pass it on
MarkJ: I think we should go ahead with this now.
RogerC: I think two things are critical: The timeframe, which should be quickly; and that the important stakeholders be brought to the table.
MarkJ: I think the sooner the better.
Katya: Agree.
Zulah: I think choreography standards should go forward. I think it's important that the major contributors participate, and i think it's important tht it be timely.
AllenB: The particulars of the proposed charter will be
important to us.
... The only other things of this scale were Schema and QUery, and
they both had a lot of operational work in place first.
DaveO: what do you mean by "Operational experience"?
AllenB: In the case of data reduce, there were several thousand schemas.
JeffM: We think the sooner the better. I think the scope
is fairly well defined. There's fuzziness around the edges, but no
more than for other work.
... I think it's obvious that the industry needs a single forum,
preferably RF, where work in this space can occur.
... If we need more workshops than we can do that, but I think
that's a delaying tactic for what we obviously know we need.
DougB: I like many of the previous comments: Zulah,
etc.
... One of the reason's the proposed charter reads the way it does
is because we had a general consensus that it would be good to have
a workshop and use the results as Wg input, but we didn't want to
slow down the formation of the WG.
... So we wanted to do them in parallel.
Colleen: I agree. Also the need for speed.
DaveO: We have our name on some of these inputs, but it
isn't clear how they should be used. The proposed charter doesn't
give clear enough direction.
... Of the list of 7 things, one or more of them might not be
availabe to the group and that would be bad.
... Or they might all be available, and we might have a year long
squabble about how to merge them together, and I'm concerned about
how that might happen.
<vorth> I have to drop off the call... regrets
DaveO: Regarding AllenB's comment, I think the way this
group is chartered is to deal with that issue. That's part of what
this group is chartered to do.
... i see less of a need for workshops. That's what we're here to
do.
... Any issues that we have a related to the process by which we
get the group going.
... My overall opinion is neutral.
ChrisF: I'm concerned about the scope, the "boil the
ocean" approach.
... It's a fairly large issue. It's not just SoAP.
... A lot of these proposals a diametrically opposed to each
other. Some are top down, others bottom up.
... This is like saying "let's boil the ocean and see if we can
come up with something".
... Also I think we probably do want something along the lines of
a workshop where we can invite these contributors to figure out
where the world wants to go, rather than try to get unified chor
theory.
... I think somethign along the lines of the security forum might
be good.
... What is the right organization for shepherding this?
... We need to consider all these things.
MikeC: For those who expressed concerns, is there any plausible rewording of the proposal that would alleviate your concerns?
Scribe: (no response)
Ugo: I am in favor of the proposal.
... I think we should try to get permission from the authors of
the reference documents do use them for this future WG.
... I am in favor of having also the workshop started ASAP in
order to require participation from experts as early as
possible.
EricN: IONA was the first to market for a workflow
product.
... It uses a proprietary language.
... The industry hasn't adopted a standard yet, so we're still
using our own.
... But we prefer having a standard.
... We'd like to have one and move on.
Igor: The area is pretty well defined. But I think it's important that we not drop it from the architecture.
Prasad: I think the time has come for a WG. We definitely
support the proposal.
... But I concur that we need cooperation from the other
contributors.
Suresh: Suresh: I think there is confusion in the market.
Though we use BPML in our product, we also would like to see a W3C
standard.
... But instead of trying to find a unified choreography theory, I
think we should try to leverage previous work, and build bridges
with other standards where necessary. I think we should scope the
WG better, but I think we should advance the charter.
<igors> For the record: I also noted that I'd prefer to offload debates and desision making on the specific matters of choreography to a more focused group than this
Scribe: (Scribe apologizes to IgorS for not being able to keep up with all comments!)
DaveH: I know a lot of people put a lot of effort into
this.
... There are serious issues of the tech integrity of this
project. Having tackled schemas, i understand those concerns. I
also understand the concerns of not having sufficient material
submitted to the group, and i turn that around as a challenge to
the member companies to submit those materials to the W3C for
consideration.
<DaveH> daveh also noted the effort, and focus on openness and interoperability by all parties involved.
JeffM: This is a large space. The only way to come to
consensus is to do the work. Workshops don't do this. The last
thing I need is yet another set of presentations in order to know
that we need to do the work.
... If it's that big a task, then that's the reality.
... When we drafted the proposed charter, we concluded that the
only way to get past some of these issues was to presuppose the
answer. So we need to get the people together and decide on a
compromises.
Roger: DaveO expressed dismay at the size of the list of input technologies. The only way to get past this is to lop off some of the inputs. But it's clear that this WG doesn't have the expertise to do that, so we should just let the new WG do that.
MarkJ: It's some comfort that IONA has done somethign in this space. We also have the existance of multiple specs, so the problem may be large, but I thinnk we have some proof that it isn't insurmountable.
ChrisF: Addressing the point Jeff was making, it's not
clear to me that we CAN get the right people around the table at a
W3C WG.
... There's a hurdle to join W3C, and maybe not all want to jump
over that hurdle.
... I think it's important that if we tackle this space, we do it
in a body where the parties can participate.
... The big question I think is: What's the right place?
AllenB: The way it was done in Query was that the WG was open -- not just W3C members.
DaveH: We are not necessarily the experts in the space.
Martin: If it's not here, where else? If it's somewhere else, it's going to be the same people. WS Security had 85 people last week. It doesn't matter where it goes, the same thing's going to happen.
Zulah: What experts don't have access to W3C? And can't we invite them as experts?
AllenB: The XLang people are largely academics.
DaveH: WGs can have invited experts at the chair's
discretion.
... I'd like to take a formal vote.
<DaveH> Here is the proposed statement:
... [[
... The problems posed by the lack of a widely adopted
choreography
... specification, the current proliferation of overlapping
work,
... and the time required to complete this effort merit the
chartering
... of a new W3C WG now.
... .
... The WSA WG encourages the W3C Web Services Coordination
... Group to recommend the creation of a working group to address
the
... choreography space. This WG should also coordinate with
other
... WGs within the Web Service Activity, with the aim of
developing an
... interoperable and open standard for Web service
choreography.
... Attached[1] is a charter proposal for a Choreography WG
that
... encompasses the WSA WG recommendation for the scope of
... this effort.
... .
... [1]
http://lists.w3.org/Archives/Member/w3c-ws-arch/2002Aug/att-0054/01-part
... .
... ]]
Scribe: Formal vote:
ATT: y
BEA: abs
Carn: y
Chev: y
Cisco: abs
CA: y
Contivo: abs
FranceTel: abs
Erikson: abs
HP: y
IBM: abs
Idoakoro: abs
IONA: y
Mitre: (not present)
Nokia: y
Oracle: y
Microsoft: n
Progress: y
Roguewave: y
SeeBeyond: y
SoftwareAG: y
Thompson: y
SAP: (by proxy) y
Sun: y
Tibco: (not present)
Stirling: y
WWGrainger: (not present)
W3C: abs
WebMethods: y
Fujitso: (not present)
Scribe: (end of vote)
... Final vote tally:
... [[
... 17 Yes: AT&T CA CarnegieMellon ChevronTexaco HP IONA Nokia
Oracle Progress Roguewave SAP SeeBeyond SoftwareAG Stirling Sun
Thompson WebMethods
... 1 No: Microsoft
... 8 Abstain: BEA Cisco Contivo Erikson FranceTel IBM Idoakoro
W3C
... 4 Others attended the F2F but were not present for the vote:
Fujitso Mitre Tibco WWGrainger
... ]]
Scribe: Volunteers for workshop program committee: JeffM, Katya
Martin: I think a workshop should be the first mtg of the new WG.
Scribe: Straw poll: Should we pursue a workshop
idea?
... (Many hands up in favor, 2 against)
EricN: I'm not sure we need a workshop. I don't want to delay the formation of a WG. I think the proposed charter is clear enough.
MarkJ: But the work would be done in parallel.
EricN: There are two leading proposals, and having a workshop won't help. But I don't have a strong objection.
MikeC: Who would volunteer for a TF to propose a workshop?
Scribe: Volunteers noted: Katia, JeffM, Suresh, DougB,
MikeC: Proposed Statement 3b: The WSA WG shall work with
the W3C mgmt to request the authors of the specs referenced in the
proposed charter submit these specs to the w3c as notes.
... Specifically BPEL. I don't know specifically what others.
DougB: I have no idea how extraordinary this request would be for w3c. (Would this be an unusual request?)
MikeC: Should the w3c try to get these specs to be considered?
Hao: What's the impact of getting it submitted as a w3c Note?
MikeC: Without formal submission, it's a tenuous situation. Everyone involved would be happier if they were submitted.
Martin: Why not be specific? Why not ask for BPEL to be submitted?
DaveH: For me, others are also significant.
Suresh: There are other specs that could potentially be submitted also.
MikeC: There was a suggestion that we single out some specs, but that seems to be problematic.
Roger: If the w3c cannot get the stakeholders to the table, I don't think w3c should do this.
DaveO: It's not just about the submission of documents. It's also about what kinds of things are used as input that can cause concern about doing the work. I think that's the bigger issue.
MikeC: I think we should leave this to W3c to decide.
DaveO: People think significant stakeholders need to be at the table, and the importance of that needs to be communicated to W3C Management.
MikeC: We're asking w3c to do what they can to get these stakeholders to the table.
Scribe: (Straw poll)
... Many in favor, none against.
Consensus: We should ask W3C management to work with the authors of other specs listed in the chor wg charter proposal to get them to the table.
Scribe: ACTION: Chairs to ask W3C management to work with the authors of other specs listed in the choreography WG charter proposal to get them to the table
Scribe: Mark Jones
Scribe: The next F2f is in Boston in mid-November hosted
by Macromedia.
... Hao has offered to host in Sydney in mid-January 2003.
... Another alternative for the January meeting would be a
west-coast company.
... The March meeting would likely be in Cambridge.
Scribe: DaveH will be posting an i18n issue as soon as he
can re-sync.
... Hugo will help Allen with XSL hacking on the Glossary.
<zulah> [[
... AC033 The WSA must enable Peer to Peer interoperable web
services
... AR033.1 The wSA must support peer to peer message exchange
patterns
... AR033.1.1 request-response
... AR033.1.2 publish-subscribe
... AR033.1.3 events and event notification
... AR033.1.4 forwarding
... AR033.2 The WSA must not preclude persistent identities for
peers
... AR033.3 The WSA must not preclude determining capabilities for
peers
... AR033.4 The WSA must enable direct peer to peer interactions
without the
... use of third party intermediaries
... AR033.5 It must be possible for peers to discover each
other
... ]]
... [[
... AC033 The WSA must enable Peer to Peer interoperable web
services
... AR033.1 The wSA must support atleast the following peer to
peer message exchange patterns
... AR033.1.1 request-response
... AR033.1.2 publish-subscribe
... AR033.1.3 events and event notification
... AR033.1.4 forwarding
... AR033.2 The WSA must not preclude persistent identities for
peers
... AR033.3 The WSA must not preclude determining capabilities for
peers
... AR033.4 The WSA must enable direct peer to peer interactions
without the
... use of third party intermediaries
... AR033.5 The WSA must not preclude the use of th
... ird party intermediaries
... AR033.6 It must be possible for peers to discover each
other
... ]]
<hao> peer-to-peer
<zulah> [[
... AR033.5 The WSA must not preclude the use of third party
intermediaries (e.g., forwarding)
... ]]
... note that 33.1.4 has been removed.
... NOTE that 33.1 has typo - wSA/WSA
Scribe: As pasted above, AR033 is approved.
<dbooth> Frank had to leave suddenly, due to a
family illness, but Katya, Roger Cutler and I worked last night to
edit his proposed requirements in an attempt to help the group
reach agreement on them.
... Frank's high level goal:
... [[
... AG037 Business Friendly
... The Web Services Architecture enables the
... potential evolution of business needs
... Critical success factors:
... AC033 Peer-to-Peer Interoperability
... AC034 Multi-party Interactions
... AC035 Service Re-use
... AC036 Semantic Descriptions
... ]]
<chrisf> fyi, here's latest draft of WSA Req'ts doc: http://www.w3.org/2002/ws/arch/2/09/wd-wsa-reqs-20020912
Scribe: Due to technical difficulties, we're shifting to
the Glossary discussion...
... Allen has re-organized the Glossary around the 3-stack
diagram.
... The Glossary currently has been harvested from multiple
sources (whose attributions have been captured).
... The definitions overlap and conflict, and do not yet have a
direct correspondence with the architecture doc.
<dbooth> The top level goal again:
... [[
... AG037 E-Business Friendly
... The Web Services Architecture enables the
... potential evolution of business needs
... Critical success factors:
... AC033 Peer-to-Peer Interoperability
... AC034 Multi-party Interactions
... AC035 Service Re-use
... AC036 Semantic Descriptions
... ]]
... The CSF groups:
... [[
... AC034 Multi-Party Interactions
... Web Services must not preclude the support of N party
interactions, such as auctions, escrow services, proxy services,
broker services
... AR034.1: Systems must not be precluded from quoting, verbatim
and modified, messages within top-level messages, to an arbitrary
depth
... AR034.2: Web Services must not be precluded from supporting
interactions where one or more parties of the interaction are
anonymous
... AR034.3: Systems must not be precluded from supporting
multiple receivers and `wait' points in service orchestration
... ]]
... (The above is the proposed re-wording of one of Frank's
requirements.)
... [[
... AC035 Service Re-use
... The Web Services Architecture must permit the effective re-use
and composition of services
... AC035.1: It must be possible to compose services dynamically,
on the fly, as well as statically
... AR035.3: It must be possible to express sequencing and nesting
of services, and the flow of information between services
... AR035.4: Must not preclude the possibility for third parties
to verify performance of services (where performance includes
results as well as timeliness)
... ]]
... [[
... AC036 Semantic Descriptions
... The Web Services Architecture must not preclude the
characterization of a
... Web Service that attempts to make its semantics clear to an
automatic system
... AR036.1: It must be possible to publish references to an
ontology in a Web Service description
... AR036.2 Web Service descriptions must not preclude the
characterization
... of temporal characteristics of the service.
... ]]
... Frank's proposed requirements reworded:
http://lists.w3.org/Archives/Public/www-archive/2002Sep/att-0132/01-frank-requirements-02-09-11.txt
... Frank's original proposed requirements:
http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0313.html
... who just joined the phone bridge?
Scribe: <AC034 discussion>
<dbooth> [[
... AC034 Multi-Party Interactions
... Web Services must not preclude the support of N party
interactions, such as auctions, escrow services, proxy services,
broker services
... ]]
Scribe: Zulah would like some of these terms in the glossary.
<dbooth> [[
... AC034 Multi-Party Interactions
... The Web Services Architecture must not preclude the support of
N party interactions, such as auctions, escrow services, proxy
services, broker services
... ]]
<yinleng> The term "quoting" is unclear
Scribe: AC034 statement was approved.
<dbooth> [[
... AR034.1: Systems must not be precluded from quoting, either
unmodified or modified, messages within other messages, to an
arbitrary depth
... ]]
Scribe: AR034.1 was approved.
<dbooth> [[
... AR034.2: Web Services must not be precluded from supporting
interactions where one or more parties of the interaction are
anonymous
... ]]
Scribe: AR034.2 was approved.
<dbooth> [[
... AR034.3: Systems must not be precluded from supporting
multiple receivers and `wait' points in service orchestration
... ]]
Scribe: AR034.3 was rejected.
<dbooth> [[
... AC035 Service Re-use
... The Web Services Architecture must permit the effective re-use
and composition of services
... ]]
... [[
... AC035.1: It must be possible to compose services dynamically,
on the fly, as well as statically
... ]]
Scribe: AC035.1 had no clear consensus.
<dbooth> [[
... AR035.3: It must be possible to express sequencing and nesting
of services, and the flow of information between services ]]
... [[
... AR035.4: Must not preclude the possibility for third parties
to verify performance of services (where performance includes
results as well as timeliness)
... ]]
Scribe: AR035.3 was not accepted.
... AR035.4 was not accepted.
<soliton> ar35.4 covered in ac18.03
<dbooth> ALso not accepted:
... [[
... AC035 Service Re-use
... The Web Services Architecture must permit the effective re-use
and composition of services
... ]]
<dougb> group notes 35.1 covered in 23, 35.3 covered in 17, 35.4 covered in 18
Scribe: AC035 is not accepted since the sub-bullets were not accepted, largely due to the redundancy with other requirements and csfs.
<dbooth> [[
... AC036 Semantic Descriptions
... The Web Services Architecture must not preclude the
characterization of a
... Web Service that attempts to make its semantics clear to an
automatic system
... ]]
<zulah> Response to AR035.4: This is covered in AC018. Specifically 18.1.1 which covers the availablility of standardized metrics in architecture implementations; 18.1.4 which covers a standard methodology for accessing metrics (e.g.,performance metrics); and 18.3 which explicitly statement that is must be possible to monitor performance.
<DaveH> chair notes that the efforts to describe these canidate requriements is greatly appreciated, the subject of these items are believed to be covered in specific requirements identifiied during disucssion.
<dbooth> [[
... AR036.1: It must be possible to publish references to an
ontology in a Web Service description
... ]]
Scribe: This closely relates to AR009.4.
<DaveH> related requirement: AC009.5
... also realated to 9.3
<dbooth> Reworded:
... [[
... AR036.1: It must be possible to publish a URI reference to an
ontology in a Web Service description ]
... ]]
Scribe: AR036.1 is accepted and to be merged with AR009.5.
<chrisf> http://www.w3.org/2002/ws/arch/2/09/wd-wsa-reqs-20020912
Scribe: AR036.2 is not accepted -- lack of precision, other similar characteristics are not specifically called out for 'must not preclude'.
<chrisf> [[
... AR009.4 It should be possible to characterize the semantics of
a web service using technologies adopted as part of the Semantic
Web.
... ]]
Scribe: AC0036 was accepted and is to be merged into AR009.4
<dougb> suggests AC036 could replace ac009, move existing 009 to be 009.4, move exsting 009.4 to be 009.4.1 (as part of editorial shift we just accepted)
<chrisf> [[
... AR009.4 The Web Services Architecture must not preclude the
characterization of a Web Service that attempts to make its
semantics clear to an automatic system using technologies such as
those adopted as part of the Semantic Web.
... ]]
... the wording above is what I used for AC009.4
<zulah> We concur with Dougb
<dbooth> Wording not accepted (as
unnecessary):
... [[
... AG037 E-Business Friendly
... The Web Services Architecture enables the
... potential evolution of business needs
... ]]
Scribe: Zulah recommends that we put AC033 under AG003.
<zulah> [[
... AC033 The WSA must enable Peer to Peer interoperable web
services
... AR033.1 The wSA must support atleast the following peer to
peer message exchange patterns
... AR033.1.1 request-response
... AR033.1.2 publish-subscribe
... AR033.1.3 events and event notification
... AR033.2 The WSA must not preclude persistent identities for
peers
... AR033.3 The WSA must not preclude determining capabilities for
peers
... AR033.4 The WSA must enable direct peer to peer interactions
without the
... use of third party intermediaries
... AR033.5 The WSA must not preclude the use of third party
intermediari
... intermediaries (e.g., forwarding)
... AR033.6 It must be possible for peers to discover each
other
... ]]
Scribe: Editors should decide where AC033 should be put
in the document.
... Editors should decide where the other accepted CSF's should be
placed.
Scribe: <Agenda -- pulling together what we want to do next.>
<yinleng> There was a suggestion to replace Peer to Peer interoperable with Peer to Peer interaction between for AC033
Scribe: DaveH -- we thank our host for the great facilities.
<zulah> [[
... AC033 The WSA must enable Peer to Peer interacting web
services
... AR033.1 The WSA must support atleast the following peer to
peer message exchange patterns
... AR033.1.1 request-response
... AR033.1.2 publish-subscribe
... AR033.1.3 events and event notification
... AR033.2 The WSA must not preclude persistent identities for
peers
... AR033.3 The WSA must not preclude determining capabilities for
peers
... AR033.4 The WSA must enable direct peer to peer interactions
without the
... use of third party intermediaries
... AR033.5 The WSA must not preclude the use of third party
intermediaries (e.g., forwarding)
... AR033.6 It must be possible for peers to discover each
other
... ]]
Scribe: Roger may be able to provide graphic resources
for the document figures.
... DaveH -- need more discipline in email postings to make them
more effective.
... DaveH -- read and respond to editorial work.
<DaveH> The Working Group maintains an issues list.
The process used to administer the issues list is documented in the
Web Services Architecture Issues Process.
...
http://www.w3.org/2002/ws/arch/2/04/wd-wsa-issues-process-20020426
... how? It was to the network drop
<dbooth> Here is the current WSDL 1.2 Primer editor's draft: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12-primer.html
Scribe: DaveH -- read and respond to editorial work.
<DaveH> The End---for now
<zulah> 2. Invite liaisons
... OASIS liaison to DMTF (is there one)
... DMTF liaison to Oasis management TC
... * Would like to make "formal" the relationship with the two
groups. Heather will propose this at her meetings next week.
... * Might consider an "OGSA" rep at some time
... * we will not solicite other companies
... Hi mark!!
<soliton> this is management meeting.
<zulah> 0. Review what we have done so far -
document contents
... Move to adopt this as our starting point with the addition of
an arch assumptions section
... Note that we are beginning an MTF meeting
... Requirements - AC018
... Scope
... Making ws implementation, of the arch as a whole and a
particular ws, manageable.
... Not in Scope
... Management Applications
... We would like to add software distribution support as not in
scope
... Data
... · Identification
... · Configuration
... · Metrics
... · Operations
... · Events
... Access
... · To Service Container
... · To Web Service
... · To Registry
... Discovery
... · Of managable components
... · Of management data
... Suggest two use cases: B2B and EAI
... Managed Components
... Web Service Container
... Identification
... Identification information:
... o service identifier
... o service name
... o service description
... Configuration
... Configuration information
... o its access URL
... o its WSDL description URL
... o configuration files
... o Handler chain
... o Security settings
... single protocol for accessing data - which can be used for
accessing from all arch components
... change container to execution environment
... metrics
... notifications
... operations
... unique identifier ==URI
... must explain handler and handler chain