Web Services Architecture Face to Face Meeting -- 16 May 2003

Present: Chris Ferris (remote) Dave Hollander, Dave Orchard, Doug Bunting, Kevin Liu, Martin Chapman, Mark Jones (remote), Mike Champion, Roger Cutler, Davie Booth (remote), Eric Newcomer (remote), Hugo Haas, Jeff Mishinsky, Paul Denning (remote), Ugo Corda (remote) Yinleng Husband

Regrets:

Chair: Mike Champion

Scribe: Mike Champion

walking through the spec to see where work is needed; version reviewed: http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch-review2.html?rev=1.27&content-type=text/html

<mchampion> 1.3 needs updating, hodgepodge of other topics besides organization
... 1.4 put in the normative hasa-isa stuff
... 1.5 trout!
... DaveH: role of humans doesn't talk about exceptions, and possibility that WS moves responsibility away from humans
... daveh: move most of 1.5 into 2
... 1.6 needs venn diagram stuff, major discussion
... maybe telcon dedicated to this, grounded in email discussion
... 1.6 needs discussion of binding, early/late

<MChapman> when we discuss rest soa vs ws soa we should have champions for those that think there is a distinction and those that think there is no difference

<mchampion> 1.7 needs bridge between diagram and concepts discussion; basically wordsmithing
... 1.7 needs discussion of MEPS, synchronous, stuff if we are going into binding issues [some believe anyway]
... 2.1 done
... 2.1. see Wednesday minutes
... 2.2.1 Agent
... Roger: provides operations, not agents ...
... Needs reconsideration in light of Thursday discussion
... 2.2.1 rework
... 2.2.2 Authentication
... Hugo- not happy with summary
... Daveh: too abstract for this section of doc; more of a feature that crosses layers
... Abbie: Security needs to be overlayed
... 2.2.2 Delete or move (potentially)
... 2.2.3 Choreography
... linked off spaghetti diagram;
... some discussion of whether it belongs in diagram itself
... choreography/orchestration distinction needs to be made clearly.
... 2.2.3 needs rework, Martin owns it
... 2.2.2 Choreography description language
... daveh: this is the concept node, the "choreography" concept is a relationship
... others: don't agree
... martin: this section is lower level than other "core concepts"
... 2.2.4 compress, move, consolidate
... 2.2.5 Corelation
... martin: this is a label on an arc; move to relationships
... a2.2.5 move to relationships
... roger: not so sure that this is an arc; which arc.
... Consensus on 2.2.5 - no spaghetti
... 2.2.6 Deployed Element
... Not spaghetti; management is an overlaid concept
... wording is out of date with WG thinking.
... 2.2.6 ask MtF to rework
... 2.2.7 Discovery
... Need concept called registry; discovery is more of a verb
... move to 2.2.8 relationship
... oops, the suggestion is "move to 2.3 relationships"
... 2.2.8 Discovery service
... Why does "registry" not work as the concept here?
... 2.2.8 Relabel, but basically needs just wordsmithing
... 2.2.9 Feature
... terminiate with predjudice?
... daveo: this is SOAP:feature, which we were going to put as key part of WSA
... hugo, martin, roger: it's a core concept, needs major rework because it says/links to nothing
... 2.2.9 Major rework, coordinate with PFTF, make sure it is linked to other concepts
... 2.2.10 Identifier
... Summary needs major wordsmithing; opaque is a property; probably we can just refer to IRC 2396
... This is tangled up in QName/URI discussion
... daveh:Seems to be glossary term, but not something that we will add constraints to
... daveo: TAG thinks it's an architectural issue.
... hugo: if everything has an identifier, everything will point to it.
... daveh: it's a property, not a concept
... 2.2.10 - rework, possibly move, may not be core concept
... 2.2.11 Intermediary
... "an agent" is too slim a definition
... also, not same sense of "agent" as in Thursday discussion
... 2.2.11 Major rework
... 2.2.12 Legal entity
... dave: we should not use word "legal"
... martin: call this "owner"
... abbie: abstraction of different concepts in management domain and security domain, doesn't belong here
... roger: this basic concept needs explicaiton; at what point in arch are things owned?
... 2.2.12 - rename to owner, rework
... 2.2.13 Lifecycle
... martin: property not box

