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.
