When compared to CORBA, EJB development is simpler due to this level of
abstraction. In fact, one of the criticisms of CORBA has been that it does
not isolate the developers from the perils of distributed component
development. For instance, dealing with security and transactions (using
the security and transaction services respectively) is not a trivial task.
It requires a thorough understanding of both distributed transactions and
security. In most cases, the developers will be required to understand the
underlying concepts for these technologies. This is one of the main reasons
that the adaptation of CORBA has been slow for building distributed
component applications. On the other hand, dealing with transactions within
J2EE is a relatively simple task.
The abstractions provided by J2EE are essential in dealing with the complex
and fast-paced development tasks of e-commerce and other enterprise
applications. Without the shielding that J2EE offers developers from the
underlying technology, it would be a monumental task to develop, debug, and
maintain these applications.
Client Development
As mentioned above, with EJB, the distinction between an object and a bean
is marginal. Let us first consider a client invoking methods on a local
(non-EJB) object:
// Create the object
OrderService orderService = new OrderService();
// Invoke a method
try
{
orderService.placeOrder(order);
}
catch(SomeException se)
{
// Catch a business exception
}
In this example, the order management functionality of an e-commerce
application is developed as a plain object. Therefore, the client creates
the object first, and then invokes a method, and catches any exception
thrown by the object during the method execution.
Let us now consider the same functionality developed as an EJB:
// Obtain the home
OrderServiceHome orderServiceHome = // JNDI lookup
// Create the service
OrderService orderService = orderServiceHome.create();
// Invoke a method
try
{
orderService.placeOrder(order);
}
catch(SomeException se)
{
// Catch a business exception
}
To keep the discussion simple, I have intentionally omitted the exceptions
related to JNDI lookup, bean creation, and remote method invocation.
As you see from these two code snippets, there are two differences between
these approaches – object creation, and exception handling. In the
first case, an instance of the OrderService class is created
using the Java new operator. In the second case, the same
reference is created using a method on the bean's remote interface. The
exception handling also differs as the client is dealing with JNDI and
remote methods in the second case. Apart from these, from the client's
perspective, there are no differences between these two implementations.
However, there is one side effect to such an abstraction provided by J2EE
and EJB — that is, developers often miss the fact that they are
dealing with distributed components and not plain objects. In reality,
there are several differences:
- Network traffic — Client calls travel via the network to the distributed component.
- Instance management — Containers hold instances of components, while clients see proxy
objects. A proxy is not a real object, but represents the server-side component on the client-side.
- Container interception for transactions, and security — Containers receive client-requests and
hand-off to instances, and while doing so, manage declarative transactions and security.
However, these details are abstracted within the container and other infrastructure.
Bean Development
The same holds true for the bean developer. With an EJB, instead of
developing just one class, the developer specifies two interfaces (the home
and remote respectively), and develops an implementation class. Although
the implementation class will have certain additional methods for the home
interface, it is largely EJB-independent.
As far as the bean developer is concerned, they are developing a class
conforming to a framework. To extend this argument further, it is easy to
see the developer need not even be aware of what a transaction is to
develop EJBs. In the majority of cases, the container-provided defaults for
transactions might do the job. One of the immediate victims of this view is
component granularity, and component distribution drives granularity
decisions.
The key point here is that higher-level abstractions such as EJB and J2EE
are like double-edged swords. Being high-level abstractions, their goal is
to shield the developers from the issues of distributed technology, such
that distributed component development is as close to normal object
development as possible — for both the client applications and
component developers. Because of this, developers miss the fact that they
are dealing with distributed components that are transaction/security
aware, and that their components communicate over the wire.
However, what is a distributed component?
A distributed component is one that can be invoked across
process boundaries via an interface for its services.
Although both CORBA and EJB support this notion, there are fundamental
differences in their evolution.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
