SV_MEETING_TITLE
25 Sep 2003

See also: IRC log

Attendees

Contents

• Topics
  1. Discovery
  2. Intermediaries
• Summary of Action Items

<dbooth> ACTION: Hugo to bug MikeC about minutes from the last F2F and extract editor actions from them
... ACTION: EricN to send dbooth comments on Sec 1
... Frank: Intro needs more consisistency.
... dbooth: THere's also inconsistency in the use of the term "semantics".
... ACTION: dbooth to look into adding mention of "syntax and semantics are relative: one person's syntax is another's semantics"
... dbooth: We need a mechanism for editors to record how we are using terms, to be consistent.
... ACTION: dbooth to start a list of editors' term usage and check it into CVS

<hugo> Source of to-do's:
... http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa-todo.html

<dbooth> Mike's WG to do list: http://www.w3.org/2002/ws/arch/3/07/items.htm
... Editor's to do list (made by Hugo): http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa-todo.html
... Plus, we are missing the ones from the last F2F.

<MChapman> http://www.ooblick.com/text/tomordor/

Discovery

<hugo> Reviewing http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch-review2.html#discovery
... Issue raised: discovery is optional in our document, but management assumes that discovery is always happening

Scribe: Starting a discussion on discovery
... Messing around with projectors

<dbooth> Starting with http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch-review2.html#discovery

<mikeM> note - it is practically impossible to follow the voice conversation from the dialin network
... perhaps we are sol for not making the trip

Martin: Is discovery the same thing as locating binding info?

fgm: What are the minimal requirements for a service description?

Martin: Always have discovery

<MChapman> i think the required/not required is of the discovery itself
... i mean of a discovery service

Scribe: DavidB walks through discovery
... diagram

fgm: Why do we separate WSD from semantics?

Martin: semantics should be associated with the WSDL, not really the service

Scribe: discovery

MikeC: originally semantics was somewhat backchannel, human.

Scribe: Consensus: semantics and web service description are associated with each other

ugo: semantics is normally backchannel
... is no semantics in repository, cant search for it

<MChapman> the back channel can be used for semantica and/or wsdl
... the dicovery search can be used for locating semantica and/or wsdl
... any combinations of back channel and search engine are valid
... not all may be possible e.g. if semnatics are not written down they cannot be in a repository

<dougb> wondering if the issue here is dividing description into 2 components rather than 4, 10 or one? does the number of divisions change the act of discovery? architecturally, most important things may be ability to divide the components (for reuse) and ability to retrieve everything about a particular service (linking)

<MChapman> +1
... to dougb

davidb: Fig 1 is all inclusive, the rest are variations

martinc: what are we discovering: metadata or the service itself?

<MChapman> need to differeniate discovering the wsdl/semantics from selecting which one(s) to invoke

Katia: multiple steps to discovery: finding what services do what I want then figure out how to use the service

<dougb> {just to balance the morning} +1 to Martin, criteria-based selection and discovery are related but not identical; general issue with this section is some distinctions are made that apply only some of the time while other (important) distinctions are not made

Scribe: in danger of infinite regress

<dbooth> http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch-review2.html#id2617281

<mikeM> thanks david

Scribe: Just because you didn't see the discovery process doesn't mean that it didn't happen
... if discovery is 'optional' then so is WSDL itself
... the process of discovery can be seen as an elaboration of step 1 in figure 1

MikeC: 1. Distinguish search from selection
... 2. Discovery and selection happen

Martin: 1. Criteria, 2. find instances, 3. select instance 4. invoke

DaveH: Advertising is step 0

Martin: what is done, not how it is done.

<mchampion> DavidB: The parties may define the semantics and interface jointly, or the requester may impose them on the provider

DavidB: important use cases include cases where requester drives process

<mikeM> Please indicate when the 'intermediaries' discussion begins ... following discovery is futile

Scribe: back in session
... in figure 1, need step 0, for parties to meet each other

