3 Replies Latest reply on Feb 20, 2007 10:12 AM by Mark Little

    Services on two ESBs over TCP/IP

    Ashish Rajhansha Newbie

      My company has applications deployed at different sites and we are aiming at integrating these using ESB. According to me the architecture will involve JBossESBs at each site running on clustered JBoss AS with HA-JBossMQ. The sites will also use Apache Axis for communication between the JBossESBs inorder to achive complete integration. The architecture is aims at supporting any future services. The new services will be ESB aware and hence will be just plug into the ESBs. The protocol stack intended to be used here is -

      Message payload <-> ESB <->SOAP <-> JMS <-> HTTP/S <->TCP/IP

      Please advice about any other alternatives possible. Your suggestions are valuable.

      Regards,
      Ashish

        • 1. Re: Services on two ESBs over TCP/IP
          Mark Little Master

          I'm not sure what alternatives you want? If you mean transport protocol, then you could look at FTP. Also, we'll have SOAP integration in JBossESB 4.2 due in May. There may be preliminary releases of that before then.

          • 2. Re: Services on two ESBs over TCP/IP
            Ashish Rajhansha Newbie

            This architecture intends to use Apache axis to implement SOAP <-> JMS part of the protocol stack. I would like to know about any other implementations possible ? I know that the SOAP <-> JMS <-> HTTP/S part can be replaced by just JMS and also by XML <-> JMS <-> SSL. I would like to know if there are any such engines available and are they suitable for this scenareo at all considering the fact that all we want is assured asynchronous messaging between JBossESBs.

            Regards,
            Ashish

            • 3. Re: Services on two ESBs over TCP/IP
              Mark Little Master

              JMS is probably your best bet at the moment. Reliable message delivery is a tricky subject in general. We intend to support reliable (and asynchronous) delivery over a range of protocols, but we're not there yet. BTW, you do realise that true asynchrony is maybe not what you want, since you cannot reason about the completness of any distributed system (ESB or not) in that event?