Java Reference
In-Depth Information
classes, then compile them. Then, in the next chapter, we'll package them,
along with other supporting information, into an EAR file. But let's begin by
writing some Java classes.
It's not that we just write a single EJB class, say a session bean, and we're
done. Keep in mind that we're going to be using these beans in a distributed
environment, so we need a way to have an application running on one system
find, create, look up, or otherwise access the bean running on another machine
somewhere in our enterprise network. The job of EJBs is to simplify (up to a
point) the efforts of the application programmer doing all this, and make it
seem as if the bean is quite local or at least independent of location.
Here's how it works. Any application that wants to use the functions pro-
vided by an EJB must first locate the bean. It uses a naming service
(Chapter 21) for this. What it gets from the lookup is something called a
home
interface
. The home interface object is in effect a factory for producing
remote
interfaces
, which are the proxies for the actual service(s) that our application
wants to use. A remote interface has the method signatures that give the func-
tionality that the application is after, but it doesn't do the actual work of the
bean. Rather, it is a proxy for the bean. The remote interface's job is to do all
the work behind the scenes to marshal the arguments and send them off to the
bean, and to unmarshal the results returned from the bean.
So it's a three step process:
1. Do the lookup.
2. Use the home interface to produce a remote interface.
3. Use the remote interface to call the methods on the bean.
What's all this talk about interfaces? They provide a way to define the
methods you want to use, but without having to write all the code to do it. For
example, with the remote interface you may define a method to do something
with several arguments, say
Blah(a, b, c)
. Now the remote object doesn't
really do the
Blah
work; its job is to marshal the arguments (serialized
a
,
b
,
and
c
) and send them off to the EJB to do whatever
Blah
is, and then unmar-
shal the results. So you as an application programmer will write the guts of
Blah
in the EJB object, but for the remote object, its proxy, you only need to
declare the method signature. Then the job of the EJB container (e.g., JBoss
or Geronimo) is to provide the smarts of the proxy—that is, to generate a Java
class that implements your interface, along with the code that knows how to
contact your EJB and marshal and unmarshal the arguments and results. That's
