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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
