CUBA FAQ
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.