Vinay Chandran wrote:
Steve,
The reason
for the existance of all of these things your describing are related to
distributed service support.
So whats the current use of urn:avalon:service.type.?
I assume its just hanging in there to be lifted to higher grounds during a built of distributed infrastructure.
Vinay!
You are giving away a bunch of secrets here - stop! STOP! If you keep this up then everyone will figure out all of the things you can really do - and that's plain dangerouse - think of the implications!
Yet if we provide for a generic means to plugin extension points(eclipse style ) to the way we resolve
and export services from component types , we are
actually addressing some of our concerns of dist'n.
I was looking at a flexible means for doing this
since not all of the platform instances
might have this need. One way to handle this by making block.xml
executable. (Infact I could dream further of
making all descriptors executable,if needed).
Take a look at merlin/meta/data - its already executable (not in the runtime yet but you can figure out where things are heading).
By executable I mean , the descriptors although has most of its parts dead, yet can contain jelly(ant) style tasks which can provide magic right from under the carpet.
:-)
This might thus lead to a scenario where we have
descriptors itself acting as a glue to bind components
within a container and provide 'extra' magic out from them.
Thus(one can imagine), <block xmlns:magic="java:org.apache.avalon.magic.taskdef">
....... (standard stuff) <magic:export> <component type="org.apache.avalon.simple.component"/> </magic:export> ..
</block>
Thoughts?
... ummm, yep. :-)
Anyways this is definitely stetching things further.
Yet I would be truely interested in understanding
how you have implemented a 'heavy' custom appliance
to provide custom decorating features to service
types.
Not so dramatic - just overloading of the the getURL function to return the object reference to somthing like corbaloc://home.osm.net/... and when you resolve the value of the service URL reference - guess what - it's in another JVM.
However, there is more work needed before
bringing these features out of the closet - namely the introduction
of a solution for remote service notification so that we can
synchronize deployment, suspension, re-deployment and decommissioning
actions across different JVMs.
Seems like time to get AltRMI into this act. (maybe it can be the hero of this movie one day :-) )
AltRMI has a role to play.
The script isn't finalized just yet.
Steve.
Regards, Vinay
__________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
