RE: [JBoss-dev] Remoting and NAT traversal, advanced network]

2004-01-07 Thread Marc Fleury
 
 
 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_id78alloc_id371op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


Re: [JBoss-dev] Remoting and NAT traversal, advanced network

2004-01-06 Thread Jeff Haynie
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=1278alloc_id=3371op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


RE: [JBoss-dev] Remoting and NAT traversal, advanced network

2004-01-05 Thread Scott M Stark
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_id78alloc_id371op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


Re: [JBoss-dev] Remoting and NAT traversal, advanced network

2004-01-05 Thread Jeff Haynie
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