1 Reply Latest reply on Jan 21, 2003 4:47 AM by Adrian Brock

    JMX Service implementation question

    olivier brand Newbie

      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) ?

        • 1. Marc's Re: Scott's Re: MARC's POST: Re: JMX Connectors vs. J
          Adrian Brock Master

          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.
          > >
          >