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] [i021]: update on NO proposal ... and maybe a hint of a proposal


Title: RE: [ws-rx] [i021]: NO proposal ...

1. More precise assessment of  why attaching RMAssertion at message binding level is not that exciting, at least in the context of i021:

- really we are talking of a policy here that governs RMS and RMD behavior w/r to entire Sequences (per WS-RM Policy definitions).  not to single messages (or message types) as subjects. E.g. InactivityTimeout, AckIntervals, etc are behavioral properties of RMD at  Sequence granularity at best, not policies that apply to individual messages (does not make sense).

- assuming we still attach RMAssertion at message binding with the understanding that the meaning is like "this message must be sent over via an RMS and a sequence that follows policy XYZ"  that still requires a slew of precautions: prevent conflict with other RM policies at endpoint level, make sure the client RMS  uses different sequences for sending messages related to different policies, have the RMS know about which policy applies to which message / operation... etc. Kind of getting more trouble than we were bargaining for.

-  I feel this is rather a kludge for what we really need here: a role-based assignment of policies. We just want to say that the endpoint will act in the Destination role w/r to this protocol policy, regardless of the message type - nothing more.

 

2. Given the lack of support for roles in WS-Policy, and assuming there is no reason to always force outbound messages to follow the same RM policy as inbound messages, then I'd propose the following:

 

-          get rid of the RMAssertion container as we know it.

-          Replace it with RMSAssertion and RMDAssertion. Each one of these will be container for assertion items that concern respectively the behavior of a Source and of a Destination endpoints, relative to a sequence.

-          Then if we want a policy that only concerns reliability of received messages, we only use RMDAssertion in the policy. Same if we want to express a policy for the endpoint as a Source -> use RMSAssertion.

-          Note that does not preclude a more fine-grained attachment than endpoint.

-          If we want to add the client-related assertion items when defining a Destination policy for an endpoint (like done today within RMAssertion), but just for information purpose, we can do something like:

<wsp:Policy wsu:Id="MyDestinationPolicy" >

 <wsrmp:RMSAssertion wsp:Usage='Informational'> ... </ wsrmp:RMSAssertion>

<wsrmp:RMDAssertion > ... </ wsrmp:RMDAssertion>

</wsp:Policy  >

 

Opinion?

 

Jacques

 

 

 

 


From: Jacques Durand
Sent: Thursday, October 13, 2005 12:25 PM
To: Tom Rutt2; Yalcinalp, Umit
Cc: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] [i021]: NO proposal ...

 

OK, I thought we had two decent alternatives for i021, but I now believe we have none...  (sigh) See below:

 

1. First one I heard is: Attach an RM Assertion to message level in the binding, e.g. with  wsdl:binding/wsdl:operation/wsdl:input as policy subject. At first that looks good, but:

- really we are talking of a policy here that applies to RMS and RMD behavior, not to single messages as subjects. E.g. InactivityTimeout, AckIntervals, etc are behavioral properties of RMD as a QoS provider, not properties that apply to individual messages.

- assuming we still do that with the understanding that the meaning is like "this message must be sent over via an RMS that follows policy XYZ"  that still requires a slew of precautions: avoid conflicting RM policies at endpoint level, make sure the client uses different sequences for messages related to different policies, have the RMS know about which policy applies to which message... etc. Kind of getting more trouble than we were bargaining for. I feel it is rather a cludge for what we really need here: a role-based assignment of policies.

 

2. Second one, is to declare that it is perfectly our right to say that particular policy assertions (here RMAssertions) per their very nature, only concern messages that are received by the endpoint to which they are attached. That would not solve the problem of how to deal with outbound message flow if we want to make these reliable too. We could "tag" an assertion whether it applies to the endpoint itself or to clients to the endpoint --> kind of ad-hoc substitute for a more general missing role mechanism.

3. Other option: We could also decide to only attach to endpoint the assertions that relate to Destination if we want to control its RMD behavior only (meaning inbound messages only), and assertions that relate to Source only if we want to control its RMS behavior (outbound messages). But a policy that governs a communication RMS-RMD is now split in two separate parts.

 

The best way to get this solved is by fixing the policy framework:
- policy assertions may have roles tags
- when attaching a policy to a subject, the role(s) this subject acts into must be specified.

Otherwise it sounds like back to the old days when the notion of "role" did not exist, policies had to be assigned directly to every subjects 1 by 1... (that is what (1) above is about)

 

Jacques

-----Original Message-----
From: Tom Rutt2
Sent: Thursday, October 13, 2005 10:12 AM
To: Yalcinalp, Umit
Cc: Jacques Durand; ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] [i021]: a proposal

Yalcinalp, Umit wrote:

>
>

