4 Replies Latest reply on May 22, 2007 3:22 PM by Mark Little

    ESB 4.2 GA?

    Andre Fernando Salvati Novice

      Hi,

      when ESB 4.2 GA is due?

      Would it be regular have EJB3 + ESB in the same server configuration? What would be the vantages and disavantages of this choice in comparison with diferent server configurations?

      Thanks.

        • 1. Re: ESB 4.2 GA?
          Mark Little Master

           

          "Andre1001" wrote:
          Hi,

          when ESB 4.2 GA is due?


          We're aiming for mid-July for the release.


          Would it be regular have EJB3 + ESB in the same server configuration? What would be the vantages and disavantages of this choice in comparison with diferent server configurations?

          Thanks.


          That depends what you mean. EJB3 is a perfectly acceptable way of developing your services to then be deployed on the ESB. Did you have something else in mind?

          • 2. Re: ESB 4.2 GA?
            Andre Fernando Salvati Novice

             

            "mark.little@jboss.com" wrote:

            That depends what you mean. EJB3 is a perfectly acceptable way of developing your services to then be deployed on the ESB. Did you have something else in mind?


            I was thinking about a server with ESB starting services in another server with EJB3. Maybe, I was influenced by this presentation (slide 5)

            http://wiki.jboss.org/wiki/attach?page=JBossESBDocumentation%2FMay_ESB_Deep_Dive_v2.pdf

            But I don't think it scales so well, because there is a round trip for each service access. What would be the most scalable?

            • 3. Re: ESB 4.2 GA?
              Burr Sutter Master

              For some people they will wish to deploy with everything in one JVM. AS+ESB. Others will wish to have the ESB operating in its own JVM. The biggest disadvantage of 2 JVMs is as you've suggested more network/serialization. Running in a single JVM (within the AS) has the advantage of better performance and easier to manage one thing vs two things. However, the disadvantage is what happens one part of the overall application infrastructure needs to be restarted.

              You'll have to consider the tradeoffs.

              We recommend the use of EJB3, POJOs or Spring beans for your business logic so that it is reusable outside of the ESB context. If you've written your business logic correctly then web apps, client-server apps and SOA apps (based on the ESB) can reuse it.

              Burr

              • 4. Re: ESB 4.2 GA?
                Mark Little Master

                 

                "Andre1001" wrote:
                "mark.little@jboss.com" wrote:

                That depends what you mean. EJB3 is a perfectly acceptable way of developing your services to then be deployed on the ESB. Did you have something else in mind?


                I was thinking about a server with ESB starting services in another server with EJB3. Maybe, I was influenced by this presentation (slide 5)

                http://wiki.jboss.org/wiki/attach?page=JBossESBDocumentation%2FMay_ESB_Deep_Dive_v2.pdf

                But I don't think it scales so well, because there is a round trip for each service access. What would be the most scalable?


                In that respect think of the ESB as yet another distributed system environment. Where you host your business logic/services will really depend upon where they need to reside. If you're services are developed by different organisations or users, then they may well have to live in different environments for a number of reasons, e.g., corporate security restrictions, resource requirements etc. One of the things we're planning in the 5.x series is dependency tracking and service migration so that, where possible, services can migrate to locations physically close to the users. This is important in situations where deployments run for months or years but user habit may change over that time. Therefore, what was a good deployment initially may no longer be so. The ESB should transparently handle this for you to maintain QoS.