Hi,
More comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, September 22, 2006 12:58 AM
Subject: Re: How can we insert a DataBindingInterceptor for the outbound
wire of a composite-level reference?
3) The JDKWireService will check the existence of the
bindingServiceContract and use it for Service.inboundWire and
Reference.outboundWire. If no bindingServiceContract, then we assume
the bindingServiceContract is the same as the one from
<interface.xxx>.
I thought it would use interface.xxx since the wire services generates
proxies given to SCA clients (e.g. components). The binding service
contract would be used by the target invoker to dispatch an invocation
and hence would have to perform a mapping from the operation specified
by interface.xxx.
You're right too. I think we're on the same page. Here the picture that
matches what I described.
... --- (inbound)--> (interface.contract) Reference ---(outbound)--
> (binding.contract) TargetInvoker
--- (inbound)--> (binding.contract) Service (interface.contract) ---
(outbound)--> ...
Thinking about this more, we may have two ways to do this:
1. For services, we could have something like:
binding receiver (binding.contract) ---> inbound wire
(interface.contract) --->outbound wire (interface.contract)
The inbound wire is used to generate a proxy so has to be
interface.contract. The drawback here is the code that receives an
invocation needs to do the operation mapping.
I prefer not to have the receiver code to deal with the operation mapping.
The databinding framework should be able to handle it.
Can we directly locate a composite service? I had an impression that the
proxy can only be created out of the component.service or
composite.reference as defined by the SCA C&I spec.
CompositeContext.locateService() has the following statement:
T locateService(Class<T> serviceType, String serviceName);
"serviceName" can either be "<component-name>/<service-name>" or
"<reference-name>". Composite service is not a valid target and I got a
confirmation from Jeremy the other day on IRC.
We could also have this:
binding receiver (binding.contract) ---> inbound wire
(binding.contract) --->outbound wire (interface.contract)
We would need the connector to be able to map operations between
different idls, which would be done through Operation.equals() as it
connected the inbound and outbound wires. The one drawback here is what
interface does a generated proxy take?
A DataBindingInterceptor will be added on the inbound wire and it will map
the binding.contract to interface.contract.
A service wired to a target with a different interface would be:
inbound wire (interface.contract) --->outbound wire
(interface.contract) --> inbound wire (target.interface.contract) --
> target invoker (target.interface.contract)
I have this in my mind:
inbound wire (binding.contract) -(i1)-->outbound wire
(interface.contract) --(i2)-> inbound wire (target.interface.contract) -->
target invoker (target.interface.contract)
i1: DataBindingInterceptor1
i2: DataBindingInterceptor2
We can potentially optimize i2 out so that i1 directly convert the data from
binding.contract to target.interface.contract.
2. For references
inbound wire (interface.contract) --->outbound wire
(interface.contract) -->target invoker (binding.contract)
Which would mean the target invoker would have to perform the mapping
(similar to a service receiver)
My version:
inbound wire (interface.contract) ---> outbound wire
(binding.contract) -->target invoker (binding.contract)
Or, the second option would look like:
inbound wire (interface.contract) --->outbound wire
(binding.contract) -->target invoker (binding.contract)
I prefer to have the 2nd.
The connector would be responsible for performing the mapping when it
connects the wires.
What do you think?
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
