Web Services Addressing F2F Day 3

<dorchard> scribe: dorchard

<scribe> scribe: daveorchard

<scribe> scribe: dorchard

Chair requests any more issues

Chair then We'll start prioritizing

crowd: jocularity but no new issues

crowd compliments scribe on word selection

<Gudge> http://www.w3.org/2002/ws/addr/wd-issues/

<scribe> chair: issue 6 discussion

<Gudge> http://www.w3.org/2002/ws/addr/wd-issues/#i006

Importance of issues

chair asks for poll on importance of issues to folks

pushback on question..

Michael: write a paragraph on each issue

rebecca: tech question on issue #6 addresses the same across transports.

<scribe> Chair: Trying to get prioritization and support for issues

Jonathan: how about just ask for priority

DaveO: Concerned about meeting schedule if lengthy discussion of issues

Paul: prioritizing may help keep schedule because a contentious issue resolution could resolve other issue.

Rebecca, Jeff: haven't look at issues list, hard to prioritize

Jeff: how about just start doing the work

Jonathan: WSDL 2.0 issues on call are done by seeing traffic on the list

<scribe> Chair: question for each issue is high priority

Issue #6: high priority: 1

Issue #7: high priority: 0

Issue #7: high priority: 1

Issue #8: high priority: 8

Issue #9: high priority: 8

Issue #10: high priority: high priority: 6

Issue #10: high priority: 5

Issue #11: high priority: 3

Issue #11: high priority: 4

Issue #12: high priority: 3

Issue #13: high priority: 4

Issue #14: high priority: 0

Issue #15: high priority: 7

Issue #16: high priority: 5

Issue #17: high priority: 0

Issue #17: high priority: 1

Issue #18: high priority: 7

Issue #19: high priority: 1

Issue #20: high priority: 10

Issue #21: high priority: 9

Issue #21: high priority: 10

Issue #22: high priority: 3

Issue #22: high priority: 4

Issue #22: high priority: 5

Issue #23: high priority: 10

Issue #24: high priority: 6

Issue #25: high priority: 1

Issue #1: high priority: 8

Issue #4: high priority: 4

Issue 20,21, 23 are high priority

common theme is wsdl interactions

Issue 20

Gudge: every endpoint that I can send messages to must have a service element
... Q: for anish: every endpoint that I can send messages to must have a service element?

Anish: don't like question. phrases different question.

Marsh: WSDL is central to ws, or is off to the side.

Discussion about knowing protocol, portType, service

Gudge: Imagine redirect, using new address and porttype, no service element

Anish: quoth the raven..... web services arch definition of web service

Gudge: get a reference is a common distributed meme

Anish: have to have a service reference

MarkN: architecture greater than WS-Addressing?

Marsh: is this about accomodating versus enforcing an architecture?

paco: This is about 23

?

Paco: if we have a more refined address construct, should this replace wsdl address construct?

marsh: 2 solution spaces: EPR into WSDL endpoint structure, OR re-use WSDL address constructs

3 options: nothing, EPR->WSDL, WSDL->EPRs

daveo makes brilliant point about sometimes it is not useful to have an "abstract" class and then 2+ different subtypes, just have the subtypes especially given the weakness of our schema language for refining cardinalities.

rebecca sometimes URLs are not sufficient: multi protocol, message queues

urls don't have interface information

rebecca urls don't have interface information

rebecca: ws-a assumes a priori wsdl knowledge of service
... services may have extensible information, such as services etc. that can't be accessed from addressing
... have to use WSDL
... properties are good, callbacks/pub-sub

marsh: when given an address, can always get WSDL

daveo: clarification: rebecca wants endpoint to at least have interface so operations are known.

pauld: here's an endpoint, how do I find out how it's described.

anish: serviceQName required.
... make serviceQName required.

pauld: making requiring doesn't solve problem because they'll use "anonymous" qnames, or "any" content models
... should use metadata separately
... should use metadata separately, and then it won't be metacrap.

chair tries diligently to bring group back to whether issue 23 captures the meaning

pauld: this builds a dependency upon wsdl, and services outlive descriptions

marsh: what about versions of wsdl?

<pauld> worries about the one to many - there may be many ways of describing a single endpoint/service. putting a dependency between an EPR and a given version of WSDL is limiting

<pauld> daveo: suggests going to the whiteboard - doesn't understand the use-case

<pauld> anish and paco discuss discovery of WSDL from endpoints

<pauld> daveo: service has a WSDL, client emits a request based upon a WSDL

<pauld> rebecca: no, you start with a URL

<pauld> ... refernence may have come from somewhere else

<pauld> jeff: programmer finds URL on side of the bathroom wall

<pauld> rebecca: need to know a lot more than just the URL for interface, security, etc

<pauld> gudge: all i have is a URI?

<pauld> jonathan: this is only one of a number of use-cases: could start with WSDL first

