| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]
Subject: Re: [sca-bindings] ISSUE-48: How are mayProvide intents on bindingssatisfied
- From: David Booz <firstname.lastname@example.org>
- To: email@example.com
- Date: Fri, 10 Oct 2008 12:12:17 -0400
Unfortunately I don't agree with Mike E, let me try to explain in line <dab> </dab>
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
Mike Edwards ---10/09/2008 01:05:07 PM---Eric, Let me try to give my perspective on this issue.
Mike Edwards <firstname.lastname@example.org>
"OASIS Bindings" <email@example.com>
10/09/2008 01:05 PM
Re: [sca-bindings] ISSUE-48: How are mayProvide intents on bindings satisfied
Let me try to give my perspective on this issue.
The core of this issue is that:
IF a bindings specification says that a given binding has a non-null @mayProvide attribute
THEN that bindings specification MUST define how the intents identified in the @mayProvide attribute
are provided by that binding.
<dab> This is where I disagree. The current Policy FW spec says that intents specified in @mayProvides are optional provided by the binding implementation. I'll concede that we could add text to the Policy FW spec to make this clearer (and I hope/expect we will use Ashok's issue to do this), but the conclusion is in-escapable. How then does a binding instance indicate that it wants one of these optional features? It does so by specifying the intent on the binding instance. Let's use an example:
<bindingType type="binding.someBinding" mayProvide="confidentiality"/>
<binding.someBinding name="exa1" requires="confidentiality"/>
The both exa1 and exa2 are valid binding instances. exa1 has turned on the "confidentiality" feature (i.e. might be using SSL), exa2 has not turned it on. No policySets are required, no binding specific configuration is required.
In another related email chain, Anish asked the question:
what if enabling the intent in mayProvides requires some binding specific configuration.
My answer is simple. If a policySet or binding configuration is needed to enable the feature/intent, then the intent should NOT HAVE BEEN in the @mayProvide of the bindingType. Instead, what you're talking about is what I call a "capability" for with the Policy FW spec has no solution....but for which POLICY-33 is open to provide a solution. The solution to POLICY-33 will address the notion of policy alternatives, which is really what you're asking about in this question.
Mike, I think the rest of your email is good fodder for the capability discussion in Policy and I will draw on it as part of the solution for POLICY-33.
- and the binding.jms binding seems to fall into this category (I think you agree on that)
- but that specification does not say anything about how those intents are provided
OK, to open the discussion a bit more. I would expect that if some binding said @mayProvide="xx yy",
where "xx" and "yy" are some intents, then some configuration of the binding is required in order to
have those intents satisfied - if no configuration was required, then I'd expect those intents to be in
the @alwaysProvides list....
Typically, I'd expect such configuration to be part of the parameters defined by the binding spec.
eg. Intent "xx" is provided by this binding if parameter "foo" is given the value "bar"
The whole question of whether a binding should declare @mayProvide intents at all is a different
question. There seem to be two potential approaches to this. One is to say that the provision of
specific intents is (surprise surprise) a question of Policy - and should be handled through the use
of concrete policySets that can be applied to the binding. The other is to use binding parameters,
as defined by the specification. There are no hard and fast rules here - either is acceptable.
I argue that where a well defined body of Policy exist already, it would be wise to use it. So in the case
of binding.ws, there is the WS-Policy specification and policies that relate to it. However, for other kinds
of binding, policy of this type is not well established in the marketplace and so it may be preferable to
use configuration parameters - this may well be the case with JMS, for example.
So - how to resolve this issue?
At the very least the binding.jms spec needs fixing - possible resolutions:
1) remove the statements about @mayProvide
2) define how the intents mentioned in @mayProvide are actually provided - ie what configuration is
needed in order for the user to get those intents when using the binding.
I think it is also worth the TC thinking about the other binding specs - as to whether they should have any
@mayProvides intents. The answer may be "no" - but it should be a considered "no".
Hope this helps....
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
|From: ||Eric Johnson <firstname.lastname@example.org> |
|To: ||OASIS Bindings <email@example.com> |
|Date: ||08/10/2008 18:41 |
|Subject: ||Re: [sca-bindings] ISSUE-48: How are mayProvide intents on bindings satisfied|
OK, now that I've logged the issue, I'm going to argue for why we
shouldn't open it.
Eric Johnson wrote:
> Logged as: http://www.osoa.org/jira/browse/BINDINGS-48
> ashok malhotra wrote:
>> The SCA Policy spec says that in addition to the intents that a
>> bindingType alwaysProvides
Point #1.1 - The first item in the description flags that other work
might be appropriate for other TCs first.
>> "... The binding type also declares the intents that it may provide by
>> using the optional @mayProvide attribute. Intents listed as the value
>> of this attribute can be provided by a binding instance configured
>> from this binding type."
Point #1.2 - Still seems to be relevant only to the policy specification.
>> My assumption was that, to use some of the mayProvide intents, a
>> binding instance had to be configured outside of SCA and then that
>> instance used for some service/reference. At last week's Policy f2f,
>> it became clear that this assumption was not universally shared. Some
>> thought that the SCA runtime would configure the binding instance
>> during the deployment phase.
Point #2.1 - Looking through the existing specifications, the notion of
a binding "instance" is discussed only in passing for the binding.ws
spec, and not at all in binding.jms or binding.jca. The concerns raised
in the above paragraph don't seem to have much bearing on the binding
specifications that I see.
>> I looked at the binding.ws, the binding.jca and the binding.jms specs
>> and found that, as expected, binding.ws says nothing about mayProvide.
>> Binding.jca does not say anything about mayProvides either.
>> Binding.jms says
>> <bindingType type=”binding.jms”
>> alwaysProvides=”jms” mayProvide=”atLeastOnce atMostOnce ordered
Aha! Finally, something specific to one of the binding specifications.
Perhaps a glimmer of an issue? Except:
Point #3 - As stated the above doesn't actually raise an issue. JMS
spec is clearly different from the other two, but is this one right, and
the others wrong? I'm lacking in specifics to understand. Further, as
issues editor, in I need to know whether this should be raised as one,
two, or three issues, and I still cannot tell.
>> but it does not say how the mayProvides intents are satisfied. That
>> is, it does not say what configuration parameters can used to provide
>> these intents.
>> Thus, two requests
>> - Clarify whether the binding instances configured to provide the
>> capabilities indicated in mayProvides are generated separately,
>> earlier and outside of SCA and then used in the SCDL or whether they
>> are generated by the SCA runtime.
Point #2.2 - Again, the notion of binding "instances" seems to lie
outside of the binding specifications. Bindings specifications at this
point do not talk about "generating" anything for runtime, except the
binding.ws spec, which talks about WSDL.
>> - As far as possible, indicate in the bindings specs which
>> configuration parameters need to be tweaked and how to satisfy the
>> mayProvide intents.
Point #4 - the term "configuration parameters" leaves me completely
muddled - Is this something specified via policy? Does it appear in the
composite file? Is it data that is part of the binding elements?
Further the notion of "tweaking" those "configuration parameters" sounds
interesting, but leaves me completely in the dark as to what you think
might be appropriate.
This issue certainly has piqued my curiosity, and I suspect there is a
very important issue to raise here related to one or more of the binding
specifications, but I still flailing in a fog as to what that specific
consideration might be. I would much prefer to see a new issue filed
that identifies precisely which text in which specification(s) is
problematic, why it is problematic with respect to issues already
resolved in other TCs or the text of the other specifications, and
hopefully even a suggested resolution.
I'm also certainly happy with the notion that this is a topic of
discussion as an agenda item, but that simply isn't the same as an issue
to be raised.
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]