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.
xxxxxxxxxxxxxxxxxxxxxxxx
Scott Stark
Chief Technology Officer
JBoss Group, LLC
xxxxxxxxxxxxxxxxxxxxxxxx -----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_id=1278&alloc_id=3371&op=click _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
