You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Vinay Chandran <vi...@yahoo.com> on 2003/07/16 13:38:13 UTC
Custom Service Attributes
Folks,
meta.info.ServiceDescriptor javadoc talks of
supporting
attributes associated with service declarations.
(
"<p>Possible uses for the attributes are to declare a
service
* as "stateless", "pass-by-value", "remotable" or
even to attach
* attributes such as security or transaction
constraints.
"
)
A small peek into
org.apache.avalon.assembly.engine.impl.DefaultTypeRepository:line
443
reveals the presence of an attribute
'urn:avalon:service.type'.
Correct me here in my understanding of the reason
service attributes exist:-
Service attributes can be used by the container to
resolve
service implementations by its potential users.
One can build a infrastructure to exploit this to get
non-avalon component implementations
to be weaved in to the framework.
So extrapolating my understanding,
potentially I could define a component(AImpl)
implementing a serivice(A)
as (AImpl.xinfo) :-
<!-- AImpl.xinfo -->
<type>
<name>AImpl</name>
<services>
<!-- Standard -->
<service type="vinay.A"/>
<attruibutes>
<!-- Can be removed -->
<attribute
key="urn:avalon:service.type" value="native"/>
</attributes>
</service>
<!-- Custom -->
<service type="vinay.A">
<attruibutes>
<!-- Express an 'remote' service contract ,which
can be potentially be exploited to
create a 'public' contract to be used by external
clients
-->
<attribute
key="urn:avalon:service.type" value="remote"/>
</attributes>
</service>
</services>
</type>
This form of custom service types can be used to
create custom
means to export ( remote ) service(s) implemented by
a avalon component to the container.
Thus the above component(AImpl) in-addition to
implementing the service (A) also
expresses to the container that it intends to export
its service (A) to remote clients.
(How ??. One can use custom Service Resolvers/Handlers
at kernel level to export the service in its
custom fashion)
Moreover one can also exploit the notion of custom
service type declaration to create
services which are implemented as non-avalon
components.
Thus I can define a service(MySoapService) as a avalon
service by declaring a type
(MySoapService.xservice) as: -
<!-- MySoapService.xservice -->
<service>
<name> A Soap Service </name>
<attributes>
<attribute key="urn:avalon:service.type"
value="soap">
<attribute key="urn:soap.wsdl"
value="http://avalon.apache.org/your-soap.wsdl"/>
</attributes>
</service>
Any other component can lookup for this
service(MySoapService) using the SericeManager.
(Service Resolvers shall hook onto any custom service
types and provide a means to link the
service to the custom implementation associated with
the service)
Thus one can realize this by defining at a kernel(or
maybe a container) level a service resolver for
custom service types.
These handlers/resolvers can resolve the custom
service interface
and provide for the approriate implementation by
providing means to handle the declaration of
a custom service or by exporting the service.
I might have floated far off the intent custom
attribute were associated with services in this
explanation.
Thoughts?
Regards,
Vinay
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Custom Service Attributes
Posted by Vinay Chandran <vi...@yahoo.com>.
> 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!
>
I am not even a fish in a sea of sharks :-)) .
> >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).
>
Heading towards that direction.
> 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.
>
Interesting. But this is not as transparent as a
component developer might want it to be.
Getting service decorations out into the type
descriptors and their decorators/handlers into
block descriptors can provide a feature that can
be a really neat.
> AltRMI has a role to play.
>
> The script isn't finalized just yet.
>
Hopefully we can write one soon.
Regards,
Vinay
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Custom Service Attributes
Posted by Stephen McConnell <mc...@apache.org>.
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: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
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: Custom Service Attributes
Posted by Vinay Chandran <vi...@yahoo.com>.
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.
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).
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?
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.
> 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 :-) )
Regards,
Vinay
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Custom Service Attributes
Posted by Stephen McConnell <mc...@apache.org>.
Vinay Chandran wrote:
>Folks,
>
>meta.info.ServiceDescriptor javadoc talks of
>supporting
>attributes associated with service declarations.
>(
>"<p>Possible uses for the attributes are to declare a
>service
> * as "stateless", "pass-by-value", "remotable" or
>even to attach
> * attributes such as security or transaction
>constraints.
>"
>)
>A small peek into
>org.apache.avalon.assembly.engine.impl.DefaultTypeRepository:line
>443
>reveals the presence of an attribute
>'urn:avalon:service.type'.
>
>
>Correct me here in my understanding of the reason
>service attributes exist:-
>
>Service attributes can be used by the container to
>resolve
>service implementations by its potential users.
>One can build a infrastructure to exploit this to get
>non-avalon component implementations
>to be weaved in to the framework.
>
>
Yep.
>So extrapolating my understanding,
>potentially I could define a component(AImpl)
>implementing a serivice(A)
>as (AImpl.xinfo) :-
>
><!-- AImpl.xinfo -->
><type>
> <name>AImpl</name>
> <services>
> <!-- Standard -->
> <service type="vinay.A"/>
>
> <attruibutes>
> <!-- Can be removed -->
> <attribute
>key="urn:avalon:service.type" value="native"/>
> </attributes>
> </service>
>
> <!-- Custom -->
> <service type="vinay.A">
> <attruibutes>
> <!-- Express an 'remote' service contract ,which
>can be potentially be exploited to
> create a 'public' contract to be used by external
>clients
> -->
> <attribute
>key="urn:avalon:service.type" value="remote"/>
> </attributes>
> </service>
>
> </services>
></type>
>
>This form of custom service types can be used to
>create custom
>means to export ( remote ) service(s) implemented by
>a avalon component to the container.
>
Yep.
>Thus the above component(AImpl) in-addition to
>implementing the service (A) also
>expresses to the container that it intends to export
>its service (A) to remote clients.
>(How ??. One can use custom Service Resolvers/Handlers
>at kernel level to export the service in its
>custom fashion)
>
>
It is currently possible be declaring a custom appliance (which is kind
of heavy but its what I do when I'm working with components that
generate remotable services).
>
>Moreover one can also exploit the notion of custom
>service type declaration to create
>services which are implemented as non-avalon
>components.
>
Yep.
>
>Thus I can define a service(MySoapService) as a avalon
>service by declaring a type
>(MySoapService.xservice) as: -
>
><!-- MySoapService.xservice -->
><service>
> <name> A Soap Service </name>
> <attributes>
> <attribute key="urn:avalon:service.type"
>value="soap">
> <attribute key="urn:soap.wsdl"
>value="http://avalon.apache.org/your-soap.wsdl"/>
> </attributes>
></service>
>
>Any other component can lookup for this
>service(MySoapService) using the SericeManager.
>(Service Resolvers shall hook onto any custom service
>types and provide a means to link the
>service to the custom implementation associated with
>the service)
>
>
>
>Thus one can realize this by defining at a kernel(or
>maybe a container) level a service resolver for
>custom service types.
>These handlers/resolvers can resolve the custom
>service interface
>and provide for the approriate implementation by
>providing means to handle the declaration of
>a custom service or by exporting the service.
>
>
:-)
That's the principal.
>I might have floated far off the intent custom
>attribute were associated with services in this
>explanation.
>
>
>Thoughts?
>
You have been doing some deep digging! The reason for the existance of
all of these things your describing are related to distributed service
support. 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.
Cheers, Steve.
>
>Regards,
>Vinay
>
>
>__________________________________
>Do you Yahoo!?
>SBC Yahoo! DSL - Now only $29.95 per month!
>http://sbc.yahoo.com
>
>---------------------------------------------------------------------
>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
http://www.osm.net
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