WS Architecture Call
11 Sep 2003

See also: IRC log

Attendees

Contents

• Topics
  1. Review of Action items
  2. SOA Thread
  3. Terminology question from 21 August telcon: requester/provider, client/service, etc.
  4. Handle diversity with standards or binding frameworks? (from
• Summary of Action Items

<dbooth> ACTION: MikeC to ask Geoff if he took additional minutes off line on 4-Sep-2003 conf call
... Agenda: http://lists.w3.org/Archives/Member/w3c-ws-arch/2003Sep/0016.html

Review of Action items

<dbooth> Action items: http://www.w3.org/2002/ws/arch/3/09/ActionItems.htm

Scribe: Katia has looked at WS-Policy, etc. needs to be looked at more.
... Glossary updated with sync/asyn language

Katia: Presentation about semantics at the F2F?

Mike: What is the appropriate formalism for doing the architecture (UML/OWL/RDF?)
... What is needed to declare victory

DaveO: I have no problem with sets of proprietary documents being listed in the WSA

Martin: the purpose of the WSA is to provide a framework
... Cannot predict evolution of proprietary documents

DaveO: So what?

scribe: Is DaveO volunteering to produce this list?

Mike: what recommendations should WSA make to the W3C?

dougb: Am hesitant in turning the WSA into a FAQ

DaveO: suggests a straw poll to see if group wants to construct such a list

Scribe: ACTION: Mike, DaveB, DaveH to draft a straw poll

<dbooth> ACTION: MikeC, DBooth, Hugo to draft a straw poll asking whether people want a list of proprietary specs in our WSA document

DaveB: Which specs should be listed

DaveO: This could indeed be contentious, e.g., Message reliability

Martin: Compare and contrast - takes a lot of time.

Mike: is this required for victory?

Roger: if everyone contributes their lists, then this may be easier

MikeM: The purpose is to identify missing functionality

Mike: editing: consistency in document, e.g. glossary and concepts, e.g. usage scenarios

<dbooth> Frank: Can we discuss the uniform interface topic at the F2F? There are some constraints that we haven't addressed.
... ... Such as: What are the appropriate abstractions for interop between WSs?
... .... Will the way we're doing it lead to large scale interop?
... Frank: For example, if you have two Web services, what would it take to make one service out of the two?

ugo: no clear way of combining document standards
... just being able to send a document doesn't mean you can understand it

<dbooth> Frank: YOu can't solve all the semantic problems at once. But you can peel off a couple of layers of the onion that will give a lot of leverage.
... ... Without that, we'll end up with CORBA for the Internet. That's the risk. We still won't have global WSs.
... MikeC: Suggest discussing by email.
... ACTION: Frank to start email discussion on what constraints are needed for truly global WSs

Scribe: ACTION: to propose some better layering on message semantics to promote interoperabilty at a global level

<dbooth> Roger: We also need to do something about the usage scenarios.

martin: Usage scenarios is a means to an end, not nec. part of the final victory parade

Roger: useage scenarios is an identified part of the output
... not organized properly

DavidB: agrees somewhat with martin

DavidO: Should not be required for victory
... Should be pragmatic about available time, resources

Scribe: ACTION: put review of Usage Scenarios doc be Chairs to put on the F2F agenda

Hao: what about reliability

Mike: remind people to respond to message reliability

Hao: text about relationship with REST
... What to do about REST

SOA Thread

Mike: has tried to pull SOA messages together

Scribe: a response to Mike's message

MikeM: I like mike's version, lets move on

Hao: SOA is higher-level than the Web architecture itself
... extensibility is fundamental

DavidO: the myth of loose coupling

DaveO: not on the same page about architecture, esp. relative to constraints

<rcutler> Myth of Loose Coupling: http://lists.w3.org/Archives/Public/www-ws-arch/2003Jan/0115.html

DaveO: what are the fundamental constraints of the WSA

Scribe: e.g. extensibility

<mchampion> frank: generally agrees with daveo, many WS "ilities" are emergent properties

Hao: good practice shades into constraints

DaveO: You apply constraints to yield properties

<dbooth> DaveO's message on the Myth of Loose Coupling: http://lists.w3.org/Archives/Public/www-ws-arch/2003Jan/0115.html

<mchampion> Daveo: for example, interoperability is a property that emerges from constraints and limiting choices, not a property itself

DaveO: how is extensibility different for WS c.f. the Web

Mike: Focus on getting words in the document

Terminology question from 21 August telcon: requester/provider, client/service, etc.

<Hao> I already proposed a definition of "loose coupling" in the glossary

Scribe: ACTION: to the editors: use service requestors and providers

Mike: its in the glossary

DavidB: Can I use the word the service?

Mike: we need to be consistent in our terms
... we use requestor as a synonym for consumer/client
... we use provider as a synonym for server

Scribe: Scribe thinks that a service provider provides a service to a service requestor

<dbooth> dbooth: So the editors should avoid the terms "client" and "consumer", perferring instead "requester". We should also avoid the term "server".

Scribe: ACTION MikeM should check that the Liberty Alliance's terminology is consistent with the WSA

<dbooth> ACTION: MikeM to check that the Liberty Alliance's terminology is consistent with the WSA

Scribe: oops

Handle diversity with standards or binding frameworks? (from

<dbooth> WS-CHOR WG)

Mike: in a world in which there are different, competitive specs, e.g. in message reliability, what should the WSA do
... Should we allow the overlap, or should we pick a winner?

Martin: there is an issue, how to specify the choices
... where is correlation covered?

Mike: Reliable messaging is required. There are multiple RM specs out there.

Martin: We need a binding framwork, let the market choose the winner

Mike: binding framework should be part of the WSA

Summary of Action Items