<pauld> daveo: you want every web service to provide such a 'discovery' mechanism

<pauld> daveo: discovery of meta-data should be optional

<pauld> daveo: discovery is out of scope!

<pauld> jeff: interoperability is the issue here

<pauld> jonathan: i have a URI, i know it's a web service. what can i do?

<pauld> ... not much! with just a URI there isn't enough information

<pauld> rebecca: that's why just a URI is such a problem

<pauld> gudge: you need a description. i don't understand why a reference needs to carry this information

<pauld> rebecca: what about if you're not using soap

<pauld> markn: (1) you start with a URI

<pauld> ... (2) or you start with an EPR with addr, protType, svcRef embedded

<pauld> jonathan: should we allow multiple portTypes in an EPR?

<pauld> rebecca: but we also have multiple bindings, etc

<pauld> jonathan: other reasons not to include this information, bandwidth, etc

<pauld> ... you agree that in some cases you don't need such information?

<pauld> anish: no, should we allow you to just pass partial information?

<pauld> JT: so we should make it mandatory .. sometimes!

<pauld> jeff: if you want to provide an interoperable solution .. should you be required to include or at least be able to get that information

<pauld> ... as a service provider, you probably have all that information - engineering trade-off, so provide a mandatory way to get that information. which is how other distrib systems have solved this

<pauld> ... so it's either the info is readily available or requires another round trip

daveo: I agree that there is often a need for a metadata discovery service.

<pauld> gudge: to me this is not about enforcing a particular architecture, but about enabling other architectures. i'm unconvinced that it is a requirement that the description should travel with the address

<pauld> markn: (hat off) a URI doesn't exist in a vacuum. an EPR has context, and maybe data could be different depending on where it's going to be used

<pauld> rebecca: is including a portType is too much information?

<pauld> gudge: an address may not be dereferencable

<pauld> paco: address is a runtime construct, service description is not. i think you're making meta-data required at runtime

<pauld> gudge: you may elect to build a system without a description

paul: argument is about whether description exists or not

<Gudge> I *think* anish is saying that 'in order to be a web service, you MUST have a service QName'

paul: version 2 of wsdl comes out, then identifers would change

<scribe> New Issue: multiple description formats

<pauld> paul: i think discrovery is orthognal to addressing: i may have multiple descriptions some of which may be WSDL 1.1, 2.0, RDF, whatever and i'd like my customers to be able to negotiate the description format that suits them (not me as provider of a service)

<pauld> daveo: cites the way the web works - you don't know much from http://.. does it support HTTP 1.1, PUT, GET, no spec says "GET" is a default method, but it just works. addressing system just "works" by having discovery, negotioation as optional features

<pauld> anish: this is slightly different. HTTP has a constrained interface, but Web services are more open.

<pauld> rebecca: dave you described informal standard behavious. i think for interoperable

<pauld> .. you need to be more rigerous

<pauld> paul: is the web not interoperable?

<pauld> daveo: why should i have to give you meta data you may already have?

<pauld> rebecca: extensions may change the way a service works (e.g. https)

<pauld> rebecca: you could cache meta-data

Rebecca: EPR is more than just an identifier

DaveO: There is a difference between an identifier for a service, and a description of service.
... I don't want to mandatorily couple the description to the identifier

pauld: Where will the world be if the interface description was coupled.

JT: imagine cell phone world with this.
... cell phone requests something and needs to create callback, must he include the callback interfaces in the address
... cell phone wants minimal approach
... wants minimal address

jonathan: If I just have port type and service QName, that doesn't require WSDL to be publicly available, does that also require WSDL:Location in? Falls into discovery bucket

Paco: measured approach, can layer on things later

Rebecca: wants this to work in all cases

Paco: will force people to use other technologies if WS-A is too heavy. WS-* is regularly mentioned as being too heavy, so keep it light.

<Zakim> pauld, you wanted to provide a use-case for when WSDL is not discoverable

greg: layered approach. What about policy? it's going to be removed.. What'll it be? Layers or monolithic

<Zakim> dorchard, you wanted to say if WSDL is in client, then why is Service QName is requred?

DaveO: I assert that if the client doesn't have the WSDL, the ServiceQName is insufficient, and if the client does have the wsdl, then the Service QName is unnecessary

Anish: if client has WSDL + EPR.....

<scribe> ACTION: Anish to answer why Service QName is required if client has WSDL + EPR + engaged in conversation.

Chair suggests 4 options: 1 require metadata in all EPRs; 2) require MD on a use-by-use basis,; 3) no MD constraints; 4) MD + Address optional. 3 is the current state

Chair suggests 4 options: 1 require metadata in all EPRs; 2) require MD on a use-by-use basis,; 3) no MD constraints, address required; 4) MD + Address optional; 5) Address optional, MD required. 3 is the current state