geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiram Chirino <cojonud...@yahoo.com>
Subject Remoting Patch
Date Thu, 21 Aug 2003 05:17:57 GMT
In this patch you will find several new
classes/packages that will allow geronimo containers
to be access remotely.  A quick descriptions of what
is in each new package:

org.apache.geronimo.proxy
=========================
- Holds some Simple implementations of Component,
Container, RPCContainer.  These implementations do not
depend on JMX.  These will be useful if you are
creating client side containers.
- Implements a ProxyContainer that is invoked via a
Dyanamic Proxy.  This lets you create simple client
side containers with and interceptor stack that could
potentially just be calling a POJO.

org.apache.geronimo.remoting
============================
- Holds a bunch of interceptors related to remoting. 
Interceptors that Marshall Invocations, Interceptors
that demarshal Invocation, Interceptors that change
the next interceptor to force Marshalling or to avoid
Marshalling.  You get the Idea.  
- It also defines the interface of a transport
interceptor.

org.apache.geronimo.remoting.transport
======================================
- Provides a couple of transport interceptors and the
defines what a ‘transport’ is.  
- A transport is un-aware of the “Invocation”.  You
could use it to transport other types of messages.
- The transport is responsible for: 
  - providing the MarshalledObject implementation that
is used for the transport.  Different transports (like
SOAP) will want to marshal their data differently.  
  - Moving a marshalled request or datagram to a
target URI.  
- java.net.URI is used to define a the transport
destination.

org.apache.geronimo.remoting.transport.async
============================================
- An implementation of a remoting transport.
- NIO Socket Based.
- Supports Asynchronous requests.  A request over a
socket does not block the socket from being used to
send additional requests.
- Establishes connection Pools to remote servers.  If
all sockets are in use additional sockets get created.
- Inbound sockets and outbound sockets to and from the
same remote server go into the same socket pool.  A
new request can go over inbound socket!
- Since requests can be sent over and inbound socket,
the server can do callbacks to a client established
socket that does not have access to bind a
ServerSocket.  (think doing a callback to an Applet)
- Supports doing either Blocking socket calls or
NonBlocking socket calls.  Right now It is defaulted
to NonBlocking socket calls.  This allows you to
reduce the number so socket “reader” threads.  You can
go down from needing n reader threads per n sockets
down to 1 reader thread per n sockets. (Helps
scalability).
======================


The current patch as it stands will build OK but the
unit tests for the remoting will fail because the mock
app that it tests against is not built by MAVEN.  I’m
not a MAVEN guru so I’m not going to try to figure it
out.  I’m sure somebody out there can give me a hand
with this.  The mock app has to be compiled to a
location outside of the CLASSPATH that is used by
junit.  The remoting Tests will create URLClassLoaders
to load the mock app to simulate 2 applications and
the marshalling issues they face when they try to
communicate with each other.


I hope this patch can be integrated soon into CVS!

Regards,
Hiram Chirino

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Mime
View raw message