WSA Telcon
17 Apr 2003

See also: IRC log

Attendees

Contents

• Agenda Items
• Summary of Action Items

<scribe_sg> ACTION: Chris to summarize WS-Policy spec for the list
... Protocol independence:
... Action : Eric, Geoff to propose text about protocol independance
... Face-to-face: Do we need a bridge? only 1 line so far.
... Contact David/Hugo if you plan to dial in to F2F.
... MTF update: -
... Properties & features TF: -
... Security TF: Abbie created some text for document.
... Chris: Synchronous VS Asynchronous update: some agreement on use of MEPs to express sync. vs. async. information towards the correlation of messages.
... ACTION: Geoff, Chris to report back to the group once agreement is reached on sync vs. async next week
... Stack diagrams: tabled till Eric joins
... Mike: We are in reasonable "striking distance" from achieving consensus
... Dave: If we don't have consensus soon, use a process to get to the end of it.
... DaveH: If we don't strike, may need to define constaints to define the issue better

<DaveH> constraints and scope examples

<scribe_sg> Mike: Define a generic definition, then define one for WSA. We may require XML, SOAP, while many WS exist today without using these. Same with WSDL. Is this a good approach?
... Chris: Within the W3C framework, it's important to ensure SOAP, WSDL and choreography specs are in line with this definition.
... Mike: Keep a more rigorous definition as the one that the W3C operates under just to get behind this issue
... DaveH: Like two pronged approach to address various audiences. Narrow definition can be qualified to fully deploy the WS Arch.
... DaveH: XML & URIs are sufficient for basic definition; SOAP for envelopes, etc.

<DaveO> Fact #1: the term "Web service" appears to be very broad

<mchampion> acl daveo

<scribe_sg> Mario: Too broad definition says anything on the web is a web service. We should use a light-stack at least
... DaveO: Web service is a very generic term.

<DaveO> Fact #2: We want a more restrictive definition.

<dbooth> "WSDL-SOAP Web Service"

<scribe_sg> DaveO: We can say that a WS that is SOAP & WSDL compliant is W3C Compliant. Or extensibility based on SOAP and WSDL are used.
... DaveO: Come up with something very marketing centric VS. a more technology oriented version.

<mario> Right! I don't anyone waits for us to tell them what a Web Service is since they all think they already know

<scribe_sg> DaveH: WS are defined by a large community. No point alienating any group. Prefers calling them "eXtensible Web Service XWS".
... Chris: Disagrees. Don't want to characterize anything that anyone has ever done over the web as a WS
... Daniel: The architecture is to define a more refined version of what is already being used e.g. XML over HTTP.

<Mark_J> +q

<scribe_sg> Chris: Don't want the name changed from Web services
... Mike: No intention to change the name. Just add more constraints and that will have to have a name that is augmented from "Web services".
... MarkJ: Give a reasonable name to the broader, fuzzier version and call "Web services" the more constrained version...
... DaveO: Do we like the approach that two terms can/should be defined? Or extending this out to N terms is possible too? Is it one or two names?
... DaveH: the name Web services should not bless anything and everything that people are doing out there.

<DaveO> Decision #1: 1 Name or 2 names.
... Decision #2a: if 1 Name, is "Web service" the broad definition or the narrow.

<mitrepauld> broadDefinition=WS-0, somewhatRefined=WS-1, constrained=WS-2|WS-3|WS-n (WS profiles)

<DaveO> Decision #2b: If 2 names, same question but we need a term for what WS is NOT.

<scribe_sg> DBooth: Don't bless the primordial soup out there as "Web services". For the services we are talking about, we can define in our document the constraints we impose on what WE call Web services.

<MChapman> +1 to dbooth

<scribe_sg> Hugo: agrees with DBooth. Not sure if the name should be changed.
... Chris: Dismayed at the topic of discussion. SOA is not new to Web services. What we have today to realize the SOA vision is SOAP and WSDL.
... accommodating all types of envelopes and descriptions is a waste of time. Use whatever W3C has blessed.
... DaveH: We need to discuss this as we attempt to define WS in our document.
... DaveO: Agrees to work with more generic non-SOAP, non-WSDL means to implement Web services.
... DaveO: Define SOA in document. Define SOAP, WSDL based WS as WS. Got a lot of pushback on this approach.
... Mike: Poll the group for one or two terms preference
... One: Use the approach: For the purposes of this document, BLAH

<dbooth> Option 1: Use the term "Web services" _as defined in our document_.

