ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ws-rx] Minimalist GetMessage proposal: the anon use case
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Sun, 7 May 2006 20:56:40 -0400
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]