OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: PR001 - Feedback on MSFT's MC proposal



Per my todo, here's feedback on the MSFT proposal for PR001 which
also has the various use-cases interspersed.

Metacomments:
- Current solution in spec is not broken nor incompatible with WSA
- This proposal will force a new PR review and Interop
- This proposal does not address any new features or use-cases

Legend:
MC = MakeConnection
MP = MessagePending
CS = CreateSequence

Specific comments:
- Lack of support for multiple endpoints per Sequence.
  When a MC is received the receiver can determine which Sequence
  is being targeted by the ref-p's of the incoming message. However,
  not all messages being sent on that Sequence can be received by
  all anon endpoints.  How can the receiver of MC ensure that the
  proper message (e.g. response) is given to the proper anon endpoint?
  Ability to share RM state does not equate to share of messages.

- Restrictions on RM Processing model.
  Base specifications should, within reason, try to avoid restricting the
  usage pattens under which they are used.  Since the RM spec is silent on
  algorithm used to determine when (and how many) Sequences are used we need
  to be careful about adding things to the spec that would restrict the
  impl's choices.  Above we talk about a single Sequence spanning multiple
  endpoints, but going the other direction there may be RM processors that
  choose to group messages destined to the same endpoint under one Sequence.
  In essence what we're talking about grouping based on wsa:To.  This proposal
  would not allow for this type of processing model because all wsa:To values
  would be the WSA Anon URI.

- How many MC messages are needed?
  This proposal would require one MC per Sequence. If there are multiple
  Sequences at play between the two endpoints the current spec allows
  for a single MC to pull back messages from any Sequence. This could be
  a significant performance issue.

- Since MC is an optional feature, how does the receiver know it will be used?
  Here there are two reasons the receiver of the MC would like to know
  whether or not MC will be used at all. First, the receiver may choose to
  reject requests to use the anon EPR if MC will not be used - thus saving
  resources.  Second, in cases where RM is optional for messages targeted
  to the Anon EPR, if the receiver knows that MC will not be used it may
  choose to not turn on RM at all, thus allowing normal WSA rules to
  apply to its delivery.  This would still allow a non-MC enabled client
  to function, where if the receiving end assumed that MC were always
  an option it may never actually deliver any message until a MC is sent.
  Thus never sending any messages.

  Also, if the receiver of the MC makes the wrong choice (meaning it thinks
  MC will not be used) and MC's do flow then a new (unused) Sequence will
  be created.

- Requires special AcksTo EPR construction.
  While obviously its possible to create AcksTo EPRs with distinguishing
  ref-p's, w/o this proposal there is no need to.  All RM protocol
  messages have a wsrm:Identifier already that is used to identify which
  Sequence is at play.  This would require a secondary mechanism to also
  be used.  While not a deal-breaker it is a duplication of function and
  forces exposure of the MC feature into the other RM aspects.  Current
  version has no impact the rest of the RM spec - thus when this RM
  feature is turned on it doesn't require a change to the rest of the RM
  stack.

- The AcksTo is not the same thing as the RMS.
  Implicit in this proposal is that the AcksTo endpoint has access to all
  of the same information as the RMS - which is not necessarily true. The
  AcksTo EPR is not required to do anything more than be able to update the
  state of the RM Sequences w.r.t. Acks - nothing more.  This is one of the
  reasons we have a dedicated AcksTo EPR at all - otherwise we would have
  just overloaded an existing EPR - like wsa:ReplyTo or wsa:From. Using the
  AcksTo EPR for this purpose is forcing a certain implementation choice.

- Orphan AcksTo
  This proposal suggests that a MP header may contain an AcksTo EPR as a
  signal that the receiver of the MP should then send a MC to that EPR
  as a mechanism by which new Sequences can be created.  This would then
  create an 'orphan' AcksTo EPR.  This EPR is not associated with a
  Sequence, thus its an orphan, and quite a change to how RM works.
  Or if it is associated with a Sequence then what is the state of that
  Sequence?  This would imply that a Sequence is created before a CS is
  actually processed.