<DaveH> option - don't define Web Service --- jsut define w3c-ws or x-ws or "new name"

<scribe_sg> Two: use 2
... Mike: Should we use the term Web services as it's used in the document currently? Grab term for our use Y/N
... <confusion about what the vote is>

<cferris> web service = SOA with SOAP as message format and WSDL as description
... or web service == anything done over the web to date using XML

<DaveH> argree with first as a good question, not the phrase after the or

<cferris> no, i was positioning this as what we are voting for

<DaveH> should we use "web service" to describe the thing that conforms to most/all of our architecture document

<DaveO> Let A=SOAP+WSDL; B=XML (may include A). Does WS=A, or WS=B? If WS=B, what is A? If WS=A, what is B? Vote: WS=A or WS=B.

<scribe_sg> Abbie: WS is an overloaded name. W3C compliant WS could be the restrictive version...

<DaveO> Chris Ferris position = A

<scribe_sg> Why don't we vote on Chris' options?
... chrisF: Choice A: web service = SOA with SOAP as message format and WSDL as description
... chrisF: Choice B: web service = anything done on the web using XML

<DaveH> Question 1 - should we define the new, restrictive thing?
... Q2 - should we define the current "soup"
... Q3 - what to call each of the above if we define them

<scribe_sg> UGO: The number of things used as wS is endless. Prefer to define one way of doing WS

<frankmccabe> We have two definitions (at least) to deal with in our document anyway.

<cferris> might I remind the group that this is the "Web Services Architecture WG" and that we are in the Web Services Activity in the W3C, that has 3 sibling WGs working on SOAP, WSDL and a choreography solution

<DaveH> DaveH position - we can not define "web service" that has already been done.

<frankmccabe> We are looking at three definitions: What the world thinks is WS, our global view of WS and a specific technology package

<cferris> WS-I has defined in its basic profile that a conformant Web service is SOAP, WSDL and optionally UDDI

<dbooth> Should we use the term "Web service" for the architecture that we define in our document?

<scribe_sg> Martin: Not sure of WSDL AND SOAP needed to be used together.

<mario> +1 to Martin. We should not force every SOAP user to describe it's services by WSDL.

<MChapman> i didnt say that exactly i just wanted the discission separted

<scribe_sg> Mike: Is david b's expression clear?

<mchampion> martin

<scribe_sg> Hao: SOAP is a feature and WSDL is another feature.

<DaveO> Martin and Mario take us down the rabbit hole. If a Web service MAY be SOAP/WSDL, then we don't actually have an architecture as there are no constraints.

<scribe_sg> Frank: 3 definitions possible: a loose one, one based on SLA and one based on technologies. Is the strawpoll for the middle level or the technology level?

<mario> I prefer to separate SOAP and WSDL usage. WS=SOAP(MUST)+WSDL(SHOULD)+whatever(Optional)

<cferris> I agree with DaveO's points here

<scribe_sg> DaveO: People prefer MAY use SOAP ; MAY use WSDL... so there are no arch. constraints. leaving them out leaves you with that broader definition...

<cferris> if we say should or may, then we have no constraints

<colleen> +1 to DaveO

<scribe_sg> DaveO: it should be MUST in order to apply architectural constraints...

<mitrepauld> have to drop off. bye.

<scribe_sg> DaveH: For strawpoll: can/should we redefine the term Web service?

<dougb> ? what's wrong with "for the purposes of this document?"...

<scribe_sg> ChrisF: Prefer to support two terms: SOA as generic and WS for SOAP/WSDL WS.

<DaveO> I think the vote is all about whether WS=MUST use SOAP/WSDL or MAY use SOAP/WSDL.

<cferris> i agree with daveo here

<dbooth> MikeC question: Should we redefine "Web service" for the purposes of our document?

<mario> Redefine WS does not imply MUST use SOAP and WSDL.

<scribe_sg> Mike: Strawpoll: Should we redefine the term Web services in our document to mean the specific sense of the WSA?
... +1 to daveO's vote

<DaveH> I think I could live with SOA as super-set and ws for things that meet our constraints
... I am suprized, It is not what I have said upto now

<igors> I agree with ChrisF: SOA generic, WS = SOAP/WSDL

<mario> I also agree, but I'm strongly oposed to a MUST use WSDL, MAY would be ok with me.

<scribe_sg> Mike: Do we want Web Service to mean MUST use SOAP & WSDL.

<Hao> NO

<DaveH> suggest: change Must to will have constraints regarding SOAP/WSDL

<scribe_sg> DBooth: Mixing 2 questions: what terms do we use and how we constrain the arch.

