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.

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

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