Hi,
I have some minor comments below.
Based on the discussions, I think my initial proposal is at least a
short-term fix. If we all agree, I'll go ahead to commit the changes.
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, September 22, 2006 9:43 AM
Subject: Re: How can we insert a DataBindingInterceptor for the outbound
wire of a composite-level reference?
On Sep 22, 2006, at 9:01 AM, Raymond Feng wrote:
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.
Agreed with the caveat that it is the connector that wires the invocation
chains together and does the operation mapping while the data binding
framework handles transformations. In other words, the
operation-to-operation mapping is done by the connector statically.
Agreed. The operation mapping is handled by Connector and data
transformation is done with DataBindingInterceptor between the mappable
source and target operations.
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:
Yes that was the intent (a composite is also a component) but the spec
may have not have reflected that. I'm happy not to allow that but then it
seems strange to specify interface.xxx and binding interface on a
composite service - if it has no representation in the programming model
the idl designation should only be in the binding. The interesting thing
about this is the spec probably needs to be clarified. For example, if I
invoke a composite service, does the invocation go through the binding
stack (that would be messy to do)? Do we only allow invocations of this
sort to bindless composite services?
I was struggling with the similar guess as well. What's the story of how to
invoke a service on a component implemented by a composite (I assume the
composite service is introspected as the service for the component)? The
spec needs to clarify.
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.
A valid *wire* target is a different thing than the above. A composite
service may be a target of a composite reference but not a component.
Did you see Jeremy's point on how the proxy should be created? It's an
interesting view. Does the spec say anything about this?
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.
I don't think the databinding interceptor should do the mapping of the
operation; just the data transformation.
I should say "mediate data".
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.
yep
Great.
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.
ok me too
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]
---------------------------------------------------------------------
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]
