Projects using EJB have a common problem: EJBs are necessary for some reason (e.g. scalability) but using EJBs does harm the development process and the flexibility of the application:
- The turn-around times (edit-compile-deploy-execute) are much longer with an application server than within a stand alone rich client application.
- If unit tests fail, there are two possible reasons: The code is broken or the application server is not available. It can cost some efforts to figure out what the reason really was.
- Some application servers consume a lot of memory and are therefore not usable on developer PCs. Then parallel tests of developers may influence each other in an unintended way.
- Sometimes there is the requirement that the same application must be runnable with and without an application server. That’s especially true for off-the-shelf products.
These problems are solvable through architecture. It is possible to introduce abstractions that allow to execute the application with and without an application server. On the downside these abstractions introduce a lot of complexity which often irritate developers.
With MockEJB there is the alternative to solve the mentioned problems with technology. MockEJB provides a local container for session beans (entity beans are not supported yet). That enables the application to simply use EJBs without further abstractions while being executable without an application server.