...
El Ejemplo Time Bean
Este es un ejemplo de una página-JSP que llama a un Session Bean. El resultado es similar a:
...
Bien, lo que quiero es un EJB que me pueda decir el tiempo, lo siguiente es el código para el bean:
...
He puesto mi EJB en un paquete al cual llamo mytimepak. Los primeros 6 métodos son implementaciones de la interfaz javax.ejb.SessionBean. No se realmente que tan buenos sean, pero el método ejbCreate es como un constructor, en este caso un constructor vacío. Para permitir a los clientes el llamar al EJB se deben proporcionar a las famosas interfaces home y remote. La primera, la interfaz home, se usa para localizar al EJB y la otra, la interfaz remote, se usa para invocar métodos en el EJB. La interfaz remote es como una interfaz normal empleada para RMI. Como este EJB sólo será usado desde una página-JSP que se ejecuta en el mismo servidor (la misma JVM) yo uso otro tipo de interfaces que no emplean la red. Son conocidas como LocalHome y Local interface, aunque son lo mismo.
A continuación se muestra el código para la interfaz local home (la cual corresponde a la interfaz home):
...
...
Como puedes ver, la interfaz LocalHome es como un constructor que devuelve MyTimeLocal.
A continuación se muestra el código para la interfaz Local (la cual corresponde a la interfaz remota)
...
...
Esta es sólo una interfaz plana para los métodos (prefiero no llamarlos métodos de negocio) del EJB, en este caso el método getTime().
Ese código no es díficil entenderlo, la parte complicada son los descriptores de activación (deployment descriptors). Necesitas 2 de ellos, ejb-jar.xml y openejb-jar.xml. Así es como se observan:
ejb-jar.xml:
...
...
Primero tienes algo que no se que tan bueno sea, por ejemplo el tag display-name. Creo que puedes escribir lo que quieras ahí. Me parece completamente innecesario, pero no he probado que pasa si lo asumo así. Lo que importa son los tags ejb-name, local-home, local, ejb-class, session-type. Creo que ejb-name es parte de lo que usan los clientes para localizar al bean (consulta al siguiente archivo-xml). Los tags local-home, local y ejb-class apuntan a las clases. El tipo Session indica que se trata de un statefull (con estados) ó stateless (sin estados) session bean. Creo que el tipo de transacción no tiene sentido, ya que no hay transacciones en un session bean, ¿o si las hay? He intentado leer más sobre estos descriptores de activación aquí: http://cwiki.apache.org/GMOxDOC11/deployment-plans.html Pero no he podido deducirlo. En el otro extremo, creo que los archivos ejb-jar.xml no serán necesarios en la siguiente generación EJB 3.0, por lo que uno no debería gastar mucho tiempo en tratar de entenderlo.
A continuación el archivo openejb-jar.xml:
...
...
------------------------------- > FALTA TRADUCCION
Again, I don't understand much of the first part, but the ejb-ref part is important. ref-name=ejb/MyTimeBean is what clients use to lookup the EJB. ejb-link=MyTimeBean is the same as ejb-name=MyTimeBean in ejb-jar.xml. The ejb-link and the ejb-name must be the same.
(Why this information has bean split up in 2 files is a mystery to me. I guess that it has something to do with what is generic for the application (ejb-jar.xml) and other stuff that is spesific to the application server. If you were to deploy this application on another application server than geronimo you would only have to change the openejb-jar file. That sounds good. On the other hand, now you have the extra complexity of knowing what goes where and that sure aint easier than having to rewrite one sigle deployment descriptor if you would face the rare situation of deploying your code on another type of server. But this is ofcourse my personal oppinion based on limited understanding of EJB.)
...
This is my JSP-page, I comment the code directly in the code:
...
...
Note that this JSP-page also have to include mytimepak.MyTimeLocalHome and mytimepak.MyTimeLocal. I have done that in the first line import="mytimepak.*. This two class files must be in the WEB-INF/classes directory, and not only that, in the WEB-INF/classes/mytimepak directory. I'll get back to that later.
If the JSP is simple, again the deployment descriptors are hard (or at least that is what I think). This is what they look like:
geronimo-web.xml:
...
...
Only inportant here (as far as I understand) is the context-root that becomes the URI.
web.xml
...
welcome-file is what file the server will show if no file name is in the URI. ejb-local-ref is important. Here you must get the data right in all the tags (or so I think). Note how ejb/MyTimeBean corresponds to ref-name int openejb-jar. ejb-link seams to be unessesary, but we can't deply it without the local-home and local tags pointing out the classes for the interfaces.
There are 2 more deployment descriptors, the ones for the application as a whole. This is what they look like:
application.xml
...
...
This file tell which two modules, the ejb and the web, that the ear file consists of.
geronimo-application.xml:
...
...
This file is pretty empty. The only thing of importance is the artifactId, it shows if you look a the lists of modules at http://localhost:8080/console/portal/apps/apps_ear like this: default/MyPhonebook_ArtifactId/1.0/car
(Anybody knows what "car" stands for?)
Allright, this is how I have organised my files :
...
First we must compile the EJB.
Then copy the interface classes to the WEB-INF\classes\mytimepak directory
Last task is to pack the EJB-jar file the WEB-war file and finaly the EAR-file.
To compile the EJB we must have geronimo-ejb_2.1_spec-1.0.1.jar in the classpath. I have installed geronimo in C:\geronimo\geronimo-1.1 and This is a bat-script that does this. Modern programmers use ant ofcourse, but for clarity, this is exactly what is needed to get the ear. So beginning in the app-home directory (in my case cd c:\java\j2ee\mytime)
...
...
As you can see here I start with declaring a variable CLPATH just not to get to long lines. Then cd to the ejb-directory and compile the EJB. Then copy the interface flasses to the web application. Then I use jar to first create an jar file for the EJB, then a war-file for the web, and finaly put this to jars (or mor corectly the jar and the war) in an ear file. Note how the META-INF/WEB-INF is directly in the jar-file root directory for all the jars.
Finaly the ear must be deployed. I use the geronimo deploy tool like this:
...