We connect to multiple third party system via jax-rpc. The default wrapping of those webmethods when they want to throw a fault is java.rmi.RemoteException.

The thing to keep an eye on is that EJB transactions will roll back on System Exceptions which include RuntimeException and RemoteException. The subclasses of these exception can be turned into Application Exceptions, rather than System Exceptions, and consequently not causing transaction rollbacks by the @javax.ejb.ApplicationException annotation.

However, the annotation can contain the rollback=true definition which will cause a roll back to be introduced into the flow of control of that application exception is caused.

One thing I see a lot is that people don't understand that EJB is for a distributed system in the same way that CORBA and DCOM are. For many of the implementation's EJB is put too, it is far too complex a model and I think this is where people trip up and make horrible EARs with all sorts of craziness compiled in. The simplest EAR structure is:

PROJECT-EAR
PROJECT-EJB-Client
PROJECT-EJB
PROJECT-WS
PROJECT-Util

The PROJECT-EAR contains the APP-INF/lib directory which has all the jar files that are required on the classpath for the EAR to work on a JVM. This includes the project utility jar and the client jars from other projects.

The PROJECT-EJB-Client jar is the equivalent of the IDL from CORBA. This is where the remote interfaces and DTOs for the remote interfaces are located. These serve as the stubs across the distributed network and container system. If you think of the distributed system as an ocean of stubs (remote interfaces) floating across the surface that external systems can attach to and use the concrete beans that are implemented under the surface.

The PROJECT-EJB contains the concrete bean implementations for the remote interfaces and local interfaces for the project. It also contains the necessary JPA model objects and entity beans for persistence storage. Usually this is where all the business logic resides.

The PROJECT-WS layer is a dynamic web project where the webservices reside. This is a really light layer that does little other than accept the DTOs in the WSDL and then pass them directly into the injected beans. Too often I have seen that all the business logic and manipulation is done in the WS layer rather than being off loaded into the EJB layer where the beans can handle it. This is usually the newbie mistake I see most that suggests someone doesn't understand EJB.

Another issue I see commonly is that people will compile down a WSDL in the system rather than attach to a remote interface via JNDI. This is woefully inefficient and runs the risk of calls popping out of the system and hitting unexpected webservices in the wider system. With a remote interface they will attach directly across the container and keep the business logic concise and within the scope of the EJBs.

It is surprisingly common to see the entity beans copied en-masse or compiled into a jar from one EAR and then accessed via an entity manager to persist them in another EAR. Again this is best handled by remote interfaces across the container so that only one implementation of the entity beans exist for each table being mapped.

If another project requires access to the EJBs or entity beans in another EAR the structure would be:

OTHER-EAR
OTHER-EJB-Client
OTHER-EJB
OTHER-WS
PROJECT-Util
PROJECT-EJB-Client

In that structure two jars from the original PROJECT-EAR are compiled into the OTHER-EAR's APP-INF/lib. This is the PROJECT-EJB-Client jar which contains the DTOs and Remote interfaces from the PROJECT-EAR. The other is the util jar. By compiling in the PROJECT-EJB-Client jar the OTHER-EAR has access to the EJBs in the PROJECT-EAR and can access them as if they are in the OTHER-EAR.