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