avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: Service as a first class types?
Date Wed, 28 Aug 2002 13:02:59 GMT
On Wed, 28 Aug 2002 22:50, Nicola Ken Barozzi wrote:
> Peter Donald wrote:
> > 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.
> >
> > 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.
>
> Hmmm... are not services simply Objects?

No they are versioned java interfaces in most cases.

> If I use an existing service with no metadata, I loose the ability to
> specify this?

No - it just has no metadata associated with it (much like now).

> > 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 don't get the immediate value of repeating the method names
> somewhere else... hmmm...
>
> example?

the mxinfo files in phoenix essentially define management information for a 
component. As a result they include things like

<attribute
        name="addressString"
        description="Address String"
        isWriteable="no"
        type="java.lang.String"
      />

or

      <operation
        name="getServerPort"
        description="Returns port that the server listens on"
        type="java.lang.String"
      >
        <param
          name="instance"
          description="no description"
          type="java.lang.Integer"
        />
      </operation>

These are things that are needed to automagically assembly nicely looking 
MBeans.

There is also other value to this. Paul could add transaction or security 
attributes per method for EOB. He would then be capable of doing everything 
EJB could theoreitcally.

Hell - you could even dynamically assembly the interface using BCEL if the 
service is remote service or someother stuff by just looking at descriptor.

However I am not sure that there is enough value in going down to that level 
of granularity or not.

-- 
Cheers,

Peter Donald
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof."                   *
*              - John Kenneth Galbraith               *
*-----------------------------------------------------*


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


Mime
View raw message