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: RE: [ws-rx] issue i021 requirements



Ashok,

Where does it say that an RM enabled endpoint MUST understand WS-Policy and/or the
WS-RM policy assertion?

I don't think it unreasonable at all.

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295


"Ashok Malhotra" <ashok.malhotra@oracle.com> wrote on 03/09/2006 11:51:20 AM:

> Chris, you said ...

>  
> > There are certain situations, such as a gateway, that may not have
> access to the
> > WSDL/policy to determine which messages should be included in an RM
> Sequence.

>  
> This is the contentious requirement.  You want the spec to cover
> situations where

> one of the participants does not adhere to the spec or does not have
> enough information

> to follow the spec.  I don't think this is reasonable.
> All the best, Ashok
>  
>
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> Sent: Thursday, March 09, 2006 8:24 AM
> To: Anish Karmarkar
> Cc: wsrx
> Subject: Re: [ws-rx] issue i021 requirements

>
> Anish,
>
> I don't necessarily disagree with these requirements.
>
> However, as I indicated in my previous notes, and during the discussion on
> last week's call, It isn't clear to me that every RM enabled
> endpoint will have
> the capacity to apply the RM semantics on a message-by-message basis.
>
> There are certain situations, such as a gateway, that may not have
> access to the
> WSDL/policy to determine which messages should be included in an RM
> Sequence. Further more, even if the WSDL/policy WERE available, there may be
> considerable overhead involved in having to parse the messages (in the
> gateway scenario) to determine if they match those messages which have
> been annotated as needing to be sent reliably.
>
> In such cases where a source endpoint is just on/off for all messages that
> pass though, I think that the corresponding destination endpoint should NOT
> reject messages that are sent reliably yet are not indicated as being required
> to be sent reliably in the WSDL/policy.
>
> Thus, adding to my proposed addendum to Sanjay's proposal:

> If an RM policy assertion is attached to any of:
> wsdl:binding/wsdl:operation/wsdl:input
> wsdl:binding/wsdl:operation/wsdl:output
> wsdl:binding/wsdl:operation/wsdl:fault
> then an RM policy assertion, specifying wsp:Optional=true MUST be
> attached to the corresponding wsdl:binding or wsdl:port, indicating
> that the endpoint supports WS-RM. Any messages, regardless of
> whether they have an attached Message Policy Subject RM policy
> assertion, MAY be sent to that endpoint using WS-RM. Additionally,
> the receiving endpoint MUST NOT reject any message belonging to a
> Sequence, simply because there was no Message Policy Subject RM
> policy assertion attached to that message.
>
> I would offer the following explanation/rationale:
>
> There might be certain RM implementations that are incapable of
> applying RM QoS semantics on a per-message basis. In order
> to ensure the broadest interoperability, when an endpoint decorates
> its WSDL with RM policy assertions using Message Policy Subject,
> it must also be prepared to accept that all messages sent to that
> endpoint might be sent within the context of an RM Sequence, regardless
> of whether the corresponding wsdl:input, wsdl:output or wsdl:fault
> had an attached RM policy assertion.
>
> Rather than turn away messages that were unnecessarily sent with RM
> semantics, the receiving endpoint described by the WSDL
> must accept these messages.
>
> By attaching an RM policy assertion that specifies wsp:
> Optional="true" to the corresponding endpoint that has attached RM policy
> assertions at the Message Policy Subject level, the endpoint is
> describing the above constraint in policy.
>
> Cheers,
>
> Christopher Ferris
> STSM, Software Group Standards Strategy
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295
>
> Anish Karmarkar <Anish.Karmarkar@oracle.com> wrote on 03/09/2006 08:01:12 AM:
>
> > I took an action during last week's concall to send requirements for
> > what I see as the desired semantics for issue i021. Sorry for being late
> > but I'm on vacation till 17th march (my regrets for the next 2 concalls).
> >
> > Requirements:
> >
> > 1) Provide the capability to specify in WSDL that a particular message
> > (input, output, or fault) MUST be sent reliably within a WSRM Sequence.
> >
> > 2) Provide the capability to specify in WSDL that a particular message
> > (input, output, or fault) MAY be sent using WSRM. The means that it is
> > the sender's choice (and not the receiver's) whether the message is sent
> > reliably or not.
> >
> > 3) Provide the capability to specify in a WSDL binding/port that all
> > messages  sent using that binding/port MUST be sent reliably within a
> > WSRM Sequence (but not in the same Sequence). This potentially could be
> > syntactic sugar based on how the capability in (1) is provided.
> >
> > 4) Provide the capability to specify in a WSDL binding/port that all
> > messages  sent using that binding/port MAY be sent reliably within a
> > WSRM Sequence (but not in the same Sequence). The means that it is the
> > sender's choice (and not the receiver's) whether the message is sent
> > reliably or not. This potentially could be syntactic sugar based on how
> > the capability in (2) is provided.
> >
> > 5) The capability in (1) and (2) should not impose onerous constrains on
> > other messages within the same portType/Binding/Port wrt reliability.
> > For example, one should have the ability to specify that a particular
> > in-message MUST be sent reliably without requiring any reliability
> > constrains on the out-message (supported or required).
> >
> > Consider a port which is a purchase order service providing 'submitPO'
> > and 'getStatus' operations. The submitPO operation is reliable, secure
> > and transacted operation which returns a PO number. Both the in and out
> > messages for submitPO are sent reliably. The getStatus operations
> > requires the PO number and returns a status (pending, approved) -- this
> > is not a secure, reliable or a transacted operation. The capabilities
> > provided in (1) - (4) above should not force the port to support
> > reliability for the getStatus operation.
> >
> > -Anish
> > --
> >
> >
> >


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