7 Replies Latest reply on Feb 5, 2004 12:57 AM by apdo

    Struts - to EJB or not - scalability & performance

    bstil

       

      "bstil" wrote:
      "bstil" wrote:
      I recently read through the following books

      Professional Struts Applications, Wrox
      Programming Jakarta Struts, O'Reilly

      and want to know the scalability and performance issues of using EJB or not.

      Wrox recommends the following pattern with OJB and Value Objects:

      Struts Action class
      Business Delegate
      Service Locator
      Session Facade/ Business Objects
      DAO/VO

      (In the actual code, Wrox skips the Session Facade and has BD classes contact the DAO directly.)

      O'Reilly uses

      Struts Action class (called ClientObject)
      Business Delegate Interface
      Business Object
      DAO with OJB, TopLink, etc

      What are the peformance and scalability issues with plain Java classes for Business Objects, contacting DAO?

      Is this "simplier" approach to EJB limited in terms of scalability and performance (ie, pooling) for high traffic websites?


        • 1. Re: Struts - to EJB or not - scalability & performance
          pharaoh

           

          "Pharaoh" wrote:
          "Pharaoh" wrote:
          Struts + EJB, or Struts + no EJB..

          picking between the two , does not directly effect if one performance and scalibility is better than the other..it depends on who you write the code... depending on the complexity of your project you don't use every patterns they suggest for every project...

          Struts was designed to further loosely coupled business logic processign from the client... it was not designed with EJB in mind(though it fits nicely)

          Pharaoh.


          • 2. Re: Struts - to EJB or not - scalability & performance
            pharaoh

             

            "Pharaoh" wrote:
            "Pharaoh" wrote:
            Struts + EJB, or Struts + no EJB..

            picking between the two , does not directly effect if one performance and scalibility is better than the other..it depends on who you write the code... depending on the complexity of your project you don't use every patterns they suggest for every project...

            Struts was designed to further loosely coupled business logic processign from the client... it was not designed with EJB in mind(though it fits nicely)

            Pharaoh.


            • 3. Re: Struts - to EJB or not - scalability & performance
              petermd

               

              "petermd" wrote:
              "petermd" wrote:
              imho you should only use ejbs if you really require the extra services they provide, i.e. transactions, remote-access, security. there is always an overhead (performance, complexity, implementation) in using them, so it must be worth it.

              if your application has some of the following attributes

              - is a web app
              - most actions will be reading the database not writing
              - queries across objects / tables
              - is high-volume
              - shares the database with other applications

              then you probably don't need/can't use the services ejbs provides.

              as a general design rule. i would still use a facade or delegate pattern to seperate the struts tier from the business tier, and the dao/vo pattern for data access. which would allow you to introduce session ejbs/bmps into the design at a later stage if required.





              • 4. Re: Struts - to EJB or not - scalability & performance
                petermd

                 

                "petermd" wrote:
                "petermd" wrote:
                imho you should only use ejbs if you really require the extra services they provide, i.e. transactions, remote-access, security. there is always an overhead (performance, complexity, implementation) in using them, so it must be worth it.

                if your application has some of the following attributes

                - is a web app
                - most actions will be reading the database not writing
                - queries across objects / tables
                - is high-volume
                - shares the database with other applications

                then you probably don't need/can't use the services ejbs provides.

                as a general design rule. i would still use a facade or delegate pattern to seperate the struts tier from the business tier, and the dao/vo pattern for data access. which would allow you to introduce session ejbs/bmps into the design at a later stage if required.





                • 5. Re: Struts - to EJB or not - scalability & performance
                  darryl_staflund

                   

                  "darryl_staflund" wrote:
                  "darryl_staflund" wrote:
                  Hi there,

                  I was lucky enough to build a Struts/EJB application following Wrox's recommendations and the application runs well. The more important issue (IMHO) that needs to be considered before you starting coding such an application, however, is whether you will using BMP or CMP, and if the latter, whether CMR will be used as well. Whether or not you use these technologies will have great impact on whether and how you choose to implement DOs and VOs and, if so, how the responsibility will be distributed for making them. This is even more important if the presentation and business tiers reside on different nodes since the business delegate AND certain objects in the business tier will all need to be able to create VOs at one time or another.

                  Darryl


                  • 6. Re: VOs still needed
                    trajano

                     

                    "trajano" wrote:
                    "trajano" wrote:
                    Are VO's still needed when using local references?
                    Assuming (VO == value object)


                    • 7. Re: Struts - to EJB or not - scalability & performance

                      VO is still needed when business tier send data to the presentation tier.