[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fw: [sca-assembly] ISSUE 57: Unresolved bindings on references
For awareness of the TC.
No decision has been made by the Assembly TC on the resolution of this
issue, so there's no action for Policy until it is resolved. This is just
a heads up.
Dave Booz
STSM, SCA and WebSphere Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
----- Forwarded by David Booz/Poughkeepsie/IBM on 03/12/2008 09:14 AM -----
Scott Vorthmann
<scottv@tibco.com
> To
Michael Rowley <mrowley@bea.com>
03/11/2008 11:13 cc
AM "OASIS Assembly"
<sca-assembly@lists.oasis-open.org>
Subject
[sca-assembly] ISSUE 57: Unresolved
bindings on references
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".
>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and 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]