You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by James Strachan <ja...@gmail.com> on 2005/12/13 15:53:11 UTC
[spec] @Reference versus @Property
BTW I really like the SCA specification, though coming from a POJO /
Spring background the distinction between @Reference and @Property
seems a little surprising at first - I just wanted to describe my
initial confusion and see if I'm on the right track to their intended
differences and how they should be used.
Can you use @Property for services and @Reference for configuration
values?
=============================================================
The specification seems to imply @Property is used to mark "a
configuration property value" and @Reference is used to inject "a
service that resolves the reference". For the moment lets ignore the
difference between property injection by value versus by reference
(we'll come on to that in a moment).
What is the real difference, from the perspective of an application
programmer - between a service and a configuration property? It seems
a fairly vague distinction - are there some rules the application
developer can know when writing a POJO on what the difference between
the two are. e.g. a JMS ConnectionFactory and a JDBC DataSource are
probably configuration properties right?.
Is a "service" in this case something which is @Remotable or has
@Service? If either of those two are the case then can't the runtime
figure out the difference based on the type without the application
developer having to keep services & non-services in sync? Is the
difference between the two really just that of by-value rather than
by-reference configuration (and I was reading too much into the
description of the annotations)?
e.g. in Spring we can configure a service by name and inject it into
a beans property whether it has no annotation, @Property or
@Reference; so I'm wondering if the distinction between @Property and
@Reference makes sense WRT configuration property value versus
service - other than @Reference acts as a hint to the runtime to
auto-wire the property value by using a named reference.
So I guess I'm wondering; what is a service in this context and can
@Reference be used for non-services (like JDBC connections and other
properties you may wish to configure by-reference rather than by
value). I wonder if Im just being picky and @Reference is usually
used for configure-by-reference properties which usually are
services, but could in fact be any property?
IoC of values versus references
========================
In IoC containers like Spring there is no difference between
configuration by value or by reference at the POJO level; a POJO just
has bean properties (which may or may not be annotated by @Property);
the 'reference' only really exists in the XML configuration file.
e.g. in Spring we'd do
<bean id="myBean" class="Foo">
<!-- regular property injection -->
<property name="foo" value="1234"/>
<!-- named reference injection of a property -->
<property name="bar" ref="someName"/>
</bean>
In this case it is the author of the XML config file who decides
which properties are configured by value or by reference.
So at first it seems a little surprising as to why a POJO needs to
understand whether a property is set via direct property
configuration (@Property) or via looking up some named reference
(@Reference). It kinda feels wrong to make the POJO developer choose
how its going to be configured - especially when one of SCA's goals
is to hide middleware (which includes configuration).
I guess one effect of @Reference is that the container can
automatically inject the named POJO without it explicitly being
configured in some XML file. Maybe - considering Spring for a moment
here - if we don't explicitly configure a property then the runtime
would automatically inject it for us.
e.g.
public class Foo {
@Reference(name="myBar")
private Something bar;
...
}
the container would know how to inject the "bar" property by looking
up myBar - so in Spring we could just do...
<bean id="myBean" class="Foo">
<!-- runtime automatically injects "bar" property -->
</bean>
Though I guess there's nothing to stop someone reusing Foo and
explicitly configuring it in some runtime if they really want to...
<bean id="myBean" class="Foo">
<!-- lets override the name used... ->
<property name="bar" ref="aDifferentBar"/>
</bean>
Required defaults for @Reference and @Property
========================================
Since that @Reference & @Property are both optional; my main use case
for using @Property would be to mark mandatory properties (as
properties with no @Property annotation can still be injected). So
why not make @Property required default to true like it is for
@Reference? Then the default use of @Property adds some value -
denoting mandatory properties - without having to specify
(required=true)?
e.g.
public class Cheese {
public void setFoo(Something) {}
@Property
public void setBar(Something) {}
}
so that "foo" is optional and "bar" mandatory?
Then we'd have a little less clutter in our POJOs.
James
-------
http://radio.weblogs.com/0112098/
Re: [spec] @Reference versus @Property
Posted by Jim Marino <jm...@myroma.net>.
I just thought about something else - we may be able to infer
@Reference semantics if a reference is decorated with a policy or
QoS. For example, if I have the following:
@SomePolicy
Foo fooReference
The runtime should be smart enough to infer that 'fooReference' can
only be a "reference" in SCDL (the configuration artifact) and not a
"property" since it is decorated with a policy. Then, we are left
with the distinction between @Property and @Reference being useful
only in cases where there is a distinction between attributes that
can be set on the annotations.
Jim
On Dec 13, 2005, at 8:46 AM, Jim Marino wrote:
> Thanks for the feedback James! Some comments inline...
>
> On Dec 13, 2005, at 6:53 AM, James Strachan wrote:
>
>
>> BTW I really like the SCA specification, though coming from a
>> POJO / Spring background the distinction between @Reference and
>> @Property seems a little surprising at first - I just wanted to
>> describe my initial confusion and see if I'm on the right track to
>> their intended differences and how they should be used.
>>
>>
>> Can you use @Property for services and @Reference for
>> configuration values?
>> =============================================================
>>
>> The specification seems to imply @Property is used to mark "a
>> configuration property value" and @Reference is used to inject "a
>> service that resolves the reference". For the moment lets ignore
>> the difference between property injection by value versus by
>> reference (we'll come on to that in a moment).
>>
>> What is the real difference, from the perspective of an
>> application programmer - between a service and a configuration
>> property? It seems a fairly vague distinction - are there some
>> rules the application developer can know when writing a POJO on
>> what the difference between the two are. e.g. a JMS
>> ConnectionFactory and a JDBC DataSource are probably
>> configuration properties right?.
>>
>>
> A service offers behavior and the reference may be decorated with
> QoS. A property is just a data value that does not offer
> fundamental behavior (of course a pojo data value could have some
> logic on it, but generally those are component implementation types)
>
> The reason why we put this distinction into the spec (at one point
> we had them collapsed) was the ability to specify QoS on references
> as opposed to properties. If people think the distinction is more
> problematic than useful then we should definitely look at removing
> it. For example, one thing the distinction buys people is the
> ability to specify attributes specific to references, such as the
> potential autowire capability (see below). That may not be
> compelling enough. Do others have opinions here?
>
> I do, however, like the distinction in SCDL for <references> and
> <properties>. We still need to distinguish between a component name
> in a reference and a string data value and that seems like a nice
> way to do it (it also groups stuff nicely). What do you think?
>
>
>> Is a "service" in this case something which is @Remotable or has
>> @Service? If either of those two are the case then can't the
>> runtime figure out the difference based on the type without the
>> application developer having to keep services & non-services in
>> sync? Is the difference between the two really just that of by-
>> value rather than by-reference configuration (and I was reading
>> too much into the description of the annotations)?
>>
> @Remotable is used to define remotable services - the default, when
> no annotation is specified is local. @Service is optionally used to
> define the business interface of a local service in cases where it
> needs to be specified (i.e. the type may implement additional
> interfaces which are not business interfaces that should be exposed
> as a reference). References can be local or remote, so they can
> follow by-value or by-ref semantics. I may be missing something
> here since it is early so let me know.
>
>>
>> e.g. in Spring we can configure a service by name and inject it
>> into a beans property whether it has no annotation, @Property or
>> @Reference; so I'm wondering if the distinction between @Property
>> and @Reference makes sense WRT configuration property value versus
>> service - other than @Reference acts as a hint to the runtime to
>> auto-wire the property value by using a named reference.
>>
>>
> In SCA these annotations are also optional so if the implementation
> does not want to be aware of the distinction, it does not need to
> be as long as it does not have to specify a mandatory property or
> reference.
>
> We are also looking to potentially add autowire capability (we may
> need it for the Tuscany runtime for "recursive injection" where
> module components or "aggregates" are assembled as pojos, which in
> turn contain other components, etc. In this case we want to wire
> things like a data binding component to a module component and do
> it by saying something to the effect of "for this type of component
> - a module component pojo - inject a component that implements this
> interface". This will allow us to use SCA to "assemble" the runtime.
>
> Related to this, we have been discussing the usefulness of
> autowiring in general. A couple of very sketchy ideas we need to
> flush out are:
>
> - The ability to specify autowire in the component type reference
> such as "wire a component the implements the interface specified by
> the reference or implements the interface specified by the
> reference and has the same name as the reference"
>
> - The possibility of creating a way to describe auto-wiring, a type
> of "pointcut" expression language
>
>
>> So I guess I'm wondering; what is a service in this context and
>> can @Reference be used for non-services (like JDBC connections and
>> other properties you may wish to configure by-reference rather
>> than by value). I wonder if Im just being picky and @Reference is
>> usually used for configure-by-reference properties which usually
>> are services, but could in fact be any property?
>>
>>
>>
> I think one of the things to keep in mind is @Reference can be by-
> ref as well (when you mean by ref or by val are you talking about
> parameter passing?). I would view things like DataSources as local
> (i.e. by ref) services that happen to be provided by the runtime as
> opposed to properties (basically "data" used for configuration that
> does not offer behavior).
>
>
>> IoC of values versus references
>> ========================
>> In IoC containers like Spring there is no difference between
>> configuration by value or by reference at the POJO level; a POJO
>> just has bean properties (which may or may not be annotated by
>> @Property); the 'reference' only really exists in the XML
>> configuration file.
>>
>> e.g. in Spring we'd do
>>
>> <bean id="myBean" class="Foo">
>> <!-- regular property injection -->
>> <property name="foo" value="1234"/>
>>
>> <!-- named reference injection of a property -->
>> <property name="bar" ref="someName"/>
>> </bean>
>>
>> In this case it is the author of the XML config file who decides
>> which properties are configured by value or by reference.
>>
>
> Assuming by value or by reference refers to parameter passing, we
> (the spec people) thought this needed to be decided by the
> developer (code has to behave if it is by reference capable), and
> hence should be specified on the component type. If you mean the
> other case, i.e. the distinction between references and properties,
> perhaps the implementation should not specify that (only the
> configuration artifact would) which has the downside of not being
> able to specify attributes specific to a reference in the
> implementation. I think we should seriously consider merging the
> two. Dave Booz had some use cases for this distinction so I will
> follow-up with him and see if he can post them to the list.
>
>
>> So at first it seems a little surprising as to why a POJO needs to
>> understand whether a property is set via direct property
>> configuration (@Property) or via looking up some named reference
>> (@Reference). It kinda feels wrong to make the POJO developer
>> choose how its going to be configured - especially when one of
>> SCA's goals is to hide middleware (which includes configuration).
>>
>> I guess one effect of @Reference is that the container can
>> automatically inject the named POJO without it explicitly being
>> configured in some XML file. Maybe - considering Spring for a
>> moment here - if we don't explicitly configure a property then the
>> runtime would automatically inject it for us.
>>
>> e.g.
>>
>> public class Foo {
>> @Reference(name="myBar")
>> private Something bar;
>> ...
>> }
>>
>> the container would know how to inject the "bar" property by
>> looking up myBar - so in Spring we could just do...
>>
>> <bean id="myBean" class="Foo">
>> <!-- runtime automatically injects "bar" property -->
>> </bean>
>>
>>
>> Though I guess there's nothing to stop someone reusing Foo and
>> explicitly configuring it in some runtime if they really want to...
>>
>> <bean id="myBean" class="Foo">
>> <!-- lets override the name used... ->
>> <property name="bar" ref="aDifferentBar"/>
>> </bean>
>>
>>
>>
> I think autowire is useful in basic cases like this. We should
> bring it up with the spec group.
>
>
>>
>> Required defaults for @Reference and @Property
>> ========================================
>> Since that @Reference & @Property are both optional; my main use
>> case for using @Property would be to mark mandatory properties (as
>> properties with no @Property annotation can still be injected). So
>> why not make @Property required default to true like it is for
>> @Reference? Then the default use of @Property adds some value -
>> denoting mandatory properties - without having to specify
>> (required=true)?
>>
>>
> Yes this is a good point.
>
>> e.g.
>>
>> public class Cheese {
>>
>> public void setFoo(Something) {}
>>
>> @Property
>> public void setBar(Something) {}
>> }
>>
>> so that "foo" is optional and "bar" mandatory?
>>
>> Then we'd have a little less clutter in our POJOs.
>>
> Less clutter is always good :)
>
>>
>> James
>> -------
>> http://radio.weblogs.com/0112098/
>>
>
Re: [spec] @Reference versus @Property
Posted by Mike Edwards <mi...@gmail.com>.
James Strachan wrote:
>
...snip....
>> We should bring it up with the spec group.
>
>
> Just out of interest; is the spec group a private separate mail list?
> It might be worth using a tuscany mail list for public discussions of
> the spec. I guess we could just reuse the dev list and use a [spec]
> prefix on subjects so folks can filter them out if they like.
>
> James
> -------
> http://radio.weblogs.com/0112098/
The spec group is in the process of setting up its infrastructure too,
just like the Tuscany project. There will be a public site for its work
separate from Tuscany, but there are (unfortunately) a few legal hurdles
to worry about, just like there are for contributing to an Apache
project. The SCA spec is provided in a Royalty-Free form and the legal
hassles relate to the need to preserve that - basically, we have to
ensure than any contributions to the spec are given royalty free too.
I expect that it may take until early in the new year before all the
infrastructure is in place for the spec work, but the spec team is
certainly looking for community input to the spec - and for feedback
from the folk working on and using Tuscany.
Thanks for your interest and for your comments so far!
Yours, Mike.
IBM, SCA Spec Team.
Re: [spec] @Reference versus @Property
Posted by David Booz <sc...@gmail.com>.
This is a good discussion, and it's getting long.
I added comments inline...and snipped some text to
narrow the discussion. I hope this helps.
On 12/13/05, James Strachan <ja...@gmail.com> wrote:
> On 13 Dec 2005, at 16:46, Jim Marino wrote:
> > Thanks for the feedback James! Some comments inline...
> >
> > On Dec 13, 2005, at 6:53 AM, James Strachan wrote:
> >
> >> BTW I really like the SCA specification, though coming from a
> >> POJO / Spring background the distinction between @Reference and
> >> @Property seems a little surprising at first - I just wanted to
> >> describe my initial confusion and see if I'm on the right track to
> >> their intended differences and how they should be used.
> >>
> >>
> >> Can you use @Property for services and @Reference for
> >> configuration values?
> >> =============================================================
> >>
> >> The specification seems to imply @Property is used to mark "a
> >> configuration property value" and @Reference is used to inject "a
> >> service that resolves the reference". For the moment lets ignore
> >> the difference between property injection by value versus by
> >> reference (we'll come on to that in a moment).
> >>
> >> What is the real difference, from the perspective of an
> >> application programmer - between a service and a configuration
> >> property? It seems a fairly vague distinction - are there some
> >> rules the application developer can know when writing a POJO on
> >> what the difference between the two are. e.g. a JMS
> >> ConnectionFactory and a JDBC DataSource are probably
> >> configuration properties right?.
> >>
> > A service offers behavior and the reference may be decorated with
> > QoS. A property is just a data value that does not offer
> > fundamental behavior (of course a pojo data value could have some
> > logic on it, but generally those are component implementation types)
>
> So a component property value is really just a primitive type then?
> Or maybe something that can be coerced to/from a String? :). FWIW the
> latter is the definition Spring uses - it uses the Java Beans
> PropertyEditor to see if values can be read/written as strings.
As Jim stated, we did debate this point quite a bit. The conclusion we came
to is probably better stated as follows: it's a service if there is some QoS
that
needs to be expressed in the wiring between the client of the service and
service itself, or if it has some reusable, consummable, discrete behavior
(in the days
before OO, it's a function or subroutine) that fits the definition of a SOA
service.
Everything else can be a property. So yes, there can be ambiguity,
especially when you
drill down into service construction and start considering local services.
We definitely
need to crisp up the normative language in the spec. However, I am still
convinced that
in the context of coarse grained SOA services, there is an important
distinction between
properties and services. Services represent as behaviors in the system that
a business
analyst would understand, submit order, query inventory, etc. The ability
to condition these
business functions is the role of a property.
> > The reason why we put this distinction into the spec (at one point
> > we had them collapsed) was the ability to specify QoS on references
> > as opposed to properties. If people think the distinction is more
> > problematic than useful then we should definitely look at removing
> > it. For example, one thing the distinction buys people is the
> > ability to specify attributes specific to references, such as the
> > potential autowire capability (see below). That may not be
> > compelling enough. Do others have opinions here?
> >
> > I do, however, like the distinction in SCDL for <references> and
> > <properties>. We still need to distinguish between a component name
> > in a reference and a string data value and that seems like a nice
> > way to do it (it also groups stuff nicely). What do you think?
>
> It does feel a little like different concepts are kinda being
> overloaded. How properties are configured (looking values up by name
> or not) seems to be quite separate to creating possibly remote
> references to services which may have additional QoS.
>
> In Spring worlds I see folks inject by value and by reference both
> for primitive values and for services - they are both very useful.
>
> e.g. I'm using DataSource here as a service; but its equally
> interchangable for primitive values too...
>
> <!-- by value -->
> <bean id="foo" class="SomeService">
> <property name="dataSource">
> <!-- lets inject by value creating a new
> implementation -->
> <bean class="com.acme.MyDataSource">
> <property uri="someuri"/>
> </bean>
> </bean>
> </bean>
>
> <!-- by reference (name) -->
> <bean id="bar" class="SomeService">
> <!-- the use of the @Reference could make this line
> unnecessary -->
> <property name="dataSource" ref="myDataSource"/>
> </bean>
>
>
> <!-- by reference (name) where the name comes from the @Reference
> annotation -->
> <bean id="another" class="SomeService">
> </bean>
>
> So am wondering if injection by value or by reference should be a
> different concept to a 'possibly remote service reference with some
> QoS'.
Applying the by-value/by-reference concept to defining the difference
between
services and properties is intriguing, but I'm not sure I understand
completely.
Is the difference in the way that the runtime creates or reuses a Java
object
when injecting onto a property? In my mental model, there's no such thing
as
a service that's injected by-value. As I said above, a service is just a
software function.
<snip>
--
Dave Booz
IBM, SCA Architecture
scabooz@gmail.com
Re: [spec] @Reference versus @Property
Posted by Jim Marino <jm...@myroma.net>.
On Dec 13, 2005, at 9:58 AM, James Strachan wrote:
> On 13 Dec 2005, at 16:46, Jim Marino wrote:
>
>> Thanks for the feedback James! Some comments inline...
>>
>> On Dec 13, 2005, at 6:53 AM, James Strachan wrote:
>>
>>
>>> BTW I really like the SCA specification, though coming from a
>>> POJO / Spring background the distinction between @Reference and
>>> @Property seems a little surprising at first - I just wanted to
>>> describe my initial confusion and see if I'm on the right track
>>> to their intended differences and how they should be used.
>>>
>>>
>>> Can you use @Property for services and @Reference for
>>> configuration values?
>>> =============================================================
>>>
>>> The specification seems to imply @Property is used to mark "a
>>> configuration property value" and @Reference is used to inject "a
>>> service that resolves the reference". For the moment lets ignore
>>> the difference between property injection by value versus by
>>> reference (we'll come on to that in a moment).
>>>
>>> What is the real difference, from the perspective of an
>>> application programmer - between a service and a configuration
>>> property? It seems a fairly vague distinction - are there some
>>> rules the application developer can know when writing a POJO on
>>> what the difference between the two are. e.g. a JMS
>>> ConnectionFactory and a JDBC DataSource are probably
>>> configuration properties right?.
>>>
>>>
>> A service offers behavior and the reference may be decorated with
>> QoS. A property is just a data value that does not offer
>> fundamental behavior (of course a pojo data value could have some
>> logic on it, but generally those are component implementation types)
>>
>
> So a component property value is really just a primitive type then?
> Or maybe something that can be coerced to/from a String? :). FWIW
> the latter is the definition Spring uses - it uses the Java Beans
> PropertyEditor to see if values can be read/written as strings.
>
>
Right now, a property value is anything that can be represented by
the runtime's data binding mechanism, in the case of Tuscany's
default, as an SDO type. So, I could have complex data value types as
well, as long as they can be described by SDO. I would personally
like to expand the definition or change SDO. For example, currently
Maps and POJOs are not supported by SDO (in terms of the latter only
POJIs are). I think it is valuable to be able to use collections or
POJOs for typed configuration. I'd like to see if the SDO spec could
change to allow these use cases. An alternative approach is to plug
in another data binding technology to do it in Tuscany (e.g. hand
rolled STaX parser, XStream, etc.) with the limitations such an
approach would imply. Hopefully we can support both approaches.
>
>> The reason why we put this distinction into the spec (at one point
>> we had them collapsed) was the ability to specify QoS on
>> references as opposed to properties. If people think the
>> distinction is more problematic than useful then we should
>> definitely look at removing it. For example, one thing the
>> distinction buys people is the ability to specify attributes
>> specific to references, such as the potential autowire capability
>> (see below). That may not be compelling enough. Do others have
>> opinions here?
>>
>> I do, however, like the distinction in SCDL for <references> and
>> <properties>. We still need to distinguish between a component
>> name in a reference and a string data value and that seems like a
>> nice way to do it (it also groups stuff nicely). What do you think?
>>
>
> It does feel a little like different concepts are kinda being
> overloaded. How properties are configured (looking values up by
> name or not) seems to be quite separate to creating possibly remote
> references to services which may have additional QoS.
>
> In Spring worlds I see folks inject by value and by reference both
> for primitive values and for services - they are both very useful.
>
> e.g. I'm using DataSource here as a service; but its equally
> interchangable for primitive values too...
>
> <!-- by value -->
> <bean id="foo" class="SomeService">
> <property name="dataSource">
> <!-- lets inject by value creating a new
> implementation -->
> <bean class="com.acme.MyDataSource">
> <property uri="someuri"/>
> </bean>
> </bean>
> </bean>
>
> <!-- by reference (name) -->
> <bean id="bar" class="SomeService">
> <!-- the use of the @Reference could make this line
> unnecessary -->
> <property name="dataSource" ref="myDataSource"/>
> </bean>
>
>
> <!-- by reference (name) where the name comes from the @Reference
> annotation -->
> <bean id="another" class="SomeService">
> </bean>
>
> So am wondering if injection by value or by reference should be a
> different concept to a 'possibly remote service reference with some
> QoS'.
>
I think the problem may be in the wording of the spec. A reference on
a component type is an unbound dependency on a service that
implements a certain contract. A "reference value" binds a reference
to a service offered by a particular component. The "reference name"
is the name used by the component implementation type to refer to the
reference - it's not the name of the service the reference is bound
to (which would in my opinion be a really bad thing to burn in). It
may be easier to explain in code:
public class SomeClientImpl{
@Reference(name="foo")
private FooType mFoo;
}
SCDL:
<component name="MyClient">
<implementation.java class="...SomeClient"/>
<references>
<foo>MyFooTypeProvider</foo>
</references>
</component>
<component name="MyFooTypeProvider>
<!-- ... -->
</component>
In this case, the "reference name" is a layer of indirection used to
refer to the mFoo field; I could have just left it out, in which case
the SCDL would be:
<component name="MyClient">
<implementation.java class="...SomeClient"/>
<references>
<mFoo>MyFooTypeProvider</mFoo>
</references>
</component>
Ditto for properties
>
>
>
>>> Is a "service" in this case something which is @Remotable or has
>>> @Service? If either of those two are the case then can't the
>>> runtime figure out the difference based on the type without the
>>> application developer having to keep services & non-services in
>>> sync? Is the difference between the two really just that of by-
>>> value rather than by-reference configuration (and I was reading
>>> too much into the description of the annotations)?
>>>
>> @Remotable is used to define remotable services - the default,
>> when no annotation is specified is local. @Service is optionally
>> used to define the business interface of a local service in cases
>> where it needs to be specified (i.e. the type may implement
>> additional interfaces which are not business interfaces that
>> should be exposed as a reference). References can be local or
>> remote, so they can follow by-value or by-ref semantics. I may be
>> missing something here since it is early so let me know.
>>
>
> I guess we're talking about two different things. Spring has a by-
> value and by-reference configuration mechanism as I've shown above;
> I'm kinda using this mental model (which I'm sure many Java
> developers these days share) - and was getting confused over the
> wording of the SCA spec which is why its confusing for me when you
> talk about by-value or by-ref semantics of @Reference.
>
Yea some of the wording is confusing. We need to clean it up. Spring
by-value == SCA properties; Spring by-reference == SCA references.
Then there is by-ref/by-val parameter semantics for references.
> The use of @Reference implies that the runtime will use the name
> you supply (or the property name if not) and look the service up by
> name - the name of the @Reference is the name of the service to
> inject. The value of this service is then injected into the
> property/field - but to me its still injection by reference, since
> you are using a name as an indirection.
Agreed. The name isn't intended to be the name of the configured
artifact - that would basically defeat the purpose of DI. For
autowiring I can see this as somewhat useful though.
> When injecting by value in Spring there is no name - so there is no
> worry that your 'dataSource' property name on service A might
> accidentally use the same 'dataSource' service of another component
> etc. So the by-value or by-reference distinction is quite handy.
>
> Having said that; the @Property also has a name, so I guess
> @Property is injection could be by reference as well :). With my
> Spring-head on I'd kinda assumed the @Property.name was just used
> to rename the field/property in XML land;
Yes, likewise for references
> not to do a reference look up in some context. So (in a Spring
> sense) are both @Property and @Reference by reference (they look up
> the names in a context)?
>
>
> I guess I'm really just highlighting where there is a conceptual
> clash with the POJO/Spring mental model and just wanted
> clarification. It might be useful to map the SCA annotations to how
> you may configure the POJOs in Spring (without any of the remoting
> stuff to start with) and understand how the annotations map to a
> Spring world to avoid confusion. e.g. a wiki page some place on
> 'what SCA annotations mean in a Spring container' or something.
I believe it should map cleanly in most cases. Ideally, we'd like to
merge the two configuration styles (perhaps with Spring's new schema-
based format). When we get the infrastructure up I can take a shot
at that.
> It would be good if Tuscany could sit on top of Spring as one
> possible Dependency Injection container without folks getting
> horribly confused with properties, references, services and by-
> value and by-reference.
>
That's the plan. I see a couple of interesting integration points.
One is to use Spring to do injection within a module. So basically,
there is a Spring module component POJO that wraps an
ApplicationContext. This pojo is injected by the Tuscany runtime with
whatever it needs, perhaps remote references, infrastructure
services, etc. and it is then responsible for kicking off the Sping
application context load. In addition, this context would also have a
hierarchical BeanContext which could reach back out into the SCA
runtime to wire SCA references expressed in Spring configuration
files (in this case the programming model would be "pure" Spring"
inside the module).
Another interesting integration point would be through the invocation
framework. For example, it should be possible to use Spring AOP
addvices as part of an invocation in the runtime.
> i.e. there's a bunch of annotations which seem mostly to be to do
> with Dependency Injection and lifecycle (@Init, @Destroy,
> @Property, @Reference, @ComponentName) - it'd be interesting to see
> how they could map to Spring. As an experiment I hacked up a Spring
> PostProcessor to deal with most of the dependency injection
> annotations in SCA...
>
> http://svn.xbean.org/trunk/sca/src/main/java/org/xbean/sca/
> ScaBeanPostProcessor.java?rev=174&view=auto
Great - i'll take a look.
>
> I'm keen to ensure that POJOs can work well in both environments.
> Of course we could just completely ignore all the SCA annotations
> when deploying a POJO inside Spring but I think it'd be good Io
> encourage them to be reused in both SCA and pure Spring runtimes
> when they make sense (then many more folks might use them all the
> time, whether services are local or remote).
>
Yes, agreed. One of the goals is to try to merge these common things
with what Spring is doing so we standardize on a set of common
annotations and perhaps configuration.
>
>
>>> e.g. in Spring we can configure a service by name and inject it
>>> into a beans property whether it has no annotation, @Property or
>>> @Reference; so I'm wondering if the distinction between @Property
>>> and @Reference makes sense WRT configuration property value
>>> versus service - other than @Reference acts as a hint to the
>>> runtime to auto-wire the property value by using a named reference.
>>>
>>>
>> In SCA these annotations are also optional so if the
>> implementation does not want to be aware of the distinction, it
>> does not need to be as long as it does not have to specify a
>> mandatory property or reference.
>>
>> We are also looking to potentially add autowire capability (we may
>> need it for the Tuscany runtime for "recursive injection" where
>> module components or "aggregates" are assembled as pojos, which in
>> turn contain other components, etc. In this case we want to wire
>> things like a data binding component to a module component and do
>> it by saying something to the effect of "for this type of
>> component - a module component pojo - inject a component that
>> implements this interface". This will allow us to use SCA to
>> "assemble" the runtime.
>>
>> Related to this, we have been discussing the usefulness of
>> autowiring in general. A couple of very sketchy ideas we need to
>> flush out are:
>>
>> - The ability to specify autowire in the component type reference
>> such as "wire a component the implements the interface specified
>> by the reference or implements the interface specified by the
>> reference and has the same name as the reference"
>>
>
> I've gotta say I'm a little uneasy at putting too much of this
> configuration into the annotations - unless its just a hint to the
> runtime - as its class level, not instance level configuration.
> e.g. I may want to auto-wire 1 set of POJOs of service in one XML
> config, but in the same JVM configure it quite differently (I may
> use the same service class with 2 different database connections or
> 2 different back end services for different customer groups).
>
Yes, I strongly agree. I don't think component names have any place
in annotations unless perhaps in a very simple auto wire case (in
which case it is inferred from the field or setter name). We may not
even want that (i.e. autowire can only be done by interface type or
through some kind of expression language). I've seen other component
models floating around that do this and I think it defeats the
purpose of DI and re-use.
> There's an interesting blog entry which describes one solution
> using Spring and describes how its not necessarily ideal...
> http://www.jroller.com/page/habuma/20051206
>
Thanks for the link - I'll take a look.
>
>
>
>> - The possibility of creating a way to describe auto-wiring, a
>> type of "pointcut" expression language
>>
>
> Yeah - the stuff in Spring 2.0-M1 is well worth a look to see how
> the AOP BeanConfigurer works. I like being able to use annotations
> to create pointcuts in XML-land to configure things.
>
>
>> I would view things like DataSources as local (i.e. by ref)
>> services that happen to be provided by the runtime as opposed to
>> properties (basically "data" used for configuration that does not
>> offer behavior).
>>
>
> Yeah - see my first part of the response in this mail - spring
> developers use both kinds of injection for things like DataSources.
> References tend to be used when you have many services sharing the
> same thing - there's nothing particularly special about the types
> involved & its typically outside of the POJO - the XML file - which
> decides if its good to use a reference or not.
>
>
>
>
>>> So at first it seems a little surprising as to why a POJO needs
>>> to understand whether a property is set via direct property
>>> configuration (@Property) or via looking up some named reference
>>> (@Reference). It kinda feels wrong to make the POJO developer
>>> choose how its going to be configured - especially when one of
>>> SCA's goals is to hide middleware (which includes configuration).
>>>
>>> I guess one effect of @Reference is that the container can
>>> automatically inject the named POJO without it explicitly being
>>> configured in some XML file. Maybe - considering Spring for a
>>> moment here - if we don't explicitly configure a property then
>>> the runtime would automatically inject it for us.
>>>
>>> e.g.
>>>
>>> public class Foo {
>>> @Reference(name="myBar")
>>> private Something bar;
>>> ...
>>> }
>>>
>>> the container would know how to inject the "bar" property by
>>> looking up myBar - so in Spring we could just do...
>>>
>>> <bean id="myBean" class="Foo">
>>> <!-- runtime automatically injects "bar" property -->
>>> </bean>
>>>
>>>
>>> Though I guess there's nothing to stop someone reusing Foo and
>>> explicitly configuring it in some runtime if they really want to...
>>>
>>> <bean id="myBean" class="Foo">
>>> <!-- lets override the name used... ->
>>> <property name="bar" ref="aDifferentBar"/>
>>> </bean>
>>>
>>>
>>>
>> I think autowire is useful in basic cases like this.
>>
>
> Agreed. I just wanted to highlight the need to overload/override
> the automatic autowiring sometimes. i.e. annotations should often
> just be a hint, the runtime may allow you to override things if
> necessary.
>
Yes, I was thinking of autowiring being a way to specify a default
(the developer would have to turn it on) that could be overriden.
>
>
>> We should bring it up with the spec group.
>>
>
> Just out of interest; is the spec group a private separate mail
> list? It might be worth using a tuscany mail list for public
> discussions of the spec. I guess we could just reuse the dev list
> and use a [spec] prefix on subjects so folks can filter them out if
> they like.
>
Not sure of the infrastructure. I know it will be a public list at
some point but we'll probably want to keep it separate since other
runtimes may implement SCA. Most of the spec authors should be on
this list and I'll make sure they are today by pinging them.
> James
> -------
> http://radio.weblogs.com/0112098/
>
Re: [spec] @Reference versus @Property
Posted by James Strachan <ja...@gmail.com>.
On 13 Dec 2005, at 19:28, Jim Marino wrote:
> So I also looked at
>
> http://www.jroller.com/page/habuma/20051206
>
> Yes I think burning component names in annotations is bad. Also,
> likewise for specifying property values since Java has an
> assignment operator for that ;-).
Agreed
> I also had a look at:
>
> http://jroller.com/page/habuma?entry=spring_2_0_vs_the
>
> I might approach this differently based on the Tuscany runtime (too
> bad we're still getting the code in place). Basically, we have the
> notion of a scope container which manages components and implements
> SCA scoping functionality (ability to resolve the correct component
> implementation instance for a given invocation). The scope
> containers are pluggable so one could theoretically have a scope
> container which uses some backing store, perhaps through EJB3 or
> Hibernate. One would need a mechanism for specifying a query to
> retrieve the instance. So, I could do:
>
> @Reference
> User user;
>
> and have the user deserialized from some backing store.
>
> I'm not really convinced on the utility of @SpringConfigured. It
> may be useful if I just want to new stuff up but that kind of
> defeats the purpose of DI. Maybe I'm just being too narrow-minded
> on that or haven't thought about it enough?
@SpringConfigured is more for performing DI onto POJOs that someone
else creates, like for injecting services into your entities that
EJB3 persistence/hibernate/ORM creates when doing queries. I'm not
that convinced of its use either - its main use case seems to be
injecting services into entity objects (which is kinda handy - I've
often used the static method-wtih-a-thread-local-inside to get round
this one in the past :)
James
-------
http://radio.weblogs.com/0112098/
Re: [spec] @Reference versus @Property
Posted by Jim Marino <jm...@myroma.net>.
So I also looked at
http://www.jroller.com/page/habuma/20051206
Yes I think burning component names in annotations is bad. Also,
likewise for specifying property values since Java has an assignment
operator for that ;-).
I also had a look at:
http://jroller.com/page/habuma?entry=spring_2_0_vs_the
I might approach this differently based on the Tuscany runtime (too
bad we're still getting the code in place). Basically, we have the
notion of a scope container which manages components and implements
SCA scoping functionality (ability to resolve the correct component
implementation instance for a given invocation). The scope
containers are pluggable so one could theoretically have a scope
container which uses some backing store, perhaps through EJB3 or
Hibernate. One would need a mechanism for specifying a query to
retrieve the instance. So, I could do:
@Reference
User user;
and have the user deserialized from some backing store.
I'm not really convinced on the utility of @SpringConfigured. It may
be useful if I just want to new stuff up but that kind of defeats the
purpose of DI. Maybe I'm just being too narrow-minded on that or
haven't thought about it enough?
Jim
On Dec 13, 2005, at 9:58 AM, James Strachan wrote:
> On 13 Dec 2005, at 16:46, Jim Marino wrote:
>
>> Thanks for the feedback James! Some comments inline...
>>
>> On Dec 13, 2005, at 6:53 AM, James Strachan wrote:
>>
>>
>>> BTW I really like the SCA specification, though coming from a
>>> POJO / Spring background the distinction between @Reference and
>>> @Property seems a little surprising at first - I just wanted to
>>> describe my initial confusion and see if I'm on the right track
>>> to their intended differences and how they should be used.
>>>
>>>
>>> Can you use @Property for services and @Reference for
>>> configuration values?
>>> =============================================================
>>>
>>> The specification seems to imply @Property is used to mark "a
>>> configuration property value" and @Reference is used to inject "a
>>> service that resolves the reference". For the moment lets ignore
>>> the difference between property injection by value versus by
>>> reference (we'll come on to that in a moment).
>>>
>>> What is the real difference, from the perspective of an
>>> application programmer - between a service and a configuration
>>> property? It seems a fairly vague distinction - are there some
>>> rules the application developer can know when writing a POJO on
>>> what the difference between the two are. e.g. a JMS
>>> ConnectionFactory and a JDBC DataSource are probably
>>> configuration properties right?.
>>>
>>>
>> A service offers behavior and the reference may be decorated with
>> QoS. A property is just a data value that does not offer
>> fundamental behavior (of course a pojo data value could have some
>> logic on it, but generally those are component implementation types)
>>
>
> So a component property value is really just a primitive type then?
> Or maybe something that can be coerced to/from a String? :). FWIW
> the latter is the definition Spring uses - it uses the Java Beans
> PropertyEditor to see if values can be read/written as strings.
>
>
>
>> The reason why we put this distinction into the spec (at one point
>> we had them collapsed) was the ability to specify QoS on
>> references as opposed to properties. If people think the
>> distinction is more problematic than useful then we should
>> definitely look at removing it. For example, one thing the
>> distinction buys people is the ability to specify attributes
>> specific to references, such as the potential autowire capability
>> (see below). That may not be compelling enough. Do others have
>> opinions here?
>>
>> I do, however, like the distinction in SCDL for <references> and
>> <properties>. We still need to distinguish between a component
>> name in a reference and a string data value and that seems like a
>> nice way to do it (it also groups stuff nicely). What do you think?
>>
>
> It does feel a little like different concepts are kinda being
> overloaded. How properties are configured (looking values up by
> name or not) seems to be quite separate to creating possibly remote
> references to services which may have additional QoS.
>
> In Spring worlds I see folks inject by value and by reference both
> for primitive values and for services - they are both very useful.
>
> e.g. I'm using DataSource here as a service; but its equally
> interchangable for primitive values too...
>
> <!-- by value -->
> <bean id="foo" class="SomeService">
> <property name="dataSource">
> <!-- lets inject by value creating a new
> implementation -->
> <bean class="com.acme.MyDataSource">
> <property uri="someuri"/>
> </bean>
> </bean>
> </bean>
>
> <!-- by reference (name) -->
> <bean id="bar" class="SomeService">
> <!-- the use of the @Reference could make this line
> unnecessary -->
> <property name="dataSource" ref="myDataSource"/>
> </bean>
>
>
> <!-- by reference (name) where the name comes from the @Reference
> annotation -->
> <bean id="another" class="SomeService">
> </bean>
>
> So am wondering if injection by value or by reference should be a
> different concept to a 'possibly remote service reference with some
> QoS'.
>
>
>
>
>>> Is a "service" in this case something which is @Remotable or has
>>> @Service? If either of those two are the case then can't the
>>> runtime figure out the difference based on the type without the
>>> application developer having to keep services & non-services in
>>> sync? Is the difference between the two really just that of by-
>>> value rather than by-reference configuration (and I was reading
>>> too much into the description of the annotations)?
>>>
>> @Remotable is used to define remotable services - the default,
>> when no annotation is specified is local. @Service is optionally
>> used to define the business interface of a local service in cases
>> where it needs to be specified (i.e. the type may implement
>> additional interfaces which are not business interfaces that
>> should be exposed as a reference). References can be local or
>> remote, so they can follow by-value or by-ref semantics. I may be
>> missing something here since it is early so let me know.
>>
>
> I guess we're talking about two different things. Spring has a by-
> value and by-reference configuration mechanism as I've shown above;
> I'm kinda using this mental model (which I'm sure many Java
> developers these days share) - and was getting confused over the
> wording of the SCA spec which is why its confusing for me when you
> talk about by-value or by-ref semantics of @Reference.
>
> The use of @Reference implies that the runtime will use the name
> you supply (or the property name if not) and look the service up by
> name - the name of the @Reference is the name of the service to
> inject. The value of this service is then injected into the
> property/field - but to me its still injection by reference, since
> you are using a name as an indirection. When injecting by value in
> Spring there is no name - so there is no worry that your
> 'dataSource' property name on service A might accidentally use the
> same 'dataSource' service of another component etc. So the by-value
> or by-reference distinction is quite handy.
>
> Having said that; the @Property also has a name, so I guess
> @Property is injection could be by reference as well :). With my
> Spring-head on I'd kinda assumed the @Property.name was just used
> to rename the field/property in XML land; not to do a reference
> look up in some context. So (in a Spring sense) are both @Property
> and @Reference by reference (they look up the names in a context)?
>
>
> I guess I'm really just highlighting where there is a conceptual
> clash with the POJO/Spring mental model and just wanted
> clarification. It might be useful to map the SCA annotations to how
> you may configure the POJOs in Spring (without any of the remoting
> stuff to start with) and understand how the annotations map to a
> Spring world to avoid confusion. e.g. a wiki page some place on
> 'what SCA annotations mean in a Spring container' or something. It
> would be good if Tuscany could sit on top of Spring as one possible
> Dependency Injection container without folks getting horribly
> confused with properties, references, services and by-value and by-
> reference.
>
> i.e. there's a bunch of annotations which seem mostly to be to do
> with Dependency Injection and lifecycle (@Init, @Destroy,
> @Property, @Reference, @ComponentName) - it'd be interesting to see
> how they could map to Spring. As an experiment I hacked up a Spring
> PostProcessor to deal with most of the dependency injection
> annotations in SCA...
>
> http://svn.xbean.org/trunk/sca/src/main/java/org/xbean/sca/
> ScaBeanPostProcessor.java?rev=174&view=auto
>
> I'm keen to ensure that POJOs can work well in both environments.
> Of course we could just completely ignore all the SCA annotations
> when deploying a POJO inside Spring but I think it'd be good Io
> encourage them to be reused in both SCA and pure Spring runtimes
> when they make sense (then many more folks might use them all the
> time, whether services are local or remote).
>
>
>
>>> e.g. in Spring we can configure a service by name and inject it
>>> into a beans property whether it has no annotation, @Property or
>>> @Reference; so I'm wondering if the distinction between @Property
>>> and @Reference makes sense WRT configuration property value
>>> versus service - other than @Reference acts as a hint to the
>>> runtime to auto-wire the property value by using a named reference.
>>>
>>>
>> In SCA these annotations are also optional so if the
>> implementation does not want to be aware of the distinction, it
>> does not need to be as long as it does not have to specify a
>> mandatory property or reference.
>>
>> We are also looking to potentially add autowire capability (we may
>> need it for the Tuscany runtime for "recursive injection" where
>> module components or "aggregates" are assembled as pojos, which in
>> turn contain other components, etc. In this case we want to wire
>> things like a data binding component to a module component and do
>> it by saying something to the effect of "for this type of
>> component - a module component pojo - inject a component that
>> implements this interface". This will allow us to use SCA to
>> "assemble" the runtime.
>>
>> Related to this, we have been discussing the usefulness of
>> autowiring in general. A couple of very sketchy ideas we need to
>> flush out are:
>>
>> - The ability to specify autowire in the component type reference
>> such as "wire a component the implements the interface specified
>> by the reference or implements the interface specified by the
>> reference and has the same name as the reference"
>>
>
> I've gotta say I'm a little uneasy at putting too much of this
> configuration into the annotations - unless its just a hint to the
> runtime - as its class level, not instance level configuration.
> e.g. I may want to auto-wire 1 set of POJOs of service in one XML
> config, but in the same JVM configure it quite differently (I may
> use the same service class with 2 different database connections or
> 2 different back end services for different customer groups).
>
> There's an interesting blog entry which describes one solution
> using Spring and describes how its not necessarily ideal...
> http://www.jroller.com/page/habuma/20051206
>
>
>
>
>> - The possibility of creating a way to describe auto-wiring, a
>> type of "pointcut" expression language
>>
>
> Yeah - the stuff in Spring 2.0-M1 is well worth a look to see how
> the AOP BeanConfigurer works. I like being able to use annotations
> to create pointcuts in XML-land to configure things.
>
>
>
>> I would view things like DataSources as local (i.e. by ref)
>> services that happen to be provided by the runtime as opposed to
>> properties (basically "data" used for configuration that does not
>> offer behavior).
>>
>
> Yeah - see my first part of the response in this mail - spring
> developers use both kinds of injection for things like DataSources.
> References tend to be used when you have many services sharing the
> same thing - there's nothing particularly special about the types
> involved & its typically outside of the POJO - the XML file - which
> decides if its good to use a reference or not.
>
>
>
>
>>> So at first it seems a little surprising as to why a POJO needs
>>> to understand whether a property is set via direct property
>>> configuration (@Property) or via looking up some named reference
>>> (@Reference). It kinda feels wrong to make the POJO developer
>>> choose how its going to be configured - especially when one of
>>> SCA's goals is to hide middleware (which includes configuration).
>>>
>>> I guess one effect of @Reference is that the container can
>>> automatically inject the named POJO without it explicitly being
>>> configured in some XML file. Maybe - considering Spring for a
>>> moment here - if we don't explicitly configure a property then
>>> the runtime would automatically inject it for us.
>>>
>>> e.g.
>>>
>>> public class Foo {
>>> @Reference(name="myBar")
>>> private Something bar;
>>> ...
>>> }
>>>
>>> the container would know how to inject the "bar" property by
>>> looking up myBar - so in Spring we could just do...
>>>
>>> <bean id="myBean" class="Foo">
>>> <!-- runtime automatically injects "bar" property -->
>>> </bean>
>>>
>>>
>>> Though I guess there's nothing to stop someone reusing Foo and
>>> explicitly configuring it in some runtime if they really want to...
>>>
>>> <bean id="myBean" class="Foo">
>>> <!-- lets override the name used... ->
>>> <property name="bar" ref="aDifferentBar"/>
>>> </bean>
>>>
>>>
>>>
>> I think autowire is useful in basic cases like this.
>>
>
> Agreed. I just wanted to highlight the need to overload/override
> the automatic autowiring sometimes. i.e. annotations should often
> just be a hint, the runtime may allow you to override things if
> necessary.
>
>
>
>> We should bring it up with the spec group.
>>
>
> Just out of interest; is the spec group a private separate mail
> list? It might be worth using a tuscany mail list for public
> discussions of the spec. I guess we could just reuse the dev list
> and use a [spec] prefix on subjects so folks can filter them out if
> they like.
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
Re: [spec] @Reference versus @Property
Posted by James Strachan <ja...@gmail.com>.
On 13 Dec 2005, at 16:46, Jim Marino wrote:
> Thanks for the feedback James! Some comments inline...
>
> On Dec 13, 2005, at 6:53 AM, James Strachan wrote:
>
>> BTW I really like the SCA specification, though coming from a
>> POJO / Spring background the distinction between @Reference and
>> @Property seems a little surprising at first - I just wanted to
>> describe my initial confusion and see if I'm on the right track to
>> their intended differences and how they should be used.
>>
>>
>> Can you use @Property for services and @Reference for
>> configuration values?
>> =============================================================
>>
>> The specification seems to imply @Property is used to mark "a
>> configuration property value" and @Reference is used to inject "a
>> service that resolves the reference". For the moment lets ignore
>> the difference between property injection by value versus by
>> reference (we'll come on to that in a moment).
>>
>> What is the real difference, from the perspective of an
>> application programmer - between a service and a configuration
>> property? It seems a fairly vague distinction - are there some
>> rules the application developer can know when writing a POJO on
>> what the difference between the two are. e.g. a JMS
>> ConnectionFactory and a JDBC DataSource are probably
>> configuration properties right?.
>>
> A service offers behavior and the reference may be decorated with
> QoS. A property is just a data value that does not offer
> fundamental behavior (of course a pojo data value could have some
> logic on it, but generally those are component implementation types)
So a component property value is really just a primitive type then?
Or maybe something that can be coerced to/from a String? :). FWIW the
latter is the definition Spring uses - it uses the Java Beans
PropertyEditor to see if values can be read/written as strings.
> The reason why we put this distinction into the spec (at one point
> we had them collapsed) was the ability to specify QoS on references
> as opposed to properties. If people think the distinction is more
> problematic than useful then we should definitely look at removing
> it. For example, one thing the distinction buys people is the
> ability to specify attributes specific to references, such as the
> potential autowire capability (see below). That may not be
> compelling enough. Do others have opinions here?
>
> I do, however, like the distinction in SCDL for <references> and
> <properties>. We still need to distinguish between a component name
> in a reference and a string data value and that seems like a nice
> way to do it (it also groups stuff nicely). What do you think?
It does feel a little like different concepts are kinda being
overloaded. How properties are configured (looking values up by name
or not) seems to be quite separate to creating possibly remote
references to services which may have additional QoS.
In Spring worlds I see folks inject by value and by reference both
for primitive values and for services - they are both very useful.
e.g. I'm using DataSource here as a service; but its equally
interchangable for primitive values too...
<!-- by value -->
<bean id="foo" class="SomeService">
<property name="dataSource">
<!-- lets inject by value creating a new
implementation -->
<bean class="com.acme.MyDataSource">
<property uri="someuri"/>
</bean>
</bean>
</bean>
<!-- by reference (name) -->
<bean id="bar" class="SomeService">
<!-- the use of the @Reference could make this line
unnecessary -->
<property name="dataSource" ref="myDataSource"/>
</bean>
<!-- by reference (name) where the name comes from the @Reference
annotation -->
<bean id="another" class="SomeService">
</bean>
So am wondering if injection by value or by reference should be a
different concept to a 'possibly remote service reference with some
QoS'.
>> Is a "service" in this case something which is @Remotable or has
>> @Service? If either of those two are the case then can't the
>> runtime figure out the difference based on the type without the
>> application developer having to keep services & non-services in
>> sync? Is the difference between the two really just that of by-
>> value rather than by-reference configuration (and I was reading
>> too much into the description of the annotations)?
> @Remotable is used to define remotable services - the default, when
> no annotation is specified is local. @Service is optionally used to
> define the business interface of a local service in cases where it
> needs to be specified (i.e. the type may implement additional
> interfaces which are not business interfaces that should be exposed
> as a reference). References can be local or remote, so they can
> follow by-value or by-ref semantics. I may be missing something
> here since it is early so let me know.
I guess we're talking about two different things. Spring has a by-
value and by-reference configuration mechanism as I've shown above;
I'm kinda using this mental model (which I'm sure many Java
developers these days share) - and was getting confused over the
wording of the SCA spec which is why its confusing for me when you
talk about by-value or by-ref semantics of @Reference.
The use of @Reference implies that the runtime will use the name you
supply (or the property name if not) and look the service up by name
- the name of the @Reference is the name of the service to inject.
The value of this service is then injected into the property/field -
but to me its still injection by reference, since you are using a
name as an indirection. When injecting by value in Spring there is no
name - so there is no worry that your 'dataSource' property name on
service A might accidentally use the same 'dataSource' service of
another component etc. So the by-value or by-reference distinction is
quite handy.
Having said that; the @Property also has a name, so I guess @Property
is injection could be by reference as well :). With my Spring-head on
I'd kinda assumed the @Property.name was just used to rename the
field/property in XML land; not to do a reference look up in some
context. So (in a Spring sense) are both @Property and @Reference by
reference (they look up the names in a context)?
I guess I'm really just highlighting where there is a conceptual
clash with the POJO/Spring mental model and just wanted
clarification. It might be useful to map the SCA annotations to how
you may configure the POJOs in Spring (without any of the remoting
stuff to start with) and understand how the annotations map to a
Spring world to avoid confusion. e.g. a wiki page some place on 'what
SCA annotations mean in a Spring container' or something. It would be
good if Tuscany could sit on top of Spring as one possible Dependency
Injection container without folks getting horribly confused with
properties, references, services and by-value and by-reference.
i.e. there's a bunch of annotations which seem mostly to be to do
with Dependency Injection and lifecycle (@Init, @Destroy, @Property,
@Reference, @ComponentName) - it'd be interesting to see how they
could map to Spring. As an experiment I hacked up a Spring
PostProcessor to deal with most of the dependency injection
annotations in SCA...
http://svn.xbean.org/trunk/sca/src/main/java/org/xbean/sca/
ScaBeanPostProcessor.java?rev=174&view=auto
I'm keen to ensure that POJOs can work well in both environments. Of
course we could just completely ignore all the SCA annotations when
deploying a POJO inside Spring but I think it'd be good Io encourage
them to be reused in both SCA and pure Spring runtimes when they make
sense (then many more folks might use them all the time, whether
services are local or remote).
>> e.g. in Spring we can configure a service by name and inject it
>> into a beans property whether it has no annotation, @Property or
>> @Reference; so I'm wondering if the distinction between @Property
>> and @Reference makes sense WRT configuration property value versus
>> service - other than @Reference acts as a hint to the runtime to
>> auto-wire the property value by using a named reference.
>>
> In SCA these annotations are also optional so if the implementation
> does not want to be aware of the distinction, it does not need to
> be as long as it does not have to specify a mandatory property or
> reference.
>
> We are also looking to potentially add autowire capability (we may
> need it for the Tuscany runtime for "recursive injection" where
> module components or "aggregates" are assembled as pojos, which in
> turn contain other components, etc. In this case we want to wire
> things like a data binding component to a module component and do
> it by saying something to the effect of "for this type of component
> - a module component pojo - inject a component that implements this
> interface". This will allow us to use SCA to "assemble" the runtime.
>
> Related to this, we have been discussing the usefulness of
> autowiring in general. A couple of very sketchy ideas we need to
> flush out are:
>
> - The ability to specify autowire in the component type reference
> such as "wire a component the implements the interface specified by
> the reference or implements the interface specified by the
> reference and has the same name as the reference"
I've gotta say I'm a little uneasy at putting too much of this
configuration into the annotations - unless its just a hint to the
runtime - as its class level, not instance level configuration. e.g.
I may want to auto-wire 1 set of POJOs of service in one XML config,
but in the same JVM configure it quite differently (I may use the
same service class with 2 different database connections or 2
different back end services for different customer groups).
There's an interesting blog entry which describes one solution using
Spring and describes how its not necessarily ideal...
http://www.jroller.com/page/habuma/20051206
> - The possibility of creating a way to describe auto-wiring, a type
> of "pointcut" expression language
Yeah - the stuff in Spring 2.0-M1 is well worth a look to see how the
AOP BeanConfigurer works. I like being able to use annotations to
create pointcuts in XML-land to configure things.
> I would view things like DataSources as local (i.e. by ref)
> services that happen to be provided by the runtime as opposed to
> properties (basically "data" used for configuration that does not
> offer behavior).
Yeah - see my first part of the response in this mail - spring
developers use both kinds of injection for things like DataSources.
References tend to be used when you have many services sharing the
same thing - there's nothing particularly special about the types
involved & its typically outside of the POJO - the XML file - which
decides if its good to use a reference or not.
>> So at first it seems a little surprising as to why a POJO needs to
>> understand whether a property is set via direct property
>> configuration (@Property) or via looking up some named reference
>> (@Reference). It kinda feels wrong to make the POJO developer
>> choose how its going to be configured - especially when one of
>> SCA's goals is to hide middleware (which includes configuration).
>>
>> I guess one effect of @Reference is that the container can
>> automatically inject the named POJO without it explicitly being
>> configured in some XML file. Maybe - considering Spring for a
>> moment here - if we don't explicitly configure a property then the
>> runtime would automatically inject it for us.
>>
>> e.g.
>>
>> public class Foo {
>> @Reference(name="myBar")
>> private Something bar;
>> ...
>> }
>>
>> the container would know how to inject the "bar" property by
>> looking up myBar - so in Spring we could just do...
>>
>> <bean id="myBean" class="Foo">
>> <!-- runtime automatically injects "bar" property -->
>> </bean>
>>
>>
>> Though I guess there's nothing to stop someone reusing Foo and
>> explicitly configuring it in some runtime if they really want to...
>>
>> <bean id="myBean" class="Foo">
>> <!-- lets override the name used... ->
>> <property name="bar" ref="aDifferentBar"/>
>> </bean>
>>
>>
> I think autowire is useful in basic cases like this.
Agreed. I just wanted to highlight the need to overload/override the
automatic autowiring sometimes. i.e. annotations should often just be
a hint, the runtime may allow you to override things if necessary.
> We should bring it up with the spec group.
Just out of interest; is the spec group a private separate mail list?
It might be worth using a tuscany mail list for public discussions of
the spec. I guess we could just reuse the dev list and use a [spec]
prefix on subjects so folks can filter them out if they like.
James
-------
http://radio.weblogs.com/0112098/
Re: [spec] @Reference versus @Property
Posted by Jim Marino <jm...@myroma.net>.
Thanks for the feedback James! Some comments inline...
On Dec 13, 2005, at 6:53 AM, James Strachan wrote:
> BTW I really like the SCA specification, though coming from a
> POJO / Spring background the distinction between @Reference and
> @Property seems a little surprising at first - I just wanted to
> describe my initial confusion and see if I'm on the right track to
> their intended differences and how they should be used.
>
>
> Can you use @Property for services and @Reference for configuration
> values?
> =============================================================
>
> The specification seems to imply @Property is used to mark "a
> configuration property value" and @Reference is used to inject "a
> service that resolves the reference". For the moment lets ignore
> the difference between property injection by value versus by
> reference (we'll come on to that in a moment).
>
> What is the real difference, from the perspective of an application
> programmer - between a service and a configuration property? It
> seems a fairly vague distinction - are there some rules the
> application developer can know when writing a POJO on what the
> difference between the two are. e.g. a JMS ConnectionFactory and a
> JDBC DataSource are probably configuration properties right?.
>
A service offers behavior and the reference may be decorated with
QoS. A property is just a data value that does not offer fundamental
behavior (of course a pojo data value could have some logic on it,
but generally those are component implementation types)
The reason why we put this distinction into the spec (at one point we
had them collapsed) was the ability to specify QoS on references as
opposed to properties. If people think the distinction is more
problematic than useful then we should definitely look at removing
it. For example, one thing the distinction buys people is the ability
to specify attributes specific to references, such as the potential
autowire capability (see below). That may not be compelling enough.
Do others have opinions here?
I do, however, like the distinction in SCDL for <references> and
<properties>. We still need to distinguish between a component name
in a reference and a string data value and that seems like a nice way
to do it (it also groups stuff nicely). What do you think?
> Is a "service" in this case something which is @Remotable or has
> @Service? If either of those two are the case then can't the
> runtime figure out the difference based on the type without the
> application developer having to keep services & non-services in
> sync? Is the difference between the two really just that of by-
> value rather than by-reference configuration (and I was reading too
> much into the description of the annotations)?
@Remotable is used to define remotable services - the default, when
no annotation is specified is local. @Service is optionally used to
define the business interface of a local service in cases where it
needs to be specified (i.e. the type may implement additional
interfaces which are not business interfaces that should be exposed
as a reference). References can be local or remote, so they can
follow by-value or by-ref semantics. I may be missing something here
since it is early so let me know.
>
> e.g. in Spring we can configure a service by name and inject it
> into a beans property whether it has no annotation, @Property or
> @Reference; so I'm wondering if the distinction between @Property
> and @Reference makes sense WRT configuration property value versus
> service - other than @Reference acts as a hint to the runtime to
> auto-wire the property value by using a named reference.
>
In SCA these annotations are also optional so if the implementation
does not want to be aware of the distinction, it does not need to be
as long as it does not have to specify a mandatory property or
reference.
We are also looking to potentially add autowire capability (we may
need it for the Tuscany runtime for "recursive injection" where
module components or "aggregates" are assembled as pojos, which in
turn contain other components, etc. In this case we want to wire
things like a data binding component to a module component and do it
by saying something to the effect of "for this type of component - a
module component pojo - inject a component that implements this
interface". This will allow us to use SCA to "assemble" the runtime.
Related to this, we have been discussing the usefulness of autowiring
in general. A couple of very sketchy ideas we need to flush out are:
- The ability to specify autowire in the component type reference
such as "wire a component the implements the interface specified by
the reference or implements the interface specified by the reference
and has the same name as the reference"
- The possibility of creating a way to describe auto-wiring, a type
of "pointcut" expression language
> So I guess I'm wondering; what is a service in this context and can
> @Reference be used for non-services (like JDBC connections and
> other properties you may wish to configure by-reference rather than
> by value). I wonder if Im just being picky and @Reference is
> usually used for configure-by-reference properties which usually
> are services, but could in fact be any property?
>
>
I think one of the things to keep in mind is @Reference can be by-ref
as well (when you mean by ref or by val are you talking about
parameter passing?). I would view things like DataSources as local
(i.e. by ref) services that happen to be provided by the runtime as
opposed to properties (basically "data" used for configuration that
does not offer behavior).
> IoC of values versus references
> ========================
> In IoC containers like Spring there is no difference between
> configuration by value or by reference at the POJO level; a POJO
> just has bean properties (which may or may not be annotated by
> @Property); the 'reference' only really exists in the XML
> configuration file.
>
> e.g. in Spring we'd do
>
> <bean id="myBean" class="Foo">
> <!-- regular property injection -->
> <property name="foo" value="1234"/>
>
> <!-- named reference injection of a property -->
> <property name="bar" ref="someName"/>
> </bean>
>
> In this case it is the author of the XML config file who decides
> which properties are configured by value or by reference.
Assuming by value or by reference refers to parameter passing, we
(the spec people) thought this needed to be decided by the developer
(code has to behave if it is by reference capable), and hence should
be specified on the component type. If you mean the other case, i.e.
the distinction between references and properties, perhaps the
implementation should not specify that (only the configuration
artifact would) which has the downside of not being able to specify
attributes specific to a reference in the implementation. I think we
should seriously consider merging the two. Dave Booz had some use
cases for this distinction so I will follow-up with him and see if he
can post them to the list.
> So at first it seems a little surprising as to why a POJO needs to
> understand whether a property is set via direct property
> configuration (@Property) or via looking up some named reference
> (@Reference). It kinda feels wrong to make the POJO developer
> choose how its going to be configured - especially when one of
> SCA's goals is to hide middleware (which includes configuration).
>
> I guess one effect of @Reference is that the container can
> automatically inject the named POJO without it explicitly being
> configured in some XML file. Maybe - considering Spring for a
> moment here - if we don't explicitly configure a property then the
> runtime would automatically inject it for us.
>
> e.g.
>
> public class Foo {
> @Reference(name="myBar")
> private Something bar;
> ...
> }
>
> the container would know how to inject the "bar" property by
> looking up myBar - so in Spring we could just do...
>
> <bean id="myBean" class="Foo">
> <!-- runtime automatically injects "bar" property -->
> </bean>
>
>
> Though I guess there's nothing to stop someone reusing Foo and
> explicitly configuring it in some runtime if they really want to...
>
> <bean id="myBean" class="Foo">
> <!-- lets override the name used... ->
> <property name="bar" ref="aDifferentBar"/>
> </bean>
>
>
I think autowire is useful in basic cases like this. We should bring
it up with the spec group.
>
> Required defaults for @Reference and @Property
> ========================================
> Since that @Reference & @Property are both optional; my main use
> case for using @Property would be to mark mandatory properties (as
> properties with no @Property annotation can still be injected). So
> why not make @Property required default to true like it is for
> @Reference? Then the default use of @Property adds some value -
> denoting mandatory properties - without having to specify
> (required=true)?
>
Yes this is a good point.
> e.g.
>
> public class Cheese {
>
> public void setFoo(Something) {}
>
> @Property
> public void setBar(Something) {}
> }
>
> so that "foo" is optional and "bar" mandatory?
>
> Then we'd have a little less clutter in our POJOs.
Less clutter is always good :)
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
Re: [spec] @Reference versus @Property
Posted by Mike Edwards <mi...@gmail.com>.
James,
Here is my view of the questions you have with regard to the SCA spec:
James Strachan wrote:
> BTW I really like the SCA specification, though coming from a POJO /
> Spring background the distinction between @Reference and @Property
> seems a little surprising at first - I just wanted to describe my
> initial confusion and see if I'm on the right track to their intended
> differences and how they should be used.
>
>
> Can you use @Property for services and @Reference for configuration
> values?
> =============================================================
>
> The specification seems to imply @Property is used to mark "a
> configuration property value" and @Reference is used to inject "a
> service that resolves the reference". For the moment lets ignore the
> difference between property injection by value versus by reference
> (we'll come on to that in a moment).
>
> What is the real difference, from the perspective of an application
> programmer - between a service and a configuration property? It seems a
> fairly vague distinction - are there some rules the application
> developer can know when writing a POJO on what the difference between
> the two are. e.g. a JMS ConnectionFactory and a JDBC DataSource are
> probably configuration properties right?.
The major difference between a service reference and a property relates
to how the service reference is treated by the wiring of services at the
module level. A property is simply that - some data value that can be
configured on the component and which is used by the component in any
way it likes.
A service reference is different because this represents a connection to
some other service implementation, defined by the wires of the SCA
assembly. Wires of this kind can have behaviour attached to them -
infrastructure capabilities such as Security, Transactions and so on.
The SCA runtime applies these aspects to a reference, according to the
definition supplied in the configuration of the wire. SCA does not do
this for properties, since in general properties would not need such
capabilities applied to them.
So I suppose another way of saying this is that SCA does treat the
assembly of components in a special way and that SCA identifies service
references separately from general properties for this purpose.
If you wanted to supply something like a JMS ConnectionFactory then that
would be supplied as a property, although the SCA approach would be to
define such entities as services and hide the JMS nature of the service
in the SCA bindings - keeping the middleware APIs away from the business
code in the component.
>
> Is a "service" in this case something which is @Remotable or has
> @Service? If either of those two are the case then can't the runtime
> figure out the difference based on the type without the application
> developer having to keep services & non-services in sync? Is the
> difference between the two really just that of by-value rather than
> by-reference configuration (and I was reading too much into the
> description of the annotations)?
>
Its more a question of SCA making clear a distinction between services /
references which can have various infrastructure capabilities applied to
them and properties which are more simply viewed as data elements (yes,
they could have associated behaviour too in the case of complex data)
> e.g. in Spring we can configure a service by name and inject it into a
> beans property whether it has no annotation, @Property or @Reference;
> so I'm wondering if the distinction between @Property and @Reference
> makes sense WRT configuration property value versus service - other
> than @Reference acts as a hint to the runtime to auto-wire the property
> value by using a named reference.
>
> So I guess I'm wondering; what is a service in this context and can
> @Reference be used for non-services (like JDBC connections and other
> properties you may wish to configure by-reference rather than by
> value). I wonder if Im just being picky and @Reference is usually used
> for configure-by-reference properties which usually are services, but
> could in fact be any property?
>
By-reference and by-value are not the issue with SCA service interfaces,
since they can be either at the choice of the developer. The real
difference is the way that the SCA assembly treats a service wire.
>
> IoC of values versus references
> ========================
> In IoC containers like Spring there is no difference between
> configuration by value or by reference at the POJO level; a POJO just
> has bean properties (which may or may not be annotated by @Property);
> the 'reference' only really exists in the XML configuration file.
>
> e.g. in Spring we'd do
>
> <bean id="myBean" class="Foo">
> <!-- regular property injection -->
> <property name="foo" value="1234"/>
>
> <!-- named reference injection of a property -->
> <property name="bar" ref="someName"/>
> </bean>
>
> In this case it is the author of the XML config file who decides which
> properties are configured by value or by reference.
>
> So at first it seems a little surprising as to why a POJO needs to
> understand whether a property is set via direct property configuration
> (@Property) or via looking up some named reference (@Reference). It
> kinda feels wrong to make the POJO developer choose how its going to be
> configured - especially when one of SCA's goals is to hide middleware
> (which includes configuration).
>
> I guess one effect of @Reference is that the container can
> automatically inject the named POJO without it explicitly being
> configured in some XML file. Maybe - considering Spring for a moment
> here - if we don't explicitly configure a property then the runtime
> would automatically inject it for us.
>
> e.g.
>
> public class Foo {
> @Reference(name="myBar")
> private Something bar;
> ...
> }
>
> the container would know how to inject the "bar" property by looking up
> myBar - so in Spring we could just do...
>
> <bean id="myBean" class="Foo">
> <!-- runtime automatically injects "bar" property -->
> </bean>
>
>
> Though I guess there's nothing to stop someone reusing Foo and
> explicitly configuring it in some runtime if they really want to...
>
> <bean id="myBean" class="Foo">
> <!-- lets override the name used... ->
> <property name="bar" ref="aDifferentBar"/>
> </bean>
>
I think that the notion of reference really implies that it is just that
- a reference to a service provided by some other component, which can
be wired up separately by the Assembly. Of course this has deeper
meaning once you consider the case of a remote service, where the actual
implementation may not be in Java at all, but the spec team for SCA
certainly thought that there is value in treating local and remote
services in the same fashion from an Assembly perspective (ie the Wire
concept and the idea of wires applying qualities of service when needed).
>
>
> Required defaults for @Reference and @Property
> ========================================
> Since that @Reference & @Property are both optional; my main use case
> for using @Property would be to mark mandatory properties (as
> properties with no @Property annotation can still be injected). So why
> not make @Property required default to true like it is for @Reference?
> Then the default use of @Property adds some value - denoting mandatory
> properties - without having to specify (required=true)?
>
> e.g.
>
> public class Cheese {
>
> public void setFoo(Something) {}
>
> @Property
> public void setBar(Something) {}
> }
>
> so that "foo" is optional and "bar" mandatory?
>
> Then we'd have a little less clutter in our POJOs.
>
Your thoughts are interesting and it is surely the aim of SCA to make
things simple and clean.
Certainly the thinking around services is that you are more likely to
require them (though you can set up an allowed multiplicity of 0 which
implies that your code will cope with no service being wired to a
reference - though this was a matter of some debate in the spec team and
it certainly isn't the default).
> James
> -------
> http://radio.weblogs.com/0112098/
>
>