See also: IRC log
Present: Umit, Amy, DBooth
Regrets:
Chair: dbooth
Scribe: dbooth
Umit: Had internal discussion and concluded that p2c is more general than p2e.
... But to use p2c, one would have to define who the recipient is.
... Needs to be defined in WSDL for people to make use of it.
... So that client users know how to send the recipient address.
... Also agreed that patterns where faults go to completely different parties are useless.
... So faults can be treated similar to a response.
... Wherever the response is supposed to go, that's where the fault should go.
Amy: Not necessarily.
Umit: Who are we targeting? App or binding?
... There might be different MEP at the binding level than at the binding level.
Amy: Our stuff isn't intended to represent transport level faults, but we should be able to represent any configuration of app level faults.
Umit: I agree. In a one-way message, there's nothing in WSDL saying that a fault will be generated.
Amy: The majority of patterns use a single fault generation model, but that doesn't mean that other models are invalid.
... I'll create a new MEP that looks like one-way, but has "message triggers fault".
Umit: Do you think MEPs are targetted at the app level or infrastructure level?
Amy: App level. You should be able to look at an operation and say "I know how to implement the code for this".
Scribe: [Amy departs]
Umit: If one-way did not expose a fault pattern, and implement it with HTTP where you'll always get a response which may be discarded.
... But if the MEP is one-way, that's what the client sees.
... We think the WSDL is exposing the app level MEP.
dbooth: The MEP specifies expectations/requirements that must be met.
... The MEP provides minimal assumptions that the client can make about what is know about the interaction.
... Without looking at the binding details, the client and service can assume AT LEAST that much about the interaction.
... The binding will provide more information.
Scribe: It makes sense for the client to separate the code into the part that is abstract (corresponds to the wsdl:interface part of the WSD), and the binding specific part.
... [Long discussion about whether the client specifies the recipient address in p2c]
dbooth: Suppose we break p2c into two patterns: p2c1 and p2c2.
p2c1: The Client IS responsible for specifying the recipient address, and the client must agree with the Service about the mechanism by which it will be communicated.
p2c2: The Client is NOT responsible for specifying the recipient address. It's up to the service to decide on the recipient of the response.
Scribe: p2c1 could be used by the client to accomplish classic request-response if there is a standard way to specify the recipient address.
... However, p2c2 could not.
... Therefore, p2c (which allows either p2c1 or p2c2) could not be used by the client to accomplish classic request-response without making additional assumptions about the service that the service has not expressed in the wsdl:interface of the WSD.
... If p2c1 is used, and there isn't a standard way for the client to specify the recipient address, then the client would not be able to know from the wsdl:interface of the WSD that it would use the same mechanism for sending the recipient address as the service is expecting.
... I.e., the client and service need to agree on the contract for how the recipient address will be transmitted.
... Suppose it's up to the binding to specify how the recipient address will be transmitted.
... As long as they agree on the binding, then that would work also.
<umit> it would not work as the concept, the information item for the receipents address
... needs to be not binding specific.
Scribe: So the client's abstract code needs to know the syntax (or datatype) of the recipient address that it needs to send, and it will be taken as a parameter to the binding code, which will know the details about how it will be transmitted.
Umit: There would have to be standard binding ways to transmit the recipient address, or else we would have an interop problem.
dbooth: Definitely.
Scribe: [Meeting adjourned]