ISSUE 57: Unresolved bindings on references

[Scott Vorthmann <scottv@tibco.com>]

http://www.osoa.org/jira/browse/ASSEMBLY-57

On Mar 11, 2008, at 8:04 AM, Michael Rowley wrote:

>
> RAISER: Michael Rowley (on behalf of the SCA Bindings TC)
>
> TARGET: SCA Assembly Specification, Bindings Section
>
> DESCRIPTION:
>
> The SCA Bindings TC was tasked with clarifying what it means for two  
> bindings to match.  This was due to the fact that SCA’s wire  
> validity rules (which are currently part of the SCA Policy Spec, but  
> should be moved to the Assembly Spec) say that the bindings on the  
> reference and service sides of the wire must “match”.  However, it  
> is not clear what matching should mean.
>
> In exploring the issue further, the Bindings TC discovered that, in  
> practice, it is difficult or impossible to know whether a binding  
> specified on the reference side of a wire can interoperate with a  
> binding specified on the service side of a wire.
>
> Note that having the binding _types_ match is neither a necessary  
> nor a sufficient condition for interoperability:
>
> Not necessary: different bindings can be created which are  
> configured in very different ways, but which can interoperate.   
> Examples of this include:
> - bindings that might be specified for very different Web Service  
> stacks (such as Axis 1, Axis 2, Celtix, Glassfish, etc).  Each would  
> have potentially very different ways of specifying configuration,  
> “handlers”, and other characteristics, but might interoperate under  
> the right circumstances.
> - bindings for Web Services and JMS.  A web service binding could  
> point to a WSDL that has a JMS binding, while a JMS binding could be  
> used to send SOAP messages.  It is possible (and not unlikely) that  
> these two bindings could be used to talk to each other.
> - bindings for RMI and EJB.  EJB does use RMI after all.
>
> Not sufficient: if different binding instances have the same binding  
> type, they do not necessarily interoperate.  Examples include:
> - Binding.ws  If the two sides use different WSDL bindings  
> (referenced through @wsdlElement), they won’t interoperate.
> - Binding.jms.  If one side is configured differently from the  
> other, then they won’t interoperate.  In an extreme example, one  
> side could be configured to use a Queue while the other requires  
> Topic.
>
> After noting that knowing the binding type is neither necessary nor  
> sufficient to determine a match, we examined why bindings would need  
> to be matched.  The need seems to come from the fact that the  
> creator of the reference would like to place some restrictions on  
> the binding technology that will be used.  We saw two subcases of  
> this:
> 1) The person creating the reference wants to restrict the  
> technology used for wiring, since the code that uses the reference  
> depends on some characteristic of that binding technology.
> 2) The person configuring the reference would like to wire it to a  
> specific binding of a service that is offered by some other component.
>
> For case (1), we believe that this should be represented by  
> intents.  That is the best mechanism we have for representing  
> constraints on technology.
>
> For case (2), it would be overkill to require that an intent be used  
> just so that a specific binding could be chosen.  As such, this case  
> should be handled separately in the way that wires are specified  
> (see below).
>
> Thus, we believe that specifying bindings on references for the  
> purpose of constraining technology is the wrong approach, and we  
> should not use an approach that depends on binding matching.
>
>
> PROPOSAL:
>
> In a unanimous roll-call vote (without abstentions) the SCA Bindings  
> TC voted to make the following recommendation to the Assembly TC.
>
> Remove the need for binding matching from any wire validity rules.   
> The following rules should be added to the description of how  
> bindings can be used on references:
>
> If a reference has any bindings they must be “resolved”.  The  
> bindings MUST include a value for the @URI or must otherwise specify  
> an endpoint.  The reference MUST NOT be wired using SCA mechanisms.
> To specify constraints on the kinds of bindings that are acceptable  
> for use with a reference, the user should specify either policy  
> intents or policy sets.
>
> Users may also specifically wire, not just to a component service,  
> but to a specific binding offered by that target service.  To do so,  
> a wire target may optionally be specified with a syntax of  
> "componentName/serviceName/bindingName".
>