NEW ISSUE: Unresolved bindings on references

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".

sca-assembly message