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]



Reply via email to