<MChapman> 1. ws = web protocols

<cferris> mario, I'd have to disagree with not using wsdl

<MChapman> 2. ws = web prto + xml

<scribe_sg> Dbooth: mixing terms is not good

<MChapman> 3. ws = soap

<DaveO> Web service: 1: Must SOAP/WSDL; 2: Must SOAP; 3: Must WSDL; 4: May SOAP or WSDL.

<MChapman> 4. ws= wsdl
... 5 ws = soap +wsdl

<mario> Chris, I'm not opposed of using WSDL. But I would not make it a MUST, SHOULD would be ok.

<scribe_sg> Chris: ebXML in marketing terms is not Web services. if you read SOAP 1.2, its an Infoset model, the protocol just requires that you are able to exchange the information. This requires that you use WSDL and this is a critical part of Web services

<frankmccabe> What appens about WS-CHOR when its available? ....

<scribe_sg> DaveO: That is in the context of our document.

<frankmccabe> What 'appens?

<scribe_sg> MarkJ: we may have a document with multiple architectural styles. we can't hang WS on a specific technology that is current today.
... DaveO: So MarkJ appears to favor 4

<cferris> mario, well, we can agree to disagree:)
... I don't think that should use wsdl is enough

<dbooth> Option 1: Must use SOAP + WSDL

<scribe_sg> Strawpoll: Web service: 1: Must SOAP/WSDL; 2: Must SOAP; 3: Must WSDL; 4: May SOAP or WSDL.

<DaveH> 4

<jeffm> 1

<Hao> 4

<cgi-irc> 4

<frankmccabe> 4

<Mark_J> 4

<hugo> 4

<DaveO> 1

<ugo> 1

<cferris> 1

<igors> 1

<mario> 2

<DaveO> lol

<colleen> 4 with mods ;-)

<Kreger> 3

<arkin> 4

<scribe_sg> 1

<MChapman> 1

<mmahan> 4

<mchampion> gerald votes 4

<hugo> Gerald is cgi-irc

<dougb> 1

<mchampion> sinisa votes 4
... markpotts votes 3

<DaveO> 1:7, 2:1; 3:2; 4:9
... 4(colon)9

<dbooth> Should we use the term "Web service" for the architecture that we define in our document?

<DaveO> yes

<mario> yes

<DaveH> no

<frankmccabe> yes

<cferris> yes

<hugo> Y

<mchampion> yes

<ugo> yes

<Hao> no

<cgi-irc> Gerald: yes

<MChapman> yes

<scribe_sg> y

<dougb> our document uses same term for multiple things, which are you talking about?

<jeffm> yes

<arkin> yes

<Hao> use Web Services

<dougb> yes for at least one of them

<mmahan> n

<mario> +1

<Kreger> ++++++
... +2!

<DaveO> I'd also like to find out the people who voted for 4, what they would call #1?

<DaveH> x-ws

<scribe_sg> Jeff: What are people voting 4 thinking?

<Kreger> interoperable web services?
... ws-i services?

<mchampion> x-ws works for me

<Kreger> :-)

<DaveH> xws - good - cool - great - new - best - better - sam

<scribe_sg> ;-)

<mmahan> x-ws or some better explicit label

<cgi-irc> Gerald: I would say that #1 is the basis for currnt web services, but future web services may not have the two parts.

<scribe_sg> frank: want to go from all kinds of constraint levels.

<DaveH> sws - not bad

<Mark_J> the doc can say we are defining a "web service arch" but informally use "web service" for the architectural style that uses teh SOAP+WSDL constraint

<mario> MS always talks about "XML Web Services" perhaps it's already trademarked or patented ;)

<cgi-irc> I agree withn mark_j

<DaveH> eXtensible WS

<mmahan> extreme WS

<DaveH> +1 mike m

<scribe_sg> frank: An abstract WS in which SOAP and WSDL would become concrete instantiations

<arkin> should be: defining "a web service arch"

<Hao> call it SOAP/WSDL Web Services

<scribe_sg> Jeff: we may have a problem interpreting MAY

<DaveH> we are over

<mario> for a definition what MAY means check IETF's RFC 2119

<scribe_sg> chrisf: reiterating that when i say SOAP I mean SOAP 1.2 in the infoset sense... read the spec carefully and it means that the only important thing is the exchange of infosets
... +1 Chrisf as well.

<MChapman> +1 to Chrisf

<scribe_sg> <meeting is now closed as we are over 2PM.>

Summary of Action Items