Re: ISSUE 3564: Optional Assertions may not be usable in all cir cumstances

> IMHO, using 'capability' and 'requirement' as different terms is  
> confusing.

this is why I suggested "advisory" attribute.

It is difficult to combine the concept of optional with its  
normalization implications with flagging items that can be ignored  
without implication of actual impact.

regards, Frederick

Frederick Hirsch
Nokia


On Sep 27, 2006, at 11:37 AM, ext Sergey Beryozkin wrote:

> Hi
>
> IMHO, using 'capability' and 'requirement' as different terms is  
> confusing.
> Personally I see both unoptional and optional assertions as those  
> marking various capabilities. For ex, optional mtom assertion and  
> non optional sp:httpstoken assertion are capabilities in that a  
> provider is capable of supporting optimized mtom serialization and  
> htts security. I'm sure there can be many more interpretations there.
>
> I believe if following simple assumptions/rules are made clear in  
> the text, then there won't be a source for any confusions/arguments.
>
> 1. wsp:optional can be used to mark an assertion as being optional.  
> This means a client is free to ignore it. This is backed up by the  
> spec mandating wsp:optional is not part of the normal form  
> expression, per every assertion marked as wsp:optional in the  
> compact form there will be at least two alternatives with one of  
> them including the optional assertion and with the other one not.
>
> 2. wsp:optional marks an assertion which MAY be processed/noted by  
> a client. By no means it's supposed to give any signals to a  
> (provider) entity. A provider entity is guaranteed to support all  
> policy assertions listed in a given policy, those marked as  
> wsp:optional and those which are not. This is again backed up by  
> the fact that wsp:optional is not present in the normal expression  
> form.
>
> 3. IMHO, reserving wsp:optional as a means to mark only those  
> assertions which identify behaviours which may be engaged during  
> the interaction between entities, is confusing. Clearly, there's a  
> range of policy assertions which have no behavioural requirements  
> on the consuming entity and these assertions are normal citizens of  
> the WS-Policy landscape. Such assertions can also be marked  
> optional, see also 5.
>
> 4. Given 1-3 above I believe primer/guidelines shouild be updated  
> to clearly state 1. and 2. and say that wsp:optional can be used to  
> mark assertions which identify behaviours which may be engaged and  
> assertions which identify provider capabilities with no behavioral  
> requirements on the consuming entity
>
> 5. I know it's a controversial one but : given 1-4 and the fact  
> that capabilities with no behavioral requirements have no effect on  
> the consuming entity and can only be used for the selection, primer  
> should recommend marking such capabilities as optional (Apologies  
> for repeating it all again and again, I'll open an issue for it be  
> properly tracked). Otherwise unaware (client) entities will  
> unnecessarily fail. I believe policy authors will put wsp:optional  
> on such assertions anyway, but first they'll learn the hard way  
> that their services can only be consumed by a limited set of  
> entities. Should 3 be addressed then I feel there won't be any  
> disagreement here too.
> Cheers, Sergey Beryozkin
>
> Hi Prasad,
>
> It seems to me that perhaps the problem is the assumed definition  
> of capability in the community and lets tease out a bit. You are  
> right, there is an anomaly, but I am not sure I agree with the term  
> "optional requirement".
>
> When MTOM assertion is present with optional="true" on a msg, I do  
> not understand why you think it as a requirement. >From the  
> perspective of the service, it is an optimization that is available  
> but NOT necessary to be engaged. Hence, IMO this fits to a  
> definition of a capability, albeit inherent at runtime.
>
> The marker to indicate that an interaction will take 10 seconds  
> response time is more of a property of the service. I do not  
> consider this a capability that is selectively engaged. In essence,  
> the service does not advertise that "hey I can response to you in  
> 10 seconds, but you must do sth in order to get this kind of  
> quality of service". It just says that you will get this behaviour.  
> IMO, this is just an inherent property of the QoS, not a  
> capability.  It is a requirement of the service to provide you this  
> QoS. The burden is on the provider (or whomever) that advertises  
> this assertion as it is a requirement on their part. Just like a  
> marker that advertises whether the interactions with a service  
> guarantees confidentiality ("we won't sell your information to  
> third parties".). You may be able to take legal action if they do  
> if they did not comply with the advertised policy which they  
> advertise. The client does not do or no choice in altering the  
> outcome, but it is just there. I agree that this expression of this  
> category should be part of the WS-Policy assertions. I would not  
> call this a capability however. In this case, the #2 is a  
> requirement, but the requirement is on the provider where the  
> client does not need to do anything.
>
> In the end it all boils down to what we mean by "capability" and  
> whether we need a glossary to explain it. The MTOM category IMO is  
> certainly NOT a requirement.
>
> Lets see what others think. After we solidify the terminology, it  
> is easy to fix the guidelines, primer, etc.
>
> Cheers,
>
> --umit
>
>
>
>
> From: public-ws-policy-request@w3.org [mailto:public-ws-policy- 
> request@w3.org] On Behalf Of Prasad Yendluri
> Sent: Friday, Sep 22, 2006 12:18 PM
> To: Daniel Roth; Yalcinalp, Umit; public-ws-policy@w3.org
> Subject: RE: ISSUE 3564: Optional Assertions may not be usable in  
> all cir cumstances
>
> Dan, Maryann, Umit et. al,
>
>
>
> The spec defines  a policy assertion to be, “ A policy assertion  
> identifies a behavior that is a requirement or capability of a  
> policy subject.”
>
>
>
> Where as the primer (best practices doc ?) clarifies, “Optional  
> Policy assertions are assertions that express capabilities."
>
>
>
> I tend to attributes two types of meaning to capabilities. (1)  
> Things the provider can do if the requester tries to engage it (e.g  
> use of MTOM/XOP encoding). That is, optional requirements, which is  
> the interpretation that the primer has taken. However I can see  
> another kind of capabilities (ii) capabilities e.g. a service  
> declares it can do but there is no requirement on the client. For  
> example, this service receives mail for xyz.com domain, but it also  
> routes mail to domains other than xyz.com (serves as a mail  
> gateway). Can a service declare that “capability” as an assertion?  
> It is useful for the (mail) client to know so that, it can send  
> mail addressed to other domains to this service. Another example  
> is, a service that boasts a10 msec response time. My understanding  
> is that declaration of capabilities such as these is a valid use of  
> policy assertions.
>
>
>
> If so, the primer / best practices doc’s interpretation of  
> capability is incomplete and perhaps misleading? It would be useful  
> to account for the use case #2 above also.
>
>
>
> Honestly, I would like to call optional requirements just that (and  
> not capabilities), as there may not be any capability implication  
> to a service in general, if or not a client engages an optional  
> requirement.  E.g. an optional requirement to follow-on an online  
> Purchase Order request via hard-copy sent to a USPS address.
>
>
>
> Regards,
>
> Prasad
>
>
>
> -----Original Message-----
> From: public-ws-policy-request@w3.org [mailto:public-ws-policy- 
> request@w3.org] On Behalf Of Daniel Roth
> Sent: Friday, September 22, 2006 11:36 AM
> To: Yalcinalp, Umit; public-ws-policy@w3.org
> Subject: RE: ISSUE 3564: Optional Assertions may not be usable in  
> all circumstances
>
>
>
> I have reviewed the primer material on using wsp:Optional that  
> Maryann and Umit proposed [1].  Other than a few minor edits (see  
> attached) I think the proposal looks good.  The attached doc contains:
>
>
>
> - Various small editorial cleanups.
>
> - I believe the mtom assertion in Example 5-2 should be marked  
> wsp:Optional="true" since it is referred to as an optional assertion.
>
> - The first bullet point seems to indicate that you must engage an  
> optional behavior.  I think the intention was to state that if a  
> provider decides to support an optional assertion it needs to have  
> some way of figuring out which alternative is being used, either by  
> looking at the wire or by some other means:
>
>
>
> NEW TEXT FOR BULLET #1:
>
> *       The engagement of the optional behavior must be explicit on  
> the wire or through some other mechanism so that the provider can  
> determine that the optional behavior is engaged.
>
>
>
> I suggest that we accept Maryann and Umit's text with these minor  
> changes as satisfying proposal option C for this issue.
>
>
>
> Daniel Roth
>
>
>
> [1] http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/ 
> att-0054/ws-policy-assertionauthors-V1.html#optional-policy-assertion
>
>
>
> -----Original Message-----
>
> From: public-ws-policy-request@w3.org [mailto:public-ws-policy- 
> request@w3.org] On Behalf Of Asir Vedamuthu
>
> Sent: Friday, August 11, 2006 4:56 PM
>
> To: Yalcinalp, Umit; public-ws-policy@w3.org
>
> Subject: RE: ISSUE 3564: Optional Assertions may not be usable in  
> all circumstances
>
>
>
>
>
> > In this case, a client sending a message
>
> > can not ensure that the outbound message will
>
> > be sent using MTOM optimization, by engaging the
>
> > capability as there are two alternatives.
>
>
>
> Providers and requestors rely on wire messages that conform to  
> prescribed data formats and protocols for interoperability. If a  
> requestor wants to signal to a provider that the requestor stack  
> chose to engage MTOM code the requestor may indicate this by  
> sending an MTOM encoded message. Another possibility is to send an  
> HTTP Accept Header [1][2][3]. That is,
>
>
>
> Accept: application/soap+xml, Multipart/Related
>
>
>
> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1
>
> [2] http://www.w3.org/TR/soap12-part2/#httpmediatype
>
> [3] http://www.w3.org/TR/soap12-mtom/#xop-serialization
>
>
>
> This is protocol negotiation. This is not metadata.
>
>
>
> > MTOM and Reliability are good examples that
>
> > will be hindered if optionality is provided
>
>
>
> The above description covers the MTOM case. The behavior indicated  
> by the Reliability assertion manifests on the wire as a Create  
> Sequence message.
>
>
>
> > When a capability is only possible on message
>
> > level subjects and expressed to apply to
>
> > outbound messages only as optional assertions.
>
>
>
> If there are policies associated with a message policy subject for  
> an outbound message, a provider is informing potential requestors  
> that they must be open to engaging any of the policy alternatives  
> in the effective policy of the message policy subject for an  
> outbound message. It is up to the provider to make the choice on  
> the outbound message. A provider may choose an alternative based on  
> an inbound message (as defined by protocol bits - as illustrated  
> above). The choice is still at the provider's discretion. Providers  
> should consider this when expressing multiple alternatives on  
> outbound messages. BTW, this is a good point to highlight in the  
> Primer.
>
>
>
> Regards,
>
>
>
> Asir S Vedamuthu
>
> Microsoft Corporation
>
>
>
>
>
> ________________________________________
>
> From: public-ws-policy-request@w3.org [mailto:public-ws-policy- 
> request@w3.org] On Behalf Of Yalcinalp, Umit
>
> Sent: Wednesday, August 02, 2006 3:32 PM
>
> To: public-ws-policy@w3.org
>
> Subject: ISSUE 3564: Optional Assertions may not be usable in all  
> circumstances
>
>
>
> Title: Optional Assertions may not be usable in all circumstances
>
> Description: Typically providers express capabilities by attaching  
> assertions
>
> that are declared as "optional' on web service artifacts. Marking  
> assertions
>
> optional allow representation of capabilities which may or may not  
> be engaged
>
> although the capability is provided on the provider side. This is  
> due to the
>
> fact that the presence of an optional assertion leads into two  
> separate
>
> alternatives, one containing the assertion and one that does not.
>
> There are certain cases where the client of a web service can not  
> ensure the
>
> engagement of an optional capability since the mechanism of  
> choosing among the
>
> alternatives can not be ensured as there is no explicit mechanism  
> to enable
>
> this. The following situations are detailed examples for this case:
>
> (a) When a capability may be assigned to an endpoint thus governing  
> both
>
> inbound and outbound, but the incoming message can not be self  
> describing to
>
> ensure the engagement of the capability.
>
> A typical example is to provide MTOM capability on an endpoint.  
> Although the
>
> presence of an optional MTOM assertion indicates that MTOM  
> optimization is
>
> possible, a client may not be able to engage MTOM. This situation  
> will occur
>
> when the inbound message does not require optimization (i.e. may be  
> a normal
>
> payload) and the outbound message may include an attachment and may  
> provide
>
> MTOM optimization per WSDL definition. In this case, a client  
> sending a message
>
> can not ensure that the outbound message will be sent using MTOM  
> optimization,
>
> by engaging the capability as there are two alternatives.
>
> (b) When a capability is only possible on message level subjects  
> and expressed
>
> to apply to outbound messages only as optional assertions. Again,  
> the client
>
> can not engage the capability expressed by optional assertions, as  
> the inbound
>
> messages will not include additional information to engage the  
> capability
>
> expressed by the optional assertion that apply to outbound messages  
> only.
>
> Note that case (a) the scoping may be apply to the endpoint, but  
> the definition
>
> of messages may not allow the determination to be made based on the  
> input
>
> message. In case (b), the granularity of attachment directly may  
> prevent the
>
> determination. Therefore, there are two distinct cases.
>
> Without the presence of additional metadata exchange between the  
> client and the
>
> provider, the engagement of optional assertions (more precisely the  
> selection
>
> of one of the alternatives), engagement of a capability is only  
> possible when
>
> the capability pertains to the input message and can be inferred.  
> However, this
>
> is also a limited view, because on message level policy subjects,  
> it is also
>
> not possible to disengage a capability on an outbound message.
>
> Justification:
>
> Non-uniform treatment of optional assertions leads to  
> interoperability problems
>
> as proven by the interop event [InteropPresentation]. It will lead  
> providers to
>
> (1) assume either a particular treatment of optional assertions  
> (always enforce
>
> or never use). Vendors may enforce an capability although an  
> assertion is
>
> expressed to be optional. For example, if a client who is not  
> capable of using
>
> MTOM were to use an endpoint with the capability and would always  
> get MTOM
>
> optimized messages back from a service, the client can not use the  
> service
>
> although the service "advertises" that MTOM is optional.
>
> (2) never use optional assertions. This is a limiting factor for  
> being able to
>
> express capabilities that may be engaged but not required. MTOM and  
> Reliability
>
> are good examples that will be hindered if optionality is provided.
>
> Proposal:
>
> There are several ways to solve this problem. Below here are three  
> sketches.
>
> Complete proposals will need to be developed.
>
> (A) Provide additional binding specific mechanisms (such as  
> specific SOAP
>
> headers) that allow clients to engage capabilities that may  
> optionally apply to
>
> a message exchange.
>
> (B) b1. Disallow alternatives to exist for each subject after  
> normalization as
>
> a design time constraint. Hence, disallow optionality at the  
> endpoint level.
>
>     b2. Disallow optionality completely. (Very much against this  
> option)
>
> For b1, suggest in primer if a capability is to be expressed,  
> always require
>
> the provider two separate endpoints, one that requires and one that  
> does not in
>
> a WSDL. This is a design consideration that would need to be  
> captured by
>
> primer, etc. but goes against the current design of the framework.  
> I believe
>
> this is a very short term option and does not really yield to the  
> usage of the
>
> framework to its fullest.
>
> C. Develop guidelines in primer about the utility of optionality  
> and illustrate
>
> when optional assertions may require additional support from the  
> environment
>
> (as in A)
>
> My preference:
>
> A, worst case C.
>
> Option B. has two major drawbacks and is only a short term solution  
> until a
>
> full solution that addresses the framework intent is developed as  
> mentioned in
>
> (A). Some of the techniques may go into the primer but optionality  
> should not
>
> be disallowed. Further, this approach does not solve fine granular  
> engagements
>
> of capabilities on a message level (see b)in the description). It  
> separates the
>
> conceptional aspect (capability vs. constraint) from the framework  
> and reduces
>
> WS-Policy to express only constraints.
>
> We should not hinder the framework at this stage and discourage  
> optionality.
>
> [InteropPresentation]
>
> http://lists.w3.org/Archives/Public/public-ws-policy/2006Jul/0039.html
>
>
>
> ----------------------
>
> 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
>
>
>
>

Received on Wednesday, 27 September 2006 16:10:39 UTC