avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: Service as a first class types?
Date Wed, 28 Aug 2002 21:00:26 GMT
> From: Peter Donald [mailto:peter@apache.org] 
> Hi,
> I have been playing with the idea of having Services as first 
> class metadata 
> objects. By this I mean it would be possible to load a 
> ServiceInfo class. ie 
> You could load both ComponentInfo and ServiceInfo objects. 
> The ServiceInfo 
> objects would contain metadata specific to the object. 

Do you mean that ComponentInfo has metadata for the implementation
(i.e. object) and ServiceInfo has metadata for the interface?

If so +1.  I would like to add an attribute to a ServiceInfo so
that a Container that isolates its children knows that a particular
service needs to be exposed.

Case and point is an application that exposes a management interface
that is intended to be exposed to other applications in Phoenix.  For
those interfaces the kernel will create a Proxy for the service,
keeping each application in its own isolated space but exposing the
functionality to other applications.

> The advantages of this is that you associate metadata with a service 
> independent of an implementation. So this would allow you to 
> indicate that 
> all implementations of this service are pass-by-value objects 
> or support 
> soap/altrmi bindings. It would also allow us to generate 
> webpages for each 
> service aswell as each component.


> Secondly, what do you think of having metadata about 
> individual features in a 
> service (ie methods/propertys). If we were to do that then we 
> could pretty 
> much model any of the various component systems out there. It 
> would also get 
> rid of a bunch of "extra" descriptors (like the mxinfo stuff 
> in phoenix). 
> However it adds a massive amount of overhead - what doyou think?

Hmmm.  I presume you are speaking of mxinfo stuff.

What about using the afformentioned attribute to flag a Service
as a management interface.  From that point, all the mxinfo
stuff would be redundant because all the methods would be assumed
to be purposed for exposure to management.

Something like this would work:

<attribute name="management" value="jmx,proxy"/>

The possible values would be something like:

"jmx", "proxy", "none"

"none" would be mutually exclusive with everything.  All the other
attributes values would be separated by a comma and represent
additive layers.  Or something like this would be appropriate:


  <management disabled="true"/>


    <policy name="jmx"/>
    <policy name="proxy"/>
    <policy name="altrmi"/>

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message