<Roger> 2.2.12 - I think it is important to connect this to service (or some box very close to service) as well as agent, and to try hard to figure out exactly what boxes this thing connects to. I view this as an important, practical aspect of the architecture.
... 2.2.12 - One issue that this addresses, or should address, is whether the ownership of one box can differ from that of another, whether the ownership of some set of boxes is inherently coupled, or whether we don't know.
... 2.2.12 - Looking to the future, it seems to me that when we have a more fleshed out architecture we may want to get assistance on this issue from someone with specialized knowledge. (As in, a lawyer).

<Roger> 2.2.12 - If ownership of portions of the architecture cannot, by their nature, be determined I think that this may expose serious flaws in the architecture.

<Roger> 2.2.13 - This seems to come from the management stuff, but it seems to me it might be identical to something in the choreography domain.

<mchampion> mike: management is an overlay
... dave: it's a property not a concept
... dave: need a new category of properties that will be associated with concepts rather than abstract model concepts as such
... martin, dave: properties in UML sense
... 2.2.14 create properties section and move there, then rework
... 2.2.15 answers the question itself - move to properties
... 2.2.16 Management event
... daveo: nuke, there are bazillions of events we could discuss
... daveh: event might be a concept ...
... daveo: event is a type of MEP ...
... 2.2.16: remove from 2.2 put in section 3?
... 2.2.17 Manager
... dave: concept of agent that supervises rather than performs is a good idea
... 2.2.17 no consensus, so rework/discuss, consider deleting/moving
... 2.2.18 manageable element
... 2.2.16 - 2.2.20 treat as a block
... abbie: it's like security ... move
... 17 move to section 3
... whole block - move, reconsider. metrics are a particular candidate for deletion
... 2.2.21 message

<mchampion> wordsmith, subdivide? It has too many relationships
... messages should have bodies ???
... 2.2.21 wordsmith, level of detail needs consideration
... 2.2.22 MEP
... likely to move to relationship or theoretical concept ... hard to think of it on spaghetti diagram
... definition is wrong to refer to single instantiation of a service
... relationship to choreography must be clarified
... 2.2.23 message header
... bring into refactoring of message
... all the MAY stuff is unncessary
... this is all wrapped up with feature discussion
... 2.2.23 - include with 2.2.21 refactoring, relationships need rework, need to incorporate feature concept
... 2.2.24 message description language
... do the same as with choreography description language - compress, move, consolidate
... 2.2.25 message identifier
... property of a message
... roll into identity discussion
... 2.2.25 remove as core concept, incorporate into 2.2.21 resolution and properties section
... 2.2.26 message recipient

<mchampion> daveo: WSRM spec discusses all this well, we should familiarize ourselves with their concepts

<MChapman> the identifer section is a general sectin talking baout the concpet/principles of identity plus (maybe) an ennumeration of teh types of identifiers in out architecture

<mchampion> merging in "sender" because it will ahve the same disposition
... sender, receiver are agents that represent their turtles, may have relationship with intermediaries
... we need to do similar harvesting as with wsdl yesterday
... ACTION: martin will try to create a harvesting of SOAP as we did with WSDL
... 2.2.28 reliability messaging
... move to section 3
... 2.2.29 remove from core concepts, discuss in relationship with webarch
... 2.2.30 resource same disposition as 29

<mitrepauld> Representation seems like a very core piece of web arch, and seems (to me) related to "message"

<DaveO> PaulD, I tried to bring up in XMLP the issue about relating representation to message, and they pushed back.

<mitrepauld> DaveO, but they probably thought it was an architecture issue ... for WSAWG

