RE: [JBoss-dev] Remoting and NAT traversal, advanced network]
> And, no Marc, this isn't relegated to just JMX as Bill > demonstrates with AOP Remoting. This should be used for JMS, > EJB and all the other subsystem layers. ;) That is great, the AOP remoting part is the future. But the best of this will come as the invoker layer for proxies of EJB (which do use the JMX invokers). Replace the EJB invokers with the functionality pointed out by Scott and you got massive usage of this. Marcf --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Remoting and NAT traversal, advanced network
Scott M Stark eloquently wrote the following on 1/6/2004 1:44 PM: The MBeanTracker appears to be a composite of the proxy factory and lookup services currently used and is where the NAT configuration would have to be I would guess. Does this layer support: - A client side interceptor stack - Specifying the class loader used for locating classes on the server side This is what is needed to look to the remoting framework as a replacement for the current proxy factory/detached invoker mechanism. Doesn't have a client side interceptor concept yet - although would be easy to add. I know this is something David Jenks started talking about before and I'm not sure if he did any work in that area. Right now there is some trivial automated class downloading that happens if you make an invocation and the class (either way) doesn't exist - but not well integrated in the UCL and needs to be better thought out. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Remoting and NAT traversal, advanced network
The MBeanTracker appears to be a composite of the proxy factory and
lookup
services currently used and is where the NAT configuration would have to
be I would guess. Does this layer support:
- A client side interceptor stack
- Specifying the class loader used for locating classes on the server
side
This is what is needed to look to the remoting framework as a
replacement
for the current proxy factory/detached invoker mechanism.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff
Haynie
Sent: Monday, January 05, 2004 7:34 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Remoting and NAT traversal, advanced network
In the remoting framework, there are three main components: a transport,
a detector and a network registry. (among others .. but these are the
biggest)
The transport encapsulates the client and server components necessary
for communication for a given protocol between two endpoints.
The detector is a specific protocol/mechanism for handling discovery and
failure of zero or more endpoints based on a domain (or a cluster,
partition, whatever you'd like to call it - a logical grouping of
machines with the same name).
For transports, we have sockets (TCP), RMI, SOAP.
For detectors, we have multicast, JNDI.
The next major component is the network registry which receives
detection notifications (or you can call it directly to enlist servers)
which keeps a network map of all machines (and their identity and valid
transports and how to communicate with them) within the same logical
domain.
In JMX remoting, a simple proxy is created for the JMX subsystem (you
can have other subsystems such as AOP, JMS, etc.) which uses a transport
(unknown to the proxy) to communicate with the remote MBeanServer.
This allows you to mix and match transports, detection/failure
mechanisms and subsystems that use the framework.
In AOP Remoting, you can simply instrument an object, given a remote
locator (which could be obtained via detection) and then make remote
method calls against it w/o RMI stubs, etc.
We make heavy use of something called an MBeanTracker which is in JMX
Remoting.
You can give the mbean tracker a set of interfaces, query expression,
and any combination/ lack thereof and he will automatically give you
back a callback for things such as register, unregister, notification
and a MBeanLocator which can be turned into a proxy to that object.
For example:
MBeanTracker tracker=new MBeanTracker(getServer(), new
Class[]{Server.class}, null, false, null, true, new
MBeanTrackerActionAdapter()
{
public void mbeanRegistered (MBeanLocator locator)
{
System.out.println("I found a new JBoss server at: "+locator+" on
the network");
// cast to a server proxy that implements the Server interface
Server server = (Server)locator.narrow(Server.class);
// look ma... no hands, I just shutdown your jboss server remotely
server.shutdown();
}
public void mbeanUnregistered (MBeanLocator locator)
{
System.out.println("I lost a JBoss server at: "+locator+" on the
network");
}
public void mbeanNotification (MBeanLocator locator, Notification
notification, Object handback)
{
System.out.println("JBoss server at: "+locator+" sent a
notification: "+notification);
}
});
It's as simple as that. You can deal with network transparency (in a
novel way), failure, detection, etc. in short-order - with very little
code - but very very powerful.
And, no Marc, this isn't relegated to just JMX as Bill demonstrates with
AOP Remoting. This should be used for JMS, EJB and all the other
subsystem layers. ;)
Jeff
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Remoting and NAT traversal, advanced network
In the remoting framework, there are three main components: a transport,
a detector and a network registry. (among others .. but these are the
biggest)
The transport encapsulates the client and server components necessary
for communication for a given protocol between two endpoints.
The detector is a specific protocol/mechanism for handling discovery and
failure of zero or more endpoints based on a domain (or a cluster,
partition, whatever you'd like to call it - a logical grouping of
machines with the same name).
For transports, we have sockets (TCP), RMI, SOAP.
For detectors, we have multicast, JNDI.
The next major component is the network registry which receives
detection notifications (or you can call it directly to enlist servers)
which keeps a network map of all machines (and their identity and valid
transports and how to communicate with them) within the same logical domain.
In JMX remoting, a simple proxy is created for the JMX subsystem (you
can have other subsystems such as AOP, JMS, etc.) which uses a transport
(unknown to the proxy) to communicate with the remote MBeanServer.
This allows you to mix and match transports, detection/failure
mechanisms and subsystems that use the framework.
In AOP Remoting, you can simply instrument an object, given a remote
locator (which could be obtained via detection) and then make remote
method calls against it w/o RMI stubs, etc.
We make heavy use of something called an MBeanTracker which is in JMX
Remoting.
You can give the mbean tracker a set of interfaces, query expression,
and any combination/ lack thereof and he will automatically give you
back a callback for things such as register, unregister, notification
and a MBeanLocator which can be turned into a proxy to that object.
For example:
MBeanTracker tracker=new MBeanTracker(getServer(), new
Class[]{Server.class}, null, false, null, true, new
MBeanTrackerActionAdapter()
{
public void mbeanRegistered (MBeanLocator locator)
{
System.out.println("I found a new JBoss server at: "+locator+" on
the network");
// cast to a server proxy that implements the Server interface
Server server = (Server)locator.narrow(Server.class);
// look ma... no hands, I just shutdown your jboss server remotely
server.shutdown();
}
public void mbeanUnregistered (MBeanLocator locator)
{
System.out.println("I lost a JBoss server at: "+locator+" on the
network");
}
public void mbeanNotification (MBeanLocator locator, Notification
notification, Object handback)
{
System.out.println("JBoss server at: "+locator+" sent a
notification: "+notification);
}
});
It's as simple as that. You can deal with network transparency (in a
novel way), failure, detection, etc. in short-order - with very little
code - but very very powerful.
And, no Marc, this isn't relegated to just JMX as Bill demonstrates with
AOP Remoting. This should be used for JMS, EJB and all the other
subsystem layers. ;)
Jeff
Scott M Stark wrote:
We use system properties that allow client environments to override
the URL used to connect to in the RMI/HTTP transport for this
issue.
What is the detection notification you are talking about here? I have
not looked at the remoting code much so describe the network traffic.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff
Haynie
Sent: Monday, January 05, 2004 2:04 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] Remoting and NAT traversal, advanced network
We have a customer that needs to use JBoss Remoting / JMX Remoting in a
fairly complex, although not unusual, network configuration.
Right now, we don't well support dynamic / NAT traversals for remoting
either in detection or transport. We basically send the local machines
address (which bind address is configurable) as part of the detection
notification to the remote machine. This works fine on a local subnet.
In the case of a remote subnet, you can use the JNDI detection which
will bind the entry into a remote (or local) JNDI context which can then
be browsed by any network that can reach the JNDI server.
In cases where NAT is being used (or potentially even DHCP, although
slightly different), we need to be able to send the detection annotated
with additional network interfaces, such as the public IP or hostname.
Ideally, this could be a simple configuration that we would read /
lookup (maybe as simple as a system property) and the Identity could be
modified to include additional addresses (similar to InetAddress when
you have multiple NICs locally). Then, the remote machine transport
could then try the primary address and then secondary addresses if the
primarily failed.
In addition, I wrote a SSHConnector that uses SSH tunneling (totally
dynami
RE: [JBoss-dev] Remoting and NAT traversal, advanced network
We use system properties that allow client environments to override the URL used to connect to in the RMI/HTTP transport for this issue. What is the detection notification you are talking about here? I have not looked at the remoting code much so describe the network traffic. Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Haynie Sent: Monday, January 05, 2004 2:04 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Remoting and NAT traversal, advanced network We have a customer that needs to use JBoss Remoting / JMX Remoting in a fairly complex, although not unusual, network configuration. Right now, we don't well support dynamic / NAT traversals for remoting either in detection or transport. We basically send the local machines address (which bind address is configurable) as part of the detection notification to the remote machine. This works fine on a local subnet. In the case of a remote subnet, you can use the JNDI detection which will bind the entry into a remote (or local) JNDI context which can then be browsed by any network that can reach the JNDI server. In cases where NAT is being used (or potentially even DHCP, although slightly different), we need to be able to send the detection annotated with additional network interfaces, such as the public IP or hostname. Ideally, this could be a simple configuration that we would read / lookup (maybe as simple as a system property) and the Identity could be modified to include additional addresses (similar to InetAddress when you have multiple NICs locally). Then, the remote machine transport could then try the primary address and then secondary addresses if the primarily failed. In addition, I wrote a SSHConnector that uses SSH tunneling (totally dynamic, not setup except giving it the credentials) on both sides to do SSH transport - I need to get this into remoting soon. This is an additional option, but not as flexible and slower. Does anyone have any good ideas, suggestions, criticisms on this topic? --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Remoting and NAT traversal, advanced network
We have a customer that needs to use JBoss Remoting / JMX Remoting in a fairly complex, although not unusual, network configuration. Right now, we don't well support dynamic / NAT traversals for remoting either in detection or transport. We basically send the local machines address (which bind address is configurable) as part of the detection notification to the remote machine. This works fine on a local subnet. In the case of a remote subnet, you can use the JNDI detection which will bind the entry into a remote (or local) JNDI context which can then be browsed by any network that can reach the JNDI server. In cases where NAT is being used (or potentially even DHCP, although slightly different), we need to be able to send the detection annotated with additional network interfaces, such as the public IP or hostname. Ideally, this could be a simple configuration that we would read / lookup (maybe as simple as a system property) and the Identity could be modified to include additional addresses (similar to InetAddress when you have multiple NICs locally). Then, the remote machine transport could then try the primary address and then secondary addresses if the primarily failed. In addition, I wrote a SSHConnector that uses SSH tunneling (totally dynamic, not setup except giving it the credentials) on both sides to do SSH transport - I need to get this into remoting soon. This is an additional option, but not as flexible and slower. Does anyone have any good ideas, suggestions, criticisms on this topic? --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
