The JBoss Messaging JMS Facade
The JMS Facade exposes a JMS1.1 implementation at the front end to the client.
This layer will take care of simple JMS requirements, translating other requests into the more generic messaging api.
At this layer there will be implementations of:
NOTE: Some of the JMS behaviour is achieved by correct configuration of interceptors in the Messaging API and channels on the Server.
The messaging API uses an container/interceptor pattern. This gives two advantages:
The behaviour can be changed/augmented by reconfiguring the interceptor stack.
The interceptor stack extends from the facade from the client through the remoting implementation to the server. Allowing the behaviour to be moved from the client to server as required. e.g. Thin or Thick clients.
The Unified Interceptors project will define the generic interceptor. Exact details will have to wait on that project.
But the behaviour of each interceptor can be defined here.
There is also an alternate implementation based on an event driven model.
The idea being that rather than the request passing through an interceptor stack, it passes through a sequence of
event processors. This has the advantage that the request can give up its thread to the request processor,
allowing more efficient use of resources. This would allow both the client and server to make more effective usage
of Non Blocking IO.
Close interceptor acts as a valve to stop requests on closed objects.
JMSException interceptor turns non JMSExceptions thrown by the generic backend into JMSExceptions.
Factory interceptor to construct the facade and messaging api container or message objects.
Transaction interceptor bulks sends and acknowledgements into transaction requests.
Connection interceptor for handling connections, e.g. initial handshake, ping/pong and the exception handler.
Session interceptor for handling session state.
Sender interceptor for setting message send properties and encapsulating third party messages.
Receiver interceptor for handling async receives and dispatch to MessageListeners.
Browser interceptor for proxying the enumeration back to the server.
Persistence interceptor ensures the message is persisted before it proceeds down the chain.
Client interceptor used by the server to keep track of client connections.
Security interceptor used by the server to authenticate/authorise the request.
Invoker interceptor sends remote requests over the network using the configured protocol.
NOTE: Where the interceptor is responsible for multiple behaviours, it makes sense to split it into different interceptors.
The JMS facade wraps around the JBoss Messaging Core. The Core was designed based on a generic message idiom, and different facades can be added to it. The JBoss Messaging Core uses the concept of Channel and channel chains to implement the common messaging domains (Point to Point and Publis/Subscribe). Additionally, users can implement their own channels to program the server. The distributed nature of the server (and hence, the serverless behaviour) is built into the core. An extensive description of the core design can be found at JBossMessagingCore.
ConnectionToken identifies the client's connection.
Subscription identifies a receiver's subscription to the destination.
Message Reference a generic notion of a message (maps the real message).
These services are used by the interceptors to perform the real work.
Client Manager keeps track of clients connected to the server.
Destination Manager registry of channel configuration.
Security Manager responsible for the authentication/authorization implementation.
State Manager responsible for keeping track of durable subscriptions.
Persistence Manager persists the messages.
Cache Store caches data (moving data to and from an offline store).
Transaction Manager handles the transaction log.
Work Manager threading and channel processor.
NOTE: In practice one object will implement multiple interfaces, e.g. persistence, cache and transactions..