Hi Jim,
More comments/questions inline.
On 2/12/07, Jim Marino <[EMAIL PROTECTED]> wrote:
Hi Ignacio,
Comments inline.
Jim
>> - I would like to eliminate the need for outbound and inbound wires,
>> having the connector create a single Wire which is attached to a
>> source. In this scenario, targets will not have wires but will
>> continue to supply TargetInvokers to sources. This will tie in
>> directly with Meeraj's work on the physical component builders and
>> wire reconstitution on slaves. It will also further serve to simplify
>> the connect phase. As we do this, we will need to revisit the SPI for
>> WirePostProcessors. Following on Meeraj's physical builder work,
>> policy and wire processing will need to be done on the master against
>> the model and a portable representation of the wire sent to slaves
>> where it will be constituted. We will need something akin to an
>> InterceptorBuilder which will be responsible for helping to
>> constitute a wire on the slave by supplying interceptors. Thoughts?
>
>
> Not sure what the intended approach is here. I would think that
> inbound
> chains for targets would still be needed, where would those live
> now, in
> the single wire at the source?
I see two cases, managed and non-managed code. In the former, where
the source is a component, there would be one set of chains (no
distinction between inbound and outbound) attached to the source
component. For non-managed code, it would be pretty much the same
thing with the chains held in the proxy or CallableReference.
Apologies if this has been explained previously and is now common
knowledge (if so, could you point me at the explanation?).
So is the idea that each chain has interceptors (say, databinding and
security) that are used for both incoming and outgoing messages? Is
there going to be a way to indicate to an interceptor which way is in
effect? And would there be a way to indicate the order in each
direction? Maybe making the chain a doubly-linked list?
This should simplify the connector a bit more and allow us to fit in
with the master allocation process described by Meeraj. For example,
a WireDefinition will be marshalled to a slave node where it will be
reconstituted.
> Would that also preserve the bridging
> interceptors at the source wire?
We would just need the non-blocking variant. There would be no need
for the synchronous form. If a wire changes, the assembly will be
mutated on the master and a diff (probably of just the wire) sent to
the slave.
> Perhaps I am not understanding, but at some point we used to have a
> similar approach where (at least some of) the chains were co-located
> in a single wire, but that had to be undone to allow multiple sets of
> callback source chains at an inbound wire. Could you elaborate on
> how this would work with a single wire?
I think I'm proposing something different to what we had before,
essentially collapsing the distinction between inbound and outbound
wires. For example, what we currently have is:
A --------------\
|-----------------C
B --------------/
I'm proposing we do the following:
A ---------------
C
B ---------------
In the approach connections would be:
1. Between components
2. From a transport to a component
3. From a component to a transport
4. From a transport to a transport
When you say transport, do you mean a composite reference and/or
service implementation for a given binding?
Even with a single hop, a callback invocation handler at C would still
need to be able to choose between A and B depending on where the
forward call came from. How do you see it referring to the correspon-
ding wire when it needs to make the callback?
We won't need to have multiple hop wires with the "local" binding
anymore (e.g. component-->reference-->service-->component) since they
can be optimized as point-to-point communications (e.g. component--
>component) on the master. The connector would be responsible for
just creating wires, populating it with interceptors, and obtaining a
target invoker from the target.
Callback wires would just be associated on the source side and set as
context as it is today.
Jim
This is not that much different from what we have today in that we
are collapsing OutboundWire and InboundWire. Callback
>
> - Integrate the autowire changes with Meeraj's federation work which
>> will give us support for federated/distributed autowire across an SCA
>> Domain (as well as supporting more of the SCA autowire semantics).
>>
>> 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]
