OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [sca-bindings] ISSUE-48: How are mayProvide intents on bindingssatisfied

[cc'ing sca-policy]

Here is my take on this whole issue:

SCA allows a bindingType to say which intents are always provided and 
which intents may be provided. The 'alwaysProvides' is easy. All 
bindings of that type automagically satisfy the intents listed under 
'alwaysProvides'. But it is not clear to me how 'mayProvide' works. 
Under what circumstances is an intent listed under mayProvides actually 
provided by the binding? This is important for the SCA policy's 
algorithm for intent/policy matching. The algorithm has to know which 
intents are not satisfied by the binding used so that it will look for 
policy sets that satisfy the as-yet-unsatisfied intents.

One way to look at this is:
Interaction intents apply to wires. Get a union of all the intents 
specified on either end of the wire. Subtract the intents that are 
listed under 'alwaysProvides' as they are satisfied by the binding. Of 
the remaining intents for the wire, look for the ones that are listed 
under 'mayProvides' for that binding type. Since the wire requires those 
intents, assume (or required) that the SCA runtime will enable/provide 
it for that particular wire (and therefore the configured bindings on 
either end of the wire). The remaining intents would now have to be 
satisfied by policy sets.

One problem with the above is: what if enabling the intent in 
mayProvides requires some binding specific configuration. Say the value 
of a timeout, for example. Or what if there is a flag that is required 
to be turned on in the configuration to enable the 'mayProvides' intent, 
per the binding spec? And how would the binding neutral Policy algorithm 
work in such a scenario. I like to think that, if the "right" 
configuration/flag is not present in the SCDL for that binding/wire then 
SCA runtime will throw up an error. But for the policy algorithm, it 
should assume that the intent listed in mayProvides is "enabled" (and 
correctly configured) for a particular binding if the wire using that 
binding requires it.



Eric Johnson wrote:
> 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
>> -Eric.
>> 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
>>> conversational”/>
> 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.
> -Eric.
> ---------------------------------------------------------------------
> 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:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]