JMX Service implementation question

[obrand]

Hello all,

I am fairly new in the JMX development. I am highly interested in the architecture that JBoss is using in order to initialize all J2EE components.
I have a framework/JMX question, which might be trivial for more advanced users though:

Let's take a scenario where I am coding a Protocol Adapter Loader MBean which returns a specific Protocol Adapter (RMI, EJB, ...) which can be used to connect to specific adapters EAI adapter, ...).

When the system starts the service gets configured.

Now, a service exposes manageable methods which I believe will be used by other components (J2SE in my case) in order to reach a specific adapter (which can be coded using J2EE technology such as EJB).

My question is: Is there a drawback to use a JMX interface in term of performance ? I am thinking of having this JMX layer implementing a ServiceLocator type of functionality. A Business Delegate, hiding the JMX layer, will then be used by the client.

In Jboss, how is the service implemented ? Who is instantiating the business object representing the service ? Is it the MBean ? Are they combined into one object ? What about having a Singleton type of service ? (are you solving this by just enforcing the uniqueness of the ObjectName object) ?

[adrian.brock]

I agree and in fact it is the other way around. Meaning that JMX 160
invokers are just specific instances of the framework assembly.
(DP+interceptors+invokers). Adrian was right me tying the invokers to
JMX is not the way to go for 4.0. Detach it further and we may be done.


marcf> There seems to be some overlap here and merging
> functionality with existing
> components should be occurring here. If an existing
> component like clustering
> has to be refactored to support a subset or alternate
> implementation as
> required for JMX that should be done if possible. I
> find it hard to believe
> that the JMX remoting spec is sufficient for all of
> what need for 4.0 though.
> Where is the JSR160 spec so we can gauge the scope of
> what is to be
> achieved?
>
> xxxxxxxxxxxxxxxxxxxxxxxx
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
> xxxxxxxxxxxxxxxxxxxxxxxx
>
> > Negative,
> >
> > See the argument made by adrian on why connectors
> > shouldn't be tied to
> > JMX (posted on the JMX forum I think). Most of
> the
> > aspect framework
> > will use remoting as a feature, expecting all
> these
> > objects to be mbeans
> > is silly. The architecture being worked on is a
> > proxy with a logical
> > name (mbeanname or just any key) and the reifed
> > invoke. The handler
> > today directly calls the JMX mbus but really
> should
> > be a lookup with a
> > handler (and a specific JMX handler would convert
> the
> > calls to the
> > invoke(mbean) call of the JMX spec. These are
> > however specific cases.
> >
> > What is interesting in the jmx work is the
> > discovery/callback/remote
> > class loading. Can I ask you guys to not move the
> > invokers in the MX
> > layer but really make the unified invokers enabled
> > with these features.
> > Bill you should be on that one. Keep adrian in
> the
> > loop he is the first
> > one that saw the way to do it, in fact tying the
> > invokers to JMX is a
> > mistake that I made.
> >
> > marcf
> >
> >
> >
> > > Personally, I think the basis of jboss should be
> > > built on top of the JMX Microkernel, and thus
> any
> > > remote capabilities, should be moved into the
> JMX
> > > layer and work via the JMX remoting framework.
> > >
> > > This is what Tom and I are currently working on
> -
> > and
> > > Juha and Tom are both part of the JMX Remoting
> > JSR.
> > > We're trying to work in parallel with the JSR
> > until
> > > we can roll in JSR interfaces once it's public.
> > >
> > > Currently, we have a Socket-based and SOAP-based
> > set
> > > of connectors.
> > >
> > > Part of this framework is both remote
> > connectivity,
> > > as well as discovery of remote connectors.
> > >
> > > As well, we currently have remote classloading
> as
> > > well as remote callback (for notifications)
> > working.
> > >
> > > I think moving the work from the Invokers into
> the
> > MX
> > > layer wouldn't be too much effort.
> > >
> > > In our commercial product, which sits on top of
> > JBOSS
> > > - we are using this very reliably and its been
> > very
> > > easy to build remote JMX based services. We've
> > built
> > > a wealth of code that uses fully distributed JMX
> > > jboss mbeans and its very easy to implement.
> >
>