Farr, Aaron wrote:
Hello.
This was discussed before, but I don't think there was any resolution. Out current service dependency contracts look something like this:
/** * @avalon.dependency type="org.proj.MyService" key="myService " */ public void service(ServiceManager serviceManager) throws ServiceException { MyService srv = (MyService) serviceManager.lookup("myService"); getLogger().info("Hello! we got this service = "+srv.ROLE); }
I figure I'm probably the only person here who thinks this - I just don't get the value of <class>.ROLE. In fact I think its a bad practice. The role of a service is something understandable relative to the consumer - not the provider.
Anyway, moving on.
which is all well and good -- _IF_ you know what services you need to lookup at build and deployment time.
If you have a component which looks up arbitrary services which are perhaps given in the configuration (like the Codehaus Ivory project) then you're going to have issues if you MUST declare service dependencies, which is the case for Merlin.
This is the issue I raised before. 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?
In Merlin if you build the above code, and leave out the @avalon.dependency tag, then deployment fails.
Correct. Deployment fails because the component is requesting something that it did not declare as a structural dependency.
Even leaving out the 'key' attribute will cause
this to fail.
Leaving out the key is fine.
This just means that your using the type as the key. I have just added an example of key-less dependency resolution to the merlin/merlin-platform/tutorials package under ./dependencies/auto.
While I understand dependency resolution is important, we need to have a way to support runtime dependencies.
Just so that we are on the same page - I'm interpriting what your saying as "we need to have a mechanism through which a component can declare to a container that it has a dependency on a service discovery service" and by implication, (a) the container should be providing this service independently of the containment context, and (b) for compatibility reasons, the functionality of a such a service should be exposed using the service manager lookup operation.
Even something like a wildcard would be nice:
@avalon.dependency type="org.proj.MyService" key="*"
What is the problem with:
@avalon.dependency type="org.proj.MyService"
This bring me back to an older discussion [1] about lookup methods. At the time Berin put together the following:
Lookup Method | ECM | Fortress | Merlin | Phoenix --------------------------------------+-----+----------+--------+-------- Object <- lookup("alias") | | | X | X Object <- lookup(ROLE) | X | X | X | X Object <- lookup(ROLE+"/alias") | | X | | X List <- lookup(ROLE+"[]") | | | | X Map <- lookup(ROLE+"{}") | | | | X Selector <- lookup(ROLE+"Selector") | X | X | |
(edited to provide accurate Merlin status)
Since Merlin is aiming at being _the_ container, what lookup methods will it support?
I would like to take the approach of looking at this subject from a A5 perspective and from that, look at how to provide consistent A4 support. The reason I'm suggesting that is that I really think that the mixed semantics approach is a broken solution and that we should approach this problem with the objective of defining something clean and from that - addressing A4 compatibility.
Cheers, Steve.
Thanks!
J. Aaron Farr SONY ELECTRONICS DDP-CIM (724) 696-7653
[1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg06296.html
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
