- From: Prasad Yendluri <prasad.yendluri@webmethods.com>
- Date: Wed, 27 Sep 2006 16:50:22 -0400
- To: Glen Daniels <gdaniels@progress.com>, Prasad Yendluri <prasad.yendluri@webmethods.com>, "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, Daniel Roth <Daniel.Roth@microsoft.com>, public-ws-policy@w3.org
- Message-ID: <A3E375FA108EF94496269A5A96AFCAC106C3E95F@mailwest-e0b>
Glen,
See some follow-up below.
Prasad
-----Original Message-----
From: Glen Daniels [mailto:gdaniels@progress.com]
Sent: Wednesday, September 27, 2006 8:40 AM
To: Prasad Yendluri; Yalcinalp, Umit; Daniel Roth; public-ws-policy@w3.org
Subject: RE: ISSUE 3564: Optional Assertions may not be usable in all cir
cumstances
Just chiming in here... I agree 100% with Umit's characterization of
requirement vs. capability, and I'd love to see the spec/primer have
more clarity on this. Something a provider CAN do is a capability.
Something a consumer MUST do is a requirement. That's it, IMHO. The
concept of "optional requirements" makes about as much sense to me as
"low-fat Twinkie". :) I don't believe there's such a thing.
<PY> Currently the specification identifies a "policy assertion" to be
either a "requirement, or capability of a policy
subject.", and an assertion can be marked "optional" via the "optional=true"
attribute. So, the "optional"ity is applicable to either form an assertion
can take, viz. the requirement or capability. A requirement is what the
provider / policy subject expects / needs of its clients / consumers to do.
Some of these are what clients MUST do (per a certain policy alternative)
and other are clients have a choice to do or not (i.e. optional). Let us
not get sidetracked by the term "requirement" and the usual English meaning
of it. WS-I Basic profile calls its assertions "conformance requirements"
and there are MUST and MAY and SHOULD requirements. So, there can be
"optional requirements", which simply means things the client side is
expected to do, but has an "option" not to do. If the "requirement" is not
the right word perhaps we need to find a better term but, as defined in the
spec "an assertion can be marked 'optional' and an assertion is either a
"requirement" or "capability"".
The spec does not state an assertion marked "optional" is a capability. That
is what the primer was interpreting.
IMO that is a big jump to conclusion that the spec does not grant. I think
this aspect needs to be clarified in the spec rather than interpreted at
free by the primer.
In the WS-Policy realm, if you see an optional assertion, that indicates
a capability which you as a consumer somehow choose (in a
domain-specific fashion) to utilize or not.
PY>Not necessarily. An assertion in general may not have any capability
implications for the provider.
If the assertion calls for optionally sending a hardcopy of the PO to a USPS
address, in addition to submitting an online purchase order request, it has
no capability implications to the service that accepts the online PO.
If you see a non-optional
assertion in a selected alternative, then you MUST a) understand and b)
follow the rules of that assertion. If the assertion indicates
something that you don't have to do anything about (i.e. "I'll respond
within 10ms"), that's fine, but you still MUST understand it in order to
use that alternative - so in a way it's still a requirement.
PY>Fine it won't be marked optional then. It is a capability that is not
Optional :-)
Fits fine with what the spec currently defines. If you chose a policy
alternative, you are expected to have understood all the assertions in it
(optional or not), anyway.
If you want to actually be able to do something (litigate, etc) if a
policy claim like a round-trip guarantee is not honored, then you need
some kind of iron-clad indication that that policy was in fact in
effect. This gets into the "policies with no wire representation"
discussion again....
PY> Yes, we need to attain clarity and spell all these aspect out in the
spec.
I would not the primer infer and state things that are not clearly granted
by the spec.
--Glen
> -----Original Message-----
> From: public-ws-policy-request@w3.org
> [mailto:public-ws-policy-request@w3.org] On Behalf Of Prasad Yendluri
> Sent: Tuesday, September 26, 2006 9:09 PM
> To: Yalcinalp, Umit; Prasad Yendluri; Daniel Roth;
> public-ws-policy@w3.org
> Subject: RE: ISSUE 3564: Optional Assertions may not be
> usable in all cir cumstances
>
> Hi Umit,
>
>
>
> See my response inline.
>
>
>
> Prasad
>
>
>
> ________________________________
>
> From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com]
> Sent: Tuesday, September 26, 2006 5:07 PM
> To: Prasad Yendluri; Daniel Roth; public-ws-policy@w3.org
> Subject: RE: ISSUE 3564: Optional Assertions may not be
> usable in all cir cumstances
>
>
>
> 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".
>
>
>
> PY>Yes we need a clear definition of what we mean by
> capability. As clearly demonstrated by the exchange on this
> thread, there are multiple (at least two) interpretations.
> Your interpretation of capability is not what I was expecting
> but, I can grant that it can be considered a capability (of
> the provider), in that the provider can do it, if the
> consumer (client) side engages it.
>
>
>
> 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.
>
> PY>Well like I said, it is one interpretation of capability,
> something the service side can handle if the client side
> engages it. Per another interpretation, it is a requirement
> on the client to engage it, even though the client has the
> option not to engage it, as it is "optional". I tend to think
> of capability as something the provider side declares that it
> is capable of doing (like guaranteed under 10 msec. response
> time). All assertions that depend on the client (consumer)
> side doing something, fall in the "requirement" category from
> my perspective. Requirements can be optional or mandatory,
> based whether the consumer side must do it or not.
> Capabilities have no such client side impact. They are pure
> provider side declarations, which if the provider does not
> meet or deliver put the provider out of policy.
>
>
>
> The marker to indicate that an interaction will take 10
> seconds response time is more of a property of the service.
>
> PY>Well we don't have anything called a "property" in
> WS-Policy. I consider it a capability; it is a 10msec
> response time guarantee.
>
>
>
> I do not consider this a capability that is selectively engaged.
>
> PY>By my definition of capability, it may or may not be
> selective. It is what the provider declares it can deliver
> and if the provider does not deliver it, it is out of policy.
>
>
> 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.
>
> PY>Well we clearly have different view points here. I see
> that as a clear declaration of capability (sure a QoS related
> one in this case).
>
>
>
> 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.
>
> PY>The specification states that a "policy assertion"
> identifies either a "requirement, or capability of a policy
> subject." And it does not define a capability to be an
> optional assertion, whereas the primer is giving that
> interpretation. I don't think that is accurate explanation
> of what the spec states, as it stands now. It is certainly
> subject to interpretation and contention.
>
>
>
> I am not sure why you don't see MTOM category to be not a
> requirement? If there is no "optional" on the assertion that
> calls for engaging MTOM by the client, then * it is * a
> requirement on the client to use MTOM encoding on the
> messages it sends and expect to receive and handle MTOM
> encoded messages, is it not?
>
>
>
> Lets see what others think. After we solidify the
> terminology, it is easy to fix the guidelines, primer, etc.
>
> PY> Yep, fine with me, We clearly need a concrete definition
> of requirement and capability in the spec, given the
> demonstarted scope for interpretation here.
>
>
>
> 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
> <http://dev.w3.org/cvsweb/%7Echeckout%7E/2006/ws/policy/ws-pol
> icy-framework.html#policy_assertion> identifies a behavior
> that is a requirement or capability of a policy subject
> <http://dev.w3.org/cvsweb/%7Echeckout%7E/2006/ws/policy/ws-pol
> icy-framework.html#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/a
> tt-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 20:54:29 UTC