See also: IRC log
Present: Umit, Amy, JMarsh, DBooth
Regrets:
Chair: dbooth
Scribe: dbooth
Amy: Interesting things: Note that unicast/multicast seems to have significance. Party identity doesn't seem to mean much.
... Ihteresting varients for different fault gen.
<alewis> -- WSDL wg specifies these addional information items as part of the pattern
... -- how they are communicated between the client and the server is defined
... -- default cases (if any) are clarified for variations
Amy: One thing I think we should take back to the WG is that there is a need for more information in specifying patterns.
... Though we may disagree on what additional info is needed.
... We might bring back a menu of additional info to add to these patterns, with out ratings of their expressive power.
Umit: When you have a pattern in your hand, the contract is very explicit about what the contract is.
Scribe: RESOLVED: The pattern definitions need to specify more information.
dbooth: The additional info needed may vary depending on the pattern.
Umit: Agreed.
Amy: Probably true, but we should strive for generality.
dbooth: Definitely
... I've been thinking about our patterns and what they mean. I suggest we adopt something along the lines of the following:
Scribe: [[
... Each pattern specifies *minimal* behavior. The clients and services may have additional behaviors that are not specified by the pattern. Specifically, a client or service may send other messages (to each other or other parties) that are not described by the pattern. However, in such case, the parties must use other means to agree on the handling of such additional messages. For example, a message from service S to client A might actually be broadcast
... ]]
Amy: I largely agree, but I'm not sure that example is the best. Depending on the fault rule, there may be other implications.
... But in the case with no faults (p5, e.g.), I would agree. It doesn't matter if it's going to 1 or 100 or none at all. If no faults are permitted, the minimal contract is that "the service will send me something".
... The most parsimonious description doesn't care if it's multicast or not.
... I would describe your commentary as "parsimony".
... Because it implies that the pattern specifies minimal behavior for complete functionality.
dbooth: "Minimal agreed-upon behavior".
... Consider p2d: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm#p2d
Scribe: If the pattern uses "message triggers fault", then there may be another fault sent back from B to S.
... So if S actually sends a broadcast message to B and others, then it could receive multiple faults returned from B and the others.
<alewis> Interesting. There's an interaction between message-triggers-fault and unicast/multicast. I wonder how many other synergies we've got?
Scribe: Therefore, S may get additional faults back, but since S was the one who chose to send the message to addition B clients, it will know how to handle them. The key point is that it doesn't impact any other parties.
... Therefore, S can publish this pattern in its WSD, but actually use it for multicast without problem.
Amy: Consider p8d: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm#p8d
... Is it significant to the clients that other clients may be participating also?
... For any given client Ai, does it care that there are other clients involved?
Umit: In p6b http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm#p6b there is one client, in p8d there are many.
Amy: P6b and p8d are different. P8d may have zero recipients.
... When you have the "*" quantifier, you cannot force parties to respond.
... It affects how you write your code. You might write blocking code if you expect a response, whereas if you may have zero responses then you'll need to code a callback mechanism to receive messages.
Umit: Yes, in request/response you expect a response. It's an error if you don't get one.
Amy: It's very predictable behavior.
dbooth: Yes, but note that when service S decides to go beyond the contract indicated by p6b and send the output message to additional clients, it is making that decision itself, and it is the only party that will be affected by that decision. Therefore it could advertise p6b in the WSD, but privately decide to do broadcast, without affecting anyone but itself.
Amy: I did a sample email binding. ONe of the common things that happens is that you go to a Web site, and you're emailed a response.
... I'm not sure we can model that multi-protocol behavior in WSDL.
... Because you can't have input on one binding and output on the another.
... Will that make Gudge's "Interesting Pattern" invalid?
Umit: Or maybe it needs to be specified using choreography.
Amy: If we have the fundamental restriction in WSDL that we can't do that, ___.
dbooth: So should bindings be specifiable on individual messages, rather than just on operations as a whole?
Amy: Perhaps we should say "here are the things we've thought of, and here's how expressive they are".
... I.e., what potential additional info might be needed to be added to the pattern definitions.
dbooth: I think we should start listing the additional things that the pattern spec should say.
... For example, the "minimal behavior" rule described above.
Amy: If you're generating code for the service, then some of the things we said today may be needed by the service, so it may be needed in the WSD.
dbooth: I think the WSD should only contain info by multiple parties.
... We also need to make concrete statements about the p2 family.
Amy: Also need to ask how much of the contract should be specified in the interface and how much in the binding.
Umit: The problem is that we don't have an abstract binding notion.
... We had the concept of the recipient's address, and they had to exist, but different bindings might realize them in different ways.
Amy: A pattern specifies addressing properties on the basis of the messages in it.
... A binding that supports that pattern must specifies how those address properties are bound.
... For request-response over HTTP, it's easy.
... But on email, there must be a place for the response address in the request.
... We can present the need for additional info in patterns.
Scribe: [Meeting adjourned]