Present: DBooth, Amy, Umit
Regrets:
Chair: DBooth
Scribe: DBooth
Scribe: [No IRC log. We forgot to invite RRSAgent.]
p5: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm#p5
Amy: The alternatives for p5 are: unicast versus multicast, and faults or no faults.
dbooth: Should we address p6, since it's important to you?
Amy: p5 first, because it will be easier for people to understand.
Umit: Agree.
Umit: I want to understand how JMarsh proposes to use p2c for classic request-response.
... In CORBA there's a request-response pattern in IDL. When you generate the client code, it can choose 4 ways to interact: sync, async, polling, etc.
... So there's an implied IDL for each of these cases.
... But it is still request-response.
... The client uses this additional information to define its specific interaction.
... If you only have the IDL for the service, is it enough?
... So which pattern do we have, p2c or p2e?
dbooth: I think JMarsh is observing that from the service point of view, both p2e and p2c could be treated as p2c.
Umit: If a WSD specifies p2c, how can one client use it as though it is p2e, and other as though it is p2c?
dbooth: A client could make use of a service that advertises p2c to send the response back to itself or to someone else.
Umit: Who will supply the additional info if the client wants to use p2e, but the WSD says p2c?
... The client could pass an endPoint reference.
... Maybe in the header.
dbooth: If the client wants the response back to itself, and the chosen binding style is naturally bi-directional, then the client would only have to indicate the fact that it wants the response back, and would not have to specify an endPoint.
... I think JMarsh suggested that one possibility would be to have the default be to send the response back to the requester (if no endPoint is specified).
Umit: That's dangerous. Better to be explicit.
... I want to generate the client code depending on how I want to use the pattern.
dbooth: There are a couple of cases: (a) when the binding style is naturally bi-directional; versus (b) when it isn't.
Umit: For bi-directional, you can always ignore response and treat it as uni-directional.
Amy: This is an interop problem in WSDL 1.1. Some close the connection without waiting for a response.
dbooth: If the binding style is NOT naturally bi-directional, then the client would ALWAYS have to say where to sent the response.
Amy: Absolutely true.
dbooth: If the binding style IS bi-directional, AND the response should go to the requester, then the client does NOT have to indicate where to send it.
Amy: We could say that the response address always has to be specified, but it is specified by default in bi-directional comm.
... We could also introduce the notion of time. If a response comes back after the client's timeout, is it still request-response?
... Also affects the server. If you have a request-response that is slow, the server can't use that currently open socket. It has to use something else.
dbooth: I think it is not request-response if the response exceeds the client's timeout. Every pattern of more than one message could have this problem, so I don't think we should try to go there.