-
1. Re: How Will EJB 3.0 Change System Architecture?
mduffy_lists Feb 12, 2005 2:19 PM (in response to mduffy_lists)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?
ryoung2504 Feb 14, 2005 8:33 AM (in response to mduffy_lists)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?
mduffy_lists Feb 15, 2005 10:15 PM (in response to mduffy_lists)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?
emsa Feb 16, 2005 5:51 AM (in response to mduffy_lists)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?
ryoung2504 Feb 28, 2005 3:13 AM (in response to mduffy_lists)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