<mitrepauld> Are not "web architecture" and "web services architecture" core concepts? We spend a lot of time thinking about how web arch relates to WSA. All we say in 1.6.2 is that WA and WSA are instances of SOA. Seems like we need to say more, especially if we delete "Representation" and "Resource" from Section 2.1
... WSA Requirements doc: CSF: AC011
... is consistent with the architectural principles and design goals of the Web. These principles and design goals are generally outlined in [TAGTOC], [AXIOMS], [WEBAT50K], and in [REST].

<mchampion> 2.2.31 TBD ... high priority discussion
... 2.2.32 same bucket as other descriptions ... also tangled up with the 2.2.31 discussion

<mitrepauld> Stack diagram has a box "Descriptions". Service description is-a Description.

<mchampion> daveh: rename semantic description, handle it with the other descriptions

<DaveH> Contract should be the thing...but I don't like the legal connotations of "contract".

<DaveH> Service Semantic as described here is a semantic description, no different than syntax description.\

<mchampion> mike: service semantics is too complex a blob to be a property, so it's a core concept that needs wordsmithing

<mitrepauld> DaveH, "Legal contract" would be something different or more specialized. "WS Contract" not (necessarily) "Legal contract"

<DaveH> It will be hard to keep the innocent from assuming "contract" would imply "legal contract"

<hugo> Hugo: 2 different things: the contract/goal/tasks of a service and the description of these "goals/tasks"; the former should be a concept, the latter go in the description section

<DaveH> There is a general consensus that semantics descripiton is what is being defined here and similar to other descriptions

<hugo> mitrepauld, the contract should be linked to TBD:service, I think
... although TBD:service isn't well defined :-)

<mitrepauld> If we talk about contract under TBD:service, does contract need to have its own section 2.1.x?

<bijan> I'd just like to flag that "the contract between the service provider and the service requester that expresses the effect of invoking the service" probably has subtle problems, particularly if "A service semantics may be formally described in a machine readable form " is "may be *completely* formally described"

<DaveH> complete 1.5.2 and 3.4 then adopt concepts into 2.2.35
... wordsmith and stay
... wordsmith and move
... rework and stay
... remove

<mitrepauld> Semantic description can determine a "safe" operation (GET vs POST)?

<mchampion> option 1: rework with david booth's stuff and keep in core concepts
... option 2: move to description section, reworkiing to incorporate david booth's stuff as appropriate

<mchampion> 4 to 4 for options!
... Rework and figure out what to do later!
... 2.2.36 Service Task

<hugo> Hugo thinks that the solution is rework and split, which reflects the straw poll

<mitrepauld> either part of semantic description or WSDL operation (or both)
... If you delete "Representation" and "Resource" and leave "Service Task", something feels wrong

<mchampion> Service task -- roll into 2.2.31 discussion and/or turtle discussion
... 2.2.37 SOAP
... not a core concept, but clearly we need to harvest SOAP like we harvested WSDL
... daveh: put this in "stakeholder perspectives" discussion
... shows mapping back to core concepts

<mitrepauld> I need to drop of the phone and IRC for a while. Hanging up phone now.

<mchampion> Closiing the official meeting. Moving to a working lunch and BOF on sorting out the turtle after lunch with remaining people
... we are adjourned
... The Chairs wish to thank Canon for their wonderful hospitality!!!

<DaveH> If the MEP uses extensions to the Uniform Interface, then it MUST publish the schema governing the extensional features.
... and for the protocol containing the extensional data
... If the MEP uses extensions to the Uniform Interface, then it MUST publish the schema governing the extensional features
... and for the protocol containing the extensional data
... Dave's wild eyed ideas
... Goal - if the "operations/semantics/nuance/etc" are in the message, then this assures that it will be accessible and visible, at least at the level of other XML data

Web Services Architecture Face to Face Meeting
16 May 2003

Attendees

Contents

walking through the spec to see where work is needed; version reviewed: http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch-review2.html?rev=1.27&content-type=text/html

Summary of Action Items

Web Services Architecture Face to Face Meeting 16 May 2003

Attendees

Contents

walking through the spec to see where work is needed; version reviewed: http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch-review2.html?rev=1.27&content-type=text/html

Summary of Action Items

Web Services Architecture Face to Face Meeting
16 May 2003