A framework for building multi-versioned asynchronous Remoting services and clients.

When working with JBoss Remoting the definition of clients and servers becomes vague, although there will be one side of the pair listening for incoming connection and the other side being the initiator of the connection once the connection is established either side of the connection can be the initiator of the next step.

After a connection is established the next step is for one side of the connection to open a channel to a service on the far side of the connection - once the channel is opened both sides are free to pass messages over the channel.

The purpose of the remoting-framework is to allow both sides of this Channel to be represented using strongly typed interfaces.

Overall the required set of supported features are: -

• Connection Manager allowing either Connection re-use or new Connection creation.
• Protocol version negotiation.
• Marshaler negotiation for Object Serialization.
• RPC style method invocations - blocked until a response is received.
• RPC style method invocations with responses returned using a Future.
• Asynchronous invocations with immediate return (delivery not guaranteed).
• Asynchronous invocations with return once far side acknowledges receipt of message.
• Notification support including management.
• Intermediate progress updates i.e. Don't time out yet.

This framework is being developed at the same time as another project which requires a subset of these features so releases will be required by that project, as the complete set of requirements may not be implemented this means that the APIs will be subject to change. No backwards compatibility assumptions should be made regarding the API and SPI until release 2.0.0.Final.

Where the framework is involved in the message exchange backwards compatibility will be maintained from version 1.0.0.Final - should non backwards compatible changes be introduced these will require a switch to enable them, this switch should be enabled in NEW versions of protocols so both sides of a connection can be sure that a compatible version of remoting-framework is being used.

As the framework is used the channel can be considered as transitioning through the following steps: -

• NEW - No messages have yet been exchanged.
• WELCOME - Quick sanity check that both sides of the channel verify they are connected to what they think they are.
• NEGOTIATING_PROTOCOL - At this point the version of the protocol is being negotiated, the use of multiple versions could be attempted.
• ESTABLISHED - Primarily this is now protocol specific, there may be framework specific messages to cause a state switch, also the protocol may include it's own states.
• CLOSING - Message exchange to indicate closing the channel.
• CLOSED - No further communication is possible and the Channel is closed.

Message Types

The framework supports a number of message types with a pre-defined header structure - this allows protocol developers to concentrate on the content of the messages.

• New - First message in an exchange.
• Response - A reply to a message received.
• Continuation - A follow up message - could be a request for a status update, could be a subsequent message after a reply.

Response Expectation

Message Structure

{message_type}