geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <james_strac...@yahoo.co.uk>
Subject Re: Kernel Architecture
Date Tue, 12 Aug 2003 11:54:30 GMT

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/


Mime
View raw message