- From: Sverdlov, Yakov <Yakov.Sverdlov@ca.com>
- Date: Wed, 27 Sep 2006 09:48:43 -0400
- To: "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: <ACE36C31EA815A4CBA7EBECA186C0D41C51D29@USILMS13.ca.com>
Prasad/Umit,
I think the discussion, started by Umit, highlights the complexity of
trying to separate requirements versus capabilities, and
client/requester policies versus provider/service policies. I don't
think it is necessary. I actually think that it is not possible to do
this without significantly liming the specification's use case coverage.
Currently the specification states that "...policy assertion represents
an individual requirement, capability, or other property of a
behavior..." The key word here is "behavior". Any entity can have
requirements, capabilities or other properties associated with it. The
specification should not attempt to define these.
The specification should not define polices with regard to relationships
between entities, either. The client/requester may have both
requirements and capabilities to be covered by policies, and the
requirements imposed on the client may have nothing to do with service
capabilities. An example of this is the HTTPS requirement on the client
without the service actually supporting HTTPS (with intermediary in
between). The same applies to the service/provider.
The roles of the requester/provider may also change in the scope of the
same bidirectional interaction.
As long as the policy (assertion) defines entity behavior through a
subject, the variations above are not important and are covered by the
specification, in my opinion. Of course, the behavior can be optional -
as in Umit's MTOM use case.
Regards,
Yakov Sverdlov
CA
________________________________
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-policy-framew
ork.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-policy-framew
ork.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/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 13:49:10 UTC