8 Replies Latest reply on Apr 6, 2006 11:36 AM by marklittle

    Connectors, JMS and JBoss Messaging clarification

    arvinder

      I'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?





        • 1. Re: Connectors, JMS and JBoss Messaging clarification
          marklittle

          That sounds about right. I'm in the process of populating the ESB subversion repo. with the basic interfaces we've agreed, and that should be up next week.

          However, going back to your original question: we need ESB to layer on JMS too. There are advantages to going directly to the messaging core, but there are disavantages too (like it being proprietary). Customers will probably want to tie in directly with JMS (and probably not even JBoss JMS implementations). So I'd suggest going directly to the JMS approach first, because that gives us some flexiblity for testers.

          As a slight aside, you may want to think about a pros-and-cons of the messaging core versus jms from an ESB perspective.

          Mark.

          • 2. Re: Connectors, JMS and JBoss Messaging clarification
            arvinder

            Sorry let me make things clearer. What i am referring to is the MoM abstraction defined in http://labs.jboss.com/file-access/default/members/jbossesb/freezone/documentation/project/JBossESBArchitecture.pdf
            I suppose since it is an abstraction, I should need to worry about what the underlying implementaiton is going to be but more importantly the contract definition between client and implementation.

            Has anyone put any of the interfaces or any code into cvs yet ?

            • 3. Re: Connectors, JMS and JBoss Messaging clarification
              arvinder

              Ok thanks!

              • 4. Re: Connectors, JMS and JBoss Messaging clarification
                marklittle

                The basic interfaces that we've outlined in the doc and in the forum will be in svn next week (Monday in all likelihood).

                Mark.

                • 5. Re: Connectors, JMS and JBoss Messaging clarification
                  timfox

                   

                  "arvinder" wrote:
                  I'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 ?


                  Yes, that was the intention



                  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



                  Correct, there are still some stray dependencies going in the other directiopn that need to be corrected



                  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,



                  Connectors are just the jboss remoting connector we use to get communication between client and server, nothing really to do with the facade



                  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?



                  Kind of, on the right track.

                  Bear in mind there is a *lot* of work put it into the JMS facade layer. Probably more stuff in there than the core messaging layer.
                  Considering that you probably want much of the same functionality, aop stack, transaction buffering on client side, etc, etc, you probably want to take the jms facade as your starting point and mould into the facade you want rather than attempt to write a new facade from scratch

                  I would suggest messaging and ESB teams need to get together so we can discuss this in more detail.

                  Tim

                  • 6. Re: Connectors, JMS and JBoss Messaging clarification
                    marklittle

                    Depends what you mean by facade? We have an API to the ESB, both for clients/services to use, and for messaging infrastructures to plug into (API above the bus, and API below the bus, respectively). The API that the client/service sees doesn't expose the underlying messaging infrastructure implementation (so it could be JMS, or it could just as easily be SOAP-over-HTTP, or raw TCP/IP or UDP/IP).

                    Obviously services (and clients) may have non-functional requirements such as transactions and security, and how they would play within a message is something we've looked at and have some ideas about. How the ESB core then maps those requirements into (or rather onto) the underlying messaging infrastructure is up to the plugin/adapter. If they are supported natively by, say, JBossMessaging or the Web Services stack, then that makes the mapping a lot easier and we definitely shouldn't be reinventing the wheel.

                    Does that help?

                    Or are we talking at cross-purposes ;-)?

                    Mark.

                    • 7. Re: Connectors, JMS and JBoss Messaging clarification
                      timfox

                      I suppose what I mean is, there is a lot of stuff in the messaging "JMS" layer which is actually quite general outside the world of JMS and you don't want to rewrite it yourself.

                      If you interface at the messaging core level you're going to bypass all of this which seems a bit of a waste to me.

                      • 8. Re: Connectors, JMS and JBoss Messaging clarification
                        marklittle

                        OK, that makes sense. I think we should target the JMS API first though.

                        Mark.