What is CUBA?

CUBA is a small framework for the development of component-based systems which can be run as EJB applications, AXIS WebServices or stand-alone J2SE programs. The component and programming model is based on and equivalent to the EJB 3 session beans model. CUBA was originally built to allow the reuse of components in different runtime environments without modifications. Additionally, CUBA speeds up the development of client-server applications by avoiding most packaging and deployment actions and allowing ordinary local testing and debugging of components.

Does CUBA also provide an equivalent to JPA?

In fact CUBA does not only provide an equivalent but direct JPA support. In EJB environments this is based on the JPA providers integrated in the application server. CUBA's embedded container which is used in all other supported runtime environments allows to integrate independent JPA providers like Hibernate. Examples for JPA and the use of other non-standardized persistence managers are included in the CUBA destribution.

Why does CUBA not just follow the EJB standard?

CUBA actually follows the principles of the EJB 3 session beans model and provides equivalent functionality. However, it makes some important simplifications and generalizations making the model also applicable to more primitive environments without causing too much overhead. It was a design decision to define an EJB-independent API which can be mapped straight-forward to both EJB 3 and EJB 2 environment as well as to any other one. Especially, the CUBA API hides a few nasty inconveniences of EJB 2, which is also one of the supported platforms.

What is the difference to OpenEJB?

In fact CUBA and OpenEJB follow the same basic idea of providing a common model for both distributed and single-process applications. Nevertheless the approach is different: OpenEJB is basically itself an EJB container, which can be plugged into various environments allowing to host Enterprise JavaBeans in these. As a consequence, any problems and unconveniences inherited from the EJB philosophy and programming model remain as they are. On the other side, an existing EJB application can be ported to OpenEJB with a minimum effort.
CUBA's approach is to work with a simplified and more convenient model, resulting in a much smaller footprint of the framework itself. The CUBA model is functionally equivalent to EJB 3 SessionBeans and designed to suit both JEE and non-JEE environments. In a managed environment, CUBA components actually are EJBs and require a JEE application server to run in. The runtime library for EJB mode provides only an ultra-thin compatibility layer to host the components in both EJB 2 and EJB 3 containers. For non-managed environments, CUBA provides a very small enbedded container of less than 100k size.

Why AXIS instead of EJBs for WebServices?

Sure: as CUBA follows an EJB-equivalent model, it is an option to run the components as EJBs in a JEE application server and provide SOAP access by appropriate WebService endpoints. This is part of the EJB standard since version 2.1 and there is no additional help from CUBA needed. However, the AXIS framework is a much smarter solution than a full-fledged JEE environment. It is much simpler to deploy and maintain an AXIS WebService in a Tomcat servlet engine than an EJB in an application server. Of course an AXIS environment is not that powerful and has a number of drawbacks e.g. concerning scalability, security and distributed transactions. But in many applications it is nevertheless a reasonable platform. CUBA gives you the option to choose the best-suited runtime environment end even change it later on without having to change any code. This is an important option which keeps people from bothering too much wether AXIS is powerful enough or not. You could just try it and move to an application server if actually required.
Since CUBA 3 there is also another important reason. The webservice tunneling mode allows to provide any CUBA component as a WebService without limitation to stateless components and. This allows to make up the world's smallest application server from just a servlet engine, AXIS and CUBA's embedded container using SOAP as communication protocol an eliminating firewall problems you usally experience with protocolls like IIOP or JNP.

Do I actually need CUBA for testing EJBs?

One of the major goals of the EJB 3 standard is to simplify unit testing of EJBs outside an application server. That's a good idea and it is actually not new - especially not for CUBA users because this was an intention of the CUBA framework from the very beginning of the project. From the first sight it may look like that something like CUBA is no longer needed in EJB 3 because unit tests can easily be hand-written by tying all required parts together through the newly introduced dependency injection approach. But that won't work out very good because you will quickly find out that in this case nobody is providing all the container services any more which make EJBs so easy to code, e.g. container-managed transactions, call-chain-management, resource management etc. You will soon realize that serious testing requires at least a minimal container for the infrastructural issues which at the end leads exactly to what CUBA's wired container provides.

Home Introduction Javadoc