[jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: New wireformat and client side remoting

[jmesnil]

"timfox" wrote : To kick off the discussion, here are my initial comments on Jeff's wiki:
  | 
  | In the diagram where you map MINA objects to JMS objects, we should remember that the JMS layer is a thin layer on the front.
  | 
  | MINA needs to map to a JMS agnostic layer (which may look a bit like JMS).
  | 
  | I'm thinking like the following:
  | 
  | 
  |   | JMS           Agnostic         MINA
  |   | ---           --------         ----
  |   | 
  |   |                                IoConnector  IoAcceptor
  |   |                                    \            /
  |   |                                     \ IoSession/
  |   | Connection----Connection------------------
  |   |     |                |
  |   |     |                |
  |   |   Session          Session
  |   |    / \                \
  |   | Producer Consumer     Consumer
  |   | 
  | I think Connection Session and Consumer are good abstractions for generic messaging
  | But Producer and Browser only live on the JMS side.
  | Producing messages and browsing can be methods on the agnostic Session class.
  | 

You're right. I did not want to push too much emphasis on the client refactoring task (http://jira.jboss.org/jira/browse/JBMESSAGING-681 ) but it makes the picture clearer overall

anonymous wrote : 
  | IOSession will only need to maintain a map of references to the agnostic objects not the JMS objects.
  | 
  | It will need to maintain such a map so the objects can be called back.
  | 

in fact, I'm redesigning that. The IoSession will only now about "agnostic handlers" objects. Each JBM object will then implement this handler interface.

anonymous wrote : 
  | In effect the system is *symettrical*. We have a dispatcher on the client side which looks up objects in order to deliver responses, and
  | we have dispatcher on the server side which looks up objects to deliver requests.
  | 
  | Really requests and responses are the same thing, it's just the direction of travel is different. I think this symetry is aesthetically pleasing which is often a good sign.
  | 
  | Regarding the messages: Perhaps it is not such a good idea to classify the messages as synchronous or asychronous since some messages can be sent either asynchronously or synchronously - a good example is sending a message -for persistent messages they are sent synchronously, for non persistently, but the message being sent is the same.
  | 
  | We should come up with a set of messages (which can be either requests or responses) and the api determines whether they are sent asynchonrous or not.

good point. I will clarify the terminology.

anonymous wrote : 
  | Another thing to think about is management messages.
  | 
  | You probably want to define a message type as a management message (or a set of management messsages).
  | 
  | The idea here is the user could send a messages saying "createQueue" or "getNumberOfMeessafesInQueue" or any number of different operations that we currently do via JMX, and get results that way without JMX.
  | 

I'll have a look at it and update http://jira.jboss.com/jira/browse/JBMESSAGING-91

>From what I understand of MINA, it should be quite straightforward to add a handler on the server-side which handlers all the "ManagementMessage" sent on the same connection that regular messages.
This should make it simple to separate regular message logic from management message logic.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101874#4101874

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101874