Connectors, JMS and JBoss Messaging clarification
arvinder Apr 6, 2006 10:25 AMI've been looking at the wiki and the codebase for messaging. Right now
I am under the assumption the esb will be a wrapper around the messaging
core - like the jms implementation. Is this what you had envisaged ?
I thought that there was a downwards dependency like so
JMS (org.jboss.jms.*) - > depends on Messaging (org.jboss.messaging.*)
but there are some messaging dependencies on jms like classes:
org.jboss.messaging.core.local.Queue
org.jboss.messaging.core.local.Topic
org.jboss.messaging.core.message.MessageFactory
org.jboss.messaging.core.plugin.JDBCPersistenceManager
My assumptions were that for a standalone jboss esb server we would
initially be deploying the same style of connectors sitting on top
of jboss messaging and jboss remoting,
e.g
from jboss-messaging-service.xml or jboss-service.xml from the sar
<mbean code="org.jboss.remoting.transport.Connector" xmbean-dd="org/jboss/remoting/transport/Connector.xml" name="jboss.messaging:service=Connector,transport=socket" display-name="Socket transport Connector"> <attribute name="Configuration"> <config> <invoker transport="socket"> <attribute name="marshaller" isParam="true">org.jboss.jms.server.remoting.JMSWireFormat</attribute> <attribute name="unmarshaller" isParam="true">org.jboss.jms.server.remoting.JMSWireFormat</attribute> <attribute name="serializationtype" isParam="true">jboss</attribute> <attribute name="dataType" isParam="true">jms</attribute> <attribute name="socket.check_connection" isParam="true">false</attribute> <attribute name="socketTimeout">0</attribute> <attribute name="serverBindAddress">${jboss.bind.address}</attribute> <attribute name="serverBindPort">4457</attribute> </invoker> <handlers> <handler subsystem="JMS">org.jboss.jms.server.remoting.JMSServerInvocationHandler</handler> </handlers> </config> </attribute> <depends>jboss.messaging:service=NetworkRegistry</depends> </mbean>
but instead of the jms abstraction on top of messaging, the esb provides its own abstraction
of a Bus on top of messaging, so something like this would be the equivalent
the esb jboss-service.xml, note - this is simply the esb version of the jms connector ontop
of remoting
<mbean code="org.jboss.remoting.transport.Connector" xmbean-dd="org/jboss/remoting/transport/Connector.xml" name="jboss.messaging:service=Connector,transport=socket" display-name="Socket transport Connector"> <attribute name="Configuration"> <config> <invoker transport="socket"> <attribute name="marshaller" isParam="true">org.jboss.jms.server.remoting.ESBWireFormat</attribute> <attribute name="unmarshaller" isParam="true">org.jboss.jms.server.remoting.ESBWireFormat</attribute> <attribute name="serializationtype" isParam="true">jboss</attribute> <attribute name="dataType" isParam="true">esb</attribute> <attribute name="socket.check_connection" isParam="true">false</attribute> <attribute name="socketTimeout">0</attribute> <attribute name="serverBindAddress">${jboss.bind.address}</attribute> <attribute name="serverBindPort">4457</attribute> </invoker> <handlers> <handler subsystem="ESB">org.jboss.jms.server.remoting.ESBServerInvocationHandler</handler> </handlers> </config> </attribute> <depends>jboss.messaging:service=NetworkRegistry</depends> </mbean> ... and our own server peer + channel mapper ...
This implies there is an ESB Bus abstraction ontop of messaging, as opposed to JMS's
abstraction of a Queue or Topic. So I would be looking to implement
org.jboss.messaging.core.plugin.contract.ServerPlugin for the esb, the equivalent to
JMS's org.jboss.jms.server.plugin.contract.ChannelMapper which handles the jms constructs.
Am I on the right track ? Or should I be looking to build ontop of the JMS abstraction
rather along side it?
Any thoughts?