You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2003/09/01 06:19:40 UTC
Re: [meta+merlin] runtime service dependencies
Stephen McConnell said:
> There is a semantic difference
> between resolving a dependency and service discovery. A
> dependency is something structurally bound to the component type.
> A component that requires a service discovery service should be
> declaring this as a dependency (in an ideal world). Unfortuately
> we are dealing with a historical context in which the semantics
> of type based dependencies and service discovery have been
> implied on a single interface (ServiceManager).
>
> This conflict raises an important issue. If a component requests
> something that is not a dependency, does this action represent an
> error or does the action represent a ligitimate service discovery
> request?
This is why I would "promote" the solution of setAbc() for
dependency resolution and a more generic lookup() for service
discovery.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [meta+merlin] runtime service dependencies
Posted by Niclas Hedhman <ni...@hedhman.org>.
Stephen McConnell said:
>> This is why I would "promote" the solution of setAbc() for
>> dependency resolution and a more generic lookup() for service
>> discovery.
>
>
> Sort of agree but I think something related to constructors for
> dependencies is more interesting than the setAbc().
Constructors have drawbacks that you will cry over later. Typical
example, mirrored/cyclic dependency (I know it's not desirable but
happens).
Right now I am a bit dizzy and can't think of a better example, but
there are quite a lot.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [meta+merlin] runtime service dependencies
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
> Stephen McConnell said:
>
>>There is a semantic difference
>> between resolving a dependency and service discovery. A
>>dependency is something structurally bound to the component type.
>> A component that requires a service discovery service should be
>>declaring this as a dependency (in an ideal world). Unfortuately
>>we are dealing with a historical context in which the semantics
>>of type based dependencies and service discovery have been
>>implied on a single interface (ServiceManager).
>>
>>This conflict raises an important issue. If a component requests
>>something that is not a dependency, does this action represent an
>>error or does the action represent a ligitimate service discovery
>>request?
>
>
> This is why I would "promote" the solution of setAbc() for
> dependency resolution and a more generic lookup() for service
> discovery.
Sort of agree but I think something related to constructors for
dependencies is more interesting than the setAbc().
Steve.
>
> Niclas
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Service Discovery
Posted by Stephen McConnell <mc...@apache.org>.
J Aaron Farr wrote:
>Nice to see some good discussion happening about this. I'm going to try
>to split this out into another threads.
>
>As for discovery methods:
>
>On Mon, 2003-09-01 at 02:54, Stephen McConnell wrote:
>
>
>>Frankly I don't think the current ServiceManager interface is a good
>>candidate for dynamic service discovery. It does not provide support for
>>the supply of a selection policy and its exception suite needs to be
>>beefed up a lot.
>>
>>
>>
>
>Not the current ServiceManager interface, no. My point was, given the
>two roles of the ServiceManager (dependency, discovery), I tended to use
>it more for discovery.
>
>The ServiceLocator example you gave was along the lines of what I was
>thinking. Another option is to first get jndi exporting of services and
>then do all service discovery via the jndi bindings. The discovery
>service itself could then also be a JNDI Context or at least provide
>one. Then you get both JNDI exporting and internal service discovery.
>
This sounds good.
>
>
>Any downsides to that?
>
Not that I can see. One thing we need to be careful about is avoiding
the addition of features as opposed to declaring a component (in root or
child container) that is a recognized as a "facility" (as distinct from
component).
>
>
>Speaking of Contexts, what about the Avalon Context? Is it providing
>dependencies or is it a discovery service?
>
No discovery. Simply containment context established relative to the
contextual dependencies declared by a component.
>I like what Merlin now
>allows us to do in the Context, but I think it's always been confusing
>have two lookup objects (Context and ServiceManager). Currently I tend
>to think of the Context as a Container wide configuration object.
>
Umm, you have me thinking. In Merlin today a component can import
standard context entries or you can construct context values within the
component deployment directive. Your comment above about
"container-wide" get me to thinking about the possibility for the
declaration of context keys and bindings at a container level. This
would allow me (assembler) to override the value assigned to something
like "urn:avalon:home" within the scope of a particular container.
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Service Discovery (Was: runtime service dependencies)
Posted by J Aaron Farr <fa...@apache.org>.
Nice to see some good discussion happening about this. I'm going to try
to split this out into another threads.
As for discovery methods:
On Mon, 2003-09-01 at 02:54, Stephen McConnell wrote:
>
> Frankly I don't think the current ServiceManager interface is a good
> candidate for dynamic service discovery. It does not provide support for
> the supply of a selection policy and its exception suite needs to be
> beefed up a lot.
>
Not the current ServiceManager interface, no. My point was, given the
two roles of the ServiceManager (dependency, discovery), I tended to use
it more for discovery.
The ServiceLocator example you gave was along the lines of what I was
thinking. Another option is to first get jndi exporting of services and
then do all service discovery via the jndi bindings. The discovery
service itself could then also be a JNDI Context or at least provide
one. Then you get both JNDI exporting and internal service discovery.
Any downsides to that?
Speaking of Contexts, what about the Avalon Context? Is it providing
dependencies or is it a discovery service? I like what Merlin now
allows us to do in the Context, but I think it's always been confusing
have two lookup objects (Context and ServiceManager). Currently I tend
to think of the Context as a Container wide configuration object.
--
jaaron <http://jadetower.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [meta+merlin] runtime service dependencies
Posted by Stephen McConnell <mc...@apache.org>.
J Aaron Farr wrote:
> On Mon, 2003-09-01 at 00:19, Niclas Hedhman wrote:
>
>>Stephen McConnell said:
>>
>>This is why I would "promote" the solution of setAbc() for
>>dependency resolution and a more generic lookup() for service
>>discovery.
>>
>>Niclas
>
>
> There's no reason we can't have multiple dependency resolution schemes.
Sure.
> For example, we could support all three IoC types (as defined by the
> PicoContainer project). I do something like that in my JingDAO project
> already. This would also allow us to better support:
>
> - older Avalon components
> - traditional JavaBeans
> - Pico-style components
>
> One issue would be determining which dependency scheme to use. It could
> potentially be done dynamically by first trying the contructor, then any
> bean properties and finally via the service() method. The meta-info
> might also be able to store this information, but I would like it to be
> as automagical as possible, making it easier for component writers.
You would have to include this in meta - the risks are simply too high
that the container interacts with the component in an unexpected way.
>
> In the end though, you'll still be stuck with older Avalon components
> which use the service manager for both dependencies and discovery. I
> personally would like to see the service manager used more for discovery
> than dependency resolution.
Frankly I don't think the current ServiceManager interface is a good
candidate for dynamic service discovery. It does not provide support for
the supply of a selection policy and its exception suite needs to be
beefed up a lot.
This could be handled by doing something like:
public interface Locator
{
Object lookup( Criteria criteria ) throws
ServiceUnknownException,
ServiceUnresolvableException,
ServiceUnavailableException;
}
public interface ServiceLocator
extends ServiceManager, Locator{}
We can easily provide a selectable serviceable strategy such that a
ServiceLocator could be supplied directly as in:
public void service( ServiceLocator locator ) trhows ServiceException
{
// stuff
}
While enabling different modes of Locator usage as a pure service .. e.g.:
public class HelloComponent
{
public HelloComponent( Logger logger, Locator locator )
{
// constructor stuff
}
}
Or, classic service lookup:
public void service( ServiceManager manager )
{
m_locator = manager.get( Locator.class.getName() );
}
Steve.
> I'm working on some ideas for this now -- should have something a little
> more concrete tomorrow. Any other thoughts or comments would be
> appreciated.
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: runtime service dependencies
Posted by J Aaron Farr <fa...@telerama.com>.
On Mon, 2003-09-01 at 03:54, Leo Simons wrote:
>
> > I'm working on some ideas for this now -- should have something a little
> > more concrete tomorrow. Any other thoughts or comments would be
> > appreciated.
>
> been playing in the same area :D
>
<snip>very nice list of options</snip>
The trouble I've found with Algorithms (as you mentioned) is the speed
and the somewhat unpredictable results components can have. The most
common example would be a hybrid component that uses both constructors
and bean properties. The other thing that frustrates me about a purely
algorithmic method is that it would only take one line of meta-data/info
to know how to properly initialize the component.
The approach I've been playing with goes something like:
- Dependency schemes are defined by Factories
- The component can declare its dependency type via some sort
of simple meta-data
- If no such meta-data exists, each factory attempts to handle
the dependencies (leading to the algorithmic approach)
The biggest concerns I have here are to:
- Make it simple (in order of priority that Niclas mentioned)
- Make it extensible
The trick currently with Merlin is that we have lots of strong meta-info
contracts which are there, understandably, to provide predictability
when it comes to deploying a component.
Looks like I'll have to take a closer look at Jicarilla. :)
jaaron
--
jaaron <http://jadetower.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: runtime service dependencies
Posted by Leo Simons <le...@apache.org>.
J Aaron Farr wrote:
> There's no reason we can't have multiple dependency resolution schemes.
> For example, we could support all three IoC types (as defined by the
> PicoContainer project). I do something like that in my JingDAO project
> already. This would also allow us to better support:
>
> - older Avalon components
> - traditional JavaBeans
> - Pico-style components
>
> One issue would be determining which dependency scheme to use. It could
> potentially be done dynamically by first trying the contructor, then any
> bean properties and finally via the service() method.
Avalon components generally expect service() before any non-framework
methods so you probably want to reverse that.
> The meta-info
> might also be able to store this information, but I would like it to be
> as automagical as possible, making it easier for component writers.
+1
> In the end though, you'll still be stuck with older Avalon components
> which use the service manager for both dependencies and discovery. I
> personally would like to see the service manager used more for discovery
> than dependency resolution.
I'd define a new interface instead. Or, more likely, just use JNDI for
discovery.
> I'm working on some ideas for this now -- should have something a little
> more concrete tomorrow. Any other thoughts or comments would be
> appreciated.
been playing in the same area :D
1) Option: algorithm
--------------------
I've found an algorithm that seems to work reasonably well in practice:
1) select the longest available constructor ('pure' pico components will
have only one; avalon and XWork normally only have a default no-argument
constructor). Check to see if you can satisfy all its arguments. If not,
pick the next longest one. If none is left, throw a dependency
resolution exception.
2) create an instance
3) look for all avalon lifecycle interfaces and call the appropriate methods
4) look for all XXXAware interfaces and call the appropriate methods as
per XWork semantics
5) call any tellInitComplete() method (or whatever its called) to signal
XWork-style components that you're done setting them up
The main disadvantage is that this is slow (lots of introspection). You
also need to be very careful with 'hybrid' components whose state will
be initialized and overridden a few times (consider providing a
datasource in the constructor, through the service manager and through a
DataSourceAware interface: the component might open three connections),
hybrid components which don't allow you to call a non-empty constructor
and avalon lifecycle methods (ie they are picky about their state
validation), etc etc. Haven't actually encountered any that were any
kind of problem.
You also can't really support all springframework-style components this way.
The main advantage with an algorithm like this is that a component
author doesn't have to specify what kind of component he is writing, ie, no
/** @@ComponentType( ComponentType.AVALON ) */
Within merlin, of course, you also need to accept a lot more "sensible
defaults", like "expose all interfaces I implement as work interfaces".
It is possible to move away from that a little bit by excluding known
marker interfaces (ThreadSafe), but I found that not worth the hassle
(there will always be unknown marker interfaces).
2) Option: springframework
--------------------------
Springframework has an xml composition language that should allow you to
support avalon-framework by virtue of a long configuration file. Ie:
<spring>
<instance id="sm" class="DefaultServiceManager"
interface="ServiceManager">
<put arg0="my-service" arg1="urn:spring:ref:my-service"/>
</instance>
</spring>
or whatever their xml format looks like. Needless to say, this is ugly;
to a much greater degree than ant or jelly scripts.
3) Option: jython
-----------------
"Replace an ugly xml scripting language with a beautiful much cleaner
scripting language". Then populate the initial variable context with a
PicoContainer, and you need only a few lines of script to configure a
non-standard component.
4) Option: don't care, just do it
---------------------------------
The next trick is to make your container algorithm-agnostic. This looks
a lot better in pico atm than anywhere else I've seen, but there's still
room for some improvement :D. Encapsulate your policy into a factory
class (rather than lots of metadata), the only 'metadata' you need to
deploy the component is a reference to the factory class. With the
factories similar to the ones in fortress, but with a little more
responsibility.
A per-implementation-factory is a lot simpler to grasp and program than
a per-deployment-profile-assembly.
You can have an AvalonFactory, a SpringframeworkFactory, a
JythonFactory, and lots of different permutations.
/**
* @@jicarilla.atts.Component()
* @@jicarilla.atts.ComponentFactory(
* "com.leosimons.jicarilla.factories.SpringframeworkFactory" )
* @@jicarilla.atts.NamedInstance(
* new String[] { "my1", "my2", "my3" } )
*/
class MySpringFrameworkComponent implements MyComponent { /* ... */ }
/**
* @@jicarilla.atts.Component()
* @@jicarilla.atts.ComponentFactory(
* "com.leosimons.jicarilla.factories.AvalonFactory" )
*/
class MyAvalonComponent implements MyComponent, ThreadSafe, Serviceable
{ /* ... */ }
/**
* @@jicarilla.atts.Component()
* @@jicarilla.atts.ComponentFactory(
* "com.leosimons.jicarilla.factories.JythonFactory" )
* @@jicarilla.atts.jython.InitScript( "init.py" )
* @@jicarilla.atts.jython.DisposeScript( "dispose.py" )
*/
class MyScriptedComponent implements MyComponent { /* ... */ }
More?
-----
Demo of 1)-3) in my playground jicarilla.sf.net and associated wiki
(disclaimer: the code is way too ugly to actually look at, but it serves
as proof-of-concept). Springframework is at www.springframework.org.
Testcase for the picocontainer factory setup (which, I've just found
out, has been refactored) is @
http://cvs.codehaus.org/viewcvs.cgi/pico/src/test/org/picocontainer/defaults/DefaultPicoContainerWithComponentFactoryStringKeyTestCase.java?root=picocontainer
Currently working on an extended PicoContainer having various
ComponentFactory implementations (stupid refactoring have to update to
adapter now grmbl grmbl) for different lifecycles. That code is
definately too ugly to look at though.
cheers,
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [meta+merlin] runtime service dependencies
Posted by Niclas Hedhman <ni...@hedhman.org>.
J Aaron Farr said:
> making it easier for component writers.
I hope we have in mind the priority of "easier for xxx";
1. Component Users
2. Component Implementors
3. Component Specifiers
4. Container Extension Implementors
5. Container Implementors
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [meta+merlin] runtime service dependencies
Posted by J Aaron Farr <fa...@telerama.com>.
On Mon, 2003-09-01 at 00:19, Niclas Hedhman wrote:
> Stephen McConnell said:
>
> This is why I would "promote" the solution of setAbc() for
> dependency resolution and a more generic lookup() for service
> discovery.
>
> Niclas
There's no reason we can't have multiple dependency resolution schemes.
For example, we could support all three IoC types (as defined by the
PicoContainer project). I do something like that in my JingDAO project
already. This would also allow us to better support:
- older Avalon components
- traditional JavaBeans
- Pico-style components
One issue would be determining which dependency scheme to use. It could
potentially be done dynamically by first trying the contructor, then any
bean properties and finally via the service() method. The meta-info
might also be able to store this information, but I would like it to be
as automagical as possible, making it easier for component writers.
In the end though, you'll still be stuck with older Avalon components
which use the service manager for both dependencies and discovery. I
personally would like to see the service manager used more for discovery
than dependency resolution.
I'm working on some ideas for this now -- should have something a little
more concrete tomorrow. Any other thoughts or comments would be
appreciated.
--
jaaron <http://jadetower.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org