Re: [ws-rx] Minimalist GetMessage proposal: the anon use case

[Doug Davis <dug@us.ibm.com>]

Paul, 
Finally got time to look through the
latest proposal, some misc questions that came to mind while reading it:

• How does the server identify which client issued the GetMessage?  Since sequences can span multiple endpoints it can not send any message in the sequence in response to the GetMesage - it must only send it to the proper client.
• How does the gateway scenario work w.r.t. the RM logic needing to create new sequences?  e.g. 2 backend machines, one sends soap 1.1 msgs, one sends soap 1.2 messages, both to the same endpoint - how does the destination/client know to Offer 2 sequences (or even more) instead of just one?  
• How does the client know to even initiate a sequence at all since RM may be optional on the outgoing messages (and up to the server)?
• If the server chooses to close a sequence does the client assume everything is done or should it create a new seq automatically?
• Same for terminate.
• Similar but slightly different, for one-req/multi-response, if the client gets a terminate for the offered sequence should the client assume its done since it got back at least one response or must it always open a new seq in case there are more responses waiting?
• How much of the MEP being used does the client RM code need to understand? Seems like a lot.
• If it doesn't need to know the MEP then how does it know when to Offer a sequence - a msg with a replyTo is not an accurate indicator that a response will flow - nor is the MEP itself actually, since a Fault may flow back even for one-ways.
• In general, how does an RM gateway (on the cleint) know when to Offer a seq? What is the algorithm it needs to follow?  Always?  Only when replyTo is anon?  What about no replyTo? It will default to anon in those cases, so does that then mean we're back to 'always'?  What about non-anon replyTo but anon faultTo?  Does it require examination of the WSDL/Policy?  Thought there was a requirement for RM to work w/o WSDL/Policy?
• When security is turned on there will be new sequences created for each security context - in the case of Gateways, how does the client RM know not only when to send an Offer but under what security context?  This gets even harder in cases like notifications where a general notification catcher may actually be collecting notifcations that use a variety of security contexts.  Would the client need to always create new sequences for all possible security contexts even though only a few may be in use at any one time?
• For notifications - how does it work?  And in the gateway case - how does the target machine know how many sequences are needed?  May be a dup of the security+rm+gateway question above - not sure.
• How do the wsa headers (replyTo) get dealt with on the response to the GetMessage?  If replyTo isn't anon then where does the response go?  Which ref-p's are in the response - the ones from the GetMessage replyTo or the original set?
• Are the extensibility elements AND'd together?
• What are the semantics of what gets returned from the GetMessage?  Any unacked message or only unacked messages that hit their resend timeout?  I know what our thinking is for this in our proposal but is yours the same?
• Should we assume that piggy-backing of acks will not work and they must be sent in new messages?  I think you obviously can't piggy-back acks on message that are not sent with RM - in your proposal you have no way of knowing whether a non-RM enabled message is going to the right place or not.  So, for RM enabled messages can they be added?  And if so to which messages? Since there is no relation between the client->server seq and the GetMessage's Offered (server->client) sequence, when a GetMessage comes in the server has no way of knowing if that client is the same RMS of the client->server seq.
• Client send a CS/anon-acksTo to the server, seqID1 is returned.  Client sends a request message.  Let's say a 202 comes back.  Client sends an Offer to the server since it knows it wants reliable responses and the Offered seq is seqID2.  Client then sends a GetMessage/seqID2 and gets back the response.
  • How did the server know that the response was 'the response' targeted to this client?  There's no relationship between seqID2 and seqID.
  • And even if there was a relationship since you can have multiple endpoints per seq - you need to know the endpoint not the sequence.
  • How does the server know when it can send back an Ack for seqID1 in response to a GetMessage?  Again, no correlation between the two sequences.
  • If the answer is that the client should have Offered a seq when it set up seqID1, then what about follow-on sequences that the server may have needed and the client (magically) knew to offer sequences for?
  • I think the whole area of relationship between the Offered sequence and any other sequence is a bit undefined.  I get the feeling that there's an assumption that the server 'just knows' who the client is or what it is looking for and I don't believe that is true.  Or, if this proposal mandates that to be true then I think it needs to be stated what the restrictions are.  For example, does this require only one endpoint per sequence? Both directions or just one? Things like that need to be explored, understood and added to the proposal.
  • How does a RMS-server know when an anon Offer comes in what it can use it for?  For example, a server may be handling many anon clients at the same time, so when an Offer comes in how does it know what it can be used for (which client is it)?
  • If we use msgID to correlate then that implies only one message per seq (since you can't make any assumption about any other message in the seq - just the one with that msgID) and the RMS-client needs to send an Offer for each and every request message. No InOrder processing on the responses at that point.
  
  More later, just some initial questions...
  -Doug