Java™ Application Development on Linux - Dator

494Chapter 22Building an EJBclasses, 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 bywriting some Java classes.It’s not that we just write a single EJB class, say a session bean, and we’redone. Keep in mind that we’re going to be using these beans in a distributedenvironment, so we need a way to have an application running on one systemfind, create, look up, or otherwise access the bean running on another machinesomewhere in our enterprise network. The job of EJBs is to simplify (up to apoint) the efforts of the application programmer doing all this, and make itseem 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 providedby 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 homeinterface. The home interface object is in effect a factory for producing remoteinterfaces, which are the proxies for the actual service(s) that our applicationwants to use. A remote interface has the method signatures that give the functionalitythat the application is after, but it doesn’t do the actual work of thebean. Rather, it is a proxy for the bean. The remote interface’s job is to do allthe work behind the scenes to marshal the arguments and send them off to thebean, 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 themethods you want to use, but without having to write all the code to do it. Forexample, with the remote interface you may define a method to do somethingwith several arguments, say Blah(a, b, c). Now the remote object doesn’treally 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 unmarshalthe results. So you as an application programmer will write the guts ofBlah in the EJB object, but for the remote object, its proxy, you only need todeclare the method signature. Then the job of the EJB container (e.g., JBossor Geronimo) is to provide the smarts of the proxy—that is, to generate a Javaclass that implements your interface, along with the code that knows how tocontact your EJB and marshal and unmarshal the arguments and results. That’s