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


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

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

Subject: Re: [wsrm] [REL-XX]Proposal for POLL RM-Reply Pattern

 All -

 I'd like to list the concerns & suggestions that were expressed during the discussion
 of this topic yesterday and my comments on these concerns.

 1) It was suggested that instead of Sender sending a status inquiry for a particular
    Msg., Receiver could send all un-acked msgs. I did ponder on this, I do see quite
    a few issues with this:
        - We don't have an identity of the Sender. So we can't identify the Sender's msgs.
          We used to have 'From' element which could have been used for such purposes,
          but that element doesn't exist anymore. We can't use Transport specific
          address mechanism as it could be spoofed, camouflaged and as such multiple
          clients could be using the same transport address.
        - At the same time we couldn't send all Un-Acked msg ids as it will be in-efficient
          and also a security risk.

 2) Other concern was this proposal will require SOAP Envelopes being sent without Body.
     Callback pattern already does this and is a precedent to itself.

 3) One other suggestion was to  explicitly expose the status inquiry as a service to itself:
      - Explicitly in a different wsdl: RMP will become a service provider to itself
        in addition to QoS provider to some other service. In that case, it should
        have it's own endpoint which could be problem. Also, the other issues would
        be how is the service defined in wsdl: rpc vs. doc, encoded vs. literal etc...
      - Explicitly in the user's wsdl: Mucking around User's wsdl is not a good idea
        when this action is anyway done opaquely at RMP level.

 4) Sending the query (implicitly or explicitly) inside SOAP Body:
       - It will create a precedence in that it will require RMPs to look into the
         incoming SOAP Body. So far for all other cases, RMPs doesn't have to look
         into the SOAP Body which is really meant for application payload. In general
         SOAP Headers are meant to be used for extensibility and QoSs.
       - Impl. issue: If not all, a majority of RMP implementations, use some kind
         of Handlers or Interceptors to implement this functionality. While in theory
         you could muck around/peek inside the Body contents inside the Handlers, they
         are ideally meant to Handle Header contents.
       - No piggy backing and difficult for batching: Since the status inquiry is sent
         inside the SOAP Body, we couldn't piggyback this inquiry on another request
         and will be difficult to batch unless we have some what complex schema.

 5) Meta issue: It was also commented that this action is different from other. While
         I agree, I believe the difference is little and very close to what callback
         pattern will be doing. In the latter case also, RMP will be acting as an
         application sending a response at a later stage. Note that sending a Poll
         request is not totally unrelated as it is still related to the msg. for which
         inquiry is being followed up.

 I believe I've answered all the concerns expressed on this topic to my knowledge. While
 I believe that what I proposed is the best we could do, I do welcome any alternate
 proposals with a complete & concrete solution.


Sunil Kunisetty wrote:

>  All -
>  I had an AI @ the last F2F for coming up with a proposal for POLL pattern.
>  Mark/Doug:
>  Could you create a Spec. Issue for Requirement Issues 3.6 & 3.7?
>  <ProposalBegin/>
>   I'd like to propose to have 2 new Headers:
>      StatusRequest
>      StatusResponse
>   StatusRequest will be the Header used by the Sender to send a poll/status
>   inquiry to the Receiver. It will have 2 sub-elements. A mandatory GroupId
>   and an optional SequenceNo. The types for these are the same as the ones
>   in MessageHeader element.
>   StatusRequest
>       - GroupId  - Mid URI type - Mandatory
>       - SequenceNo - UnsignedLong - Optional
>   StatusRequest can be sent without a MessageHeader and hence can be
>   piggy-backed on another Request or can be batched with other status requests.
>   StatusResponse Header will be used by a Receiver to send the status back
>   to Sender. It will have the following sub-elements:
>         - RefToGroupId      -  mid URI type - Mandatory
>         - RefToSequenceNo - unsigned long  - Optional
>         - Status                    - QNAME        - Mandatory
>   Possible Status Values are:
>         - InvalidGroupId -  When the GroupId is invalid or un-recognized
>         - InvalidSequenceNo  - When the SequenceNo is invalid or un-recognized
>         - MsgExpired - When the message was expired (based on ExpiryTime)
>         - MsgReceived - When the message was received and ack-ed by the RMP/
>   Since all our Header elements are extensible, Implementations can extend with a
>   new element called 'sub-status' and send more implementation specific details
>   if desired. But I prefer that Spec. level requirements for Status be simple.
>   Multiple StatusResponse(s)  can be batched or can be piggy-backed on Response.
>   We should be able to share the above Status values with Fault Codes. Note both
>   are QNAME types and hence shareable.
>   Error due to StatusRequest processing will result in a Fault with error code
>   InvalidStatusRequest.
>   <ProposalEnd/>
>  Comments ???
>  -Sunil
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.

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