You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <pe...@apache.org> on 2002/08/28 12:16:48 UTC
Service as a first class types?
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.
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?
--
Cheers,
Peter Donald
---------------------------------------------------
Murphy's law - "Anything that can go wrong, will."
(Actually, this is Finagle's law, which in itself
shows that Finagle was right.)
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Service as a first class types?
Posted by Stephen McConnell <mc...@apache.org>.
Peter Royal wrote:
> On Wednesday 28 August 2002 09:45 am, Stephen McConnell wrote:
>
>>>>>>>No they are versioned java interfaces in most cases.
>>>>>>
>>>>>>Hmmm... there is no imposition about this in Serviceable... hmmm...
>>>>>
>>>>>But every container sans Merlin enforces this.
>>>>
>>>>Would you care to clarify this ...?
>>>>What exactly is it that you saying that Merlin does not enforce?
>>>
>>>For:
>>>
>>>MyService s = ServiceManager.lookup( serviceName );
>>>
>>>serviceName != MyService.getClass().getName() in merlin.
>>>
>>>(i think :)
>>
>>Which is a proxy feature - nothing to do with service version
>>enforcement. Merlin provides complete enforcement of service versioning.
>
>
> right.. its orthogonal. i thought that was what pete meant.. if not, i'm
> curious just like you :)
I guess we'll see.
Cheers, Steve.
> -pete
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Service as a first class types?
Posted by Peter Royal <pr...@apache.org>.
On Wednesday 28 August 2002 09:45 am, Stephen McConnell wrote:
> >>>>>No they are versioned java interfaces in most cases.
> >>>>
> >>>>Hmmm... there is no imposition about this in Serviceable... hmmm...
> >>>
> >>>But every container sans Merlin enforces this.
> >>
> >>Would you care to clarify this ...?
> >>What exactly is it that you saying that Merlin does not enforce?
> >
> > For:
> >
> > MyService s = ServiceManager.lookup( serviceName );
> >
> > serviceName != MyService.getClass().getName() in merlin.
> >
> > (i think :)
>
> Which is a proxy feature - nothing to do with service version
> enforcement. Merlin provides complete enforcement of service versioning.
right.. its orthogonal. i thought that was what pete meant.. if not, i'm
curious just like you :)
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Service as a first class types?
Posted by Stephen McConnell <mc...@apache.org>.
Peter Royal wrote:
> On Wednesday 28 August 2002 09:32 am, Stephen McConnell wrote:
>
>>Peter Donald wrote:
>>
>>>On Wed, 28 Aug 2002 23:16, Nicola Ken Barozzi wrote:
>>>
>>>>>No they are versioned java interfaces in most cases.
>>>>
>>>>Hmmm... there is no imposition about this in Serviceable... hmmm...
>>>
>>>But every container sans Merlin enforces this.
>>
>>Would you care to clarify this ...?
>>What exactly is it that you saying that Merlin does not enforce?
>
>
> For:
>
> MyService s = ServiceManager.lookup( serviceName );
>
> serviceName != MyService.getClass().getName() in merlin.
>
> (i think :)
Which is a proxy feature - nothing to do with service version
enforcement. Merlin provides complete enforcement of service versioning.
Cheers, Steve.
>
> -pete
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Service as a first class types?
Posted by Peter Royal <pr...@apache.org>.
On Wednesday 28 August 2002 09:32 am, Stephen McConnell wrote:
> Peter Donald wrote:
> > On Wed, 28 Aug 2002 23:16, Nicola Ken Barozzi wrote:
> >>>No they are versioned java interfaces in most cases.
> >>
> >>Hmmm... there is no imposition about this in Serviceable... hmmm...
> >
> > But every container sans Merlin enforces this.
>
> Would you care to clarify this ...?
> What exactly is it that you saying that Merlin does not enforce?
For:
MyService s = ServiceManager.lookup( serviceName );
serviceName != MyService.getClass().getName() in merlin.
(i think :)
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Service as a first class types?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Wed, 28 Aug 2002 23:16, Nicola Ken Barozzi wrote:
>
>>>No they are versioned java interfaces in most cases.
>>
>>Hmmm... there is no imposition about this in Serviceable... hmmm...
>
> But every container sans Merlin enforces this.
Ah, ok.
>>Ah, ok, I like this.
>>The doclet stuff, huh?
>>I thought it was already there :-)
>
> It is - but it uses a custome mechanism. Unification may be possible but it
> could also be a dose of everything looking like a nail ;)
;-)
>>But for this, I have the sense that it's overkill to get to this level,
>>to go down to /generic/ *method* attributes.
>>
>>So I can have Component lifestyle, method lifestyle... it gets me dizzy...
>
> lifestyle is an aggregation and interpretation of attributes and should not
> appear as one IMHO.
Yeah, we are saying the same thing, maybe.
>>Now we are getting to a point in which the metadata describes the role,
>>right?
>
> essentially.
I like it. Really.
It finally unifies all the ways a role is defined in one way.
>>1) use services via generic utility methods and loose strict type checking
>
>
> not really viable IMHO for programmer types like us ;)
;-)
>>2) make the interface by hand, or the metadata by hand, or both, and
>>have a doclet-like system that keeps *both* in sync.
>
> Right - either quite insane or quite brilliant.
=:-O
:-)
Whatever defines the role contract better, I like it.
But the devil is in the details, as always.
Can I dare? ;-)
I think that is we go down the metadata path, which is brilliant btw, we
should stop referencing roles as interfaces.
*BUT*
A role, from a programmer's POV *is* the interface, and whatever
language we use it will be used as such.
COM had a quite insane way of defining object access, because it didn't
use the contract wisely, and had C programmers have more access than VB
ones to the internals, but it did define a way for both to use COM.
A language doesn't even necessarily have to have interfaces to use COM,
it uses a kinda reflection invocation.
Now, if we have ROLE=metadata, the corresponding interfaces used are
just language *bindings* to the metadata, and *must* be generated
automatically.
This means that I can theoretically use cs stuff with java stuff via the
metadata, which creates an interface for each language to access the
component.
So, it comes to the point that creating interfaces by hand is bad (TM).
Hmmm...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Service as a first class types?
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
> On Wed, 28 Aug 2002 23:16, Nicola Ken Barozzi wrote:
>
>>>No they are versioned java interfaces in most cases.
>>
>>Hmmm... there is no imposition about this in Serviceable... hmmm...
>
>
> But every container sans Merlin enforces this.
Would you care to clarify this ...?
What exactly is it that you saying that Merlin does not enforce?
S.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Service as a first class types?
Posted by Peter Donald <pe...@apache.org>.
On Wed, 28 Aug 2002 23:16, Nicola Ken Barozzi wrote:
> > No they are versioned java interfaces in most cases.
>
> Hmmm... there is no imposition about this in Serviceable... hmmm...
But every container sans Merlin enforces this.
> Ah, ok, I like this.
> The doclet stuff, huh?
> I thought it was already there :-)
It is - but it uses a custome mechanism. Unification may be possible but it
could also be a dose of everything looking like a nail ;)
> But for this, I have the sense that it's overkill to get to this level,
> to go down to /generic/ *method* attributes.
>
> So I can have Component lifestyle, method lifestyle... it gets me dizzy...
lifestyle is an aggregation and interpretation of attributes and should not
appear as one IMHO.
> Now we are getting to a point in which the metadata describes the role,
> right?
essentially.
> 1) use services via generic utility methods and loose strict type checking
not really viable IMHO for programmer types like us ;)
> 2) make the interface by hand, or the metadata by hand, or both, and
> have a doclet-like system that keeps *both* in sync.
Right - either quite insane or quite brilliant.
--
Cheers,
Peter Donald
*------------------------------------------------*
| The student who is never required to do what |
| he cannot do never does what he can do. |
| - John Stuart Mill |
*------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Service as a first class types?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> 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.
Hmmm... there is no imposition about this in Serviceable... hmmm...
>>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).
Ok.
I didn't know a Service didn't have metadata, apart from the
COmponent->Object thing I don't see differences.
>>>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.
Ah, ok, I like this.
The doclet stuff, huh?
I thought it was already there :-)
> 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.
Hmmm... I understand.
But for this, I have the sense that it's overkill to get to this level,
to go down to /generic/ *method* attributes.
So I can have Component lifestyle, method lifestyle... it gets me dizzy...
> Hell - you could even dynamically assembly the interface using BCEL if the
> service is remote service or someother stuff by just looking at descriptor.
I thought of this, yes, or even wrap non-java stuff.
> However I am not sure that there is enough value in going down to that level
> of granularity or not.
Now we are getting to a point in which the metadata describes the role,
right?
Some thought that interfaces were the role, then we understood that some
didn't have methods and it was bad, so we used metadata.
Heck, go with metadata only and you have a formal role specification, right?
It's good, it finally defines a generic contract fot the Service that is
not merely a string or human-readable javadoc.
So, if I write a Service, I don't have to write the interface
theoretically, because the metdata *is* the interface (and more).
Now, how do I keep in sync the two (in case I define the Service, if I
use ready made I just can write the descriptor in xml)?
1) use services via generic utility methods and loose strict type checking
2) make the interface by hand, or the metadata by hand, or both, and
have a doclet-like system that keeps *both* in sync.
3) other?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Service as a first class types?
Posted by Peter Donald <pe...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Service as a first class types?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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?
If I use an existing service with no metadata, I loose the ability to
specify this?
> 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?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Service as a first class types?
Posted by Stephen McConnell <mc...@apache.org>.
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.
>
>
I like it.
It provides better seperation of a service defintions from
implementation defintions.
>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?
>
>
No immediate interest in doing this today.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Service as a first class types?
Posted by Peter Donald <pe...@apache.org>.
On Thu, 29 Aug 2002 07:00, Berin Loritsch wrote:
> > 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.
Thats not the hard bit. I am already enabling an interface to be marked as a
management interface via "mx:enabled=true". The problem is that I need to get
the descriptions of each operation, attribute and parameter which is not
possible without a more detailed metadata specification.
--
Cheers,
Peter Donald
--------------------------------
These aren't the droids you're
looking for. Move along.
--------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Service as a first class types?
Posted by Berin Loritsch <bl...@apache.org>.
> 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.
+1
> 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:
<service>
<interface>org.apache.cornerstone.foo.Foo</interface>
<version>1.0.0</version>
<management disabled="true"/>
<service>
<service>
<interface>org.apache.cornerstone.foo.Foo</interface>
<version>1.0.0</version>
<management>
<policy name="jmx"/>
<policy name="proxy"/>
<policy name="altrmi"/>
</management>
<service>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>