See also: IRC log
Present: Philippe, David, Umit, Jonathan
Regrets: Amy
Chair: dbooth
Scribe: Philippe
Scribe: Agenda: http://lists.w3.org/Archives/Public/public-ws-desc-meps/2003Jul/0002.html
<dbooth> http://lists.w3.org/Archives/Public/public-ws-desc-meps/2003Jul/0001.html
Scribe: (David summarizes his message)
<dbooth> p2: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm#p2
Umit: we're thinking of p2 which is expressed on behalf of the service
... so you cannot represent the client
... you cannot assume an interface for the client, unless you identify it, which is in that case a subcase
Jonathan: so p2 is too abstract?
Umit: yes. 4 types of nodes that we are describing: sender, service, receiverB, receiverC (receiver for the fault)
... if you don't have those roles identify in the pattern, you cannot determine the generated methods
... roles can be shared as well
... in p2b : sender and receiver are the same
David: for i_p2, nodes are still playing roles, but you need to identify them. some node is sending message 1, some node is receiving messsage 2
... my intent was to represent the needs for sender and receiver.
Umit: in some cases, sender and receiver cannot have the same identify
<dbooth> p2c: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm#p2c
David: in p2c?
Umit: p2c doesn't say anything about identify. it just says "somebody else", but that includes my as well.
... in p2c, i will never write the receiver callback
David: node A would not be using the receiver callback, that's correct.
... the interfaces represent the union of all methods needed by all client nodes in that pattern.
Umit: from the client of view, some patterns are useless.
<dbooth> p2d: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm#p2d
David: oops, i_p2d is missing a third parameter for the third party
Scribe: void sendMessage(ServiceAddress s, Message m);
... -> void sendMessage(ServiceAddress s, Message m, ResponseDestinationAddress rda);
David: would be the same for p2c
... actually 2 others, one for the fault and one for the regular reply
... i_p2b is missing identities of the recipients
... same thing could be true for i_p2a1, i_p2
Philippe: consider that a node needs to implement all methods of the interface, you'll need to divide some of your interfaces in severals, and indicate when a node can implement more than one interface
David: looking at i_p2d:
... note the difference between p2d and p2e
<dbooth> JMarsh: You could look at this list of interfaces in terms of sync versus asynch.
Jonathan: if pattern p2e, I can still write an interface that looks like i_p2d
... I don't want to force people to make interface in a particular way
David: agree
Jonathan: from the WSDL and client, I want to use i_p2e, but from my toolkit point of view, I may want to forward the response somewhere
David: you want to ensure that a conforming actual sequence of messages can have additional messages that are not indicated by the patterns? the pattern indicates minimal constraints?
Jonathan: yes
David: it goes down to what does it mean to be a conforming sequence of messages.
Umit: if it is not in the WSDL, you don't have to know about it.
... p2b looks like A sending a message, and the result is almost a broadcast to nodes, including A. it is relevant to know that
Jonathan: why is it relevant for A?
... whether you sent an email to me or the entire group doesn't change anything for you
... A doesn't have to know the identity of all A1, A2, ...
Joanthan: p2b is illustrative of the mailing list. if Umit sends a message, she is the one receiving the fault, others will get the broadcasted message.
David: from A1, A2, ... it's identical to p5a
Jonathan: and from the service prospective?
David: not sure. could be a silent broadcast, you can also need a list of addresses.
Jonathan: so your server is going to be loose, since it can be done in multiple ways.
Umit: whoever is the role, they will see different interfaces
Jonathan: so I also need to know the role that I play?
David: yep
Jonathan: is there anything in the WSDL that I can use to say what is appropriate for my role?
... all available roles?
David: the pattern says what roles are available. The application knows what role(s) it wishes to play.
Jonathan: looking at the WSDL, I know my role, is it sufficient for me to implement ?
David: yes
<dbooth> PLH: Even if you have a complex pattern, the MEP indicates which messages in the WSDL are needed for which roles.
Jonathan: now, do we need to know what generated the fault? we can assume it's embedded in the fault.
Umit: if I decide to write a client which is receiverC, for p2c, if there is no client for role A or B, it is not fully defined then
... without having A and B, it is not useful to have p2c
<dbooth> PLH: Yes, but to implement role C, you don't need to know A and B, they just have to exist.
David: if you want to implement request-response with p2d, what would you do?
Jonathan: you can always say that A and B are the same, or indicate it with some other ways
<dbooth> [Meeting adjourned]