>
>>-----Original Message-----
>>From: Tom Rutt [mailto:tom@coastin.com]
>>Sent: Thursday, Oct 13, 2005 8:46 AM
>>To: Jacques Durand
>>Cc: ws-rx@lists.oasis-open.org
>>Subject: Re: [ws-rx] [i021]: a proposal
>>
>>Jacques Durand wrote:
>>
>>   
>>
>>>>you can attache message subject level at message Binding , just as
>>>>       
>>>>
>>>you can >attach bound port for endpoint subject level
>>>
>>>Tom: not clear how to do that - although you can
>>>     
>>>
>>technically attach a
>>   
>>
>>>WS policy to any element of an XML doc, WS-RM Policy does
>>>     
>>>
>>not address
>>   
>>
>>>finer granularity than wsdl:binding elements. All this
>>>     
>>>
>>needs be clarified.
>>   
>>
>>>Jacques
>>>
>>>
>>>     
>>>
>>section 4.1.4 of ws policy attachment
>>"
>>4.1.4 Message Policy Subject
>>The following WSDL/1.1 elements are used to describe messages:
>>* wsdl:message
>>* wsdl:portType/wsdl:operation/wsdl:input
>>* wsdl:portType/wsdl:operation/wsdl:output
>>* wsdl:portType/wsdl:operation/wsdl:fault
>>* wsdl:binding/wsdl:operation/wsdl:input
>>* wsdl:binding/wsdl:operation/wsdl:output
>>* wsdl:binding/wsdl:operation/wsdl:fault
>>
>>These elements MAY have Element Policy as per Section 3 of this
>>specification. The Policy Scope implied by these elements
>>contains the
>>Message Policy Subject representing the specific input,
>>output, or fault
>>message in relation to the Operation Policy Subject. Policy
>>attached to
>>a Message Policy Subject pertains to behaviours associated with a
>>particular message. This includes - but is not limited to -
>>sending and
>>receiving the message. The Effective Policy for a specific
>>WSDL message
>>(i.e., input, output, or fault message) is calculated in
>>relation to a
>>specific port, and includes the Element Policy of the wsdl:message
>>element that defines the message's type merged with the
>>Element Policy
>>of the wsdl:binding and wsdl:portType message definitions
>>that describe
>>that message.
>>
>>For example, the Effective Policy of a specific input message for a
>>specific port would be the merge of the wsdl:message element defining
>>the message type, the wsdl:portType/wsdl:operation/wsdl:input
>>element,
>>and the corresponding wsdl:binding/wsdl:operation/wsdl:input
>>element for
>>that message.
>>
>>Since a wsdl:message may be used by more than one
>>wsdl:portType, it is
>>RECOMMENDED that only policies containing abstract (i.e., binding
>>independent) assertions should be attached to this type of element.
>>
>>Since wsdl:input, wsdl:output, and wsdl:fault elements in a
>>wsdl:portType/wsdl:operation may be used by more than one
>>binding, it is
>>RECOMMENDED that only policies containing abstract (i.e., binding
>>independent) assertions should be attached to these types of
>>elements.
>>Care should be taken when attaching policies to outbound
>>messages as the
>>result may not be what is expected. For example, expressing a
>>choice on
>>a service's outbound message without a mechanism for a
>>requester of that
>>service to communicate its choice to the service before the outbound
>>message is sent may not result in the desired behaviours.
>>
>>It is therefore RECOMMENDED that Policy Alternatives on outbound
>>messages SHOULD be avoided without the use of some form of
>>mutual Policy
>>exchange between the parties involved.
>>"
>>
>>I am talking about attaching policy at the levels
>>* wsdl:binding/wsdl:operation/wsdl:input
>>* wsdl:binding/wsdl:operation/wsdl:output
>>
>>   
>>
>
>This is exactly what I was suggesting as well in my email that
>
>-- RM assertion could apply to Message Policy Subject with the
>restriction that they should not apply to portType and be restricted to
>binding/operation/message.
>
>-- RM assertion to apply to either Message Policy Subject or Endpoint
>Policy Subject, but NOT both for simplicity.
>
>
>Wouldn't this solve the granularity problem?

>
Yes it would, but the question is "for what benefit"

Since WSDL request/response operations are only mapped to synchronous
http request/response
(for whatever reason this restriction is still in the wsdl 2 soap
binding), it is difficult
to provide reliability on the synchronous response.   

Response reliability is much easier to provide if the application
response is sent as its own wsdl one-way
operation.

For pragmatic reasons, I see no reason to go beyond specifying a default
behaviour in the spec
which attaches rm policy at the endpoint binding (or port) subject
level, leaving more detailed
attachments outside the scope of the ws-rm policy specification.

Tom Rutt

>--umit
>
>

>
>>--
>>----------------------------------------------------
>>Tom Rutt      email: tom@coastin.com; trutt@us.fujitsu.com
>>Tel: +1 732 801 5744          Fax: +1 732 774 5133
>>
>>
>>
>>   
>>
>

>

 

--
----------------------------------------------------
Tom Rutt        email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133



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