"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 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#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...