- MP on nonexistent message.
  This proposal talks about a MP being able to flow so that the sender of
  message can signal to the anon endpoint that a MC needs to be sent so a
  CS can flow.  But in cases where this is the first message being sent
  how can this work? There is no back-channel from the anon endpoint to
  send it on.  Also, even if there was some incoming message how did
  the sender of the MP who which anon endpoint sent it? There is no identifying
  info in the message to distinguish one endpoint from another.

- Poor performing CreateSequence
  When the sending endpoint needs to use MP to create new Sequence we see
  the following message exchanges:
  Client -> some msg           -> Server
  Client <- some msg+MP/AcksTo <- Server
  Client -> MakeConnection     -> Server/AcksTo
  Client <- CreateSequence     <- Server/AcksTo

  vs current solution:
  Client -> MakeConnection -> Server
  Client <- CreateSequence <- Server

  As stated in the previous bullet, there's no guarantee that the "some msg"
  data is actually available to do that msg exchange, but also this
  proposed solution is quite a bit more verbose and non-optimized.

- Unreliable-in/Reliable-Out not supported.
  Client sends a GetQuote, ReplyTo=anon.  Server decides to use RM to
  send the response.  How can this work?  The proposal implies that
  either a CS or a MP is sent back but how and on what socket?
  Anon replyTo means the only thing that can flow back on the current
  sockets is the GetQuoteResponse so how does the CS flow?
  Anon doesn't allow the GetQuoteResponse to flow back on any other
  socket than the one carrying the request.  Some people argue that it
  can if we're in the error case (broken socket) and using RM, but what
  about the non-error case - socket is still there and waiting for a
  response?  WSA rules would still need to apply.  Or are we suggesting
  this proposal changes WSA processing rules?

- Places burden of creating new sequences on the wrong side.
  There are scenarios mentioned in this proposal where the RMD sends a
  MC to, in essence, ask for a CS to flow.  This is quite a change to
  the current RM processing model where its the RMS that is always in
  control over when to create new Sequence.  Also, this then leads to
  the question of how did the RMD know a new Sequence is needed?

- Client Identification
  Following on the previous comment, the proposal says:
    When an unreachable client requires a new inbound sequence it MAY
    send the MakeConnection header independently to RM service endpoint.
    Upon receipt of a MakeConnection header block that the RM Source
    cannot relate to an existing sequence it MUST respond with either
    a CreateSequence message on the protocol specific back channel
    of the request, or with a MakeConnectionRefused fault.
  How does the service know if a Sequence already exists? What unique
  info is there to compare?  Since these MC's can be delayed in the
  network, its possible that many may be sent and thus lots of
  CreateSequences may flow - meaning lots of unused Sequences may be
  created.  See next point.

- Unnecessary Sequences/Message flows.
  Since we're talking about RM here we need to think about what happens
  in cases where messages are late to the party.  In this proposal if a
  rogue MC is received and the AcksTo EPR it pointed to is for a terminated
  Sequence then a CS will flow back.  This will cause an unused Sequence
  on both endpoints and cause the generation of unused MC's that will
  continually flow until the Sequence expires.  And worse, what if the
  CS had an Offer - we then double the number of unused Sequences.

- MP sent to unidentified client
  The proposal says that a MP can be sent on inbound traffic to the
  unreachable endpoint, but it doesn't link the MP header to the
  client or to the Sequence so how does the sender of the MP know
  whether or not any particular message can carry the MP header.

- MP & client id again
  The proposal says:
    In the circumstance where an RM Source wishes to initiate a sequence
    with an anonymous client, the RM Source MAY return a MessagePending
    header over an existing transport backchannel. The MessagePending
    header MAY contain an AcksTo EPR...
  How does the RMS know which anon client its talking to?



Misc:

Some pointers to old discussions:
Discussion if i089 at Raleigh f2f:
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/17492/MinutesWSRX-f2f-032306.html#_Toc131830356

Old proposal for i089 but the word doc contains a lot of the rationale
behind the thinking:
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200605/msg00123.html

Pointer to i010, which dealt with Sequences spanning multiple endpoints:
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i010

thanks
-Doug


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]