-
1. Re: JMX Connectors vs. JBoss Invokers
bill.burke Jan 2, 2003 8:50 AM (in response to bill.burke)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
davidjencks Jan 2, 2003 9:37 AM (in response to bill.burke)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
jhaynie Jan 2, 2003 10:14 AM (in response to bill.burke)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 Jan 2, 2003 5:36 PM (in response to bill.burke)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 Jan 2, 2003 5:38 PM (in response to bill.burke)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 Jan 2, 2003 5:39 PM (in response to bill.burke)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 Jan 2, 2003 5:40 PM (in response to bill.burke)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 Jan 2, 2003 5:41 PM (in response to bill.burke)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 Jan 2, 2003 5:43 PM (in response to bill.burke)-----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 Jan 2, 2003 5:44 PM (in response to bill.burke)> 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 Jan 2, 2003 6:43 PM (in response to bill.burke)> 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
starksm64 Jan 2, 2003 7:32 PM (in response to bill.burke)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 Jan 3, 2003 1:29 AM (in response to bill.burke)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 Jan 3, 2003 10:22 AM (in response to bill.burke)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