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: [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]
