1 2 Previous Next 28 Replies Latest reply on Jan 9, 2003 4:33 AM by Sacha Labourey

    JMX Connectors vs. JBoss Invokers

    Bill Burke Master

      Seems to be a lot of parallel work going on with JMX connectors for (RMI, SOAP, etc...) and JBoss Invokers for (RMI, custom, IIOP, etc...).

      My question here is should the JBoss Invokers be retired for the standard JMX connectors? They seem like redundant technologies.

      Bill

        • 1. Re: JMX Connectors vs. JBoss Invokers
          Bill Burke Master

          Ok, I'm replying to myself :)

          One problem about this is how to support client callbacks. We want JMS invocations to go through the JMX layer and JMS requires callbacks. Same goes with DTM.

          Bill

          • 2. Re: JMX Connectors vs. JBoss Invokers
            David Jencks Master

            I'm not sure what you mean by callbacks. DTM only makes calls from the "client" controlling the transaction to the "servers" who are doing work on branches. There are regular "do some work" calls to (as of now) ejbs, and "end this transaction" calls to the remote transaction managers. Both of these return values, but the remote stuff never calls a method on the "client".

            I'm not aware of callbacks in jms, but I'm definitely not an expert.

            What I'd like to preserve from some of the current invokers is running bidirectional communication over the same set of e.g. sockets. This is useful in jms for sure, and would be useful in dtm if all the jboss instances were controlling transactions. However, I suspect we should do some thinking about whether this will introduce more complexity than gain. How much does an extra socket cost, anyway?

            I haven't looked at the remote jmx stuff yet, but I certainly imagine these two areas could be combined somehow.

            • 3. Re: JMX Connectors vs. JBoss Invokers
              Jeff Haynie Newbie

              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.

              • 4. MARC's POST: Re: JMX Connectors vs. JBoss Invokers
                Bill Burke Master

                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.

                • 5. Re: Tod's POST: Re: JMX Connectors vs. JBoss Invokers
                  Bill Burke Master

                  I am not terribly familiar with the Invokers, so please forgive me if I state anything inaccurately. It seems as though JMX Remoting is intended to achieve the same goal as Invokers, which is to provide the ability to make remote calls on MBeans using transparent wire protocol that also provides extra features such as automatic classloading, security, etc. However, as Marc pointed out, Invokers seem to be a more generic approach (in that at the very least JMX Remoting is directly tied to JMX). Also have to consider that JMX Remoting will soon fall under a public specification that we should comply with, thus limiting the ability to support all the features we might want for Invokers in the manner that we might want.
                  Nevertheless, Invokers and JMX Remoting could easily share some of same codebase for some of the features. For example, JMX Remoting still needs a way to implement security, which seems to have already been addressed within Invokers in such a way that it can be re-used in the JMX Remoting.

                  Just my 2 cents.

                  -Tom



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

                  • 6. Scott's Re: MARC's POST: Re: JMX Connectors vs. JBoss Invoke
                    Bill Burke Master

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

                    • 7. Tod's Re: Scott's Re: MARC's POST: Re: JMX Connectors vs. JB
                      Bill Burke Master

                      The JSR160 spec is probably not going to address (at least in any practical detail) the features you will want for 4.0. I think the spec will end up only addressing JMX connectors and little more. At the same time, I don't think it will prohibit any extra functionality that may be needed (such as security).


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

                      • 8. Marc's Re: Scott's Re: MARC's POST: Re: JMX Connectors vs. J
                        Bill Burke 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.
                        > >
                        >

                        • 9. Marc again Re: Tod's POST: Re: JMX Connectors vs. JBoss Invo
                          Bill Burke Master

                          -----Original Message-----
                          From: Tom Elrod [mailto:telrod@e2technologies.net]
                          Sent: Thursday, January 02, 2003 3:27 PM
                          To: marc fleury
                          Cc: 'Jeff Haynie'; bill@jboss.org; 'Scott. Stark@Jboss. Org'; 'David
                          Jencks'; 'Juha-P Lindfors'; 'Adrian Brock'
                          Subject: Re: JMX Connectors vs. JBoss Invokers


                          I am not terribly familiar with the Invokers, so please forgive me if I
                          state anything inaccurately. It seems as though JMX Remoting is
                          intended to achieve the same goal as Invokers, which is to provide the
                          ability to make remote calls on MBeans using transparent wire protocol
                          that also provides extra features such as automatic classloading,
                          security, etc. However, as Marc pointed out, Invokers seem to be a more
                          generic approach (in that at the very least JMX Remoting is directly
                          tied to JMX). Also have to consider that JMX Remoting will soon fall
                          under a public specification that we should comply with, thus limiting
                          the ability to support all the features we might want for Invokers in
                          the manner that we might want.


                          MF: I don't think this is an issue. The JMX specification will specify
                          an interface that says "invoke(jmxSignature)". We DP that interface and
                          feed it in the interceptors we have. One of the client interceptors
                          encodes the JMX MBeanName in the invocation, the last interceptors can
                          do HA and actual invocation. This means that we can leverage all of the
                          good logic we have, the JMX nature of the call just being obvious in the
                          front (interface) and in the back with the actual adapter that calls the
                          JMXServer.


                          Nevertheless, Invokers and JMX Remoting could easily share some of same
                          codebase for some of the features. For example, JMX Remoting still
                          needs a way to implement security, which seems to have
                          already been addressed within Invokers in such a way that it can be
                          re-used in the JMX Remoting.


                          MF: The security should be an interceptor configurable just like the
                          J2EE ones and whatever Scott puts in there. Securing a JMX call is then
                          using the 'remote+secure+interface' set of aspects. Meaning that the
                          JMX call builds upon the aspect framework.


                          I really want the features that are built in the JMX invokers to be
                          moved to the generic ones. I am talking about the automated discovery
                          and remote notifications. The remote notifications will be key to
                          building the caches. It must be generic work. Tom and Jeff I want you
                          guys to go to one of our next trainings so that we get on the same page.


                          marcf

                          • 10. Re: Marc's Re: Scott's Re: MARC's POST: Re: JMX Connectors v
                            Bill Burke 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

                            Negative.

                            JMX is our component layer. Although AOP objects may not go through a JMX "Invoker" (whether that be a connector or JBoss Invoker), we still want things like EJB to go through the JMX layer. This is because of redeployment. To provide 24/7, we need invocations to be blocked while a component is being cycled. In fact, maybe AOP invocations should go through JMX as well.

                            Bill

                            P.S. Please move this discussion to forums....


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

                            • 11. Re: Marc's Re: Scott's Re: MARC's POST: Re: JMX Connectors v
                              marc fleury Master

                              > Negative.

                              negative on the negative.

                              > JMX is our component layer. Although AOP objects may

                              Yes.

                              AOP for me is just a way to add interfaces and interceptors to an existing object.

                              > not go through a JMX "Invoker" (whether that be a
                              > connector or JBoss Invoker), we still want things
                              > like EJB to go through the JMX layer. This is

                              EJB is a particular case as it does have an mbean. Many objects will want the remoteness and not necessarily be mbeans. I think it is a mistake to say "only mbeans are remote". Many many objects will want remoteness.

                              Look at the end of the day there isn't much in this discussion. The logical name and the signature is what counts. We all pretty much agree on the signature (we are all already close to the detyped signature) the only difference would be the object name (JMX or purely logical) that gets embedded in client proxies and added to the invocation. In fact when I wrote the first implementation I remember allowing purely logical names.

                              In the case of JMX the logical name is pointing to an adapter that takes the generic Invocation, extracts the JMX name from it and call the JMX bus with the equivalent invoke() signature from the dynamic MBean. This is all bundled in the invokers today and in fact they are tied to JMX in that fashion. Adrian and I are steady on the fact that many invocation paths will still go without mbean stuff.

                              > because of redeployment. To provide 24/7, we need
                              > invocations to be blocked while a component is being
                              > cycled. In fact, maybe AOP invocations should go
                              > through JMX as well.

                              wow... no no no please.

                              it is a mistake. So you want to leverage the 24.7 idea? there are 2 ways with the EJB and generic

                              1- Make the 24x7 stuff an interceptor that reads a 'state' of the target. In the case the component has a JMX state associated to it then we are all set. Today it will be tied to it.

                              2- Do the move we are talking about. Make the invokers generic "Unified Invokers". Unified Invokers are still MBeans themselves they are components. But they only look up logical names and delegate to a real invoker. JMX ones will go through the same chain of command and you still leverage the existing code.

                              > P.S. Please move this discussion to forums....

                              done,

                              marcf

                              • 12. JMX Connectors vs. JBoss Invokers
                                Scott Stark Master

                                We need to clear up the terminology being used here.

                                An Interceptor is just a pass through point in an invocation call stack.

                                An Invoker is just a transport handler. Up to now JMX has been brought into the Invoker layer due to Invokers being MBeans for their configuration (a good thing), and as the mechanism by which the transport agnostic invocation was passed to the Invoker target. The latter requires that Invoker targets be MBeans which is an uneccessary requirement.

                                If JMX is not going to be used as the namespace and invocation layer for Invokers, the only other suitable choice is something like JNDI and reflection. Using JMX as a naming service has been problematic so I can see that a valid criticism. What are the others and what is the proposal for replacing it?

                                • 13. Re: JMX Connectors vs. JBoss Invokers
                                  Tom Elrod Master

                                  Sounds like it makes sense (at least at first glance) to have JMX Remoting use Invokers as its transport mechanism, since there is definite duplication there now. This will also give us a head start on security within JMX Remoting.

                                  We will also want to have the ability for automatic remote class loading (which we already have now in JMX Remoting). I think Invokers already has this in the works as well (so would make sense to consolidate as well).

                                  The other big requirement we will have is a discovery mechanism. I am assuming that Invokers will need this as well (if not already there). We already have a multicast and unicast detector we use currently. It does not look like JSR 160 will apply any tight constraints on the discovery mechanism used (but will probably reference SLP, Jini, and JNDI as examples). The end result of the detection will be something that looks like a SLP URL which is used to make the client connection to the connector server. Don’t see any reason that we couldn’t use a JSR 160 compliant approach for Invokers so that JMX Remoting can easily sit on top (since not really JMX specific in detection or initial connection to server).

                                  BTW, I couldn’t find Adrian’s comments on this topic in the forums, but would like to read them if anyone knows where it was posted.


                                  • 14. Re: JMX Connectors vs. JBoss Invokers
                                    Adrian Brock Master

                                    http://www.jboss.org/modules/bb/index.html?module=bb&op=viewtopic&t=forums/ requirement comes from async responses.
                                    jmx notifications are an example,
                                    the original discussion was about jms message
                                    pushing.

                                    Regards,
                                    Adrian

                                    1 2 Previous Next