Tuscanys wiring model

[Martin Beck <ma...@hpi.uni-potsdam.de>]

Hi,

I'm currently working on a presentation about tuscany's wiring and 
autowiring concepts for my studies. Up until now, I was staring at the 
java code and some of the javadoc... ;) I identified the mechanisms of 
the Interceptors, MessageHandlers and TargetInvokers, which are used on 
the source and target side of a wire.
However, I still can't get behind the goal of all this stuff. By now, it 
seems to me that the wires are built up by the Runtime once the module 
is loaded and hided from the application developer who just uses 
tuscany. Is this right?
But the usages of interceptors and handlers who come into my mind (e.g. 
logging, filtering, conversation) require access to the internal wire 
model by the application developer, if he for example wants to hook his 
own interceptor into the wirechain. Additionaly, I didn't found many 
classes implementing interceptor and messagehandler interfaces, i.e. 
only only MessageDispatcher extends MessageHandler and therefore I dont 
see something really using the messagechannels. ;)

In http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg04104.html 
I read about the "showcase" features of SCA. I think, features like 
"dynamic re-wiring" would need sophisticated knowledge about tuscanys 
wiring by the application developer as he is the only one, who can 
decide whether to use this feature, didn't it?

So my concrete question is: Why there is such a complex wirechain if it 
is almost not used (by now)? What are your goals with it, if wires are 
managed by the Tuscany Runtime, and not the application developer?

As a last example, I could imagine using the MessageDispatcher to 
broadcast an invocation to more than one components (whyever). But this 
wouldn't be possible according to the spec because a wire is defined as 
the connection between two components.

Greets,
Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Autowire, was: Tuscanys wiring model

[Jeremy Boynes <jb...@apache.org>]

Scott Kurz wrote:
> Jeremy,
> 
> I was wondering if you were going to any detail on Autowire in your
> answer....
> 

Rather than repeat, I hope you won't mind me pointing to an earlier mail:
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg01519.html

> In looking at usages in the code, it seems to simply provide a way to
> inject
> a instance of a system component (one defined in system.module or
> system.fragment) via a setter.
> 

That's really the implemention of this in the "system" programming
model. It should be available in other implementations as well.

It doesn't have to be a setter btw, fields should also work (anything
that can be a reference). I actually think the most useful variant will
be with constructor injection.

> If there are restrictions or any further detail that would be
> interesting at
> a higher, design level I'd be interested in hearing them as well.
> 

The biggest restrictions (in M1 anyway) are that it only works on system
components and only with annotations. Adding it to other implementation
types or support for XML sidefiles would not be too hard if someone was
interested.

We only support matching by service interface. This is fine for how we
are using it with system components but the real potential comes when
you can add non-functional business constraints as well. That would
allow assemblers to provide rules for how their systems should be wired
rather than doing it all explicitly.

