5 Replies Latest reply on Feb 28, 2005 3:13 AM by Robin Young

    How Will EJB 3.0 Change System Architecture?

    Mike Duffy Novice


      Traditionally, EJBs have been thought of as separate components (initially, EJBs were a replacement for CORBA). A specific EJB jar would contain all the dependent classes required to make that jar function.

      With EJB 3.0 and the ability to annotate plain old Java objects and turn them into detached Entity Beans, the Entity Beans can now be used easily as the business model classes within an application. There is no need for data transfer objects (DTOs) and copying value fields back and forth (good riddance!).

      Also, when a member of the JBoss group spoke at the Austin JUG, he said that the recommended architecture was for the application server and EJB server to run in the same VM. Several years ago I remember a BEA rep telling me that EJBs should run on their own dedicated server (we did that and it was tragically slow).

      With EJB 3.0, it seems that EJBs are no longer separate components; they are now integrated into the web application (or at least they will always be very close to the web application).

      As a specific issue, I am working on a test application with EJB 3.0. I have a Constants class for the web application. Some of these constants are also used by the EJBs. Should I create a separate Constants class with duplicate values for the EJBs? Should I just include the full Constants class in the EJB jar? Or should I just reference the Constants class from the EJB jar?

      Please share any thoughts you have on these specific issues or any other issues relating to the question, "How will EJB 3.0 change system architecture?"

      Thanks!

      Mike

        • 1. Re: How Will EJB 3.0 Change System Architecture?
          Mike Duffy Novice

          Here is a basic architecture I've come up with for an EJB 3.0 project.

          First I've create a projects directory: ${jboss.home}/projects

          In the projects directory I've created a project called "myCompanyCommons". This project has no dependencies on any other projects (it can be built independently). In this project I have utility classes and constant classes that are shared among all projects. When the project is built, a jar is created and placed in the directory, ""${jboss.home}/server/all/lib".

          In the projects directory I have also created a project call "myCompanyEJB". This project contains DAO interfaces, DAO beans, entity beans for data access, and other session and entity beans. When this project is built I create a single jar file, "mycompany.ejb3", that is used by my web application. This jar is placed in the directory, "${jboss.home}/server/all/deploy".

          The jar, "mycompany.ejb3", can depend on "myCompanyCommons.jar" and other external resources. I do not try to create a completely independent EJB component, nor do I break the behemoth EJB jar into individual components. If I ever decide to use my EJBs outside of my web app, or if I come up with a killer EJB component that can be useful to others, I'll break things out then. But for now, the EJBs are completely dedicated to supporting my web app, so it is very efficient to keep them all together and to deploy them as a single jar.

          My web app project is contained in an exploded war directory: "${jboss.home}/server/all/deploy/myCompany.war". The web app project depends on "myCompanyCommons" and "myCompanyEJB". Most importantly. The entity beans in "myCompanyEJB" are the business model classes in my web app project. There is no longer a need for data transfer objects (this is one of the best features of EJB 3.0).

          Most importantly, the system is very fast because I am running everything under the same instance of JBoss. I do not have a separate server dedicated to EJBs (which might make the system more easily scalable).

          This seems to be a very efficient and easily workable architecture; however, it does go against the religious principle that EJBs should be separate components.

          Please share your thoughts.

          Mike

          • 2. Re: How Will EJB 3.0 Change System Architecture?
            Robin Young Newbie

            My project(s) are of a very similar design;
            I have a common.jar in ${jboss.home}/server/all/lib which has util type classes and helper classes (ones with only static methods). These packages and therefore the jar are classed as highly stable (i.e. they will change maybe once a year). Redeployment of this jar requires a server restart.
            I also have a project specific jar which both the web tier and ejb tier use. This has project specific util type classes (enums etc) and interfaces only. This again is quite stable in the latter stages of the project development. Redeploying of this jar requires the application to be made offline but does not involve a restart of the server. This only has dependency upon the common jar.
            I also have a project specific ejb3 jar (.ejb3) this has all the session and entity beans in it. It only has dependencies upon the common jar and the project specific 'interface' jar. Redeployment of this jar only requires the application to be made offline temporarily.
            I also have a project specific war (the web tier), this has all the web stuff in it. It only has dependencies upon the common.jar and the project specific 'interface' jar. Redeployment of this jar only requires the application to be made offline temporarily.
            When swapping from ebj2.x to ejb3 all that I had to change was the ejb jar. The ejb2.x version has ejbs and data transfer objects in ejb3 these are combined. The web tier uses objects that conform to an interface and does not have dependencies on the objects themselves.
            Mike's dependancy of his web tier on his ejb tier will require his web tier to be redeployed if his ejb tier is changed. It may also produce class loading issues in some circumstances which would require a server restart.

            Of course my architecture is not quite as simple as outlined above; in my full system there are multiple 'service' ejb jars, multiple wars and there is a degree of interoperability between them. Separation is achieved by having an interface jar for each service jar.

            • 3. Re: How Will EJB 3.0 Change System Architecture?
              Mike Duffy Novice

              Thx for your response.

              I am not sure I understand your statement: "The ejb2.x version has ejbs and data transfer objects in ejb3 these are combined. The web tier uses objects that conform to an interface and does not have dependencies on the objects themselves. "

              Are you saying that you have an interface for your entity beans?

              I do use a interfaces for my DAOs. I call the DAO interfaces from delegates in my web tier.

              You are correct, there is a dependency on the EJB tier from the web tier, and that leads to my basic question: Becasue entity beans can be POJOs with annotations, why not use the entity beans as business model objects within the web tier?

              The disadvantage of a server restart may be a false issue. In most cases, any significant change in the EJB tier will also involve changes in the web tier, which would require a server restart in any event.

              My goal is to create an architecture that is as simple as possible with as much funtionality as possible.

              I hope that more people will voice thier thoughts on these issues.

              Mike

              • 4. Re: How Will EJB 3.0 Change System Architecture?
                Magnus Sandberg Novice

                Hi ,

                I do not have a current ejb setup for the project I'm working on now so I'm starting with ejb3 more or less from scratch. I've been playing around with it for some time now and there are a few issues that I'm concerned about.

                My starting point here is that I have a Client and a Server, the Server consists of a number of Session and Entity Beans with Business rules etc. I want to hide as much as possible of the inner workings of the Business-layer from the Client. The Client could in this case be a Web-Layer or a Java Client.

                One if the good things with the Entities in pre ejb3 was that you could hide the implementations details in the Server by just exposing interfaces to the client. The implementation class was not needed the by client. This is still true for Sessions in ejb3 but to use the ejb3 Entities as Detached objects the class must be serialized and moved to the Client, so the Client must be able to access the actual implementation Class of the Entity and (possible) all the Classes that the Entity had references to.

                I do not like the idea of exposing the implementation in this way but I'm not sure on how to handle this in an easy yet powerful way. It would be possible to create Statefull Sessions acting like ejb2 Entities or to use some kind of property-bags for data transfer between the Client and the Server. None of those approaches feels all that appealing. A third way would of course be to use a WebServices API. I will most likely use this for client that are physically distant from the server but I guess that using this kind of API for clients that are close to the server reduces performance.

                The bottom line is that I basically want to have three jars:
                1. server.ejb3 (used only by the Server)
                2. interfaces.jar (the 'protocol' - used both on the Client and the Server)
                3. client.jar (or war ... used only by the Client)

                Do you have any comments on this - what seems to be the best approach?

                /Magnus

                • 5. Re: How Will EJB 3.0 Change System Architecture?
                  Robin Young Newbie

                  In response to Mike,

                  I am indeed saying that I have an interface to my entity beans which is used by my web tier. The web tier is actually using the 'POJOs with annotations' it just isn't explicitly aware of the fact. i.e. The number of objects created in both architectures will be the same.

                  You say 'In most cases, any significant change in the EJB tier will also involve changes in the web tier, which would require a server restart in any event.' This is true and would be true for me (as the interfaces will have changed), but if you drop the word significant then its a different ball game. Quite drastic changes can still be made to the underlying implementation without the need to change any interfaces (as these are determined by design points as to how the sytem functions).

                  There is also the ability to have two completely independant teams work upon the web and ejb tiers, with them only having to synchonise their work based upon the commonly defined interfaces. Which is a point I failed to mention in my earlier post.

                  Robin