tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ignacio Silva-Lepe" <isilval...@gmail.com>
Subject Re: Runtime bring-up and next steps
Date Mon, 12 Feb 2007 21:55:09 GMT
Hi Jim,

More comments/questions inline.

On 2/12/07, Jim Marino <jmarino@myromatours.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message