Think of it like laying out a circuit board. You can wire power to every
chip on the board (figuring out track width, routing, decoupling etc. by
hand), or you can have each component provide metadata (like "this chip
need 3.3V power at 18mA on pins 18 and 24") and let the layout tool do
all the wiring as you add them to your circuit.

Hope that helps
--
Jeremy

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Tuscanys wiring model

[Scott Kurz <sc...@gmail.com>]

Jeremy,

I was wondering if you were going to any detail on Autowire in your
answer....

In looking at usages in the code, it seems to simply provide a way to inject
a instance of a system component (one defined in system.module or
system.fragment) via a setter.

If there are restrictions or any further detail that would be interesting at
a higher, design level I'd be interested in hearing them as well.

Thanks,
Scott Kurz

On 6/23/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> Martin Beck wrote:
> > Hi,
> >
> > I'm currently working on a presentation about tuscany's wiring and
> > autowiring concepts for my studies. Up until now, I was staring at the
> > java code and some of the javadoc... ;) I identified the mechanisms of
> > the Interceptors, MessageHandlers and TargetInvokers, which are used on
> > the source and target side of a wire.
> > However, I still can't get behind the goal of all this stuff. By now, it
> > seems to me that the wires are built up by the Runtime once the module
> > is loaded and hided from the application developer who just uses
> > tuscany. Is this right?
>
> Yes. The goal is to allow the application developer to write
> implementation code with all the wiring handled by the runtime - this is
> a fairly classic IoC architecture.
>
> Wires are actually built in two phases. In the first phase, the source
> and target side each build up outbound and inbound wires for just their
> part; in the seconds the runtime connects outbound and inbound sides
> together, potentially adding Interceptors and MessageHandlers as part of
> the process.
>
> > But the usages of interceptors and handlers who come into my mind (e.g.
> > logging, filtering, conversation) require access to the internal wire
> > model by the application developer, if he for example wants to hook his
> > own interceptor into the wirechain.
>
> If someone wants to hook directly to the wirechain then yes they will
> need to know the intricacies of with wire model. Although we will allow
> that, the intention is that they would define these things at a higher
> level.
>
> For example, system behaviour like security or transaction would be
> specified in terms of policy declarations in the standard SCA assembly
> model (the is spec activity defining some of this). We would expect a
> developer or application assembler to say something like "I need a
> transaction here" rather than having to deal with interceptors.
>
> For higher level function, we would like to support a set of aspect or
> mediation programming models that could be used to define
> business-oriented things like auditing, filtering, custom routing etc.
> They would write to that programming model and its integration would
> deal with the wiring. Hopefully this would be standardized in the SCA
> spec, but we could also support models from existing implementation such
> as Synapse.
>
> > Additionaly, I didn't found many
> > classes implementing interceptor and messagehandler interfaces, i.e.
> > only only MessageDispatcher extends MessageHandler and therefore I dont
> > see something really using the messagechannels. ;)
> >
>
> Yeah - we started with the intention of supporting policies using this
> mechanism but didn't quite get to it. There is a small example where we
> started to use it in the async support. This should get some more
> attention in the next release.
>
> > In http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg04104.html
> > I read about the "showcase" features of SCA. I think, features like
> > "dynamic re-wiring" would need sophisticated knowledge about tuscanys
> > wiring by the application developer as he is the only one, who can
> > decide whether to use this feature, didn't it?
> >
>
> The intent behind SCA is that this really shouldn't be in the province
> of the application developer but in the hands of the people managing the
> SOA network. The goal is to let the application developer write business
> function without dependencies on infrastructure or wiring - hence the
> IoC nature. Then the people running the network (applications) can
> rewiring using the assembly model or other mechanism without impacting
> the code the developers wrote.
>
> For this to work, we need sophisticated wiring mechanisms to support the
> "white magic." However, the goal is to hide that complexity from the
> users, developers, assemblers, adminsitrators.
>
> > So my concrete question is: Why there is such a complex wirechain if it
> > is almost not used (by now)? What are your goals with it, if wires are
> > managed by the Tuscany Runtime, and not the application developer?
> >
>
> I hope I covered the goals above. For what we're doing now it is perhaps
> overkill but expect it to be used as we add in async, policy, etc.
>
> > As a last example, I could imagine using the MessageDispatcher to
> > broadcast an invocation to more than one components (whyever). But this
> > wouldn't be possible according to the spec because a wire is defined as
> > the connection between two components.
> >
>
> You're right in saying wires connect two components but the spec does
> support the concept of multiplicity at least at the reference level -
> the application is passed a collection of wires and is responsible for
> using them individually. Personally I'd like to see this expanded so
> that concepts like multicast vs. unicast were built into the wiring, or
> so that some form of wire identification was provided (Map rather than
> Collection style behaviour in Java terms).
>
> You've raised a whole bunch of real issues here that would be good to
> capture - would you be able to help us pull them together as scenarios
> on the wiki?
>
> Thanks
> --
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

Re: Tuscanys wiring model

[Jeremy Boynes <jb...@apache.org>]

