You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by James deGraft-Johnson <jd...@digaman.com> on 2003/08/12 12:36:59 UTC
RE: Kernel Architecture
Hi,
I like the suggestion that even if we decide to go with the MBean model, a
layer be created, possibly via an interface so this software isn't tightly
coupled to MBeans.
Whatever we do, the ease of implementation, such as ease of kernel and
service development should be paramount. The easier it is to develop, the
greater the chances that we can focus on removing bugs and increasing
performance. (In particular, by ease I mean the extra code and it's
complexity needed to integrate kernel/service implementation into the
framework.) I think this requirement should be weighed against other
benefits of the alternative architectures.
James deGraft-Johnson
Software Engineer - IT
Verizon Information Services
Tel: (240) 456-7018
Fax: (240) 456-7072
Mobile: (240) 475-1444 <jd...@verizon-uc.com>
-----Original Message-----
From: Alex Blewitt [mailto:Alex.Blewitt@ioshq.com]
Sent: Tuesday, August 12, 2003 6:07 AM
To: geronimo-dev@incubator.apache.org
Subject: Re: Kernel Architecture (was [Re: JMX as a kernel ...])
I'd recommend having separate pages for each type, rather than
everything in one page.
I'd also like to suggest that there are different groups of
architectures, such as a MicroKernel architecture (of which Avalon and
HiveMind may be examples).
Alex.
On Tuesday, Aug 12, 2003, at 12:58 Europe/London, Richard Monson-Haefel
wrote:
> I've put the the skeleton of a new Wiki page to discuss the different
> kernel solutions proposed. It would be very helpful if supporters of
> each solution could post a description (plain english please) as well
> as pros and cons for any solution ... please add any solutions that
> I've missed. This will give us a better framework around which to
> discuss this topic.
>
> See the Kernel page listed from the Architecture page.
> http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheJ2EE/Architecture
>
> .
>
Re: Dynamic MBeans. Was: Kernel Architecture
Posted by Berin Loritsch <bl...@apache.org>.
James Strachan wrote:
>> Why can't we go for a totally dynamic MBean model?
>
>
> We absolutely could. I was trying to just come up with a simple
> convention component authors could follow - though we should be flexible.
>
>> Ie - for a given FooService, why do we need to write a FooServiceMBean
>> interface that just has the methods we wish to expose?
>
>
> No reason why we couldn't do that. Could use XDoclet or an XML config
> file or some clever build process to generate the MBean or dynamic
> MBeans whatever.
Hmmm. Avalon Pheonix currently does this. We might be able to adapt what
is there and use it here.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: Dynamic MBeans. Was: Kernel Architecture
Posted by Alex Blewitt <Al...@ioshq.com>.
On Tuesday, Aug 12, 2003, at 14:20 Europe/London, James Strachan wrote:
>
> On Tuesday, August 12, 2003, at 02:07 pm, Greg Wilkins wrote:
>>>> But by creating (and calling) them MBeans, you are tying it down to
>>>> a naming convention expected by JMX which may confuse the issue
>>>> later.
>>> Why? Whats confusing about it? Why would inventing yet-another-API
>>> be any less confusing?
>>
>> Why can't we go for a totally dynamic MBean model?
>
> We absolutely could. I was trying to just come up with a simple
> convention component authors could follow - though we should be
> flexible.
What about creating an interface, say, ManagedComponent, that component
authors could implement? Then we can move any JMX/MBean specific
behavoir into that interface (or an AbstractManagedComponent abstract
class) and let developers subclass that?
A convention like XxxComponent or XxxService may also be more
meaningful to developers. Are there any other major types of code in a
server? XxxAgent, Xxx??? If we can have placeholders for these, then
future components can be described as one (many?) of these.
>> Ie - for a given FooService, why do we need to write a FooServiceMBean
>> interface that just has the methods we wish to expose?
>
> No reason why we couldn't do that. Could use XDoclet or an XML config
> file or some clever build process to generate the MBean or dynamic
> MBeans whatever.
Yes, having an externalised/automatically generated MBean is probably a
good way to go.
>> I think we should be able to just create the FooService objects
>> and then describe any MBeans we want for them in XML - describing
>> the methods and the meta data in one spot.
>>
>> If we decide not to use MBeans, then we still have our FooService
>> objects and we have no FooServiceMBean objects clutering up the
>> repository.
>
> I'm cool with alternative forms of getting to the same place. i.e.
> however the MBeans are written - whether they are just POJOs or beans
> and we adorn them to be MBeans or we follow the MBean interface or we
> use some XML deployment descriptor for the MBean metadata - I'm easy.
> It can then be the developers choice.
>
> I personally quite like the MBean interface idea as it makes
> refactoring easier and your code has no dependencies on JMX - though
> we should be able to use better / simpler mechanisms for this.
IMHO the naming convention of MBean does tie it down, though; from the
JMX spec:
JMX_1-2 p37: "The name of an MBean's Java interface is formed by adding
the 'MBean' suffix to the MBean's fully qualified Java class name. For
example, the Java class MyClass would implement the MyClassMBean
interface"
Not having the naming convention would then make it clearer if MBeans
were not to be used later. However, the principles of still having the
getters/setters is a clear and easy step for developers to be able to
interact with it, in whatever means.
>> If we decide to use MBeans - it means that we will have fewer
>> undocumented MBeans without real meta data. We can also expose
>> more of an object simply by changing the MBean descriptor file.
>
> Agreed.
Externalising the MBean descriptors (and the subsequent automatically
generated code) might be a way of implementing security as an aspect on
top of that?
Alex.
Re: Dynamic MBeans. Was: Kernel Architecture
Posted by James Strachan <ja...@yahoo.co.uk>.
On Tuesday, August 12, 2003, at 02:07 pm, Greg Wilkins wrote:
> James Strachan wrote:
>
>>>> An interface based MBean is just a naming convention. There is no
>>>> tying to anything. Indeed there's not even a dependency on JMX
>>>> never mind any other container API. Then the container is totally
>>>> free to go in whatever direction it wishes.
>>>
>>>
>>> But by creating (and calling) them MBeans, you are tying it down to
>>> a naming convention expected by JMX which may confuse the issue
>>> later.
>> Why? Whats confusing about it? Why would inventing yet-another-API be
>> any less confusing?
>
>
> Why can't we go for a totally dynamic MBean model?
We absolutely could. I was trying to just come up with a simple
convention component authors could follow - though we should be
flexible.
> Ie - for a given FooService, why do we need to write a FooServiceMBean
> interface that just has the methods we wish to expose?
No reason why we couldn't do that. Could use XDoclet or an XML config
file or some clever build process to generate the MBean or dynamic
MBeans whatever.
> This is the simplest form of MBean, but contains no meta data to
> describe that MBean - which has to be placed in an xml file elsewhere.
Agreed - though at least it works :). i.e. its the minimum requirement
for a component/service author.
> I think we should be able to just create the FooService objects
> and then describe any MBeans we want for them in XML - describing
> the methods and the meta data in one spot.
>
> If we decide not to use MBeans, then we still have our FooService
> objects and we have no FooServiceMBean objects clutering up the
> repository.
I'm cool with alternative forms of getting to the same place. i.e.
however the MBeans are written - whether they are just POJOs or beans
and we adorn them to be MBeans or we follow the MBean interface or we
use some XML deployment descriptor for the MBean metadata - I'm easy.
It can then be the developers choice.
I personally quite like the MBean interface idea as it makes
refactoring easier and you're code has no dependencies on JMX - though
we should be able to use better / simpler mechanisms for this.
> If we decide to use MBeans - it means that we will have fewer
> undocumented MBeans without real meta data. We can also expose
> more of an object simply by changing the MBean descriptor file.
Agreed.
James
-------
http://radio.weblogs.com/0112098/
Re: Dynamic MBeans. Was: Kernel Architecture
Posted by Jens Schumann <je...@void.fm>.
On 8/12/03 06:10 PM Berin Loritsch <bl...@apache.org> wrote:
> Jens Schumann wrote:
>
>> I agree with you. However I still don't get the point why relying on JMX is
>> a critical factor, and usage of jakarta-commons* is considered harmful. JMX
>> is a specification and it is up to you to implement it.
>
> Umm, I don't recall saying anything about jakarta-commons*. I use code from
> there, and in general it is usually pretty good stuff.
Just an analogy. The only reason I switched from silently reading this ML to
posting a few comments is that I see a certain resistance to certain topics
just because religious reasons or something (and I don't say you did that;),
while other areas are out of discussion. Jakarta-commons* is one of those,
and to be honest, jakarta-commons* is a one way street with no return. And
it is not just me who believes in that;).
>> See above, it is a specification. And I don't say JMX based is the only
>> solution. But I believe most people here on the list talk about the
>> instrumentation level only.
>
> I understand that JMX is a specification. The only major real damage that
> I see here is one of the golden hammer. The temptation with any new tool
> is to go hog wild with it. I am usually much more conservative, and introduce
> the tool where I think it would help. IOW, I start small. Since JMX already
> has a place where it lends a big help, I am resistent to endorsing a path
> where
> it is the *only* solution. As long as we can make it *one* solution out of
> many, I will happily shut my trap.
>
> Since you mentioned moving back and forth between JMX enabled and JMX
> based is bad, that is yet another red flag that maybe we don't want to
> go down that road. But that is my conservative side talking. I'm not
> going to get in the way if you hell bent on going that direction. I'm
> just trying to find some balance here.
And I am on the other side;). JMX is there a couple of years. And I have to
admit that I love the power of JMX in loosely coupled component based
systems. While following the discussion here I felt some pain reading about
instrumentation only, so please consider taking a look at the agent services
provided through JMX. If they are worth nothing just ignore my posts.
In the end raising the red flag is valid, since switching back to JMX
enabled will be painful to impossible, as it is for switching to a JMX based
solution at some point.
Jens
Re: Dynamic MBeans. Was: Kernel Architecture
Posted by Berin Loritsch <bl...@apache.org>.
Jens Schumann wrote:
>>Von: Berin Loritsch <bl...@apache.org>
>>Antworten an: geronimo-dev@incubator.apache.org
>>Datum: Tue, 12 Aug 2003 11:39:44 -0400
>>An: geronimo-dev@incubator.apache.org
>>Betreff: Re: Dynamic MBeans. Was: Kernel Architecture
>>
>>Jens Schumann wrote:
>>
>>The thing is that there are certain compromises in the all-in-one box that
>>you have no control over. Usually the manufacturers of these boxes can only
>>spend money on one part of it, and they skimp on the rest. So it may have
>>a good tape player, but the CD player sucks (or vice versa).
>
>
> I agree with you. However I still don't get the point why relying on JMX is
> a critical factor, and usage of jakarta-commons* is considered harmful. JMX
> is a specification and it is up to you to implement it.
Umm, I don't recall saying anything about jakarta-commons*. I use code from
there, and in general it is usually pretty good stuff.
>
>
>>>In the end it all boils down to whether a system is JMX enabled or JMX
>>>based. Interestingly most projects I have seen moved to JMX enabled at some
>>>stage, since too much stuff was maintained in parallel. However the
>>>transition from one to the other model is something you should avoid (just
>>>take a look at tomcat 5).
>>
>><shudder/>
>>
>>Seriously though, I would much prefer to have JMX enabled than JMX based,
>>as we can have more fine tuned control where we need it. The JMX dynamic
>>classloading might be something causing problems instead of solving them.
>>If that happens, what is your recourse?
>
>
> See above, it is a specification. And I don't say JMX based is the only
> solution. But I believe most people here on the list talk about the
> instrumentation level only.
I understand that JMX is a specification. The only major real damage that
I see here is one of the golden hammer. The temptation with any new tool
is to go hog wild with it. I am usually much more conservative, and introduce
the tool where I think it would help. IOW, I start small. Since JMX already
has a place where it lends a big help, I am resistent to endorsing a path where
it is the *only* solution. As long as we can make it *one* solution out of
many, I will happily shut my trap.
Since you mentioned moving back and forth between JMX enabled and JMX
based is bad, that is yet another red flag that maybe we don't want to
go down that road. But that is my conservative side talking. I'm not
going to get in the way if you hell bent on going that direction. I'm
just trying to find some balance here.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: Dynamic MBeans. Was: Kernel Architecture
Posted by Jens Schumann <je...@void.fm>.
> Von: Berin Loritsch <bl...@apache.org>
> Antworten an: geronimo-dev@incubator.apache.org
> Datum: Tue, 12 Aug 2003 11:39:44 -0400
> An: geronimo-dev@incubator.apache.org
> Betreff: Re: Dynamic MBeans. Was: Kernel Architecture
>
> Jens Schumann wrote:
>
> The thing is that there are certain compromises in the all-in-one box that
> you have no control over. Usually the manufacturers of these boxes can only
> spend money on one part of it, and they skimp on the rest. So it may have
> a good tape player, but the CD player sucks (or vice versa).
I agree with you. However I still don't get the point why relying on JMX is
a critical factor, and usage of jakarta-commons* is considered harmful. JMX
is a specification and it is up to you to implement it.
>> In the end it all boils down to whether a system is JMX enabled or JMX
>> based. Interestingly most projects I have seen moved to JMX enabled at some
>> stage, since too much stuff was maintained in parallel. However the
>> transition from one to the other model is something you should avoid (just
>> take a look at tomcat 5).
>
> <shudder/>
>
> Seriously though, I would much prefer to have JMX enabled than JMX based,
> as we can have more fine tuned control where we need it. The JMX dynamic
> classloading might be something causing problems instead of solving them.
> If that happens, what is your recourse?
See above, it is a specification. And I don't say JMX based is the only
solution. But I believe most people here on the list talk about the
instrumentation level only.
Jens
Re: Dynamic MBeans. Was: Kernel Architecture
Posted by Berin Loritsch <bl...@apache.org>.
Jens Schumann wrote:
>>MBean != interface, and we should never use them as such. By following that
>>mantra, dynamic MBeans becomes a viable tool with few drawbacks.
>
>
> Well, this is true if you talk about the instrumentation level only. But if
> you trust in JMX agents for application management you are moving towards
> the MBean == interface analogy. In my opinion JMX offers a lot more than
> management, stuff you need to implement anyway: Dynamic Classloading,
> Notifications, Monitoring, Relations and Lifecycle of components.
My alarm bells go off every time I hear that an object should ever be considered
synonymous with a simple interface.
All of those other aspects: dynamic classloading, notifications, monitoring,
etc. can be addressed by other means--many times more effectively.
I get nervous when I here something slices, dices, makes julian fries, and
will not break (oops! it broke). That combination hooka and coffie maker
(get the movie reference now?) might better be served with different mechanisms.
For example, in the world of audio and home entertainment systems, you have
two camps:
1) The all in one jobbies--usually less expensive
2) Component systems--usually more expensive
The thing is that there are certain compromises in the all-in-one box that
you have no control over. Usually the manufacturers of these boxes can only
spend money on one part of it, and they skimp on the rest. So it may have
a good tape player, but the CD player sucks (or vice versa).
With the component systems, you can get exactly what you want for the job
at hand. If you don't want a tape player, you don't have to buy one. If
you really care about your CD player, you can spend money on a good one.
In other words, if something isn't up to snuff you have the ability to swap
it out at any time for a better component. You aren't stuck with what the
initial manufacturer decided was best for you.
> In the end it all boils down to whether a system is JMX enabled or JMX
> based. Interestingly most projects I have seen moved to JMX enabled at some
> stage, since too much stuff was maintained in parallel. However the
> transition from one to the other model is something you should avoid (just
> take a look at tomcat 5).
<shudder/>
Seriously though, I would much prefer to have JMX enabled than JMX based,
as we can have more fine tuned control where we need it. The JMX dynamic
classloading might be something causing problems instead of solving them.
If that happens, what is your recourse?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: Dynamic MBeans. Was: Kernel Architecture
Posted by Jens Schumann <je...@void.fm>.
> Von: Berin Loritsch <bl...@apache.org>
>
>
> Consider for a moment the purpose of MBeans. They are to allow a management
> console to control aspects of your software. So they were originally created
> to provide an end user a way to control the guts of software. They were not
> created to provide a direct programmatic interface to the underlying software.
>
> So if you lookup your components and access them by a direct Java interface,
> then you can easily remote that component, control the inheritance structure,
> and still have the benefit of what JMX was designed for.
>
I think it depends on how much of your application is moved to the JMX
model. If you use it as a simple add on (which was the initial intend of
JMX, and it looks like you are moving towards that direction) then I would
agree. But the JMX spec also contains the agent specification, and thus
being said manageable aspects of software can (and in my opinion should) be
much more than providing a simple management interface to application
components.
> MBean != interface, and we should never use them as such. By following that
> mantra, dynamic MBeans becomes a viable tool with few drawbacks.
Well, this is true if you talk about the instrumentation level only. But if
you trust in JMX agents for application management you are moving towards
the MBean == interface analogy. In my opinion JMX offers a lot more than
management, stuff you need to implement anyway: Dynamic Classloading,
Notifications, Monitoring, Relations and Lifecycle of components.
In the end it all boils down to whether a system is JMX enabled or JMX
based. Interestingly most projects I have seen moved to JMX enabled at some
stage, since too much stuff was maintained in parallel. However the
transition from one to the other model is something you should avoid (just
take a look at tomcat 5).
Jens
Re: Dynamic MBeans. Was: Kernel Architecture
Posted by Berin Loritsch <bl...@apache.org>.
Jens Schumann wrote:
>>Von: Greg Wilkins <gr...@mortbay.com>
>>
>>
>>Why can't we go for a totally dynamic MBean model?
>>
>
>
> Just a few thoughts:
>
> - With JMX 1.2 (maybe with 1.1, can't remember when SimpleMBeans where
> introduced) you get meta data for SimpleMBeans.
> - With dynamic Mbeans you loose your concrete interface, and with it a
> simple way to create proxies to them (remote access etc.)
> - Don't forget inheritance - in my opinion pretty dangerous by using Dynamic
> MBeans.
Consider for a moment the purpose of MBeans. They are to allow a management
console to control aspects of your software. So they were originally created
to provide an end user a way to control the guts of software. They were not
created to provide a direct programmatic interface to the underlying software.
So if you lookup your components and access them by a direct Java interface,
then you can easily remote that component, control the inheritance structure,
and still have the benefit of what JMX was designed for.
MBean != interface, and we should never use them as such. By following that
mantra, dynamic MBeans becomes a viable tool with few drawbacks.
Remember, JMX is a tool but a golden hammer it is not.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: Dynamic MBeans. Was: Kernel Architecture
Posted by Jens Schumann <je...@void.fm>.
> Von: Greg Wilkins <gr...@mortbay.com>
>
>
> Why can't we go for a totally dynamic MBean model?
>
Just a few thoughts:
- With JMX 1.2 (maybe with 1.1, can't remember when SimpleMBeans where
introduced) you get meta data for SimpleMBeans.
- With dynamic Mbeans you loose your concrete interface, and with it a
simple way to create proxies to them (remote access etc.)
- Don't forget inheritance - in my opinion pretty dangerous by using Dynamic
MBeans.
Jens
Re: Dynamic MBeans. Was: Kernel Architecture
Posted by David Jencks <da...@snappydsl.net>.
Using model mbeans instead of standard mbeans has many advantages. As
I recall someone (Simone?) offered to write an xmbean model mbean for
mx4j. We can use the xdoclet JBoss xmbean template as a starting point
and generate the xml descriptor from the source.
For now we can generate standard mbean interfaces and, when we get an
xmbean impl. switch over with minimal effort. Including appropriate
documentation now will make the switch easier.
Is xdoclet being used in the current build system?
david jencks
On Tuesday, August 12, 2003, at 09:07 AM, Greg Wilkins wrote:
>
>
> James Strachan wrote:
>
>>>> An interface based MBean is just a naming convention. There is no
>>>> tying to anything. Indeed there's not even a dependency on JMX
>>>> never mind any other container API. Then the container is totally
>>>> free to go in whatever direction it wishes.
>>>
>>>
>>> But by creating (and calling) them MBeans, you are tying it down to
>>> a naming convention expected by JMX which may confuse the issue
>>> later.
>> Why? Whats confusing about it? Why would inventing yet-another-API be
>> any less confusing?
>
>
> Why can't we go for a totally dynamic MBean model?
>
> Ie - for a given FooService, why do we need to write a FooServiceMBean
> interface that just has the methods we wish to expose?
>
> This is the simplest form of MBean, but contains no meta data to
> describe that MBean - which has to be placed in an xml file elsewhere.
>
> I think we should be able to just create the FooService objects
> and then describe any MBeans we want for them in XML - describing
> the methods and the meta data in one spot.
>
> If we decide not to use MBeans, then we still have our FooService
> objects and we have no FooServiceMBean objects clutering up the
> repository.
>
> If we decide to use MBeans - it means that we will have fewer
> undocumented MBeans without real meta data. We can also expose
> more of an object simply by changing the MBean descriptor file.
>
>
> --
> Greg Wilkins<gr...@mortbay.com> Phone/fax: +44 7092063462
> Mort Bay Consulting Australia and UK. http://www.mortbay.com
>
Re: Dynamic MBeans. Was: Kernel Architecture
Posted by Alex Blewitt <Al...@ioshq.com>.
On Tuesday, Aug 12, 2003, at 14:07 Europe/London, Greg Wilkins wrote:
> James Strachan wrote:
>
>>>> An interface based MBean is just a naming convention. There is no
>>>> tying to anything. Indeed there's not even a dependency on JMX
>>>> never mind any other container API. Then the container is totally
>>>> free to go in whatever direction it wishes.
>>> But by creating (and calling) them MBeans, you are tying it down to
>>> a naming convention expected by JMX which may confuse the issue
>>> later.
>> Why? Whats confusing about it? Why would inventing yet-another-API be
>> any less confusing?
>
> Why can't we go for a totally dynamic MBean model?
Yes, this is precisely the kind of thing I was working towards. In the
code sample posted earlier, I wanted to demonstrate how it could be
done to avoid dependency on the JMX spec of calling things MBean, but
still provide that as a service. There's no reason why it couldn't be
achieved using a dynamic interface instead.
> This is the simplest form of MBean, but contains no meta data to
> describe that MBean - which has to be placed in an xml file elsewhere.
>
> If we decide not to use MBeans, then we still have our FooService
> objects and we have no FooServiceMBean objects clutering up the
> repository.
Yes, the less clutter (and dependency on MBeans) the better.
> If we decide to use MBeans - it means that we will have fewer
> undocumented MBeans without real meta data. We can also expose
> more of an object simply by changing the MBean descriptor file.
Agree completely.
Alex.
Dynamic MBeans. Was: Kernel Architecture
Posted by Greg Wilkins <gr...@mortbay.com>.
James Strachan wrote:
>>> An interface based MBean is just a naming convention. There is no
>>> tying to anything. Indeed there's not even a dependency on JMX never
>>> mind any other container API. Then the container is totally free to
>>> go in whatever direction it wishes.
>>
>>
>> But by creating (and calling) them MBeans, you are tying it down to a
>> naming convention expected by JMX which may confuse the issue later.
>
>
> Why? Whats confusing about it? Why would inventing yet-another-API be
> any less confusing?
Why can't we go for a totally dynamic MBean model?
Ie - for a given FooService, why do we need to write a FooServiceMBean
interface that just has the methods we wish to expose?
This is the simplest form of MBean, but contains no meta data to
describe that MBean - which has to be placed in an xml file elsewhere.
I think we should be able to just create the FooService objects
and then describe any MBeans we want for them in XML - describing
the methods and the meta data in one spot.
If we decide not to use MBeans, then we still have our FooService
objects and we have no FooServiceMBean objects clutering up the
repository.
If we decide to use MBeans - it means that we will have fewer
undocumented MBeans without real meta data. We can also expose
more of an object simply by changing the MBean descriptor file.
--
Greg Wilkins<gr...@mortbay.com> Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK. http://www.mortbay.com
Re: Kernel Architecture
Posted by Alex Blewitt <Al...@ioshq.com>.
On Tuesday, Aug 12, 2003, at 14:42 Europe/London, James Strachan wrote:
>
> On Tuesday, August 12, 2003, at 02:17 pm, Alex Blewitt wrote:
>> On Tuesday, Aug 12, 2003, at 12:54 Europe/London, James Strachan
>> wrote:
>>> On Tuesday, August 12, 2003, at 12:27 pm, Alex Blewitt wrote:
>>>>
>>>> But by creating (and calling) them MBeans, you are tying it down to
>>>> a naming convention expected by JMX which may confuse the issue
>>>> later.
>>>
>>> Why? Whats confusing about it? Why would inventing yet-another-API
>>> be any less confusing?
>>
>> Becuase the MBeans are the naming convention for JMX beans. Call them
>> something else, then you don't have the dependency.
>>
>> A naming convention is as much a dependency as a code requirement.
>
> Huh?
Sorry, didn't explain myself well on that one. The JMX spec dictates
that a MBean exposes itself through an interface called XxxMBean.
Therefore, if you also create interfaces/classes that end XxxMBean,
it's not just a convention. It's the way it's done in JMX containers,
and by virtue of ending interfaces in XxxMBean then (a) you allow that
to be managed by a JMX container, but also (b) it may become dependent
on a JMX container to run in. Further, external developers who see
XxxMBean will assume that it is a JMX MBean, even if it isn't meant to
be.
If I had a class called SimpleSingleton, you'd be very surprised if it
was a pop-up dialog box to ask for a file name. Names are just as
important as the implementation, since it can mean something specific
to developers. And the extension XxxMBean means a JMX managed bean.
>> True, which is why I suggested creating an MBean container to run
>> within Geronimo.
>
> We've already got one - its in CVS.
Yes, I know, but I was suggesting that a J2EE server should be
implemented as a MicroKernel architecture, and then (along with
WebContainer and EJBContainer) provide an MBeanContainer for supporting
legacy MBeans. That doesn't necessarily imply that everything needs to
be an MBean, or that a J2EE server should be implemented using JMX, in
much the same way that it wouldn't necessarily make sense to create a
J2EE server that used Servlets for all of its implementation (though
clearly, it could be done).
> We want to support MBeans as we already have MBeans and an MBean
> container and plenty of external MBeans we wish to reuse. We want to
> be fully JSR 77 and 88 compliant.
Neither JSR 77 or 88 say that the system must be implemented as MBeans
though; they merely show a way of providing an MBean interface. As Greg
suggested, these interfaces could be dynamically generated from XML
files on top of implementations that are MBean agnostic.
> There's no reason why you Alex can't write your own AlexContainer and
> drop it into Geronimo and support any component model you wish. Ditto
> for Avalon & PicoContainers etc.
I believe that the idea of Avalon as a Kernel is to sit under the JMX
level, not on top of it. I don't see those as being implemented using
JMX.
>>>> The more JMX dependencies that get added now, the more difficult it
>>>> will be to change at a later stage. So by abstracting into a common
>>>> super type(s) now, we can write to a generic API that will be
>>>> easier to migrate later, rather than having everything being
>>>> MBean-based.
>>>
>>> There are no dependencies. Its a very common *naming-convention*
>>> used throughout the J2EE world. I don't see any problem using this
>>> established standard rather than yet-another-container-API.
>>
>> It isn't a common naming convention.
>
> Look in the codebases of Geronimo, Tomcat, Jetty, JBoss, mx4j and
> others.
They use it /because/ they implement JMX beans. It's not because it's a
naming convention.
Of course, it's hardly surprising that mx4j uses a lot of MBeans --
after all, that is the Apache JMX implementation :-)
And, as already has been set, JBoss uses JMX MBeans for all of its work.
>> And the point of this discussion, and the rest of the threads
>> regarding this (including the Wiki pages) is to think of how it could
>> be done in different ways, and propose advantages/disadvantages.
>
> Sure lets by all means brainstorm and think of what the future
> container could be. However remember what the goal of Geronimo is - to
> create a full J2EE stack. It doesn't have to have the ultimate J2EE
> container framework inside it from day one.
I never meant to imply that it was, nor that work could not start
immediately on new services. Indeed, a few proposals have already been
made that would (a) allow developers to get started on writing new
services immediately, whilst at the same time (b) not being dependent
on the MBean JMX spec/naming convention. At a later stage, ideas may
surface for a replacement kernel, or they may never arise.
> The writing of other J2EE services is *high* priority and absolute
> requirement. Thinking up an alternative component model to MBeans is
> quite low IMHO - its a nice to have, not a requirement.
Absolutely agree.
> I don't want developers wishing to integrate the multitude of other
> parts to get J2EE compliance to sit and wait for some new component
> model which may or may not come out of some brainstorming session. If
> another component model comes along in the future we can look at using
> it. Until then I firmly believe our best course of action is to use
> MBeans as the default component model for course grained services -
> and plug anything else in using some custom adapters/containers.
I'd also agree with this as well.
But I think there is a happy compromise by providing some abstract
classes (Service, ManagedComponent, whatever) that provide the MBean
interface whilst allowing subclasses to be MBean agnostic. That way, we
get the benefits of being able to develop (and run) stuff immediately
whilst still initially using the MBean model, and then migrate as and
when other kernels become available.
Alex.
Re: Kernel Architecture
Posted by James Strachan <ja...@yahoo.co.uk>.
On Tuesday, August 12, 2003, at 02:17 pm, Alex Blewitt wrote:
> On Tuesday, Aug 12, 2003, at 12:54 Europe/London, James Strachan wrote:
>> On Tuesday, August 12, 2003, at 12:27 pm, Alex Blewitt wrote:
>>> On Tuesday, Aug 12, 2003, at 12:17 Europe/London, James Strachan
>>> wrote:
>>>> On Tuesday, August 12, 2003, at 11:36 am, James deGraft-Johnson
>>>> wrote:
>>>>
>>>>> I like the suggestion that even if we decide to go with the MBean
>>>>> model, a
>>>>> layer be created, possibly via an interface so this software isn't
>>>>> tightly
>>>>> coupled to MBeans.
>>>>
>>>> An interface based MBean is just a naming convention. There is no
>>>> tying to anything. Indeed there's not even a dependency on JMX
>>>> never mind any other container API. Then the container is totally
>>>> free to go in whatever direction it wishes.
>>>
>>> But by creating (and calling) them MBeans, you are tying it down to
>>> a naming convention expected by JMX which may confuse the issue
>>> later.
>>
>> Why? Whats confusing about it? Why would inventing yet-another-API be
>> any less confusing?
>
> Becuase the MBeans are the naming convention for JMX beans. Call them
> something else, then you don't have the dependency.
>
> A naming convention is as much a dependency as a code requirement.
Huh?
>>> Changing things after they've been done is much more difficult than
>>> before they've been done :-)
>>
>> If thats your argument then its already too late to change away from
>> MBeans. Geronimo has plenty of MBeans already - so has Tomcat, Jetty,
>> JBoss etc. Any container should be able to easily work with these
>> components today irrespective of tomorrows container.
>
> True, which is why I suggested creating an MBean container to run
> within Geronimo.
We've already got one - its in CVS.
>>>>> Whatever we do, the ease of implementation, such as ease of kernel
>>>>> and
>>>>> service development should be paramount. The easier it is to
>>>>> develop, the
>>>>> greater the chances that we can focus on removing bugs and
>>>>> increasing
>>>>> performance.
>>>> Agreed.
>>>>
>>>> Which is why I think us all developing MBeans to start with is the
>>>> easiest approach. They are very simple. Take a look at some of them
>>>> in CVS (they end with *MBean.java)
>>>
>>> But creating a category of different types (Service, Component etc.)
>>> that developers implement is even easier. Ideally, those two should
>>> be the only two types that implement any kind of MBean interface;
>>> and the remainder of the code developed /doesn't/ need to have the
>>> MBean suffix.
>>
>> I don't see the need as this appears to be unnecessary coupling.
>> However be that as it may - it doesn't change the original premise -
>> of writing MBeans for now until we come up with something better
>> later on. Afterall we have lots of MBeans today we should support.
>
> We can introduce the new types, and write to them, and then refactor
> existing code over. Why the fuss about MBeans? We could still support
> existing MBeans in an MBeanContainer.
We want to support MBeans as we already have MBeans and an MBean
container and plenty of external MBeans we wish to reuse. We want to be
fully JSR 77 and 88 compliant.
There's no reason why you Alex can't write your own AlexContainer and
drop it into Geronimo and support any component model you wish. Ditto
for Avalon & PicoContainers etc.
>
>>> The more JMX dependencies that get added now, the more difficult it
>>> will be to change at a later stage. So by abstracting into a common
>>> super type(s) now, we can write to a generic API that will be easier
>>> to migrate later, rather than having everything being MBean-based.
>>
>> There are no dependencies. Its a very common *naming-convention* used
>> throughout the J2EE world. I don't see any problem using this
>> established standard rather than yet-another-container-API.
>
> It isn't a common naming convention.
???
Look in the codebases of Geronimo, Tomcat, Jetty, JBoss, mx4j and
others.
> It's the JMX spec. The reason why it's used 'Throughout the J2EE
> world' is because that's the way that JBoss does it. Many other J2EE
> servers don't.
So?
> And the point of this discussion, and the rest of the threads
> regarding this (including the Wiki pages) is to think of how it could
> be done in different ways, and propose advantages/disadvantages.
Sure lets by all means brainstorm and think of what the future
container could be. However remember what the goal of Geronimo is - to
create a full J2EE stack. It doesn't have to have the ultimate J2EE
container framework inside it from day one.
The point of my original thread was to get us started writing services
that bind into the existing JMX based container along with the existing
MBeans in Geronimo, Tomcat, Jetty, mx4j and elsewhere while allowing
those interested in the internals of the container to go off in their
own direction in parallel. The writing of other J2EE services is *high*
priority and absolute requirement. Thinking up an alternative component
model to MBeans is quite low IMHO - its a nice to have, not a
requirement.
I don't want developers wishing to integrate the multitude of other
parts to get J2EE compliance to sit and wait for some new component
model which may or may not come out of some brainstorming session. If
another component model comes along in the future we can look at using
it. Until then I firmly believe our best course of action is to use
MBeans as the default component model for course grained services - and
plug anything else in using some custom adapters/containers.
James
-------
http://radio.weblogs.com/0112098/
Re: Kernel Architecture
Posted by Alex Blewitt <Al...@ioshq.com>.
On Tuesday, Aug 12, 2003, at 12:54 Europe/London, James Strachan wrote:
>
> On Tuesday, August 12, 2003, at 12:27 pm, Alex Blewitt wrote:
>
>> On Tuesday, Aug 12, 2003, at 12:17 Europe/London, James Strachan
>> wrote:
>>
>>> On Tuesday, August 12, 2003, at 11:36 am, James deGraft-Johnson
>>> wrote:
>>>
>>>> I like the suggestion that even if we decide to go with the MBean
>>>> model, a
>>>> layer be created, possibly via an interface so this software isn't
>>>> tightly
>>>> coupled to MBeans.
>>>
>>> An interface based MBean is just a naming convention. There is no
>>> tying to anything. Indeed there's not even a dependency on JMX never
>>> mind any other container API. Then the container is totally free to
>>> go in whatever direction it wishes.
>>
>> But by creating (and calling) them MBeans, you are tying it down to a
>> naming convention expected by JMX which may confuse the issue later.
>
> Why? Whats confusing about it? Why would inventing yet-another-API be
> any less confusing?
Becuase the MBeans are the naming convention for JMX beans. Call them
something else, then you don't have the dependency.
A naming convention is as much a dependency as a code requirement.
>> Changing things after they've been done is much more difficult than
>> before they've been done :-)
>
> If thats your argument then its already too late to change away from
> MBeans. Geronimo has plenty of MBeans already - so has Tomcat, Jetty,
> JBoss etc. Any container should be able to easily work with these
> components today irrespective of tomorrows container.
True, which is why I suggested creating an MBean container to run
within Geronimo.
>>>> Whatever we do, the ease of implementation, such as ease of kernel
>>>> and
>>>> service development should be paramount. The easier it is to
>>>> develop, the
>>>> greater the chances that we can focus on removing bugs and
>>>> increasing
>>>> performance.
>>> Agreed.
>>>
>>> Which is why I think us all developing MBeans to start with is the
>>> easiest approach. They are very simple. Take a look at some of them
>>> in CVS (they end with *MBean.java)
>>
>> But creating a category of different types (Service, Component etc.)
>> that developers implement is even easier. Ideally, those two should
>> be the only two types that implement any kind of MBean interface; and
>> the remainder of the code developed /doesn't/ need to have the MBean
>> suffix.
>
> I don't see the need as this appears to be unnecessary coupling.
> However be that as it may - it doesn't change the original premise -
> of writing MBeans for now until we come up with something better later
> on. Afterall we have lots of MBeans today we should support.
We can introduce the new types, and write to them, and then refactor
existing code over. Why the fuss about MBeans? We could still support
existing MBeans in an MBeanContainer.
>> The more JMX dependencies that get added now, the more difficult it
>> will be to change at a later stage. So by abstracting into a common
>> super type(s) now, we can write to a generic API that will be easier
>> to migrate later, rather than having everything being MBean-based.
>
> There are no dependencies. Its a very common *naming-convention* used
> throughout the J2EE world. I don't see any problem using this
> established standard rather than yet-another-container-API.
It isn't a common naming convention. It's the JMX spec. The reason why
it's used 'Throughout the J2EE world' is because that's the way that
JBoss does it. Many other J2EE servers don't.
And the point of this discussion, and the rest of the threads regarding
this (including the Wiki pages) is to think of how it could be done in
different ways, and propose advantages/disadvantages.
Alex.
Re: Kernel Architecture
Posted by James Strachan <ja...@yahoo.co.uk>.
On Tuesday, August 12, 2003, at 12:27 pm, Alex Blewitt wrote:
> On Tuesday, Aug 12, 2003, at 12:17 Europe/London, James Strachan wrote:
>
>> On Tuesday, August 12, 2003, at 11:36 am, James deGraft-Johnson
>> wrote:
>>
>>> I like the suggestion that even if we decide to go with the MBean
>>> model, a
>>> layer be created, possibly via an interface so this software isn't
>>> tightly
>>> coupled to MBeans.
>>
>> An interface based MBean is just a naming convention. There is no
>> tying to anything. Indeed there's not even a dependency on JMX never
>> mind any other container API. Then the container is totally free to
>> go in whatever direction it wishes.
>
> But by creating (and calling) them MBeans, you are tying it down to a
> naming convention expected by JMX which may confuse the issue later.
Why? Whats confusing about it? Why would inventing yet-another-API be
any less confusing?
> Changing things after they've been done is much more difficult than
> before they've been done :-)
If thats your argument then its already too late to change away from
MBeans. Geronimo has plenty of MBeans already - so has Tomcat, Jetty,
JBoss etc. Any container should be able to easily work with these
components today irrespective of tomorrows container.
>
>>> Whatever we do, the ease of implementation, such as ease of kernel
>>> and
>>> service development should be paramount. The easier it is to
>>> develop, the
>>> greater the chances that we can focus on removing bugs and increasing
>>> performance.
>> Agreed.
>>
>> Which is why I think us all developing MBeans to start with is the
>> easiest approach. They are very simple. Take a look at some of them
>> in CVS (they end with *MBean.java)
>
> But creating a category of different types (Service, Component etc.)
> that developers implement is even easier. Ideally, those two should be
> the only two types that implement any kind of MBean interface; and the
> remainder of the code developed /doesn't/ need to have the MBean
> suffix.
I don't see the need as this appears to be unnecessary coupling.
However be that as it may - it doesn't change the original premise - of
writing MBeans for now until we come up with something better later on.
Afterall we have lots of MBeans today we should support.
> The more JMX dependencies that get added now, the more difficult it
> will be to change at a later stage. So by abstracting into a common
> super type(s) now, we can write to a generic API that will be easier
> to migrate later, rather than having everything being MBean-based.
There are no dependencies. Its a very common *naming-convention* used
throughout the J2EE world. I don't see any problem using this
established standard rather than yet-another-container-API.
James
-------
http://radio.weblogs.com/0112098/
Re: Kernel Architecture
Posted by Alex Blewitt <Al...@ioshq.com>.
On Tuesday, Aug 12, 2003, at 12:17 Europe/London, James Strachan wrote:
> On Tuesday, August 12, 2003, at 11:36 am, James deGraft-Johnson wrote:
>
>> I like the suggestion that even if we decide to go with the MBean
>> model, a
>> layer be created, possibly via an interface so this software isn't
>> tightly
>> coupled to MBeans.
>
> An interface based MBean is just a naming convention. There is no
> tying to anything. Indeed there's not even a dependency on JMX never
> mind any other container API. Then the container is totally free to go
> in whatever direction it wishes.
But by creating (and calling) them MBeans, you are tying it down to a
naming convention expected by JMX which may confuse the issue later.
Changing things after they've been done is much more difficult than
before they've been done :-)
>> Whatever we do, the ease of implementation, such as ease of kernel and
>> service development should be paramount. The easier it is to develop,
>> the
>> greater the chances that we can focus on removing bugs and increasing
>> performance.
> Agreed.
>
> Which is why I think us all developing MBeans to start with is the
> easiest approach. They are very simple. Take a look at some of them in
> CVS (they end with *MBean.java)
But creating a category of different types (Service, Component etc.)
that developers implement is even easier. Ideally, those two should be
the only two types that implement any kind of MBean interface; and the
remainder of the code developed /doesn't/ need to have the MBean suffix.
The more JMX dependencies that get added now, the more difficult it
will be to change at a later stage. So by abstracting into a common
super type(s) now, we can write to a generic API that will be easier to
migrate later, rather than having everything being MBean-based.
Alex.
Re: Kernel Architecture
Posted by James Strachan <ja...@yahoo.co.uk>.
On Tuesday, August 12, 2003, at 11:36 am, James deGraft-Johnson wrote:
> Hi,
>
> I like the suggestion that even if we decide to go with the MBean
> model, a
> layer be created, possibly via an interface so this software isn't
> tightly
> coupled to MBeans.
An interface based MBean is just a naming convention. There is no tying
to anything. Indeed there's not even a dependency on JMX never mind any
other container API. Then the container is totally free to go in
whatever direction it wishes.
> Whatever we do, the ease of implementation, such as ease of kernel and
> service development should be paramount. The easier it is to develop,
> the
> greater the chances that we can focus on removing bugs and increasing
> performance. (In particular, by ease I mean the extra code and it's
> complexity needed to integrate kernel/service implementation into the
> framework.) I think this requirement should be weighed against other
> benefits of the alternative architectures.
Agreed.
Which is why I think us all developing MBeans to start with is the
easiest approach. They are very simple. Take a look at some of them in
CVS (they end with *MBean.java)
James
-------
http://radio.weblogs.com/0112098/