RE: Proposal for Resolution of 3564

+1 to Umit with two modifications.

 

I would like to exclude from the proposal the following statement
because of the symmetric nature of message exchanges:

 "It is recommended that authors not utilize optional assertions for
outbound messages unless there is explicit, out of band mechanism
(currently such a mechanism is outside the scope of WS-Policy Framework)
that a client can use to indicate that the optional capability must be
engaged."

 

Also I would like to change from:

"Optional assertion authors should explicitly state how the capability
that is enabled by the assertion would be engaged..."

To:

"Optional assertion authors should explicitly state how the behavior
that is enabled by the assertion would be engaged..."

 

Regards,

 

Yakov Sverdlov

CA

 

________________________________

From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Christopher B
Ferris
Sent: Monday, October 23, 2006 3:08 PM
To: Yalcinalp, Umit
Cc: public-ws-policy@w3.org
Subject: Re: Proposal for Resolution of 3564

 


All, 

On the telcon 2 weeks ago, it was suggested during the discussion that
Umit's email may hold a key to 
unraveling the "tarball" ( I like to refer to it as the hairball, since
I have none). 

All were encouraged to review Umit's note and continue discussion on the
mailing list. 

I would like to resume the discussion on this topic this week. So,
please do review 
Umit's proposal and be prepared to discuss. If you have a better
suggestion, please 
do make a proposal and send it to the list. 

Cheers, 

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

public-ws-policy-request@w3.org wrote on 10/03/2006 07:00:09 PM:

> Folks, 
> As we have decided to divide the understanding the framework 
> concerns from the assertion development concerns, below find the 
> proposal for Optional Assertions as we would like to propose for the
> Author's Guidelines Document. 
> In this proposal, it is assumed that the Primer will introduce an 
> example as it does today and the Assertion Guidelines document will 
> refer to the example by further guidance and illustration of 
> pitfalls. These pitfalls that are covered below were also noted in 
> the creation of this issue [3564] 
> In developing this proposal, I realized that we have a separate 
> issue with the Primer document, namely the choice of MTOM capability
> as an example for optional assertions. I am creating a new issue for
> that so it can be tackled separately. The current writeup, as it 
> refers to the Primer, assumes that such an assertion exists but the 
> text can easily be changed to refer to WS-RMP, or any other 
> assertion that is currently in practice to be used with 
> optional="true" marker. Therefore, please keep that in mind while 
> reading this proposal. 
> Thanks, 
> --umit 
> [3564] http://www.w3.org/Bugs/Public/show_bug.cgi?id=3564 
>
------------------------------------------------------------------------
------------------------------------------------------- 
> Section 5.7 Optional Policy Assertion: 
> Optional assertions represent behaviors which may be engaged by a 
> consumer. When using the compact authoring form for assertions, 
> behaviors are marked by using wsp:optional attribute that has a 
> value, "true". During the process of normalization, the runtime 
> behavior is indicated by two policy alternatives, one with and one 
> without containing the assertion. In a consumer/provider scenario, the

> choice of engaging the runtime behavior is upon the consumer although 
> the provider is capable of engaging the runtime behavior. 
> The Primer document contains an example that proposes MTOM as an 
> optional behavior that can be engaged by a consumer. The primer 
> proposes that this assertion identifies the use of MIME 
> Multipart/Related serialization for messages to enable a Policy-aware 
> clients to recognize the policy assertion and if they select an 
> alternative with this assertion, they engage Optimized MIME 
> Serialization for messages. 
> The semantics of this assertion declare that the behavior is reflected

> in messages: they use an optimized wire format (MIME Multipart/Related

> serialization). Note that in order for an optional behaviors to be 
> engaged, the wire message that would utilize the specific assertion 
> must be self describing. For example, an inbound message to a web 
> service that asserts MTOM, must evaluate, the protocol format of the 
> message to determine whether the incoming message adheres to the 
> Optimized MIME Serialization. By examining the message, the provider 
> can determine whether the policy alternate that contains the MTOM 
> assertion is being selected. 
> Assertion authors should be aware that optional behaviors, like 
> utilizing optional support for Optimized MIME Serialization require 
> some care. 
> + Since optional behaviors indicate optionality for both the provider 
> and the consumer, behaviors that must always be engaged by a consumer 
> must not be marked as "optional" with a value "true" since presence of

> two alternatives due to normalization enables a consumer to choose the

> alternative that does not contain the assertion, and thus making the 
> behavior not being engaged in an interaction. 
> + As demonstrated in the MIME optimization behavior, behaviors must 
> be engaged with respect to messages that are targeted to the provider 
> so that the provider can determine that the optional behavior is 
> engaged. In other words, the requirement of self describing nature of 
> messages in order to engage behaviors must not be forgotton with 
> regard to the client's ability to detect and select the alternative if

> it is to participate in the exchange. It is recommended that authors 
> not utilize optional assertions for outbound messages unless there is 
> explicit, out of band mechanism (currently such a mechanism is outside

> the scope of WS-Policy Framework) that a client can use to indicate 
> that the optional capability must be engaged. 
> + When optional behaviors are attached with only one side of an 
> interaction, such as an inbound message of a request-response, the 
> engagement of the rest of the interaction will be undefined. For 
> example, if a request-response interaction only specified MTOM 
> optimization for an inbound message, it would not be clear whether the

> outbound message from the provider could also utilize the 
> behavior. Therefore, the assertion authors are encouraged to consider 
> how the attachment on a message policy subject on a response message 
> should be treated when optional behaviors are specified for message 
> exchanges within a request response for response messages. Leaving the

> semantics undescribed may result in providers making assumptions 
> (i.e. if the incoming message utilized the optimization, the response 
> will be returned utilizing the MTOM serialization). Similarly, if 
> engagement of a behavior is only specified for an outbound message, 
> it may be necessary to describe the semantics if the incoming messages

> also utilized the behavior. WS-RM Policy currently allows the 
> incoming messages to utilize WS-RM protocol to be engaged although the

> assertion may only appear on an outbound message in a request 
> response. 
> + Optional assertion authors should explicitly state how the 
> capability that is enabled by the assertion would be engaged when they

> are designing their assertion, whether by specific headers or some 
> other means. 
> ---------------------- 
> Dr. Umit Yalcinalp 
> Architect 
> NetWeaver Industry Standards 
> SAP Labs, LLC 
> Email: umit.yalcinalp@sap.com Tel: (650) 320-3095 
> SDN: https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/36238 
> -------- 
> "First they ignore you, then they ridicule you, 
> then they fight you, then you win." Gandhi