<mchampion> Let's say 11:35 Pacific.

Scribe: still discovering

Zulah: need to elaborate the discovery concepts and relationships to include discovery and selection

Scribe: ACTION: DavidB to revise discovery text and have a review at a later telcon
... ACTION: for davidb, martin, zulah and katia to work on getting a consensus on the discovery process

deadline: Oct'9

<hugo> ACTION 2 = davidb, martin, zulah and katia to work on getting a consensus on the discovery process (deadline: Oct'9)

Zulah: may need to rediscover services

DaveH: early and late binding should be captured (in section 3?)

Scribe: Late binding = semantics after getting WSDL, early binding = semantics before getting WSDL

DaveH: policy needs to be added to discovery/resource model

Zulah: need to attach policy to things

<dougb> rediscovery is just one of the reasons proposed steps may need to repeat or recurse (refinement, elaboration of data you have about a service, ...)

Scribe: topic is now intermediaries

<dbooth> http://lists.w3.org/Archives/Public/www-ws-arch/2003Sep/0078.html

Intermediaries

<hugo> Definition of intermediary in the glossary: http://www.w3.org/TR/2003/WD-ws-gloss-20030808/#intermediary

Scribe: ACTION: use the term Web services intermediaries. Ultimately SOAP, may be higher level. Needs to be captured in the document
... by the editors
... MikeC & MikeM

<hugo> ACTION 3 = MikeM/MikeC to use the term Web services intermediaries. Ultimately SOAP, may be higher level. Needs to be captured in the document

Scribe: ACTION: MikeC to move firewall example of intermediaries to the end of the text on intermedaries

<mikeM> early source: http://www.w3.org/2001/04/wsws-proceedings/mnot/wsws-nottingham.pdf

<hugo> SOAP intermediary definition (taken from SOAP 1.2): http://www.w3.org/TR/2003/WD-ws-gloss-20030808/#intermediary
... in the SOAP 1.2 specification: http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#senderreceiverconcepts

mikeM: An active intermediary is able to do more than touch the header

<dbooth> DaveH: We need to call it a SOAP intermediary, because we're restricting ourselves to SOAP. Or we could ensure that the capabilities that we describe are a superset.
... Hugo: "Ultimate receiver" is not in our document.
... Katia: If we're restricting our discussion of intermediaries to SOAP intermediaries, then we should use SOAP terms.
... MikeM: In SOAP 1.2, part 1, it says the potential set of services ... include security, annotation and content manipulation services.

Scribe: The message model should be modified:

<dbooth> DaveH: We should add the concept of a third party.

Scribe: Messages have recipients and receivers
... ACTION: editors to add third party to concepts and reliationships around intermediaries
... An intermediary may be owned by a third party

<MChapman> +1

hugo: We have an issue: SOAP messages are processed by roles, not addresses
... we need to clarify addressing

ugo: SOAP doesn't give explicit addressing
... routing not necessarily in headers

<hugo> Description of the issue: http://lists.w3.org/Archives/Public/www-ws-arch/2003Sep/0051.html

<DaveH> ur salmon???

<hugo> Hugo: how do you express intermediaries in WSDL? should you be able to?
... Answer: good question

Scribe: Hugo wants to be included in discussions on intermediaries and SOAP vs WSDL

<mikeM> yes hugo - we should inquiry with WSD how they <pun>address</pun> intermediaries and message paths
... whether this can be implemented as features...?
... quit

<Hao> hello

<hugo> Hao's message: http://lists.w3.org/Archives/Public/www-ws-arch/2003Sep/0076.html

Mikec: wrap up on intemediaries - we need to either identify arch gap between SOAP and WSDL or

MChampman: should bring this up to coordination group

Hugo: We should look into the problema nd if the chairs can take an action item to signal to the coordination group that this is an issue and we are going to work on it.
... coordination group may have worked this out

Scribe: ACTION: chairs to bring a clear statement of the architectural issues at the intersection of SOAP and WSDL to the attention of the Coordination group

Hao: Why is SOAP needed to define intermediaries
... There are intermediaries in the HTTP world - proxies - they are transparent. When people use SOAP why do we need intermediaries

MikeC: moving to reliable messaging

<Hao> 2.3.1.13 Reliable messaging
... 2.3.1.13.1 Definition
... Reliable messaging is a feature that may contribute to the overall
... reliability and efficiency of Web services. Reliable messaging requires
... participating software agents to act on a message after receiving it.
... Relationships to other elements
... reliable messaging is
... a feature
... reliable messaging may be realized by
... a combination of message acknowledgement and correlation.
... a good practise of reliable messaging is
... to make the life cycles of messages available to participating software
... agents.
... 2.3.1.13.3 Explanation
... Reliable messaging can improve the overall reliability and efficiency of Web
... services. Reliable messaging in Web services not only requires the delivery
... of messages but also the contact on the receiving agent to act on those
... messages as defined in service contracts.
... The goal of reliable messaging is to both reduce the error frequency for
... messaging and to provide sufficient information about the life cycle of
... messages. Such information enables a participating agent to make a
... compensating decision when errors or less than desired results occur. It is
... important to note that a guarantee of the delivery of message alone does
... not improve the overall reliability due to the "end-to-end
... argument."[1] It may, however, improve the performance of messaging.
... Requiring an agent to act on a message after receiving it would improve the
... overall reliability of Web services that only involve two software agents.
... High level correlation such "two-phase commit" is needed if more than two
... agents are involved.
... Reliable messaging may be realized with a combination of message receipt
... acknowledgement and correlation. In the event that a message has not been
... properly received and acted upon, the sender may attempt a resend, or some
... other compensating action at the application level. Note that in a
... distributed system, it theoretically
... not possible to guarantee correct notification of delivery; however, in
... practice, simple techniques can greatly increase the overall confiden
... http://lists.w3.org/Archives/Public/www-ws-arch/2003Aug/0106.html

MikeC: Do we have text that puts reliable messaging into the overall context of reliability

Hao: That text is needed, we don't have it yet.

Frank: What does reliability mean in each of the architectural models

Katia: Our discussion was about reliable messaging, not reliability

Martin: need a footnote that we are addressing reliable messaging not reliability - primarily we are interested in interoperability

Frank: when looking at choreographed services, one would ask if there is a reliable choreography
... boils down to live-locked and dead-locked situations

Martin: Version 2

MikeC: concensus is point is well taken, but reliable messaging is what we will cover in V1.

martin: what does it mean to make the lifecycle of a message available...

Hao: Need to know what has happened to a message (e.g., when process will be processes, whether there is a commitment to process it)

Martin: so the message has a state machine associated with it?

Hao: we proposed lifecycle in MTF
... lifecycle of a message is important in reliable messaging

Martin: who do you query to know the state of a message?

MikeC: definition of reliable messaging system you have a state machine...

martin: and your increasing the probability that you know what state you are in

MikeC: sound slike ebXML reliable messaging where ack is all wrapped up in business process level

Martin: transactions
... reliable messaging is about making sure message got from a to b, transactions are about the fact that they actually got processed.
... so you can layer transactions on top of the general reliability discussion at the service level

MikeC: ... its a bit of a digression where we put trnsactions

Scribe: ACTION: Eric to propose concepts, relationships, text for how to encorporate transactions into the WSA doc. Presumption is that it is reliability in the service model.

MikeC: let's work on a definition of reliable messaging

Hao: some people assume when you have reliable messaging you have reliability. We need to point out clearly that this is not the case

Hugo: So we should phrase it that this is a feature that adds to reliability.
... reliable messaging is a feature aimed at increasing reliability and efficiency
... the definition isn't rigorous enough

Abbie: reliable messaging defn is a funtion of what you are using. Thre is a guarantee for the delivery of a message

<Hao> how about: reliable messaging is a feature aimed at increasing reliability and efficiency of deliverying messages in Web services.

Abbie: the second part about requiring participation of software agents is to strong (e.g., may require message ack which may not be case)

MikeC: First line is a foot note.
... reliable messaging aims at increasing the probablility that a message is actually recieved.

Martin: increases the probability that both sides know the same state of the message

Frank: Reliable messaging is not about reliable messaging, its about knowing what happened to the message

Martin: its a distributed state thing

MikeC: Hao's is a common sense starting point. can we lead people into the reality that this insn't really about reliable messaging rather than beating them over the head with state

dbooth: like the logic and detail of the state stuff but this seems a method of achieving reliable messaging
... what you want to acheive is increased probablility

Martin: you only know what happened when both sides have the same state.

dbooth: this is a method of acheiving.

MikeC: seems to be an agreement on both sides knowing the delivery status.

<hugo> Proposed text:
... [[
... Reliable messaging is a feature which aims at increasing the
... probability of both the sender and recipient have the same
... understanding of the status of a message delivery.
... ]]

DaveH: is this message limiting because it assumes the transmission is complete. it rules out covering a message that is in-flight

Scribe: Katia, Hao: red herring

Abbie: doe this defn still work with intermediaries

DaveH: after discussion - declares intermediaries red herring

Frank: useful to rename recipient to reciever
... recipient is used in SOAP to mean someting differnet

Scribe: ACTION: editors, change recipient to reciever in order that we not confuse the SOAP definition.
... ACTION: editors - do the same about sender/originator

DaveH: can we accept the definition?

Scribe: We accept the 1 sentence of the definition

MikeC: like the state machine view better than lifecycle of a message view.

Zulah: didn't we already have the discussion about state/lifecycle and its in the definition

Martin: what does a good practise of reliable messaing mean...

Scribe: The sentence about good practise has been made mute by our action item around transactions

Martin: doesn't talk about message level things like exactly once, etc.

Scribe: We have moved on to the explaination

Martin: Last paragraph. message correlation... a reliable messaging layer canactually do duplication... this paragraph isn't accurate
... doesn't talk about sequencing, order delivery, duplicate delivery, you could do this at a message layer with message IDs

Hao: even if you do this at the messsaging level, you still have to do it again at the app level.

Martin: we should talk about just the reliable messaging part

DaveH: counted three topics that need to be covered around the messages (duplicate, order of delivery, sequencing)

Martin: there are varying levels of quality that one might want to attach to reliable messaging including duplication sequencing, etc.

MikeC: Suggestion is to replace last two paragraphs of explanation with martins comment above.

Abbie: how far are you going to take reliable messaging. If you are trying to talk about implementation it is too details. So a short paragraph will do here.

DaveH: suggests miving the explanaintion to the stakeholders section.

Hugo: can we agree on the definition?

Frank: definition is really knowing about the status of the message? Does that include things like sequencing, etc.

Martin: its about what probability or incertainty you are dealing with

DaveH: one position is that the definition covers this, the other is that it needs to be added in
... second is that the levels of quality need to be explicit in the definition

Frank: If we identify properties that are associated with reliable messaging (e.g., order, sequencing) is this also part of reliable messaging

abbie: reliable messaging is about whether I got a message or not.

DaveH: some in the industry include order and frequency as managed attributes of reliable messaging
... would like to get the word increasing out of the definition
... possibly controlling

katia: you want to increase the probability

Abbie: you can't control

DaveH: reliable messaging is the scale of service while QOS is choosing the point.
... if reliable messaging implies increase, what is the scale

Abbie: increasing the probability that a soap message arrives. Scale is reliability, it is up to you to define what reliability is

Frank: you are talking about message reliability

abbie: the delivery of the message

Scribe: discussion follows about whether "increases" where we are increasing reliability is okay in the defn vs. using some statement of QOS.

DaveH: Can it be a property of message transport.

Katia: property of the message delivery (transport)

Scribe: So there seems to be concensus to attach the property to message transport.

Frank: in the model, message transport is HTTP.

DaveH: wants to add a box to the message model - what ever the label, the definition isn't subjective (in terms of increase and decrease)

Frank: message reliability is a concept, the message transport controls message reliability, and then the delivery of the message isanother concept of message reliability

DaveH: propose that in stakeholder section reliability is goal of increaing probability. From the model point of view, lets define the property.
... Tentative agreement is that under themessage model we will add a note whose name has something to do with message reliable delivery and is the definition that we are now working on. So model gets a new node, this defn goes in the section./

Katia: we will delete the concept of reliale messageing and substitute the message reliability concept which is the degree to which message devliery can be guaranteed and the means to ensure sequence etc.

DaveH: New defintion: node if message reliability, and message reliability is the degree to which the sender and recipient have the same understanding of the status of the message

Scribe: So the big shift here is that we are no longer defining reliable messaging, rather we are defining message reliability

<hugo> Proposal #1:
... [[
... 2.3.1.13 Reliable messaging
... 2.3.1.13.1 Definition
... Reliable messaging is a feature which aims at increasing the
... probability of both the sender and recipient have the same
... understanding of the status of a message delivery.
... ]]
... Proposal #2:
... [[

DaveH: would like to start from the beginning. Let's start from the model diagram. And agree what goes into this part of the diagram.

<hugo> 2.3.1.13 Message reliability
... 2.3.1.13.1 Definition
... Message reliability is the degree of certainty to which both the
... sender and the recipient have the same understanding of the status of
... a message delivery.
... ]]

Doug: Why does the second proposal add value?

DaveH: as a member doesn't believe that we have sufficient shared framework to have this conversation.
... begin with where we are in the document before we decide what does and doesn't make sense.
... start with model and decide what works go on the model and then define words.
... There is now a proposal for concepts diagram

Doug: could simplify diagram by saying message transport guarantees various QOS...

Dbooth: would like to remove message certainty and order.

Doug: proposes that we identify QOS here. as opposed to delivery confidence
... whether we need the top two boxes is a different questions - there are certianly more propoties that we have now.

Abbie: QOS is alot more than reliability

Eric: message reliability was fine

Scribe: We have four candidate concepts: message delivery, message reliability, reliability, delivery confidence
... We have converged towards having the concepts: delivery status, message order, and delivery certainty.

Martin: if you can say that message transport is constrained by a set of policies...

dbooth: couldn't al of waht we talk about be constrained by a set of policies

Frank: what is reliability policy

DaveH: Need one box that is a concceptual lead in to reliable messaging
... should have top level visibility in the model

dbooth: agee that we have narrowed policy to mesaging, but there are just as well policies for other parts of WS that we don't call out.
... note sure that we need an additional box above what we already have in the model

Tom: difficult to understand the relevance and significance of each box in the content of the diagram

Scribe: We are having a discussion about what goes on the diagrams and what doesn't
... We have used the diagram as a vehicle to "unpack" the concepts around reliable messaging

DaveH: we are entertaining 3 options 1) no additions to the diagram, 2) the current diagram, 3) just one box

Abbie: one box is okay but this diagram is a bit more revieling

Tom: level of concreteness of concepts varies

<dbooth> Straw poll results: Approx 4 favor option 1, approx 8 favor option 3, approx 1 favor option 2.

DaveH: We now have a diagram where policy constrains transport

hugo: we've singled out policy WRT message transport, should we decorate everything else with policy

Martin: can we just call this delivery policy to avoid the decorating everything with policy issue

DaveH: straw poll who is in favor of this diagram? (the one with policy attached to the "delivered by" arrow

Scribe: Straw poll results: 8, 1, and the chair doesn't care about abstentions

Summary of Action Items