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
dynamic, not setup except giving it the credentials) on both sides to do
SSH transport - I need to