The purpose of JBoss Remoting is to provide a single API for most network based invocations and related service that uses pluggable transports and data marshallers. The JBossRemoting API provides the ability for making synchronous and asynchronous remote calls, push and pull callbacks, and automatic discovery of remoting servers. The intention is to allow for the use of different transports to fit different needs, yet still maintain the same API for making the remote invocations and only requiring configuration changes, not code changes.
JBossRemoting is a standalone project, separate from the JBoss Application Server project, but will be the framework used for many of the JBoss projects and components when making remote calls. JBossRemoting is included in the recent releases of the JBoss Application Server and can be run as a service within the container as well. Service configurations are included in the configuration section below.
The features available with JBoss Remoting are:
Server identification – a simple url based identifier which allows for remoting servers to be identified and called upon.
Pluggable transports – can use different protocol transports the same remoting API.
Provided transports:
Socket (SSL Socket)
RMI (SSL RMI)
HTTP(S)
Multiplex (SSL Multiplex)
Servlet (SSL Servlet)
BiSocket (SSL BiSocket)
Pluggable data marshallers – can use different data marshallers and unmarshallers to convert the invocation payloads into desired data format for wire transfer.
Pluggable serialization - can use different serialization implementations for data streams.
Provided serialization implementations:
Java serialization
JBoss serialization
Automatic discovery – can detect remoting servers as they come on and off line.
Provided detection implementations:
Multicast
JNDI
Server grouping – ability to group servers by logical domains, so only communicate with servers within specified domains.
Callbacks – can receive server callbacks via push and pull models. Pull model allows for persistent stores and memory management.
Asynchronous calls – can make asynchronous, or one way, calls to server.
Local invocation – if making an invocation on a remoting server that is within the same process space, remoting will automatically make this call by reference, to improve performance.
Remote classloading – allows for classes, such as custom marshallers, that do not exist within client to be loaded from server.
Sending of streams – allows for clients to send input streams to server, which can be read on demand on the server.
Clustering - seamless client failover for remote invocations.
Connection failure notification - notification if client or server has failed
Data Compression - can use compression marshaller and unmarshaller for compresssion of large payloads.
All the features within JBoss Remoting were created with ease of use and extensibility in mind. If you have a suggestion for a new feature or an improvement to a current feature, please log in our issue tracking system at http://jira.jboss.com
The JBossRemoting distribution can be downloaded from http://labs.jboss.com/portal/jbossremoting . This distribution contains everything needed to run JBossRemoting stand alone. The distribution includes binaries, source, documentation, javadoc, and sample code.
IPv6 addresses are supported;
org.jboss.remoting.callback.ServerInvokerCallbackHandler can register itself as a lease connection listener.
The servlet transport can throw an exception generated on the server side;
servers can bind to 0.0.0.0.
Release 2.2.2.GA includes a number of bug fixes, greater configurability, and a couple of new features, including
an improved callback polling method;
the ability for the client to discover its IP address as seen by the server side of the connection;
The following changes affect configurability:
The address and port of the bisocket transport secondary server socket are configurable;
org.jboss.remoting.ConnectorValidator parameters are configurable;
the maximum number of errors before a org.jboss.remoting.callback.CallbackPoller shuts down can be specified;
there is a separate timeout parameter for callbacks.
For the JIRA items related to release 2.2.2.GA, see Release Notes.