[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: NEW ISSUE: Unresolved bindings on references
RAISER: 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". |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]