Martin Beck wrote:
> Hi,
> 
> I'm currently working on a presentation about tuscany's wiring and
> autowiring concepts for my studies. Up until now, I was staring at the
> java code and some of the javadoc... ;) I identified the mechanisms of
> the Interceptors, MessageHandlers and TargetInvokers, which are used on
> the source and target side of a wire.
> However, I still can't get behind the goal of all this stuff. By now, it
> seems to me that the wires are built up by the Runtime once the module
> is loaded and hided from the application developer who just uses
> tuscany. Is this right?

Yes. The goal is to allow the application developer to write
implementation code with all the wiring handled by the runtime - this is
a fairly classic IoC architecture.

Wires are actually built in two phases. In the first phase, the source
and target side each build up outbound and inbound wires for just their
part; in the seconds the runtime connects outbound and inbound sides
together, potentially adding Interceptors and MessageHandlers as part of
the process.

> But the usages of interceptors and handlers who come into my mind (e.g.
> logging, filtering, conversation) require access to the internal wire
> model by the application developer, if he for example wants to hook his
> own interceptor into the wirechain. 

If someone wants to hook directly to the wirechain then yes they will
need to know the intricacies of with wire model. Although we will allow
that, the intention is that they would define these things at a higher
level.

For example, system behaviour like security or transaction would be
specified in terms of policy declarations in the standard SCA assembly
model (the is spec activity defining some of this). We would expect a
developer or application assembler to say something like "I need a
transaction here" rather than having to deal with interceptors.

For higher level function, we would like to support a set of aspect or
mediation programming models that could be used to define
business-oriented things like auditing, filtering, custom routing etc.
They would write to that programming model and its integration would
deal with the wiring. Hopefully this would be standardized in the SCA
spec, but we could also support models from existing implementation such
as Synapse.

> Additionaly, I didn't found many
> classes implementing interceptor and messagehandler interfaces, i.e.
> only only MessageDispatcher extends MessageHandler and therefore I dont
> see something really using the messagechannels. ;)
> 

Yeah - we started with the intention of supporting policies using this
mechanism but didn't quite get to it. There is a small example where we
started to use it in the async support. This should get some more
attention in the next release.

> In http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg04104.html
> I read about the "showcase" features of SCA. I think, features like
> "dynamic re-wiring" would need sophisticated knowledge about tuscanys
> wiring by the application developer as he is the only one, who can
> decide whether to use this feature, didn't it?
> 

The intent behind SCA is that this really shouldn't be in the province
of the application developer but in the hands of the people managing the
SOA network. The goal is to let the application developer write business
function without dependencies on infrastructure or wiring - hence the
IoC nature. Then the people running the network (applications) can
rewiring using the assembly model or other mechanism without impacting
the code the developers wrote.

For this to work, we need sophisticated wiring mechanisms to support the
"white magic." However, the goal is to hide that complexity from the
users, developers, assemblers, adminsitrators.

> So my concrete question is: Why there is such a complex wirechain if it
> is almost not used (by now)? What are your goals with it, if wires are
> managed by the Tuscany Runtime, and not the application developer?
> 

I hope I covered the goals above. For what we're doing now it is perhaps
overkill but expect it to be used as we add in async, policy, etc.

> As a last example, I could imagine using the MessageDispatcher to
> broadcast an invocation to more than one components (whyever). But this
> wouldn't be possible according to the spec because a wire is defined as
> the connection between two components.
> 

You're right in saying wires connect two components but the spec does
support the concept of multiplicity at least at the reference level -
the application is passed a collection of wires and is responsible for
using them individually. Personally I'd like to see this expanded so
that concepts like multicast vs. unicast were built into the wiring, or
so that some form of wire identification was provided (Map rather than
Collection style behaviour in Java terms).

You've raised a whole bunch of real issues here that would be good to
capture - would you be able to help us pull them together as scenarios
on the wiki?

Thanks
--
Jeremy

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org