Descripción: Solucionario de los tres cuadernillos de matemática de 5º de Educación Primaria.
Descripción completa
Full description
Descripción completa
lingua galega 5º primaria
Descripción completa
Historia del arte argentinoFull description
lingua galega 5º primaria
Full description
presto 2010Descripción completa
uipDescripción completa
ejercicios lengua 1ºeso anayaFull description
Descripción completa
Descripción completa
nivel b1Full description
ejercicios lengua 1ºeso anaya
Anaya Ampliacion Lengua 5ª primaria
Sobre 10s autores Subrahmanyam Allamaraju Subrahmanyam Allamaraju es Ingeniero y trabaja desde hace afios para BEA Systems Inc. Trabaja en las ireas de tecnologias de empresa/distribuidas, modelos de objeto basados en XML y otras ireas relacionadas. Si desea mis informaci6n sobre sus actividades, inquietudes y otros trabajos, consulte su pigina Web enwww.Subrahmanyarn.com. Subrahmanyam desearia dar las gracias a Varaa por su colaboraci6n en las pruebas de c6digo (enfrentindose a estrictos plazos) y por compartir su frustration y su euforia.
Cedric Beust Cedric Beust es ingeniero de software y trabaja para el equipo de EJB en BEA Systems Inc. H a participado en la puesta en marcha de la versi6n 2.0 del contenedor WebLogic EJB. Doctorado en Informitica por la Universidad de Niza, Francia. Antes de doctorarse. trabai6 , Dara Sun Microsvstems donde se centr6 principalmente en CORBA. A lo largo de 10s aiios,'~edricha participado en diversas comisiones dedicadas, Sus intereses abarcan desde todo lo relacionado con la informitica por ejemplo, a EJB, CORBA y C + distribuida y la ingenieria de software en general, hasta aficiones como el golf, el squash, el tenis y el voleibol.
.
+.
John Davies John Davies trabaja como Director Jefe de Tecnologia ( C T O ) para Century 24 Solutions Ltd. (C24), www.C24Solutions.corn, una compafiia de software con sede en Londres que ofrece soluciones basadas en Java y J2EE para el mercado financiero. El ultimo product0 de C24, Elektra, disefiado para proporcionar una unica visi6n de las transacciones financieras complejas, hace extensivo el uso de todas las tecnologias J2EE. John esti embarcado en la actualidad en el proyecto de BNP-Paribas a la cabeza del grupo Technology Consulting Grup, recornendando el uso de tecnologias para proyectos actuales y futuros de todo el mundo. John comenzo en el mundo de las tecnologias de la informaci6n a finales de 10s setenta trabajando en el area de hardware, mis tarde en ensambladores, en C , C + + en el afio 87 y finalmente en Java desde principios del 96. Trabaj6 durante catorce afios como asesor principalmente en el sector bancario. Diez de estos afios 10s pas6 fuera del Reino Unido en diversos paises, incluido Estados Unidos, Asia y gran parte de Europa, donde aprendi6 a hablar algunos idiomas. En el tiempo que le queda libre entre su trabajo y escribir, John imparte clases de Java y XML para Learning Tree y es editor ttcnico de su curso de EJB 2.0. Sus aficiones incluyen viajar, la fotografia, la guitarra clisica, pilotar avionetas, el buen vino, la buena cerveza, la comida picante y socializar. John quisiera dar las gracias a su compaiiero licenciado en Astronomia Steve Miller por corregir sus trabajos y le gustaria saludar a su madre y pedirle perd6n por lo ma1 que se comport6 en el colegio.
Una vez ma's, nada de esto hubiera sido posible sin el carilio y el apoyo de m i fantastica esposa Rachel, Siento mucho las noches que te ha tocado pasar sola y gracias por L u c y James, os quiero Puede ponerse en contact0 con en [email protected].
Tyler Jewell Tyler Jewell trabaja corno "predicador" para BEA Systems Inc., donde escribe y alaba sobre las tecnologias de empresa para programadores. Es un experto preparador y mentor, especializado en arquitecturas a gran escalade e-business. Tyler es el autor de 19 cursos de preparacion sobre tecnologias de e-business y ha impartido mis de 200 seminarios sobre tecnologia a clientes y public0 en general. Es co-autor del libro Mastering Enterprise
JavaBeans 2.0 (O'Reilly 2001) y en la actualidad trabaja en el proyecto Java Web Services (O'Reilly 2002). Tyler mantiene una columna habitual sobre J2EE en www.onjava.com, es miembro de la editorial O'Reilly's Editorial Masthead y es asesor de la pigina www.theserverside.com, Tu Comunidad J2EE. Tyler dedica su tiempo libre a su familia y amigos. Su afici6n favorita es el pdquer Texas Hold 'Em en el que dos cartas cualquiera pueden ganar, per0 siempre que caigan en sus manos.
Rod Johnson Rod Johnson es arquitecto de Java de empresa especializado en aplicaciones Web reajustables. Ha pasado 10s dos dltimos arios diseriando una soluci6n J2EE para FT .corn, el portal de empresa mis grande Europa y en la actualidad esti escribiendo un libro para Wrox Press sobre diserio y desarrollo de J2EE. Despues de sus estudios, en 10s que se especializ6 en musica e informitica, Rod r e a h 6 un doctorado en musicologia antes de volver a dedkarse a1 desarrollo de software. Rod ha trabajado con Java tanto en ireas de cliente como en ireas de senidor desde su lanzamiento y se ha centrado en el desarrollo de Internet desde 1996. Su principal inter& es la arquitectura JZEE, EJB y el desarrollo Web 00. Rod reparte su tiempo entre Londres y Sydney, y le gusta el tenis, el esqui, la historia y tocar el piano. Puede ponerse en contacto con el en [email protected].
Gracias a Keriy por su amor y su apoyo, ahora que comenzamos nuestra nueva aventura.
Andy Longshaw Andy Longshaw es asesor independiente, escritor y educador especializado en JZEE, XML, tecnologias y componentes de base Web, en particular en las decisiones de diserio y arquitectura necesarias para utilizar estas tecnologias satisfactoriamente. Andy ha estado explicando tecnologia durante la mayor parte de la ultima decada en sus funciones principales de Director de Tecnologia de Content Master Ltd. y Q A Training. Tambien ofrece conferencias sobre JZEE, XML y arquitecturas de componentes de grada media. Circula un rumor sin confirmar que dice que algunas personas consiguen no dormirse durante estas sesiones. Esti dispuesto a responder a cualquier comentario, pregunta o critica sobre el capitulo de diserio que ha escrito para este libro en la pigina www.blueskyline.com.
A Sarah, Adam y Joshua que son la inspiracidn de todo lo que hago, y a rnis padres que se aseguraron de que yo recibiera una educacidn lo suficientemente buena como poder escribir este libro.
Ramesh Nagappan Ramesh Nagappan es Arquitecto de Tecnologia especializado en Java y en arquitecturas de aplicacidn de distribucidn de base CORBA. Es un predicador de Java y tambien un activo contribuyente a las especificaciones e implementaciones de fuente abierta. Antes de enpncharse a Java y a CORBA, trabaj6 como ingeniero de Investigacidn para desarrollar soluciones CAD/CAM y de dinimica de fluidos computational para aplicaciones aeroespaciales. En su tiempo libre le gusta disfrutar de 10s deportes de agua y jugar con hijo Roger. Puede encontrarle en su direcci6n de correo [email protected]. ils
Dedicado a mi esposa Joyce y a nuestro hijo Roger, por su carifio, apoyo e inspiracidn, y tambie'n a rnis queridos padres por alegrar m i vida.
Dr. P. G. Sarang Como contratista de Sun Microsystems, el Dr. Sarang forma a 10s clientes de la compafiia con diversos cursos del programa oficial de Sun. Tambien dirige el programa "Formar a formadores" y las "Pruebas de autorizacidn de instructores" en representacidn de Sun.
Como Director Jefe Ejecutivo ( C E O ) de A B C O M Information Systems Pvt. Ltd, el Dr. Sarang esti especializado en formacidn y en el desarrollo de proyectos sobre la plataforma Java/CORBA. Con casi 20 aiios de experiencia en el sector, el Dr. Sarang ha desarrollado diversos productos y ha completado con Cxito varios proyectos industriales. Es orador habitual en muchas conferencias de Lmbito nacional e internacional y contribuye regularmente con articulos tecnicos a la edicidn de revistas y diarios de tirada internacional. Sus intereses actuales incluyen la plataforma .NET y C#.
Me gustaria dedicar este libro a m i madre por su constante apoyo y paciencia.
Alex Toussaint Alex Toussaint es Director de Ingenieria para Vignette Corporation en Austin, Texas. Cuenta con mas de diez afios de experiencia en desarrollo de software y tiene una amplia experiencia en el manejo de Java desde 1996 y de las tecnologias J2EE desde 1998. Alex ha colaborado en articulos sobre aplicaciones Web y comercio electrdnico para revistas on-line, tales como Microsoft M S D N , y es coautor del libro Professional Site Server publicado por Wrox. Alex tambiin ha sido invitado a impartir clases en la Universidad de Texas en Austin Red McCombs School of Business sobre temas como Comercio Electrdnico y Desarrollo de Software de Empresa. Alex reside en Austin, Texas, en la actualidad con su esposa Danielle y su perro Sasha. Alex e s t i a su disposicidn en la direcci6n [email protected].
Sameer Tyagi Sameer escribe regularmente para publicaciones on-line e impresas. Cuenta con mas de cuatro afios de experiencia en diseiio y desarrollo de software y esti especializado en aplicaciones distribuidas de lado del servidor de base Java (arquitecturas n-Grada, JDBC, JNDI, EJB, JMS, RMI, JSP, Servlets, et al.). Es licenciado en Ingenieria Electrdnica y tiene una amplia formacidn sobre el tema. Es un adicto a Java y consigue su dosis saltando de cabeza a casi cualquier cosa que se compila en c6digos de bytes y se le conoce como el culpable de esa nueva area del cerebro Ilamada Javaesfera por dichos estimulos. Cuando no estC disfrutando de un cafC, puede encontrarle volando a unos 15000 pies de altura en una pequeria Cessna.
Gary Watson Gary Watson ha estado desarrollando el uso de Java durante 10s ultimos 4 arios. Es asesor independiente de Tecnologias de la Informacidn y, en la actualidad, trabaja como Arquitecto TCcnico en el Financial Times, FT. com, en el desarrollo de una importante soluci6n J2EE. Graduado por la Universidad de Teeside en 1993, Gary es Licenciado en Ciencias de la Informltica. Siempre que le es posible, Gary disfruta del windsurf, del esqui y de 10s aviones en miniatura. N o participa en estas actividades tan a menudo como le gustaria. Puede encontrarle en [email protected].
A m i esposa Angela por su amor, apoyo y aliento mientras luchamos juntos en la vida diaria.
Marc Wilcox Marc trabaja en el grupo de servicios profesionales de W e b C T Inc., la principal compafiia del mundo de desarrollo de Sistemas de Gestidn/Entornos de Aprendizaje Virtual. La prdxima version de su producto, cuyo nombre en clave es Cobalt, estari basada en un entorno de aplicaci6n J2EE.
Me gustaria dedicar este libro a Doug y a Sammy, 10s mejores peluqueros del mundo.
Alan Williamson Alan Williamson es todo un veterano del mundo Java, con un lenguaje que todavia intenta encontrar su lugar en el mundo. Alan cuenta con mis de 15 ahos de experiencia en el mundo del desarrollo de software. Se graduo con Honores en Ciencias de la Informitica por la Universidad de Paisley. Alan trabaj6 principalmente en tareas de investigaci6n y desarrollo hasta que establecio la primera compahia del Reino Unido dedicada Gnicamente a1 asesoramiento en Java hace 4 ahos, especializandose en Java en lado del servidor (http://www.n-ary.com). Alan t a m b i h ha llegado hasta lo mis alto convirtihdose en Editor Jefe de la revista mis importante del mundo sobre Java, Java Developers Journal y puede encontrarle dando conferencias por todas partes.
Me gustaria dar las gracias a m i querida Ceri y a m i nuevo hijo Cormacpor guardar el fuerte mientras yo trabajaba e investigaba para escribir este capitulo. Buen trabajo. Adernas, me gustaria dar lax gracias a Keith y Marion por realizar sus tareas de profesor y leer m i capitulo corrigiendo mis errores de gramatica. Finalmente, me gustaria dar las gracias a Wrox por hacer de este proceso de escritura algo alegre y no algo doloroso.
37
Introduccion
J2EE Edici6n 1.3 .......................................................................................................................................... 37 iQuk ha cambiado en esta edicion del libro? ....................................................................................... 38 ?A quiin va dirigido este libro? ................................................................................................................
38
tCubles son 10s contenidos de este libro? ...............................................................................................
39
Lo necesario para utilizar este libro ......................................................................................................... 39 Contenedor Web ............................................................................................................................. 39 Contenedor EJB .............................................................................................................................. 39 Bases de datos ................................................................................................................................... 39 Software adicional .......................................................................................................................... 40
.............................................................................................................................................. Atenci6n a1 cliente .................................................................................................................................... C6mo cargar el c6digo de muestra para el libro .................................................................................... Erratas ........................................................................................................................................................... Apoyo via e-mail ......................................................................................................................................... p2p.wrox.com .............................................................................................................................................. Convenciones
Capitulo 1 Plataforma JZEE Programac~onpara empresas .....................................................................................................................
La empresa actual ........................................................................................................................................ 46 iEs Java la respuesta? .............................................................................................................................49 Independiente de la plataforma ....................................................................................................... 49 Objetos gestionados ........................................................................................................................49 Reusabilidad ...................................................................................................................................... 49 Modularidad ......................................................................................................................................50
Estilos de arquitectura de empresa 50 Arquitectura de dos niveles ................................................................................................................... 50 Arquitectura de tres niveles ................................................................................................................... 51 52 Aquitectura de n niveles ....................................................................................................................... Arquitectura de empresa ........................................................................................................................ 53 La plataforma JZEE ..................................................................................................................................... 55 Period0 de ejecuci6n de J2EE ............................................................................................................... 55 Los API de J2EE .................................................................................................................................... 56 Contenedores ........................................................................................................... 58 Arquitectura JZEE . Arquitectura de contenedor ....................................................................................................................... 60 Contratos de componentes ............................................................................................................ 61 API de servicio de contenedor ....................................................................................................... 62 63 Servicios declarativos ....................................................................................................................... Otros servicios de contenedor ....................................................................................................... 65
Desarrollo de aplicaciones JZEE 71 . . Funciones de desarrollo e implementaci6n de apl~caclones................................................................ 72 Desarrollo de componentes de aplicaci6n ........................................................................................... 73 Composici6n de componentes de aplicaci6n en m6dulos ................................................................ 73 Composicibn de m6dulos en aplicaciones ........................................................................................... 73 74 Implementaci6n de la aplicaci6n ........................................................................................................... Resumen .......................................................................................................................................................
Servicios de designaci6n y de directorio 77 Servicios de designaci6n ........................................................................................................................ 78 Servicios de directorio ........................................................................................................................... 79 80 LDAP ...................................................................................................................................................... Datos LDAP .................................................................................................................................... 81
Las concesiones ................................................................................................................................ 85 85 iPor qu6 utilizar J N D I cuando tenemos LDAP? ......................................................................... LDAP sin J N D I ................................................................................................................................ 86 86 J N D I sin LDAP ................................................................................................................................ iY XML? ............................................................................................................................................ 86 Uso de J N D I ............................................................................................................................................... 86 Instalaci6n de J N D I .............................................................................................................................. 87
Proveedores de servicios J N D I 87 88 C6mo obtener poveedores de semicios J N D I .................................................................................. 88 C o m o desarrollar su propio proveedor de servicios ..........................................................................
Java y LDAP 89 Control de acceso .................................................................................................................................. 89 Autentificacion ................................................................................................................................. 89 90 Autorizaci6n .................................................................................................................................... 90 Semicios de piginas blancas .................................................................................................................. 91 Directorio de procesamiento distribuido ............................................................................................ Configuraci6n de la aplicaci6n ........................................................................................................ 91
Operaciones LDAP ..................................................................................................................................... 92 92 Operaciones LDAP estindar ................................................................................................................ 92 Conexion a1 semidos LDAP con J N D I .............................................................................................. 93 Asociacion .............................................................................................................................................. 94 Seguridad simple, SSL/TLS y SASL ................................................................................................ 94 Simple .................................................................................................................................................
95 SASL ................................................................................................................................................... 95 Autentificacion en LDAP v2 y LDAP v3 ......................................................................................
95 Busqueda en u n s e n i d o r LDAP 96 Filtros LDAP de ejemplo ...................................................................................................................... 96 Determinar el alcance de LDAP ........................................................................................................... LDAP-SCOPE-SUBTREE ........................................................................................................... 96 LDAP-SCOPE-ONELEVEL ....................................................................................................... 97 LDAP-SCOPE-BASE .................................................................................................................... 97 Ejecucion de una b6squeda J N D I ......................................................................................................... 98 100 Cbmo funciona el programa de bhqueda .................................................................................... Restringir 10s atributos presentados .................................................................................................. I03 Aiiadir entradas .................................................................................................................................... 105 111 Modificar una entrada .......................................................................................................................... 113 Eliminar una entrada ........................................................................................................................... Almacenar y recuperar objetos Java en LDAP ....................................................................................... 114 115 LDAP tradicional ........................................................................................................................... 116 Java serializado .............................................................................................................................. Referencias Java .............................................................................................................................. 116
116 Volver a J N D I sin LDAP Ejemplo de aplicacidn D N S ................................................................................................................. 117
La arquitectura RMI ................................................................................................................................. 122 Capa de Stub y Skeleton ....................................................................................................................... 123 Stubs ................................................................................................................................................ 124 Skeletons ......................................................................................................................................... 124 Capa de referencia remota ................................................................................................................... 125 Capa de transporte ............................................................................................................................... 125 Localizaci6n de objetos remotos ............................................................................................................ 126 Archivos de politica ...................................................................................................................... 128 Excepciones RMI ..................................................................................................................................
129
Desarrollo de aplicaciones con RMI ...................................................................................................... 130 Definir la interfaz remota ............................................................................................................131 Implementar la interfaz remota .......................................................................................................... 131 Grabar el cliente que utiliza 10s objetos remotos .........................................................................133 Generar stubs y skeletons ................................................................................................................... 134 Registrar el objeto ................................................................................................................................ 134 Ejecutar el cliente y el servidor ........................................................................................................... 135 Pasar parimetros e n RMI ......................................................................................................................... 136 Parimetros de primitivas ..................................................................................................................... 136 Parimetros de objeto ........................................................................................................................... 136 Parimetros remotos ............................................................................................................................ 137
.................................................................................................. Clases de carga dinimica ..................................................................................................................... Retrollamadas remotas ............................................................................................................................ Activaci6n de objeto ............................................................................................................................... El recolector de residuos distribuidos
138 141 146
149 El grupo de activaci6n ......................................................................................................................... 150 ActivationID .................................................................................................................................. 151 Descriptor de activacion ................................................................................................................ 152 Convertir objetos en activables ......................................................................................................... 153 Paso 1: Crear la interfaz remota .............................................................................................. 154 Paso 2: Crear la implementacih del objeto .........................................................................154 Paso 3: Registrar el objeto con el sistema ...............................................................................154 Alternativa a ampliar la clase Activatable ..................................................................................... 156 Iniciar mGltiples JVMs sin recurrir a rmid ..............................................................................157 Desactivaci6n ....................................................................................................................................... 159
................................................................................................................... RMI. cortafuegos y H T T P ....................................................................................................................... Sockets de adaptaci6n y SSL
160
172 Tunelado HTTP ................................................................................................................................... 172 H T T P a puerto ............................................................................................................................... 172 H T T P a C G I .................................................................................................................................. 173
lndice El protocolo SOCKS ..................................................................................................................... 173 174 Factorias de sockets descargados ........................................................................................................ RMI sobre I I O P ........................................................................................................................................ 174 175 Interoperatividad con CORBA .................................................................................................... Escribir programas con RMI-HOP ...............................................................................................176 176 En el servidor ................................................................................................................................. 176 HelloServer.java ............................................................................................................................... 177 En el cliente ................................................................................................................................... 177 HelloClient.java ...............................................................................................................................
180 RMI-IIOP y Java IDL 180 El archivo IDL ............................................................................................................................... 180 La implernentacion de servidor ..................................................................................................... 182 La implementacibn cliente ............................................................................................................. RMI-IIOP y J2EE ..................................................................................................................................... 184 Ajustar aplicaciones RMI ......................................................................................................................... 185 Resumen .....................................................................................................................................................
189
.
Capitulo 4 Programacion de bases de datos con JDBC Drivers de bases de datos ..................................................................................................................... 193 Puente JDBC-ODBC .......................................................................................................... 193 Tipo 1 . Parte Java, parte driver nativo ............................................................................................. 194 Tipo 2 . Servidor intermediario de acceso a bases de datos ............................................................. 195 Tipo 3 . Drivers Java puro ................................................................................................................ 196 Tipo 4 . 196 Cdmo comenzar ..................................................................................................................................
El paquete java.sq1 ...................................................................................................................................... 197 197 Gesti6n de conexion ........................................................................................................................... 198 Acceso a bases de datos ....................................................................................................................... 198 Tipos de datos ...................................................................................................................................... 199 Metadatos de base de datos .................................................................................................................. 200 Excepciones y advertencias ................................................................................................................. 201 Cargar un driver de base de datos y abrir conexiones ...................................................................... 201 Los URL de JDBC ......................................................................................................................... DriverManager ............................................................................................................................... 202 203 Mitodos para gestionar drivers ...................................................................................................... 203 Mitodos para obtener conexiones ................................................................................................. 204 MCtodos de registro ........................................................................................................................ 205 Driver .............................................................................................................................................. 205 Establecer una conexion ...................................................................................................................... 208 Crear y ejecutar instrucciones SQL ................................................................................................... 209 U n ejemplo: catdogo de peliculas ................................................................................................. 210 Crear la tabla Movie ........................................................................................................................ 210 Insertar datos .................................................................................................................................. 211 Mitodos para el manejo de excepciones ......................................................................................... 214 Consultar la base de datos ................................................................................................................... 214 Mktodos para recuperar datos ........................................................................................................ Interfaz ResultSetMetaData ............................................................................................................ 216
Instrucciones preparadas ..................................................................................................................... 217 219 Representar tipos S Q L en Java ........................................................................................................... 221 Apoyo a transacciones ....................................................................................................................... 223 Puntos de salvaguardia ......................................................................................................................... Listas de resultados desplazables y actualizables ................................................................................ 225 225 Listas de resultados desplazables ................................................................................................... Metodos relacionados con la posici6n del cursor ......................................................................... 227 227 Metodos para desplazamiento ........................................................................................................ 227 Direcci6n y tamafio de toma .......................................................................................................... Listas de resultados actualizables .................................................................................................. 230 230 Actualizar una fila ............................................................................................................................ Eliminar una fila .............................................................................................................................. 231 231 Insertar una fila ............................................................................................................................... Actualizaciones de lotes ....................................................................................................................... 231
.................................................................................................................................... Fuentes de datos JDBC ............................................................................................................................
El paquete javax.sql
232
234 La interfaz javax.sql.DataSource ......................................................................................................... 234 El mCtodo getconnection() ......................................................................................................... 234 235 El metodo getLoginTimeout() ..................................................................................................... El metodo setLoginTimeout() ...............................................................................................235 El metodo getlogwriter() ........................................................................................................... 235 235 El metodo setlogwriter() ............................................................................................................ J N D I y fuentes de datos ...................................................................................................................... 236 237 Crear una fuente de datos .............................................................................................................. Recuperar un objeto Datasource .................................................................................................. 238 Caracteristicas clave ....................................................................................................................... 238 239 Revisi6n del catilogo de peliculas .......................................................................................................
240 Reserva de conexiones Resewa de conexiones tradicional ...................................................................................................... 241 Resewa de conexiones con el paquete javax.sq1 ...........................................................................243 La interfaz javax.sql.ConnectionPoolDataSource...................................................................... 244 244 La interfaz javax.sql.PooledConnection ...................................................................................... 245 La interfaz javax.sql.ConnectionEventListener.......................................................................... La clase javax.sq1.ConnectionEvent ............................................................................................. 245 Implementaci6n de reservas de conexi6n .............................................................................245
246 Transacciones distribuidas i Q d es una transacci6n? .................................................................................................................... 246 247 Antecedentes ........................................................................................................................................ Procesamiento de transacciones - Conceptos ...........................................................................248 248 Demarcaci6n de transacciones ..................................................................................................... Contexto de transacciones y propagaci6n .............................................................................249 249 Alistamiento de recursos ............................................................................................................... Aceptar en dos fases ...................................................................................................................... 249 Construcci6n de bloques de sistemas de procesamiento de transacciones .....................................250 250 Componentes de aplicaci6n .......................................................................................................... 250 Gestores de recursos ..................................................................................................................... Gestor de transacciones ................................................................................................................ 251 251 Transacciones distribuidas JDBC ......................................................................................................
La interfaz javax.sq1.XADataSource ............................................................................................. 252 La interfaz javax.sql.XAConnection ............................................................................................ 252 La interfaz javax.Transaction.UserTransaction ......................................................................... 252 Pasos para la irnplementaci6n de transacciones distribuidas ............................................................ 253 Configuraci6n ................................................................................................................................ 254 Iniciar una transacci6n .................................................................................................................. 254 Operaciones de base de datos ....................................................................................................... 254 Finalizar una transaction .............................................................................................................. 255 Precauciones especiales .................................................................................................................. 255
El protocolo H T T P 266 MCtodos de solicitud H T T P ............................................................................................................... 266 El metodo de solicitud GET ......................................................................................................... 266 El mitodo de solicitud POST ....................................................................................................... 267 El metodo de solicitud H E A D ..................................................................................................... 267 La respuesta H T T P ............................................................................................................................. 267
Contenedores Web y aplicaciones Web 268 Sewlets Java .......................................................................................................................................... 269 Piginas JavaServer ............................................................................................................................... 272 Descriptores de despliegue .................................................................................................................. 273 Estructura de aplicaciones Web .......................................................................................................... 274 Tipos de contenedores Web ................................................................................................................ 274
Una sencilla aplicaci6n Web 275 Prepara el contenedor Web ................................................................................................................. 275 Crear el archivo H T M L ...................................................................................................................... 275 Crear un servlet .................................................................................................................................... 276 Construir la aplicacion Web ................................................................................................................ 277 Desplegar la aplicaci6n Web ............................................................................................................... 281 Ejecutar la aplicaci6n Web ................................................................................................................... 283 C6mo funciona la aplicaci6n ............................................................................................................... 283 El servlet Greeting ......................................................................................................................... 284 Importar 10s paquetes de servlet ..................................................................................................... 284 Declaraci6n de clase ......................................................................................................................... 285 Revisar la solicitud POST HTTP ................................................................................................... 285 Extraer parametros de HttpServletRequest ................................................................................... 285 Generar respuesta ............................................................................................................................ 285
................................................................................................................. Implementacidn de servlet ......................................................................................................................
Analisis del API Java Servlet
292
296 La interfaz servlet ................................................................................................................................ 296 El metodo init () ............................................................................................................................. 297 297 El metodo service() ....................................................................................................................... El metodo destroy() ...................................................................................................................... 297 El metodo getServletConfig() ...................................................................................................... 298 El metodo getServletInfo() .......................................................................................................... 298 La clase GenericServlet ........................................................................................................................ : La interfaz SingleThreadModel .......................................................................................................... La clase HttpServlet ............................................................................................................................. Los metodos service() ................................................................................................................... Los metodos doXXX() ................................................................................................................. El metodo getLastModified() .......................................................................................................
Configuracidn de servlets La interfaz ServletConfig .................................................................................................................... El metodo getInitParameter() ...................................................................................................... El metodo getInitParameterNames() .......................................................................................... El metodo- getServletContext () .................................................................................................... El mitodo getServletName0 ........................................................................................................ Obtener una referencia a ServletConfig ............................................................................................ Durante la inicializaci6n del servlet .............................................................................................. Utilizar el metodo getServletConfig() .........................................................................................
Excepciones servlet La clase ServletException .................................................................................................................... La clase UnavailableE~ce~tion ............................................................................................................
................................................................................................................. El ciclo de vida de u n servlet . FreakServlet ......................................................................................... El ciclo de vida de 10s servlets
Solicitudes y respuestas Lainterfaz ServletRequest ................................................................................................................... Metodos para solicitar parametros .................................................. :............................................ El mktodo getparameter() .............................................................................................................. 319 319 El metodo getParameterValues() ................................................................................................... El metodo getParameterNames0 .................................................................................................. 320 320 El mktodo getParameterMap0 ................................................................................................. Metodos para atributos de solicitud ............................................................................................. 320 El metodo getAttribute() ................................................................................................................ 320
El metodo getAttributesNames() .................................................................................................. 320 El metodo setAttribute() ................................................................................................................ 320 El metodo removeAttribute0 ........................................................................................................ 320 Metodos de entrada ....................................................................................................................... 321 El metodo getInputStream() .......................................................................................................... 321 El metodo getReader() .................................................................................................................... 321 El metodo getCharacterEncoding0 .............................................................................................. 321 El metodo setCharacterEncoding() .............................................................................................. 321 La clase ServletRequestWrapper ......................................................................................................... 321 La interfaz HttpServletRequest .......................................................................................................... 321 Metodos para solicitar ruta y URL ............................................................................................... 323 El metodo getPathInfo0 ................................................................................................................ 323 El metodo getPathTranslatedO ...................................................................................................... 323 El metodo getQueryString() .......................................................................................................... 324 El metodo getRequestURI0 .......................................................................................................... 324 El metodo getRequestURL0 .......................................................................................................... 324 El metodo getsewletpath() ............................................................................................................ 324 Metodos para cabeceras HTTP ..................................................................................................... 324 El m6todogetHeaderO .................................................................................................................... 324 El metodo getHeaders() ................................................................................................................. 324 El metodo getHeaderNames0 ....................................................................................................... 324 El metodo getMethod() ................................................................................................................ 324 La~laseHtt~ServletRequestWrapper ..........................................................................................325 La interfaz ServletResponse ................................................................................................................ 325 Metodos para tip0 de contenido y longitud ................................................................................ 325 El metodo setContentType() .................................................................... ....................................325 El metodo setcontentlength() ..................................................................................................... 325 Metodos de salida ........................................................................................................................... 326 El metodo getOutputStream() ....................................................................................................... 326 El metodo getwriter() .................................................................................................................... 326 Metodos para salida en bfifer ........................................................................................................ 326 El metodo setBufferSize0 .............................................................................................................. 326 El mktodo getBufferSize0 .............................................................................................................. 326 El metodo resetBuffer() ................................................................................................................. 326 El metodo flushBuffer() ................................................................................................................. 327 El metodo isCommitted() .............................................................................................................. 327 El metodo reset() ............................................................................................................................ 327 La clase ServletResponseWrapper ...................................................................................................... 327 La interfaz H t t p S e w l e t R e ~ ~ o n s....................................................................................................... e 327 MCtodos para el manejo de errores .............................................................................................. 328 El metodo sendError() .................................................................................................................. 328 El metodo sendError() .................................................................................................................. 328 El metodo setstatus() ..................................................................................................................... 328 El metodo sendRedirect() ............................................................................................................. 328 La clase HttpServletResponseWrapper .............................................................................................. 328 Funci6n de las clases envoltorio ......................................................................................................... 328
Programacidn de servlets . Aplicacidn de apoyo tkcnico ................................................................... 329
Configurar la pigina HTML ......................................................................................................... 330 Preparar la base de datos ................................................................................................................ 332
Escribir el servlet ........................................................................................................................... 333 Extraer datos del formulario .......................................................................................................... 334 Insertar la solicitud de apoyo tecnico ............................................................................................. 334 335 Generar la respuesta ........................................................................................................................ Compilar la fuente ....................................................................................................................... 336 Construir la aplicaci6n Web .......................................................................................................... 336 340 El descriptor de despliegue .............................................................................................................. 340 Configurar la fuente de datos ....................................................................................................... Desplegar la aplicaci6n Web ......................................................................................................... 341 Apoyo tecnico en marcha ............................................................................................................. 344 Resumen .................................................................................................................................................... 346
.
Capitulo 7 Sesiones de servlets. context0 y colaboracion
349
.............................................................................................................. Enfoques del registro de sesi6n ..............................................................................................................
Protocolo sin estado y sesiones
350
352 Reescritura de URL .............................................................................................................................. 353 Campos de formulario ocultos ........................................................................................................... 354 Cookies ................................................................................................................................................. 354
Registro de seslon con el API Java S e n l e t 356 Creaci6n y registro de sesiones .......................................................................................................... 357 357 La interfaz HttpSession ...................................................................................................................... Metodos para vida de sesion ......................................................................................................... 358 El metodo getCreationTime0 ........................................................................................................ 359 El mitodo getId() ........................................................................................................................... 359 El mitodo getLastAccessedTime() ................................................................................................. 359 El mitodo getMaxInactiveInterval() ............................................................................................. 359 El metodo setMaxInactiveInterval() ............................................................................................. 359 El metodo isNew() ......................................................................................................................... 359 360 El metodo invalidate() .................................................................................................................... 360 Demostrar el ciclo de vida de la sesion con cookies ................................................................... Ciclo de vida de sesion sin cookies .............................................................................................. 364 365 Metodos para gestionar el estado ................................................................................................. El metodo getAttribute() ................................................................................................................ 365 El metodo getAttributeNames0 .................................................................................................... 365 El mCtodo setAttribute() ................................................................................................................ 365 366 El metodo removeAttribute() ........................................................................................................ Demostrar la gesti6n de estado .................................................................................................... 366 Manejo de eventos de ciclo de vida de sesi6n .................................................................................... 369 369 La interfaz HttpSessionListener .................................................................................................. La interfaz HttpSessionActivationListener ................................................................................ 370 El mitodo sessionDidActivate() .................................................................................................... 370 370 El metodo sessionWillPassivate() .................................................................................................. 370 La clase HttpSessionEvent ............................................................................................................ El mCtodo getsession() .................................................................................................................. 370 Manejo de eventos de atributos de sesi6n ......................................................................................... 371 371 La interfaz HttpSessionBindingListener..................................................................................... El metodo valueBound() ................................................................................................................ 371 El metodo valueUnbound() ........................................................................................................... 371
La interfaz HttpSessionAttributeListener ................................................................................... 371 El metodo attributeAdded0 ........................................................................................................... 372 El metodo attributeRemoved0 ...................................................................................................... 372 El metodo attributeReplaced0 ........................................................................................................ 372 La clase HttpSessionBindingEvent .............................................................................................. 372 El mitodo getName() ..................................................................................................................... 372 El mitodo getvalue() ...................................................................................................................... 372 El metodo getsession() .................................................................................................................. 372 U n sencillo carro de la compra utilizando sesiones ........................................................................372 El senlet del catilogo .................................................................................................................... 373 El senlet Shoppingcart ................................................................................................................ 374 Contexto de sewlet ................................................................................................................................... 377 La interfaz Senletcontext .................................................................................................................. 378 El mttodo getMimeType0 .............................................................................................................. 378 El mttodo getResource0 ................................................................................................................ 378 El metodo getResourceAsStream() ............................................................................................... 378 El metodo getRequestDispatcher() ................................................................................................ 379 El metodo getNamedDispatcher ................................................................................................. 379 El metodo getRealPath0 ................................................................................................................ 379 El metodo getcontext () ................................................................................................................. 379 El mitodo getSenerInfo() ............................................................................................................. 379 El metodo getSenletcontextName() ............................................................................................ 379 El metodo getResourcePaths() ...................................................................................................... 379 Los metodos getInitParameter0 y getInitParameterNames() ....................................................380 Los metodos getAttribute0, getAttributeNames0, setAttributes0 y removeAttribute0 ........380 Los metodos log() .......................................................................................................................... 380 El manejo de eventos de ciclo de vida de Senletcontext ..............................................................380 La interfaz Senlet Context Listener .............................................................................................. 380 SenletContextAttributeListener.................................................................................................. 381 Una aplicacion de chat que utiliza context0 y sesiones ..................................................................381 La clase ChatRoom ........................................................................................................................ 384 La clase ChatEntry ........................................................................................................................ 384 El senlet de administracion .......................................................................................................... 385 Servlets para chat .......................................................................................................................... 388 La clase ListRoomsSenlet .............................................................................................................. 388 La clase ChatRoomSenlet .............................................................................................................. 391 Configuration del chat .................................................................................................................. 396 Una pigina de bienvenida ................................................................................................................ 396 Descriptor de despliegue ................................................................................................................. 396 Desplegar y probar .......................................................................................................................... 397
..
Colaboracion de sewlet ............................................................................................................................ 399 Encadenado de senlet ...................................................................................................................399 Lanzamiento de solicitudes ........................................................................................................... 400 La interfaz RequestDispatcher ...................................................................................................... 400 El metodo forward() ...................................................................................................................... 401 El metodo include() ........................................................................................................................ 401 Obtener un objeto R e q ~ e s t D i s ~ a t c h ........................................................................................ er 401 Revision de Apoyo Tecnico ................................................................................................................ 401 La pigina techsupp.html ................................................................................................................ 402
TechSupportSe~let....................................................................................................................... 404 La pagina register.htm1 .................................................................................................................. 406 RegisterCustomerSe~let.............................................................................................................. 407 ResponseSe~let............................................................................................................................. 408 BannerServlet ................................................................................................................................. 409 Configuracion de Apoyo Tkcnico y despliegue ........................................................................... 411 Utilizar RequestDispatcher para colaboraci6n ............................................................................412 Reenviar una solicitud a ResponseSemlet ...................................................................................... 412 Reenviar solicitud a regiter.htm1 ..................................................................................................... 412 Incluir insignia en ResponseSemlet ............................................................................................... 413 Resurnen ................................................................................................................................................. 413
.
Capitulo 8 Filtros para aplicaciones Web
415
..................................................................................................................................... Filtro de rnuestra .................................................................................................................................. i Q u i es u n filtro?
El API filtro .............................................................................................................................................. 422 La interfaz de filtro .............................................................................................................................. 422 El mktodo init () .............................................................................................................................. 423 El metodo doFilter() ....................................................................................................................... 423 El metodo destroy() ....................................................................................................................... 423 La interfaz Filterconfig ...................................................................................................................... 424 El metodo getFilterName() ............................................................................................................ 424 El mitodo getInitParameter0 ........................................................................................................ 424 El metodo getInitParameterNames() ............................................................................................ 424 El metodo getSemletContext() ...................................................................................................... 424 La interfaz Filterchain ........................................................................................................................ 424 El metodo doFilter() ....................................................................................................................... 425 Descriptor de despliegue para filtros ................................................................................................. 425 La aplicacidn de chat con filtros ............................................................................................................. 427 Registro de mensajes ........................................................................................................................... 428 Moderaci6n de mensajes ..................................................................................................................... 430 Descriptorde despliegue ...................................................................................................................... 434 Despliegue ....................................................................................................................................... 436 Chat con registro y moderaci6n ........................................................................................................ 437 Resurnen ..................................................................................................................................................... 438
.
Capitulo 9 Despliegue Web. autentificacion y empaquetado 4 4 1 Estructura de aplicacidn Web .................................................................................................................. 441 Estructura de directorio ...................................................................................................................... 442 Ficheros en archivo Web .......................................................................................................................... 444 Desplegar un archivo WAR .......................................................................................................... 445 i C u i n d o deben utilizarse 10s archivos WAR? ............................................................................ 446 Asociar de solicitudes a aplicaciones y servlets .................................................................................... 446
lndice Asegurar aplicaciones Web ....................................................................................................................... 451 Seguridad programada ..................................................................................................................454 El mitodo getAuthtype() ............................................................................................................... 454 El metodo getRemoteUser() ................................................................................................... 454 El metodo getUserPrincipal() ..................................................................................................454 El mCtodo isUserRole() ................................................................................................................. 454 Autentificacibn basada en un formulario ....................................................................................454
Configuraclon de despliegue 457 Parimetros de inicializaci6n de context0 .......................................................................................... 458 Parimetros de inicializaci6n de servlet ............................................................................................459 Cargar servlets en el arranque ............................................................................................................ 459 Tiempo limite de sesi6n ....................................................................................................................... 460 Asociaciones MIME ............................................................................................................................ 460 Archivos de bienvenida ....................................................................................................................... 461 Piginas de error ................................................................................................................................... 462 Enviar errores ............................................................................................................................463 Lanzar ServletException .........................................................................................................463 Manejar errores y excepciones HTTP ......................................................................................... 464 Aplicacionesdistribuibles .................................................................................................................... 465 Resumen ....................................................................................................................................................
.
Capitulo 10 Fundamentos y arquitectura de JSP
........................................................................................................................ Presentaci6n de JSP ................................................................................................................................ Los aspectos pricticos ............................................................................................................................. La especificaci6n JSP 1.2
lndice El objeto Request ........................................................................................................................... 505 505 El objeto Response ........................................................................................................................ 505 El objeto Pagecontext .................................................................................................................. El objeto Session ........................................................................................................................... 505 506 El objeto Application ..................................................................................................................... 506 El objeto O u t ................................................................................................................................. 506 El objeto Config ............................................................................................................................ 506 El objeto Page ................................................................................................................................. Alcance .................................................................................................................................................. 506 507 Alcance de pigina ........................................................................................................................... 507 Alcance de solicitud ........................................................................................................................ 507 Alcance de sesi6n .......................................................................................................................... 507 Alcance de aplicacion ..................................................................................................................... 507 Piginas JSP como documentos XML ................................................................................................ 508 Directrices ...................................................................................................................................... 508 Elementos de directivas ................................................................................................................. Acciones ......................................................................................................................................... 509 509 Una pigina de ejemplo ................................................................................................................... 509 Sintaxis JSP ...................................................................................................................................... 509 Sintixis XML ................................................................................................................................... Apoyo tecnico JSP .................................................................................................................................... 509 511 Disefio de aplicacih ............................................................................................................................ 511 La pigina de bienvenida ....................................................................................................................... La pagina JSP de procesamiento de solicitudes ...............................................................................512 513 La clase JDBCHelper .......................................................................................................................... 514 TechSupportBean ................................................................................................................................. 516 Formulario de registro ........................................................................................................................ 517 JSP de registro ...................................................................................................................................... 517 Las piginas JSP de respuesta y de anuncio ......................................................................................... 518 La pigina de error ................................................................................................................................ 519 Desplegar la aplicacidn ......................................................................................................................... Estrategias de disefio JSP ......................................................................................................................... 520 521 Disefios centrados en la pigina o cliente-servidor ........................................................................... 521 Vista de pigina ...................................................................................................................................... 522 Vista de pigina con bean ..................................................................................................................... 523 El patron de controlador frontal ....................................................................................................... Implementaci6n de una arquitectura de controlador frontal .......................................................524 524 Servlet controlador ........................................................................................................................ 525 Manejadores de solicitud ............................................................................................................... 525 Beans de pigina .............................................................................................................................. 525 Vistas JSP ....................................................................................................................................... Implementation ............................................................................................................................. 526 534 Ventajas .......................................................................................................................................... 535 Utilizar un sistema de controlador genkrico ............................................................................... Resumen ................................................................................................................................................... 535
.
Capitulo 11 Extensiones de etiaueta de JSP Extensiones de etiqueta ............................................................................................................................. 539
Mejoras de la extensi6n de etiqueta JSP 1.2 ....................................................................................... 542 Una sencilla etiqueta ................................................................................................................................. 542 Anatomia de una extensidn de etiquetas ................................................................................................ 546 Manejadores de etiqueta ....................................................................................................................... 547 La interfaz javax.se~let.jsp.tagext.Tag.............................................................................................. 547 ......................................................................550 La interfaz javax.se~let.js~.ta~ext.IterationTag La interfaz javax.se~let.jsp.tagextBodyTag.........................................................................550 La clase javax.servlet.jsp.tagextBodyContent .............................................................................. 552 Clases de conveniencia .................................................................................................................. 553 554 Objetos de disposici6n de 10s manejadores de etiqueta .............................................................. Revisi6n del sencillo ejemplo ........................................................................................................ 555 Descriptores de biblioteca de etiqueta ................................................................................................ 556 Utilizar extensiones de etiqueta en piginas JSP ................................................................................ 558 Despliegue y empaquetado de bibliotecas de etiquetas ....................................................................... 559 Asociaciones en Web.xm1 ............................................................................................................. 560 561 Paquete JAR de biblioteca de etiquetas ......................................................................................... Asociaci6n por defect0 .................................................................................................................. 561 Combinaciones de asociaci6n ....................................................................................................... 561 Escribir extensiones de etiqueta ............................................................................................................. 561 Atributos de procesamiento ................................................................................................................ 561 Contenido de cuerpo ........................................................................................................................... 565 Variables de directivas introducidas por etiquetas ............................................................................. 567 Cambios en el manejador de etiqueta ........................................................................................... 568 Ejemplo de variables de directiva .................................................................................................. 568 Definici6n programitica de variables de directiva ....................................................................... 571 573 Iteraci6n y manipulaci6n de contenido de cuerpo ............................................................................ 573 Evahaci6n repetida con la interfaz IterationTag ........................................................................ Etiquetas de cuerpo que filtran su contenido ............................................................................... 576 Anidamiento de etiqueta ...................................................................................................................... 578 Validar el uso de extensiones de etiqueta en piginas JSP .................................................................. 583 Manejo de errores ................................................................................................................................ 584 TryCatchFinally: ?un peligro para el disefio? .............................................................................. 590
................................................................................................... Locuciones de extensiones de etiqueta ................................................................................................... Resumen ..................................................................................................................................................... Eventos de ciclo de vida de aplicacidn
590 595 597
.
Capitulo 12 Escribir aplicaciones JSP con bibliotecas de etiquetas
599
............................................................... Ejemplos de bibliotecas de etiquetas existentes ..................................................................................... Introducci6n de la Biblioteca de Etiquetas Estindar JSP (JSPTL) .................................................... Ventajas de utilizar bibliotecas de etiquetas personalizadas
600 601
602 602 Obtener JSPTL ....................................................................................................................................
Iniciarse en JSPTL
Integrar JSPTL en sus piginas JSP 604 U n ejemplo de iteraci6n ...................................................................................................................... 604 Ejecuci6n .............................................................................................................................................. 605 Etiquetas JSPTL .........................................................................................................................................
608
Algunas consideraciones de disefio de JSPTL ...................................................................................... 609 Algunas etiquetas bisicas ..................................................................................................................... 609 Etiquetas de flujo de control ............................................................................................................... 610 Etiquetas de iteraci6n ....................................................................................................................612 Estado de iteraci6n ........................................................................................................................ 618 Capacidad de ampliaci6n de la etiqueta de iteraci6n ................................................................618 Etiquetas condicionales ....................................................................................................................... 619
Una aplicac~onde registro y autentificacion 622 La pigina de bienvenida ..................................................................................................................623 El servlet controlador de registro ................................................................................................624 La pigina de formulario de registro ..............................................................................................628 Etiquetas para el rnanejo de formularios HTML ..................................................................632 Gracias por registrarse ........................................................................................................................ 636 Internacionalizaci6n de nuestro c6digo JSP ............................................................................... 637 i Q u e es un lote de recursos? .....................................................................................................637 C6mo se localizan 10s lotes de recursos ........................................................................................ 638 Aplicar lotes de recursos a aplicaciones JSP ..............................................................................639 La pigina de error de registro ............................................................................................................. 643 La pigina de formulario de entrada ................................................................................................644 Ver su perfil de usuario ......................................................................................................................645 Algunas ideas fundamentales sobre etiquetas en JSP ................................................................ 648 Pigina de error de entrada ...............................................................................................................651 Ver el sitio Web favorito del usuario .................................................................................................652 Server-Side Includes (SSI) .............................................................................................................652 Algunos temas relacionados con Server-Side Includes ..............................................................653 Una etiqueta Server-Side Include .................................................................................................. 654 Administraci6n: la pigina Mostrar-todos-10s-usuarios .............................................................657 Administraci6n: un servicio Web de base XML ................................................................................659
................................................................................................................. API de JavaMail ......................................................................................................................................... iRipido. enviarne u n e-mail!
674
675 javax.mail.Session ................................................................................................................................ 675 javax.mail.Authenticator ..................................................................................................................... 677 javax.mail.Message ............................................................................................................................... 678 javax.mai1.internet.MimeMessage................................................................................................. 679 De ..................................................................................................................................................... 680 Para, C C y C C O ............................................................................................................................. 680 Responder a ..................................................................................................................................... 681 Asunto ............................................................................................................................................. 681 Fecha ................................................................................................................................................ 682 I D del mensaje ................................................................................................................................. 682 Otros ............................................................................................................................................... 682 javax.mail.Part ................................................................................................................................ 682 Sistema de activation de JavaBeans ................................................................................................ 683 javax.mail.Mu1tipart ......................................................................................................................... 685 javax.mail.BodyPart ......................................................................................................................... 686 Contenido del mensaje .................................................................................................................... 686 Indicadores de mensaje .................................................................................................................. 688 javax.mail.Address .........................................................................................................................689 javax.mail.internet.InternetAddress.............................................................................................690 javax.mai1.internet.NewsAddress ................................................................................................. 691 javax.mail.Store .................................................................................................................................... 691 Acceso a las carpetas ......................................................................................................................692 javax.mail.URLName ..................................................................................................................... 694 javax.mail.Folder .................................................................................................................................. 695 Abrir y cerrar carpetas ................................................................................................................... 695 Mensajes de listado ........................................................................................................................ 696 Recuperacion avanzada de mensajes ............................................................................................... 697 Copiar y mover mensajes ........................................................................................................698 Buscar mensajes ............................................................................................................................. 699 Javax.mail.Transport ........................................................................................................................... 700
i Q u 6 son 10s EJB? 720 Enterprise JavaBeans versus JavaBeans ........................................................................................ 721 Variedades de beans ........................................................................................................................722 iPor quO utilizar EJB? .........................................................................................................................723
El contenedor EJB y sus servicios .......................................................................................................... 724 725 Persistencia ..................................................................................................................................... 726 Transacciones declarativas ............................................................................................................ 726 Seguridad declarativa ...................................................................................................................... 726 Manejo de errores .......................................................................................................................... 726 Sistema de componentes para 16gica de empresa ......................................................................... 727 Reajustabilidad ................................................................................................................................ 727 Portabilidad ..................................................................................................................................... :..............................................................727 Gestionabilidad ................................................................ 727 C 6 m o proporciona servicios el contenedor ..................................................................................... 728 Contratos ....................................................................................................................................... 729 Servicios .......................................................................................................................................... 730 Interposici6n .................................................................................................................................. Trabajar con EJB ........................................................................................................................................ 731 732 La vista del desarrollador cliente ......................................................................................................... 734 La vista del proveedor de bean ............................................................................................................ 745 iQuC n o puede hacer un EJB? ............................................................................................................ 746 API responsable de 10s hilos ........................................................................................................ AWT ............................................................................................................................................... 747 747 Funcionar como un servidor de red ............................................................................................. Escribir en campos estlticos ......................................................................................................... 747 El paquete java.io ............................................................................................................................ 747 747 Cargar una biblioteca nativa .......................................................................................................... Utilizar "this" como argument0 o valor de retorno ...........................................................748 748 Retrollamadas ................................................................................................................................. Componentes EJB e n la Web ................................................................................................................... 748 Acceso de nivel cliente a EJB ................................................................................................................... 751 Diserio del nivel EJB ................................................................................................................................ 752 752 Ejemplos de uso de UML .................................................................................................................... 753 Objetos de anilisis ......................................................................................................................... 753 Objetos interfaz .............................................................................................................................. 753 Objetos control ............................................................................................................................... Objetos entidad ............................................................................................................................... 753 754 Anilisis versus implementaci6n ......................................................................................................... La funci6n de estado en el objeto interfaz ................................................................................... 756 U n ejemplo de disefio EJB .................................................................................................................. 757 Crear un product0 ......................................................................................................................... 759 759 Realizar un pedido .......................................................................................................................... 759 Cancelar un pedido ........................................................................................................................ 759 Seleccionar un pedido para su manufactura ................................................................................. 759 Elaborar un product0 .................................................................................................................... Enviar un pedido ............................................................................................................................ 759 760 Registrar pedidos atrasados ...........................................................................................................
.
.
fcapitulo 15 Beans de sesion y logica de empresa
..
769
Beans de seslon y estado ........................................................................................................................... 770
Representaci6n de 16gica de empresa .................................................................................................. 770 771 Beans de sesi6n como fachada ...................................................................................................... 773 El problema del estado conversacional .............................................................................................. Beans de sesion y almacenamiento persistente ................................................................................. 775 Bean calculadora de asistencia financiera ...............................................................................................776 Bean calculadora de necesidad financiera sin estado ......................................................................... 777 La interfaz rernota de calculadora de necesidad financiera .......................................................... 777 El cliente de necesidad financiera .................................................................................................. 777 La interfaz inicial calculadora de necesidad financiera ................................................................. 779 La clase de implementation de la calculadora de necesidad financiera ........................................779 780 public void ejbCreate0 .................................................................................................................... 781 public void ejbActivate0 ................................................................................................................. public void ejbPassivate() ................................................................................................................ 781 public void ejbRemove0 ................................................................................................................. 781 public void setSessionContext(SessionContext ctx) ....................................................................781 783 El descriptor de implementaci6n .................................................................................................. 784 Bean calculadores de necesidad financiera con estado ...................................................................... 784 La interfaz remota de necesidad financiera con estado .............................................................. La interfaz inicial calculadora de necesidad financiera con estado .............................................785 La clase de implementation de la siguiente calculadora financiera con estado ..........................785 El cliente para la calculadora de la necesidad financiera con estado ...........................................789 Descriptores de implementaci6n .................................................................................................. 789 792 Combinar beans con estado y sin estado .......................................................................................... Las nuevas interfaces y cliente de la calculadora de necesidad con estado .................................792 La nueva clase de implementaci6n de la calculadora de necesidad con estado ...........................792 795 Los descriptores de implementaci6n ............................................................................................
796 Irnplementacion de nuestra aplicaci6n de fabricacion 798 Clientes e interfaces de logica de empresa .......................................................................................... El EJB Manageorders .................................................................................................................. 799 802 El EJB de fabricaci6n ..................................................................................................................... 803 Los clientes de aplicaci6n ............................................................................................................... El cliente BeginManufacture ........................................................................................................... 805 El cliente CompleteManufactured .................................................................................................. 806 El cliente PlaceSampleOrders ......................................................................................................... 808 809 El cliente ManagerSampleOrders ................................................................................................... 810 El cliente CreateProducts ................................................................................................................ Implementacidn del bean de sesi6n sin estado .................................................................................. 811 811 Mktodos de empresa ...................................................................................................................... 818 MCtodos de ayuda de irnplementaci6n .......................................................................................... MCtodos de ciclo de vida y de sistema .......................................................................................... 820 820 Irnplementaci6n del bean de sesi6n con estado ................................................................................. Resumen L Capitulo
i P o r quC n o utilizar beans de sesion? 830 830 Utilizar un bean de sesi6n con estado ................................................................................................ 833 Utilizar un bean de sesi6n sin estado ................................................................................................. Ventajas de 10s beans de entidad ......................................................................................................... 834
..........................
Persistencia gestionada por contenedorversus persistencia gestionada p o r bean 835 Nuevas funciones para C M P introducidas en EJB 2.0 ..................................................................... 837 Accesores abstractos ..................................................................................................................... 838 Interfaces locales ............................................................................................................................ 839 Relaciones ....................................................................................................................................... 840 Lenguaje de consulta EJB .............................................................................................................. 840 La cllusula SELECT ........................................................................................................................ 841 La clausula FROM .......................................................................................................................... 841 La cliusula WHERE ........................................................................................................................ 842 laboratorio SportBean .................................................................................................................... 843 . . Claves primarlas ............................................................................................................................. 843 Las retrollamadas C.R.U.D. ................................................................................................................ 846 Crear ............................................................................................................................................... 846 Los me to do^ create() de Sports Team, interfaz inicial .................................................................. 846 La clase de implementaci6n de Sports Team CMP ........................................................................ 848 La clase de implementaci6n BMP de SportsTeam .......................................................................... 849 Leer .................................................................................................................................................. 851 Crear la tabla .................................................................................................................................... 851 Beans de entidad CMP y ejbLoad() ................................................................................................ 851 Beans de entidad BMP y ejbLoad() ................................................................................................ 852 Actualizar ........................................................................................................................................ 853 C M P y el metodo ejbStore() .......................................................................................................... 853 BMP y el metodo ejbStore() ........................................................................................................... 854 Eliminar .......................................................................................................................................... 854 C M P y el ~ n e t o d oremove() ........................................................................................................... 854 BMP y el d t o d o remove() ............................................................................................................ 855 Retrollamadas BMP versus retrollamadas C M P .....................................................................855 El descriptor de implementaci6n ........................................................................................................ 856 Persistencia en 10s descriptores de implementaci61-1................................................................857 Almacenamiento en memoria cache ................................................................................................... 858 Mitodos buscadores ............................................................................................................................ 861 Implementaci6n de metodos buscadores ..................................................................................... 861 C M P y metodos buscadores ........................................................................................................... 862 BMP y metodos buscador ............................................................................................................... 863 Activaci6n y pasivaci6n ....................................................................................................................... 864 El ciclo de vida completo ..................................................................................................................... 865 Reentrada .............................................................................................................................................. 866 Completar el ejemplo del equipo de deporte ...................................................................................... 867 El cliente C M P ................................................................................................................................. 868 El cliente BMP ................................................................................................................................. 869 Configurar WebLogic 6.1 para nuestros EJB .............................................................................872
Completar nuestra aplicaci6n de fabricaci6n 875 El bean Pedido ......................................................................................................................................876 La interfaz inicial del bean Pedido ................................................................................................876 La interfaz remota del bean Pedido ..........................................................................................877 La clase de implementaci6n del bean Pedido ...............................................................................877
La clase de clave primaria del bean Pedido ...................................................................................... 880 La excepci6n OrderNotCancelableException ............................................................................... 881 El bean Producto .................................................................................................................................. 881 La interfaz inicial del bean Producto .............................................................................................. 882 La interfaz inicial local del bean Producto ...................................................................................... 882 La interfaz remota del bean Producto ............................................................................................ 883 La clase de implementaci6n del bean Producto .............................................................................. 883 La clase de excepcidn NoSuchRoutingInstruction ................................................................... 885 El descriptor de despliegue completo ................................................................................................. 885 Ejecutar la aplicacidn de fabrication ................................................................................................... 892 Resumen
Seguridad 917 Especificar 10s requisitos de seguridad ............................................................................................... 919 Roles de seguridad .......................................................................................................................... 919 Permisos de mitodo ...................................................................................................................... 921 Control programado de acceso .......................................................................................................... 922 Seguridad y disefio de aplicaci6n ......................................................................................................... 924
Excepciones 925 Excepciones de aplicaci6n .................................................................................................................... 926 Excepciones de aplicaci6n predefinidas ........................................................................................ 929 Excepciones de sistema ........................................................................................................................ 929
Comunicac~on 932 Comunicaci6n entre servidores heterogheos ............................................................................932 Llamadas de mitodo en VM ................................................................................................................ 934 Resumen
El ensamblador de la aplicacibn .............................................................................................................. 952
..................................................................................................................................... 963 El administrador del sistema .................................................................................................................. 973 Vendedor de contenedor/servidor de aplicacibn ................................................................................. 974 Una interfaz Web para la aplicaci6n de fabricacibn .............................................................................. 975 Consejos para resolver problemas ..........................................................................................................999 Resumen ................................................................................................................................................... 1000 El implementador
.
Capitulo 19 JMS y beans controlados nor mensaje
................................................................................................................. Servicio de Mensajes Java (JMS) ...........................................................................................................
Breve historia del mensaje
1004
1005 Punto-a-punto .................................................................................................................................... 1006 1007 Publicar/suscribir ............................................................................................................................... La arquitectura JMS ........................................................................................................................... 1008 Ejernplo de cola punto-a-punto ........................................................................................................ 1010 Producir un rnensaje .................................................................................................................... 1010 Consumir un rnensaje sincr6nicarnente .................................................................................... 1013 1015 Consurnir un rnensaje asincr6nicarnente ................................................................................... Ejernplo de apartado publicar/suscribir ............................................................................................ 1018
El API JMS .............................................................................................................................................. 1025 Utilizar transacciones con JMS ....................................................................................................... 1028 Tres irnplernentaciones JMS de peso industrial ............................................................................... 1029 SwiftMQ ....................................................................................................................................... 1029 1030 SpiritWave .................................................................................................................................... SonicMQ ...................................................................................................................................... 1030 Beans controlados por mensaje ............................................................................................................ 1031 Ciclo de vida del bean controlado por rnensaje ............................................................................... 1032 Transacciones en beans controlados por rnensaje ..........................................................................1032 Transacciones gestionadas por bean .......................................................................................... 1033 Transacciones gestionadas por contenedor .............................................................................. 1033 1033 U n ejernplo de bean controlado por rnensaje .................................................................................. Irnplernentaci6n del bean controlado por rnensaje ......................................................................... 1034 Resumen ...................................................................................................................................................
1041
.
Capitulo 20 La arquitectura de conectores J2EE
....................................................................................................... La Arquitectura de Conectores JZEE y sus elementos .......................................................................
Integraci6n de EIS y el rol de JCA
1046
1048 Cornparaci6n de JCA con JDBC ............................................................................................... 1049 El adaptador de recursos y sus contratos ........................................................................................ 1050
Contratos de aplicaci6n ............................................................................................................... 1050 Contratos de nivel de sistema ..................................................................................................... 1051 1051 Gesti6n de conexiones .................................................................................................................. Gestion de transacciones .............................................................................................................. 1051 1052 Gesti6n de seguridad ..................................................................................................................... Acceso a EIS ................................................................................................................................ 1052 Empaquetado e implementacion de un adaptador de recursos ....................................................... 1053 Empaquetar un adaptador de recursos ..................................................................................1054 El descriptor de implementaci6n del adaptador de recursos (ra.xm1) .....................................1055 1058 Roles y responsabilidades de la implementacidn ....................................................................... Proveedor del adaptador de recursos ........................................................................................... 1058 1058 Vendedor del senidor de aplicacidn ............................................................................................. Proveedor del componente de aplicaci6n ..................................................................................... 1058 1059 Implementador .............................................................................................................................. 1059 Opciones de implementaci6n ..................................................................................................... Implementar un adaptador de recursos como una aplicacidn JZEE ........................................1059
1060 Adaptadores de recursos de caja negra Utilizar un adaptador de caja negra . El ejemplo Democonnector ...............................................1060 ....., Seleccionar un adaptador de caja negra ...................................................................................... 1060 "-1 Transacciones XA y no-XA que utilizan un adaptador de caja negra .........................................1061 Implementation del adaptador de recursos de caja negra .........................................................1061 1061 Configurar la base de datos y la tabla Demoaccount ................................................................... Implementaci6n del adaptador de recursos .................................................................................. 1062 Poner a prueba el adaptador de recursos de caja negra ............................................................. 1067 1067 La interfaz inicial ........................................................................................................................... 1068 La interfaz remora ......................................................................................................................... La clase de implementaci6n del bean ............................................................................................. 1068 La clase ProcessingExceptions ..................................................................................................... 1073 El descriptor de implementacidn EJB .......................................................................................... 1073 1073 Implernentacion del bean .............................................................................................................. 1074 El cliente ......................................................................................................................................... La Interfaz C o m h de Cliente (CCI) .............................................................................................. 1076 Interfaces y clases C C I ................................................................................................................ 1076 1079 Conexi6n con una aplicaci6n gestionada (J2EE) ..................................................................... Conexi6n a una aplicacion no gestionada (de dos niveles) ...................................................... 1080 1082 Utilizar una C C I con adaptador de caja negra ................................................................................ 1082 Implementaci6n de un bean de sesi6n con C C I ....................................................................... 1083 La interfaz inicial ........................................................................................................................... La interfaz remora ......................................................................................................................... 1083 1083 La clase de implementaci6n del bean ............................................................................................. 1086 El descriptor de implementaci6n EJB .......................................................................................... 1087 El cliente ......................................................................................................................................... Implementacibn del adaptador de recursos de caja negra de C C I ...........................................1087 Configurar la base de datos ........................................................................................................... 1088 1089 Implementaci6n del adaptador ...................................................................................................... 1091 Irnplementacion y prueba de la aplicaci6n C C I .........................................................................
Ventajas de la arquitectura de conectores J2EE 1092 1092 Integracidn de aplicacidn de empresa (EAI) con JCA ................................................................... 1092 Portales de empresa capacitados con J C A .......................................................................................
lndice Integration empresa-a-empresa con JCA ........................................................................................ 1093
...........................................................................................................1093 Resumen ................................................................................................................................................... 1094 Elementos que faltan en J C A 1.0
'
.
Capitulo 2 1 Consideraciones de diseiio para aplicaciones J2EE
1097
...................................................................................................................1098 Arquitectura y disefio .......................................................................................................................... 1099 El m u n d o sigue cambiando
1099 Estilos de arquitectura ....................................................................................................................... Contexto de disefio ........................................................................................................................... 1101 1102 Los requisitos de empresa ................................................................................................................. 1102 El sistema existente .................................................................................................................... El sistema deseado ....................................................................................................................... 1103 1104 El context0 de empresa .....................................................................................................................
1109 Elegir y perfeccionar una arquitectura Arquitectura para el sistema de pedidos de compra ......................................................................... 1109 1110 Iteraci6n y retroalimentacion ...........................................................................................................
1111 Aplicar patrones 1111 i Q u e son 10s patrones? ..................................................................................................................... 1112 Patrones J2EE .................................................................................................................................... Patron de controlador frontal .................................................................................................... 1114 1115 Patr6n de vista de composici6n .................................................................................................. Patron de fachada de sesion ........................................................................................................ 1117 Patron de localizador de semicios ........................................................................................1118 Patron de Objeto valor ............................................................................................................... 1119 Patron de Delegado de empresa ............................................................................................1121 1122 Patron de Objeto de acceso a datos ............................................................................................ Patron de Ayudante de vista ........................................................................................................ 1123 1124 Patr6n de Vista de lanzador ........................................................................................................ Patr6n de Semicio a1 trabajador .................................................................................................. 1125 Patron de Manejador de lista de valores (Iterador pigina-a-pbgina) .......................................1125 Patr6n de Lector de via ripida ............................................................................................. 1127
1128 Comenzar por el principio 1128 Presentaci6n de datos del producto a1 usuario ................................................................................ Abstraer el acceso a datos .................................................................................................................. 1129 Distinguir entre funcionalidad y presentacion .............................................................................1130 Separar interaction de usuario, presentaci6n y datos ..................................................................1131 1133 Evoluci6n del sistema ........................................................................................................................
Indice
.................................................................................................. De compras ..............................................................................................................................................
Afiadir el nivel medio (Middle-Tier)
1135
1137 Encapsular el flujo de trabajo de pedidos .....................................................................................1138 Modelos con estado versus modelos sin estado .......................................................................1139 Presentar el pedido ......................................................................................................................1141 Elegir un mecanismo asincrono ................................................................................................. 1141 Reajustabilidad disponibilidad a travks de la asincronicidad ...................................................1143 Cuestiones relacionadas con sistemas asincronos ...............................................................1143 Aprobar el pedido .............................................................................................................................. 1144
Mas all5 de sistema de pedidos de compra .......................................................................................... 1146 Disefio de interfaz EJB ..................................................................................................................... 1146 . . . Eventos d ~ s t r ~ b u ~ .......................................................................................................................... dos 1148 Disefio para bases de datos ................................................................................................................ 1148 Lecciones aprendidas .............................................................................................................................. 1149 Separar intereses siempre que sea posible ........................................................................................ 1149 Minimizar el trdfico de la red ............................................................................................................ 1149 Utilizar abstracci6n para contribuir a la flexibilidad ...................................................................1150 Usar patrones comunes .................................................................................................................... 1150 Reducir el acoplamiento de mecanismos asincronos ......................................................................1151 Transacciones de plan ........................................................................................................................ 1151 Resumen ...................................................................................................................................................
.
Capitulo 22 J2EE y servicios Web
1151
1153
i Q u i son 10s servicios Web? ................................................................................................................. 1154 Servicios inteligentes ......................................................................................................................... 1155 Tecnologias de servicios Web ................................................................................................................
El elemento message ..................................................................................................................... 1160 El elemento portType .................................................................................................................... 1160 El elemento binding ...................................................................................................................... 1160 El elemento port ............................................................................................................................ 1161 El elemento service ....................................................................................................................... 1161 U D D I ................................................................................................................................................. 1162 Implementation ........................................................................................................................... 1162 Tecnologias J2EE para servicios Web ................................................................................................... 1163 JAXP ................................................................................................................................................... 1164 JAXB ................................................................................................................................................... 1164 Esquema X M L ..............................................................................................................................1164 Asociaci6n de datos X M L ...........................................................................................................1165
JAXM .................................................................................................................................................. 1 166 TAX-RPC ............................................................................................................................................ 1168 JAXR ................................................................................................................................................... 1169 Arquitectura .................................................................................................................................. 1169 Objetivos de disefio ..................................................................................................................... 1170 Desarrollo de servicios Web .................................................................................................................. 1170 Arquitectura de servicio Web ............................................................................................................ 1171 Localizar servicios Web ............................................................................................................... 1171 La interfaz del servicio Web ........................................................................................................ 1172 Implementar la 16gica de empresa ............................................................................................... 1172 Integrar otros recursos ............................................................................................................... 1172 Devolver resultados a clientes .................................................................................................... 1172 U n sencillo servicio Web .................................................................................................................. 1173 Desarrollar el archivo Java StockQuote .................................................................................... 1173 Crear el JAR ................................................................................................................................. 1174 Generar archivos WSDL ............................................................................................................ 1174 El archivo StockQuote-Service.wsd1 ......................................................................................... 1177 El archivo StockQuote-Service-interface.wsd1 ......................................................................... 1177 Generar la clase proxy ................................................................................................................. 1179 Registrar el servicio en el servidor Web .................................................................................... 1179 Desarrollar un cliente .................................................................................................................. 1182 Crear servicios mas inteligentes .......................................................................................................... 1183 Contexto compartido ........................................................................................................................ 1183 Servicios Web inteligentes ................................................................................................................. 1184 La iniciativa Sun O N E ....................................................................................................................... 1184 Anilisis de la arquitectura funcional ........................................................................................... 1185 Arquitectura de servicios Web inteligentes ...................................................................................... 1186 Provisibn inteligente ................................................................................................................... 1187 Gesti6n inteligente ...................................................................................................................... 1187 Proceso inteligente ...................................................................................................................... 1187 Politica inteligente ........................................................................................................................ 1187 Apoyo del vendedor a servicios Web ................................................................................................... 1187 Servicios Web sencillos ............................................................................................................... 1187 Servicios Web complejos ............................................................................................................. 1188 Resumen
........................................................................................................................ Implementaci6n de las especificaciones J2EE ..................................................................................... Competencia en el mercado de servidores de aplicaci6n ................................................................
Servidores de aplicaci6n
1191 1194
1196 Implementaciones J2EE .................................................................................................................... 1197 Funciones de valor afiadido ............................................................................................................... 1198 Implementation actual de normas futuras ................................................................................. 1200 Posibles caminos potenciales para funciones de valor afiadido ...............................................1201
indice
..................................................................................................................... Resumen ................................................................................................................................................... Comunidad de desarrollo
.
Capitulo 24 Empaquetado e implernentacion J2EE
1205 1206
1209
Andisis del empaquetado J2EE ............................................................................................................ 1210
1234
lndice alfabetico
1237
Soporte Tecnico de Anaya Multimedia
1246
Introduccion Bienvenido a la tercera edici6n de Programacidn para Java Server Profesional. A diferencia del cambio entre la primera y la segunda edici61-1, las diferencias de la versi6n 1.3 de J2EE son relativamente menores. Las diferencias fundamentales radican en que 10s capitulos sobre servlets, JSP y EJB han sido actualizados para reflejar 10s cambios realizados en las especificaciones relevantes, por ejemplo en EJB 2.0. Ademis, se han incluido nuevos capitulo para las nuevas caracteristicas de J2EE tales como la Arquitectura de Conectores y algunos capitulos menos relevantes para el desarrollo bisico de J2EE han sido eliminados.
La Gltima entrega de JRS-58, mis conocida como Plataforma Java 2, Enterprise Edition UZEE), representa la evoluci6n de la plataforma de desarrollo del lado del servidor de Sun Microsystems hacia una especificaci6n mis madura y sofisticada. Ademis de la inclusi6n de nuevas sub-especificaciones como JAAS (Java Authentication and Authorization Service) y la Arquitectura de Conectores, la verdadera naturaleza centrada en el contenedor de la especificaci6n de J2EE no ha sufrido cambios significativos. Los cambios mis notables de esta entrega estin relacionados con las modificaciones realizadas a las subespecificaciones, en especial a Servlet, JavaServer Pages (JSP) y Enterprise JavaBeans (EJB). Los servlets obtienen eventos y filtrado; JSP obtiene una nueva sintaxis XML y mejoras en 10s mecanismos de ajuste de designador; y EJB cuenta con algunos cambios significativos en su modelo de persistencia gestionado por su contenedor. Las versiones actuales de API en J2EE 1.3 se encuentran en:
O Servlets 2.3
lntroduccion 0 JavaServer Pages 1.2 0
Enterprise JavaBeans 2.0
O JDBC 2.0 Extension
O Java Message Service 1.0 0 Java Transaction API 1.0 O JavaMail 1.2 0 Java Activation Framework 1.0 0 Java API para XML Processing 1.1
O Java Conector Architecture 1.0 O Java Authentication and Authorization Service 1.0
A lo largo de este libro examinaremos todas estas versiones.
iQue ha cambiado en esta edicion del libro? Observara que una parte del material de esta edici6n J2EE 1.3 es muy similar a1 contenido de su predecesora, la edici6n JZEE. Esto se debe a que antes de remendar notablemente el material esencialmente bueno y s6lido del libro, hemos decidido simplemente actualizar material relevante para seguir siendo consecuentes con las dltimas e~~ecificaciones identificadas por J2EE. En algunos casos, esto ha supuesto la inclusi6n de un capitulo adicional, per0 en otros s610 encontrari pequefios cambios. C o n todo ello, hay algunas diferencias significativas en lo que se refiere a capitulos entre esta edicion y la anterior. La edici6n J2EE 1.3 contiene capitulos sobre Arquitectura de Conectores Java, Servicios Web, c6mo elegir una implementacidn J2EE y Paquete de aplicaciones J2EE. Lo que ha sido eliminado son 10s capitulos mis ajenos que no eran esenciales para el aprendizaje sobre el desarrollo de aplicaciones J2EE, tales como la Internacionalizaci6n.
&A quien va dirigido este libro? Este libro esti destinado a programadores profesionales de Java que, aunque no tengan mucha experiencia prictica, estin como minimo familiarizados con 10s conceptos fundamentales de programaci6n Web y de redes. Tambiin presupone estar familiarizado con el lenguaje Java y 10s API, a travis de la lectura de Beginning Java 2, o de algdn otro libro prictico que abarque un Area similar. Sin embargo, todos 10s conceptos relacionados con la programacion Java de lado servidor serin abordados sin presuponer conocimientos previos. N o obstante, se recomienda cierta familiaridad con las tecnologias bisicas Java de lado servidor, ya que este libro abarca una amplia area de conocimientos ripidamente y no pretende ser exhaustivo en todos 10s campos.
Ademis, 10s que ya posean la edicibn JZEE anterior del libro puede que encuentren que esta edicibn no les aporta muchos conocimientos ya que gran parte del material esencial es muy similar a la edici6n anterior.
lntroduccion
iCuales son 10s contenidos de este libro? En este libro, examinamos tres temas principales: 0 Las normas de las especificaciones de tecnologia que deben seguir 10s creadores de programas para crear componentes de ernpresa. 0
Los limites y beneficios de las implementaciones tipicas reales de las compafiias distribuidoras de las especificaciones J2EE.
0 Los aspectos practicos resultantes de 10s disefios reales que utilizan las tecnologias J2EE.
El libro tiene la siguiente estructura basica: 0 Comenzaremos revisando las dtimas demandas planteadas a un agente de desarrollo de ernpresa de Java y analizando c6mo Java (y en particular J2EE) avanza para alcanzar estos retos. TambiCn tendri su primer contact0 con la arquitectura de contenedor J2EE.
DespuCs de que nos hayamos introducido a toda velocidad en la arquitectura J2EE, comenzaremos a analizar algunas de las tecnologias fundamentales en el desarrollo de una empresa: RMI, JDBC y JNDI. 0 Mis tarde, volveremos a J2EE de un modo mis explicito considerando c6mo desarrollar componentes Web utilizando 10s servlets de Java.
Una vez hayamos comprendido la tecnologia de servlets, estudiaremos c6mo se incorpora a JavaServer Pages y se amplia para proporcionar un medio mas flexible para crear contenido Web dinimico. 0
Finalmente, analizaremos algunas temas extensos de J2EE tales como consideraciones de disefio y c6mo crear paquetes con sus aplicaciones J2EE.
Lo necesario para utilizar este libro La mayor parte del codigo de este libro ha sido probado con la Plataforma Java 2, Standard Edition SDK (JDK 1.3) y la Plataforma Java 2, Enterprise Edition SDK 1.3 Implementaci6n de Referencia. Sin embargo, para algunos capitulos, bien la implementaci6n de referencia no es suficiente o necesita software adicional:
Contenedor Web Para ejecutar 10s componentes Web utilizados en este libro, necesitari un contenedor Web que soporte las especificaciones Servlet 2.3 y JSP 1.2. Nosotros utilizamos la Implementaci6n de Referencia, que utiliza el motor Jakarta Tomcat bajo la cobertura. Puede que necesite la ~iltimaversi6n de Tomcat (disponible en http:/ /jakarta.apache.org/tomcat) para poder ejecutar algunas 10s ejemplos de las librerias de designador JSP.
Contenedor EJB Para 10s capitulos EJB, tambikn necesitari un contenedor EJB que mantenga la versi6n 2.0 de la especificaci6n EJB. Nosotros utilizamos WebLogic Server 6.1 de BEA (http://www.bea.com).
Bases de datos Varios capitulos requieren tambikn acceso a una base de datos. Para estos capitulos, nosotros utilizamos: Cloudscape (una versi6n interna viene con el RI de J2EE), http://cloudscape.com/
Introduccion
Software adicional Finalrnente, un par de capitulos tarnbitn requieren algunas piezas de software adicional: O J N D I SDK de Sun, que esti incluido en JDK 1.3 O Java Secure Sockets Extensi6n USSE) 1.0.1, http://java.sun.com/products/jsse/ O Servidor LDPA (iPlanet Directory Server version 4.11 de Netscape), http://w.iplanet.com/ O Servicio SMTP y/o POP3 O JSP Standar Tag Library, http://jakarta.apache.orgltaglibs
U Web Services Toolkit de IBM, http://w.alphaworks.ibm.com/tech/webservicestoolkit
El cbdigo del libro funcionari en un ordenador sencillo, siernpre que est6 en red (es decir, que pueda ver http://localhost a trav6s del navegador local). El c6digo fuente cornpleto del libro esti disponible para su desacarga en: http://w.wrox.com/ http://w.AnayaMultimedia.es (seccion "atencion a1 cliente", opcion "complementos")
Convenciones Para ayudarle a sacar el mixirno partido a1 texto y seguir el hilo de lo que esti ocurriendo, hernos utilizado un nGrnero de convenciones a lo largo del libro: Por ejernplo:
Estos recuadros contienen inforrnaci6n irnportante que debe recodar y que es relevante con relaci6n a1 texto en el que se introduce. Mientras que el estilo en cursiva se utiliza para comentarios a1 margen del tema que esta' siendo tratado. En cuanto a 10s estilos en el texto: O A1 introducirlas,
destacarnos en negrita las palabras irnportantes.
O Mostrarnos las cornbinaciones de teclado asi:
Control-A
O Mostrarnos 10s nornbres de 10s archivos y c6digos en el texto asi: d o G e t ( ) O
El texto sobre interfaces de usuario y URL se rnuestran corno: Menu
Presentarnos el cbdigo de tres forrnas diferentes. Las definiciones de rnttodos y propiedades se rnuestran del siguiente rnodo: protected void doGet(HttpServ1etRequest req, HttpServletResponse resp) throws ServletException, IOException
Ejernplo de un c6digo: Eri
r , u e s t r o s ejernplos rnuestra e l c 6 d i g o
de cbdigos, e l . e s t i l o de primer nuevrj, i r n p o r t a n t e y p e r t i n e n t e
p l a r ~ ode
c6digo
lntroduccion M i e r ~ t r a s q u e e l f o n d o d e c b d i g o m u e s t r a e l c 6 d i g o menos i m p o r t a n t e c o n t e x t o o i n d i c a q u e ;/a ha s i d o m o s t r a d o c o n a n t e r i o r i d a d .
en
su
Atencion al cliente Siempre valoramos recibir noticias de nuestros lectores y queremos saber quk piensa sobre este libro: lo que le ha gustado, lo que no le ha gustado y lo que considera que podemos mejorar en la pr6xima edici6n. Puede enviarnos sus comentarios, bien rnediante la tarjeta de respuesta incluida a1 final del libro o por email a £ e e d b a c k e w r o x . corn o a-rnultirnediaeanaya. e s . Asegirese de que inchyeel titulo del libro en su mensaje.
Como cargar el codigo de muestra para el libro Cuando visite la pigina de Wrox, http://wrox.com/,simplemente localice el titulo en nuestra seccicin s e a r c h o utilice uno de 10s titulos de la h a . Haga clic en Download en la columna Code o en Download Code en la pigina de detalles del libro. Tambikn podri descargar el codigo en la pigina de Anaya Multimedia, http:// www.AnayaMultirnedia.es (seccion "atencMn a1 cliente", opcion "complementos") Los archivos disponibles para su descarga en nuestra pigina han sido archivados utilizando el programa WinZip. Cuando haya guardado 10s archivos adjuntos en una carpeta de su disco duro, necesitari extraer 10s archivos utilizando un programa de descompresi6n como WinZip o PKUnzip. Cuando extraiga 10s archivos, el c6digo se extraeri normalmente en carpetas de capitulos. Cuando inicie el proceso de extracci61-1,asegjrese de que su programa (WinZip, PKUnzip, etc.) esti configurado para utilizar 10s nombres de las carpetas.
Erratas Nos hemos esforzado al miximo para que no haya errores en el texto o en el c6digo. Sin embargo, nadie es perfecto y puede haber errores. Si encuentra a l g h error en alguno de nuestros libros, como un error de ortografia o un segment0 de ccidigo err6ne0, le agradeceriamos que nos lo hiciera saber. Informindonos de las erratas, ahorrari a otro lector horas de frustracicin y, por supuesto, nos estari ayudando a ofrecer informacidn de mayor calidad. Simplemente, envienos un e-mail con la informaci6n a s u p p o r t @ w r o x.corn o a-mu1 t i m e d i a e a n a y a .e s ; su informaci6n seri comprobada y, si es correcta, seri enviada a la pigina de erratas del libro en cuesti6n o utilizada en siguientes ediciones del libro. , Para encontrar erratas en la pigina Web, vaya a http://www.wrox.corny simplemente localice el titulo en nuestro apartado d e l ~ d v a n c e dS e a r c h o en la h a de titulos. Haga clic en el vinculo Book E r r a t a , que se encuentra bajo la cubierta grifica de lapigina de detalle del libro. Tambikn podri encontrar las erratas en la pigina Web http://www.AnayaMultirnedia.es (seccion "atencidn a1 cliente", opcion "complementeos").
Apoyo via e-mail Si desea plantear directamente un problema del libro a un experto que conozca el libro detalladamente, envie un e-mail a a - a n a y a m u l t i r n e d i a e a n a y a . e s o a s u p p o r t @ w r o x .corn (incluyendo el titulo del libro y 10s cuatro iltimos nimeros del ISBN en inglks en el campo de asunto del e-mail). U n e-mail convencional incluiria 10s siguientes datos: 0 El titulo del libro, 10s cuatro ultimos digitos del ISBN en inglis, un numero de pigina donde se encuentra el problema en el campo A s u n t o .
lntroduccion o Su nombre, 10s datos de contacto y el problema en el cuerpo del rnensaje. N o le enviaremos ningfin correo basura. Necesitarnos 10s detalles para ahorrarle tiernpo a usted y a nosotros. Cuando envie un e-mail, kste pasari por la siguiente cadena de atenci6n: 0
Apoyo el cliente. Su rnensaje es enviado a nuestro personal de atenci6n a1 cliente, que serin 10s prirneros en leerlo. Ellos cuentan con archivos sobre las preguntas mis frecuentes y responderin a cualquier pregunta general sobre el libro o sobre la pigina Web inrnediatarnente.
0
Editorial. Las preguntas de mayor profundidad son enviadas a1 equipo editor tkcnico responsable del libro en cuesti6n. Ellos tienen experiencia con el lenguaje de programaci6n o con el product0 en cuestion y estin capacitados para responder a preguntas tkcnicas sobre el terna.
0
Autores. Finalrnente, en el improbable caso de que el editor no pueda resolver su problema, enviari la pregunta a1 autor. Intentamos proteger a1 autor de cualquier distracci6n en su trabajo; sin embargo, nos satisface poder plantearles problemas especificos. Ellos enviarin un e-mail a1 cliente y a1 editor con su respuesta y una vez rnis todos 10s lectores se beneficiarin.
El proceso de Apoyo de Wrox solo puede ofrecer apoyo sobre ternas que estin directarnente relacionados con nuestros titulos publicados. La respuesta a las preguntas que estin fuera del irnbito normal del apoyo a nuestros libros puede encontrarla en las listas cornunitarias de nuestro for0 en http://p2p.wrox.cotW.
Para participar en debates con el autor y otras personas, registrese en las listas de correo de P2P. Nuestro sisterna dnico proporciona contacto programmer-to-programmer'" en las listas de correo, en 10s foros y en 10s grupos de noticias, todo ello surnado al sisterna individual de apoyo via e-mail. Si envia sus dudas a P2P, puede estar seguro de que serin examinados por rnuchos de 10s autores de Wrox y otros expertos de la industria que estin incluidos en nuestras listas de correo. En p 2 p . w r o x .comencontrari diversas listas diferentes que le ayudarin no s61o en la lectura de este libro, sin0 tambikn a desarrollar sus propias aplicaciones. Para este libro, son especialrnente apropiadas las listas j2ee y projava-server. Para suscribirse a una lista de correo, debe seguir 10s siguientes pasos: 0
Vaya a http://p2p.wrox.cotW
0
Elija la categoria apropiada de la barra de rnenfi situada a la izquierda
m Haga clic en la lista de correo a la que desea suscribirse Siga las instrucciones para suscribirse y rellene 10s carnpos de su direcci6n de e-mail y su contrasefia
m Conteste a1 e-mail de confirrnaci6n que reciba o Utilice el gestor de suscripciones para suscribirse a rnis listas y fije sus preferencia de correo
lPor que este sistema ofrece el mejor apoyo? Puede elegir entre suscribirse a las listas de correo o puede recibirlas sernanalmente. Si no tiene tiernpo, o rnedios, para recibir las listas de correo, puede buscar en nuestros archivos on-line. Los correos basura y rnolestos son borrados autorniticarnente, y su direccion de correo esti protegida por el sisterna finico Lyris. Las preguntas sobre c6rno suscribirse o darse de baja en las listas, y para cualquier otra duda general sobre las listas, envie un rnensaje a l i s t s u p p o r t @ p ~ w p .r o x . corn
.-
Java
+
CORBA
--Server
-1
Plataforma JZEE En la actualidad, Java es uno de 10s lenguajes de programacion mis elaborados y mis utilizados para la creaci6n de software de empresa. La evoluci6n de Java, que ha pasado de ser un medio de desarrollo de applets para ser ejecutados en navegadores a un modelo de programacibn capaz de manejar las aplicaciones de una empresa de hoy en dia, ha sido extraordinaria. Con el paso de 10s afios, Java ha desarrollado tres ediciones de plataformas diferentes, cada una de ellas destinada a cubrir un conjunto diferente de necesidades de programacibn: O
La plataforma Java 2 Standar Edition U2SE): Es la plataforma mis utilizada dentro de Java, consistente en un entorno de tiempo de ejecucibn y un conjunto de varios API para crear una amplia variedad de aplicaciones que abarca desde applets, pasando por aplicaciones independientes ejecutables en distintas plataformas, hasta aplicaciones de cliente para diversas aplicaciones de empresa.
O
La plataforma Java 2, Enterprise Edition (J2EE): J2EE es una plataforma para crear aplicaciones de senidor. Como veri a lo largo de este libro, las aplicaciones de servidor tienen requisitos adicionales durante la fase de desarrollo. J2EE proporciona la infraestructura necesaria para satisfacer estas necesidades.
O
La plataforma Java 2, Micro Edition (J2ME): Esta edicibn, la ultima en agregarse a la familia Java, permite la creaci6n de aplicaciones Java para "micro-dispositivos" (dispositivos con un apoyo de pantalla y memoria limitado, como telkfonos moviles, PDAs, etc.).
Este libro es un recorrido por la plataforma J2EE y, en particular, por la version 1.3 de la especificacion. Ya que J2EE 1.3 requiere J2SE, tambikn examinaremos algunas de las caracteristicas de J2SE cuando asi se requiera. En este libro, comenzaremos presentando las necesidades de programacibn para el desarrollo de aplicaciones de empresa, las diversas tecnologias disponibles para la creacibn de tales aplicaciones y el
Capitulo 1 mod0 de crear tales aplicaciones utilizando esas tecnologias. A medida que vayamos avanzando capitulo a capitulo, nos encontraremos con una amplia variedad de tecnologias, algunas de ellas de mayor complejidad y cada una de ellas abarcando un grupo especifico de necesidades tkcnicas. Este libro le presentari pricticamente toda la gama de tecnologias J2EE. A pesar de la complejidad de algunas de estas ireas, este libro pretende presentar cada uno de 10s temas desde 10s principios rnis bisicos. De este modo, el lector puede estudiar estos temas en el orden que prefiera.
Programacion para empresas J2EE lleva cuatro afios de funcionamiento. Durante estos afios, ha reemplazado a diversas tecnologias de propiedad y no estindar como opci6n id6nea para e-comercio y otras aplicaciones de empresa de base Web. Considerando la multitud y la complejidad de 10s requisitos de infraestructura tkcnica para las aplicaciones de e-comercio, en este capitulo conoceri c6mo J2EE se adapta a estos requisitos proporcionando una infraestructura exhaustiva. H o y en dia, J2EE es una de las dos opciones disponibles para la creaci6n de aplicaciones de e-comercio. La otra opci6n la encontramos en Windows de Microsoft y en las tecnologias . NET. Desde sus comienzos, Java ha dado lugar a la creaci6n de nuevos modelos y tecnologias de programaci6n en diferentes campos, desde 10s dispositivos rnis sencillos hasta aplicaciones de empresa, pasando por telefonia. A1 mismo tiempo, Java ha funcionado como catalizador a la hora de conseguir que ciertos campos de la tecnologia adopten formas rnis seguras y sblidas. La plataforma de informitica de empresa de Java, la Plataforma Java 2, Enterprise Edition (JZEE), es uno de estos campos. En el pasado, 10s debates en 10s medios de comunicaci6n, asi como en 10s circulos tkcnicos, han cuestionado si Java es un lenguaje de programaci6n o una plataforma sobre la que construir y presentar aplicaciones. J2EE es, de hecho, uno de 10s intentos rnis efectivos por parte de Sun y sus asociados en hacer que Java resulte creible comoplataforma para informitica de empresa distribuida. iPor quk J2EE? iPor quk es la plataforma adecuada? (Por quk deberia elegir esta tecnologia para crear aplicaciones en el imbito empresarial, desde cliente-servidor a Internet hasta m6viles? Este capitulo le ofrece una visi6n equilibrada de J2EE y le ayuda a encontrar respuestas a estas preguntas. El resto de este libro es un anilisis rnis profundo de las tecnologias individuales y demuestra c6mo construir y gestionar con kxito tales aplicaciones de empresa. En este capitulo introductorio centraremos nuestra atenci6n en 10s siguientes puntos: 0
La arquitectura tkcnica de J2EE.
a
Las caracteristicas que hacen de J2EE una plataforma creible.
U Los retos a 10s que se enfrenta J2EE. 0
Las tecnologias que comprende la plataforma J2EE.
En primer lugar, n o obstante, empezaremos con el reto que supone hoy en dia para las empresas el desarrollo de aplicaciones.
La empresa actual Este libro aborda la creaci6n de aplicaciones de empresa, per0 ia quk nos referimos exactamente cuando hablamos de una "empresa"?
46
Plataforma J2EE U n a ernpresa es una organizaci6n econ6rnica y las aplicaciones de ernpresa son aquellas aplicaciones de software que facilitan diversas actividades dentro de una ernpresa. Las aplicaciones de ernpresa pueden ser aquellas que hacen concesiones a 10s usuarios finales via Internet, a colaboradores via Internet o redes privadas, a diversas unidades econ6micas dentro de la ernpresa via distintos tipos de interfaces de usuario, etc. En esencia, las aplicaciones de empresa son aquillas que perrniten a una ernpresa gestionar sus actividades econ6rnicas. Ejernplos de tales actividades inchyen planificaci6n de recursos, inventarios y catilogos de productos, preparaci6n de facturas, satisfaccidn de bienes y servicios prestados, etc. Crear aplicaciones para una ernpresa siempre ha sido un reto. Algunos de 10s factores que contribuyen a este reto y su cornplejidad son 10s siguientes: CI Diversidad de necesidades de inforrnaci6n
En una ernpresa, la inforrnacion es creada y consurnida por varios usuarios en una serie de forrnas diferentes, dependiendo de necesidades especificas. Es rnuy cornun encontrar que cada actividad econdmica procesa la inforrnaci6n de un rnodo diferente. D Cornplejidad de procesos econ6rnicos
La mayoria de procesos econ6rnicos de ernpresa conllevan recabar inforrnaci6n compleja, procesarla y distribuirla. C o n rnucha frecuencia, se enfrentari a una 16gica cornpleja para recabar y procesar inforrnaci6n. Esto tiene corno resultado unos complejos requisitos ticnicos y de arquitectura para crear aplicaciones de ernpresa. CI Diversidad de aplicaciones
Debido a la compleja naturaleza de 10s procesos econ6rnicos de empresa, es frecuente encontrar una ernpresa consistente en un gran nurnero de aplicaciones, cada una de ellas creada en distintos mornentos para satisfacer las necesidades de distintos procesos econ6rnicos. Esto desernboca con frecuencia en la presencia de aplicaciones creadas utilizando diferentes arquitecturas y tecnologias. U n o de 10s retos a 10s que se enfrentan las ernpresas hoy en dia es la necesidad de conseguir que dichas aplicaciones se cornuniquen entre si de rnodo que 10s procesos econ6micos puedan llevarse a cab0 sin interrupciones. Estos factores son rnuy comunes y las ernpresas incurren en enormes costes para crear y gestionar aplicaciones que hagan frente a estos retos. Durante 10s filtirnos ahos, estos retos han alcanzado dirnensiones rnonstruosas. Gracias a Internet y a1 reciente crecirniento del e-cornercio, 10s dispositivos de inforrnaci6n de una ernpresa son ahora mis valiosos. Este carnbio hacia una econornia de la informacion e s t i forzando a rnuchas cornpahias a reforrnular incluso sus pricticas economicas rnis bisicas. C o n el objetivo de rnantener un rnargen cornpetitivo, la adopci6n de nuevas tecnologias para cubrir las necesidades del rnornento ripidarnente se ha convertido en un factor clave en la habilidad de una ernpresa para explotar a1 rnixirno sus dispositivos de inforrnacion. Fundarnentalrnente, la adaptation de estas nuevas tecnologias para que funcionen en cornbinacibn con 10s sistemas legados ya existentes es ahora uno de 10s requisitos principales de la empresa. Uno de 10s lugares donde estos cambios se han percibido de un rnodo mis intenso ha sido en el imbito del desarrollo de aplicaciones. A lo largo de 10s ultirnos ahos, 10s fondos y el tiernpo invertidos en el desarrollo de aplicaciones se han visto reducidos, rnientras que las dernandas para crear cornplejos procesos econ6rnicos han aurnentado. Sin embargo, arnbos son obsticulos que 10s prornotores pueden superar, per0 tarnbiin se encuentran con 10s siguientes requisitos que cumplir: 0 Productividad de prograrnaci6n
La adopci6n directa de nuevas tecnologias es insuficiente si istas no son utilizadas adecuadamente aprovechando su potencial a1 mixirno y si no son integradas apropiadarnente con otras tecnologias
Capitulo 1 relevantes. De este modo, la habilidad para desarrollar y despuks desplegar las aplicaciones tan ripida y efectivamente como sea posible es muy importante. Conseguir este objetivo puede resultar complicado debido a la gran variedad de tecnologias y normas que han sido desarrolladas a lo largo de 10s afios, que requieren capacidades altamente desarrolladas; tan s61o adquirirlas y mantenerse a la altura es un problema en si mismo. Ademis, el ripido ritmo de cambio en las mismas normas dificulta la tarea de asegurar un eficiente engranaje de las tecnologias. 0
Fiabilidad y disponibilidad En la economia actual de Internet, el tiempo de inactividad puede resultar fatal para una empresa. La habilidad para organizar y poner en marcha sus operaciones de base Web, y mantenerlas activas, es crucial para lograr el objetivo con kxito. Y por si no fuera suficiente, t a m b i h debe ser capaz de garantizar la fiabilidad de sus transacciones econ6micas de mod0 que Sean procesadas por completo y con exactitud.
0
Seguridad Internet no s61o ha aumentado exponencialmente el numero de usuarios potenciales sino tambikn el valor de la informaci6n de una compafiia, de mod0 que la seguridad de esta informaci6n se ha convertido en una preocupaci6n de primer orden. Es mis, a medida que las tecnologias son mis avanzadas, las aplicaciones mis sofisticadas y las empresas mis complejas, poner en marcha un modelo de seguridad efectivo es cada vez mis dificil. Reajustabilidad La capacidad de una apkaci6n para crecer y ajustarse a una nueva demanda, tanto en su operacidn como en su base de usuario, es esencial. Esta condici6n se cumple especialmente cuando consideramos que la base potencial de usuarios de una aplicaci6n puede ser de millones de usuarios individuales, via Internet. La capacidad efectiva de reajuste depende no s61o de la habilidad para manejar un amplio aumento en el numero de clientes sino tambikn del uso efectivo de 10s recursos de un sistema.
0
Integraci6n Aunque la information ha crecido hasta convertirse en un dispositivo econ6mico clave, mucha de esta informaci6n existe como datos en sistemas de informacibn viejos y obsoletos. Para maximizar la utilidad de esta informaci6n, las aplicaciones deben poder ser inteqadas en 10s sistemas de informaci6n ya existentes, lo cual no es necesariamente una tarea ficil ya que las tecnologias actuales con frecuencia han avanzado hasta superar algunos de estos sistemas legados. La habilidad para combinar las nuevas y las viejas tecnologias es fundamental para el kxito del desarrollo de las empresas de hoy en dia.
iEstamos buscando f6rmulas migicas para enfrentarnos a estos desafios? A pesar de las promesas de evangelistas y vendedores, n o es aconsejable esperar (o confiar en) una soluci6n que evite o supere por completo estos retos. Lo que las empresas estin buscando es una tecnologia y una infraestructura permisiva que simplifique algunos de 10s temas tkcnicos complejos. A medida que vaya avanzando en este libro, encontrari el anilisis de estos temas. Ninguno de estos imbitos problemiticos es especialmente nuevo para 10s creadores de programas de una empresa. Pero resolverlos de un mod0 exhaustivo y rentable sigue siendo crucial. Puede que sea consciente de que han existido diversas tecnologias para resolver una o mis de las demandas anteriores. Sin embargo, lo que siempre ha faltado ha sido una plataforma con una rica infraestructura y numerosas posibilidades de arquitectura que promueva a1 mismo tiempo un ripido entorno de desarrollo. El objetivo de JZEE es simplificar algunas de las complejidades tkcnicas y especificar 10s siguientes puntos para crear aplicaciones de empresa: 0
U n modelo de programaci6n, consistente en un conjunto de interfaces de programaci6n de aplicaciones (API) y e n 10s enfoques para la creaci6n de dichas aplicaciones.
Plataforma J2EE Una infraestructura de aplicaci6n, para respaldar las aplicaciones de empresa creadas utilizando 10s API.
1Es Java la respuesta? Hasta ahora hemos examinado nuestra arquitectura de sistema desde una perspectiva agnostics en cuanto a su ejecuci6n. De hecho, existen muchos caminos potenciales que pueden tomarse para poner en marcha su empresa. Existen esencialmente dos caminos principales: uno emprendido por Microsoft, con su nueva iniciativa. NET, y el segundo, emprendido por Sun y otras empresas tales como BEA, IBM, Oracle, etc. Teniendo en cuenta las opciones, ipor quC deberia ser Java una excelente elecci6n? Examinemos algunas de sus ventaias.
lndependiente de la plataforma Con la informacion de una empresa desplegada en formatos dispares, en distintas plataformas y aplicaciones, es importante adoptar un lenguaje de programacion que pueda funcionar perfectamente en la empresa sin tener que recurrir a mecanismos extrafios e ineficientes de traduccion. U n modelo de programacion unificador tambikn reduce las dificultades surgidas de la integration de muchas de las diversas tecnologias que se convierten en especificas para ciertas plataformas y aplicaciones.
Objetos gestionados J2EE proporciona un entorno gestionado para componentes y las aplicaciones de J2EE son centricas respecto del contenedor. Ambas nociones son criticas para construir aplicaciones de cliente. A1 ser ges;ionados, 10s componentes de J2EE utilizan la infraestructura prop&cionada por 10s servidores de J2EE sin que el programador sea consciente de ello. Las aplicaciones de J2EE son tambiCn declarativas, un mecanismo con el que puede modificar y controlar el funcionamiento de las aplicaciones sin cambiar de codigo. A primera vista, estas caracteristicas pueden parecer incomodas de ejecutar. Sin embargo, cuando considera las aplicaciones a gran escala con varios cientos de componentes interactuando para ejecutar complejos procesos empresariales, estas caracteristicas hacen que crear y mantener tales aplicaciones resulte menos complejo. Junto con su independencia respecto de la plataforma, iste es uno de 10s aspectos mis importantes de JZEE.
Reusabilidad La reutihaci6n del c6digo es el Santo Grial de la programacion. Separar 10s requisitos econ6micos de una aplicacion en sus partes integrantes es un modo de conseguir la reutilizacibn; utilizar la orientation a1 objeto para encapsular la funcionalidad compartida es otro. Sin embargo, a diferencia de 10s objetos, 10s componentes distribuidos requieren una infraestructura mis compleja para su construccidn y gesti6n. Los conceptos bisicos orientados a objetos no proporcionan este tip0 de marco, pero la Enterprise Edition de Java ofrece una arquitectura notablemente rigurosa para la reutilizacion de componentes. Los componentes de empresa (Ilamados Enterprise JavaBeans) desarrollados en J2EE son de basica granulometria (aunque la especificacion EJB 2.0 en J2EE 1.3 permite un enfoque de granulometria mis fina) y reproducibles. Manteniendo estos componentes bisicos, es posible crear funcionalidades de empresa complejas de un modo libremente coordinado. Ademis, ya que 10s componentes son reproducibles, lo cual quiere decir que es posible identificar ciertos metadatos sobre 10s componentes, las aplicaciones pueden ser creadas componiendo tales componentes. Ambas caracteristicas fomentan la reutilizaci6n del c6digo a alta granulometria.
Capitulo 1 Modularidad A la hora de desarrollar una aplicacidn de servidor completa, 10s programas pueden ampliarse y complicarse ripidamente. Siempre es mejor romper una aplicacidn en m6dulos discretos, cada uno de ellos responsable de una tarea especifica. Esto hace que nuestras aplicaciones sean mucho mis ficiles de mantener y comprender. Por ejemplo, 10s servlets de Java, las Piginas de JavaServer y Enterprise JavaBeans proporcionan un modo de modularizar nuestra aplicaci6n, rompiendo nuestras aplicaciones en diferentes niveles y tareas individuales. A pesar de las caracteristicas a su favor mencionadas, Java no present6 un modelo de programaci6n unificador a escala de empresa hasta principios del afio 2000. N o es que no tuviera la capacidad, sino que en el pasado estaba algo desorganizada. Sun reconoci6 este fallo y lam6 la Plataforma Java 2, Enterprise Edition (J2EE). La idea subyacente a la plataforma J2EE es proporcionar u n estindar sencillo y unificado para aplicaciones distribuidas e n u n modelo de aplicaci6n basado en componentes. En el resto del capitulo, y por supuesto en el resto del libro, analizaremos lo que aporta J2EE a1 desarrollo del lado servidor con Java.
Estilos de arquitectura de empresa Antes de que entremos de lleno en la arquitectura de J2EE, es necesario que consideremos 10s estilos de arquitectura de las aplicaciones distribuidas contemporineas: las arquitecturas de nivel2, nivel3 y nivel n. El propdsito de esta seccidn es principalmente capacitar a1 lector para reconocer el alcance y la localizacidn de estos patrones. Sin embargo, debemos tener presente que en realidad posiblemente nuestras aplicaciones requieran patrones mis complejos o en ocasiones una combinacidn de tstos. Aunque estos estilos de arquitectura se encuentran con bastante frecuencia en las empresas de la actualidad, merece la pena sefialar que estos estilos surgieron debido a la llegada de nuevas plataformas de hardware para clientes y servidores mis baratas y de tecnologias de redes. Anteriormente, 10s motores de las empresas eran sistemas principales con todos 10s servicios informiticos (desde la generacidn usuariointerfaz hasta procesamiento de transacciones de gran volumen) centralizados. Consecuentemente, la tecnologia cliente-servidor fue lo que provoc6 una automatizacidn masiva de la empresa. Los sistemas cliente-servidor tipicos estin basados en la arquitectura de dos niveles, donde existe una clara separacidn entre 10s datos y la 16gica presentacion/empresa. Estos sistemas estin generalmente controlados por datos, siendo el servidor, en gran cantidad de ocasiones, un servidor de base de datos. Aunque este enfoque nos permite compartir datos en la empresa, tiene muchos inconvenientes.
Arquitectura de dos niveles En una aplicaci6n tradicional de 2 niveles, la carga de procesamiento es facilitada el PC cliente mientras que el servidor actua simplemente como controlador del trifico entre la aplicacidn y 10s datos. Como resultado, el rendimiento de la aplicacidn no s61o sufre debido a 10s recursos limitados del P C sino que el trifico de la red tambitn tiende a aumentar. Cuando la aplicacidn completa es procesada en un PC, la aplicaci6n es forzada a realizar multiples peticiones de datos antes incluso de presentar algo al usuario. Estas mdtiples peticiones de bases de datos pueden sobrecargar la red:
Plataforma J2EE
I
I
Aplcacdn
'
I
O t r o problerna tipico relacionado con el enfoque de 2 niveles es el del rnantenimiento. Incluso el rnenor carnbio realizado a una aplicaci6n puede conllevar una completa alteraci6n en la base de usuario. Aunque sea posible autornatizar el proceso, todavia debe enfrentarse a la actualizacidn de cada instalaci6n de cliente. Es mis, algunos usuarios puede que no estkn preparados para una alteraci6n total y posiblernente ignoren 10s cambios rnientras que otro grupo puede que insista en realizar 10s cambios de inrnediato. Esto puede provocar que diferentes instalaciones de cliente utilicen diferentes versiones de la aplicaci6n.
Arquitectura de tres niveles Para enfrentarse a estos ternas, la cornunidad de software desarroll6 la noci6n de una arquitectura de 3 niveles. Una aplicaci6n se divide en tres capas 16gicas distintas, cada una de ellas con un grupo de interfaces perfectamente definido. La prirnera capa se denornina capa de p r e s e n t a c i h y norrnalmente consiste en una interfaz grifica de usuario de algun tipo. La capa interrnedia, o capa de ernpresa, consiste en la aplicaci6n o 16gica de ernpresa, y la tercera capa, la capa de datos, contiene 10s datos necesarios para la aplicaci6n. La capa interrnedia (lbgica de aplicaci6n) es bisicamente el codigo a1 que recurre el usuario (a travCs de la capa de presentaci6n) para recuperar 10s datos deseados. La capa de presentaci6n recibe entonces 10s datos y 10s formatea para su presentacibn. Esta separaci6n entre la 16gica de aplicaci6n de la interfaz de usuario ariade una enorrne flexibilidad a1 diserio de la aplicaci6n. Puede construirse y desplegarse multiples interfaces de usuario sin carnbiar en absoluto la 16gica de aplicaci6n, siernpre que la 16gica de aplicaci6n presente una interfaz clararnente definida a la capa de presentacibn. Corno veri rnis adelante en este capitulo, y e n el resto del libro, J2EE ofrece diversas abstracciones para satisfacer las necesidades de cada una de estos niveles. Por ejernplo, 10s EJB ofrecen rnecanisrnos para abstraer tanto el acceso a datos corno la 16gica de empresa. De un rnodo similar, 10s servlets y las Piginas JavaServer le perrniten abstraer la capa de presentaci6n y su interacci6n con la capa de ernpresa. La tercera capa contiene 10s datos necesarios para la aplicaci6n. Estos datos consisten en cualquier fuente de inforrnaci611, incluido una base de datos de empresa corno Oracle o Sybase, un conjunto de documentos XML o incluso un servicio de directorio corno el servidor LDAP. Adernis del tradicional rnecanisrno de alrnacenarniento relacional de bases de datos, existen rnuchas fuentes diferentes de datos de ernpresa a las que pueden acceder sus aplicaciones:
Capitulo
1 lnterfaz d e Usuario
Documentos XML
Sin embargo, todavia n o hemos finalizado nuestra subdivisidn de la aplicaci6n. Podemos dar un paso m i s e n la segregation para crear una arquitectura de n niveles.
Arquitectura de n niveles C o m o sugiere el titulo, n o hay un m o d 0 m i s precis0 de definir las capas de aplicaci6n para un sistema de n niveles. D e hecho, este tip0 de sistema puede dar cabida a varias configuraciones diferentes. En una arquitectura de n niveles, la 16gica de aplicaci6n e s t i 16gicamente dividida p o r funciones y n o fisicamente. U n a arquitectura de n niveles se descompone en las siguientes partes: 0
U n a interfaz d e usuario que maneja la interacci6n del usuario con la aplicaci6n. ~ s t puede a ser un navegador W e b ejecutado mediante un cortafuegos, una aplicaci6n de escritorio m i s laboriosa o incluso un dispositivo inalimbrico.
0
U n a 16gica d e presentaci6n que define lo que muestra la interfaz de usuario y c o m o son gestionadas las demandas del usuario. Dependiendo de las interfaces de usuario que se mantengan, puede que sea necesario contar con versiones de la 16gica de presentaci6n ligeramente diferentes para satisfacer a1 cliente adecuadamente. U n a 16gica d e empresa que modele las reglas de empresa de la aplicacibn, a menudo a traves de la interacci6n con 10s datos de la aplicaci6n.
o Semicios d e infraestructura que proporcionen la funcionalidad adicional requerida p o r 10s componentes d e la aplicacion, tales c o m o mensajeria y apoyo transactional. 0
La capa d e datos donde residen 10s datos de la empresa.
Plataforma J2EE
Navegador
~
I
1
Cortafuegos
Log~cade Empresa
Documentos XML
Las aplicaciones basadas en esta arquitectura emplean esencialmente el patrdn Model-ViewController ( M V C ) . Lo que esto sign+ca fundamentalmente es que 10s datos (el modelo) son independientes respecto de la presentacidn de la informacidn (la vista). En una posicidn intermedia se encuentra la 16gica de aplicacidnlempresa (el controlador) que controla el jlujo de informacidn. De este modo, uria aplicacidn es disefiada a partir de estos tres componentes funcionales (modelo, vista y controlador) interactuando erztre s i
Arquitectura de empresa Hasta el momento nos hemos centrado realmente en una sola arquitectura de aplicacion; nos arriesgamos a considerar estas aplicaciones "tuberias". En otras palabras, puede que terminemos con diferentes aplicaciones (posiblemente incluso con diferentes arquitecturas) que no se cornunican entre si. En una ernpresa, intentarnos crear una arquitectura cohesiva que incorpore diferentes aplicaciones. Antes que un carnbio en la arquitectura (la arquitectura de ernpresa es bdsicamente n niveles) necesitamos un carnbio en la percepcion. Para convertir un sisterna n niveles en un sisterna de ernpresa, simplernente necesitamos ampliar el nivel interrnedio perrnitiendo la existencia de multiples objetos de aplicacion en lugar de una unica aplicacion. Estos objetos de aplicacion deben tener una interfaz individual que les perrnita funcionar entre si. Una interfaz puede concebirse corno un contrato. Cada objeto afirma a travis de su interfaz que aceptari ciertos pardmetros, que realizari ciertas operaciones y devolvera un conjunto especifico de resultados. Los objetos de la apkaci6n se comunican entre si utilizando sus interfaces, corno muestra el siguiente diagrarna:
r
Capitulo 1
Forma HTML
I
lnterfaz
lnterfaz
/ S~stemaRemoto ; L-
-
-
lnterfaz
Documentos 1 XML 1
Con la arquitectura de empresa, podemos tener multiples aplicaciones utilizando un conjunto comun de componentes a traves de una organizaci6n. Esto promueve la normalizaci6n de la prictica empresarial gracias a la creaci6n de un Gnico conjunto de funciones de empresa a1 que puede acceder toda la organizaci6n. Si la norma de una empresa cambia, dichos cambios deben trasladarse tambien a1 "objeto de empresa" y, si es necesario, a la interfaz asociada y consecuentemente a cualquier objeto que acceda a la interfaz. Observe, sin embargo, que ciertas funcionalidades de 10s sistemas legados existentes no pueden eliminarse y que debe desarrollarse un "envoltorio" (o interfaz) especifico a esta funcionalidad en el nivel intermedia.
Es importante sefialar que a la hora de diseiiar un objeto y su interfaz, es conveniente hacer que la interfaz sea lo m6s generica posible para evitar cambios en el futuro. Debido que a otros objetos se comunican con la interfaz y no con el objeto en si mismo, 10s cambios realizados a1 objeto, y no a la interfaz, son relativamente sencillos y ripidos. Observe que, en todos estos patrones, las interfaces de usuario son la parte que aparece en la parte superior de cada diagrama. A partir de estos diagramas, puede obtener la impresi6n de que las interfaces de usuario son las que siempre dirigen 10s sistemas. Aunque ksta es la forma mis comGnmente visible de interacci6n de sistema, a1 considerar la integraci6n de aplicaciones intra e inter-empresa, y en 10s procesos entre empresas, comprobari que las aplicaciones interactGan con otras aplicaciones. N o obstante, la mayoria de las tecnologias que examinaremos y 10s disefios que encontrari en este libro tambien se aplican a estos sistemas.
Plataforma J2EE
La plataforma JZEE C o m o podri comprobar en el resto del libro, J2EE es una de las mejores soluciones encontradas hasta el momento para satisfacer las demandas de la emprcsa de hoy en dia. J2EE especifica tanto la infraestructura para gestionar sus aplicaciones, como 10s sewicios API para construir sus aplicaciones. La plataforma J2EE es esencialrnente un entorno distribuido aplicaci6n-servidor, un entorno Java que ofrece: 0 U n conjunto de varios API de extension Java para construir aplicaciones. Estos API definen un
modelo de programacibn para aplicaciones J2EE. U n a infraestructura de periodo de ejecuci6n para albergar y gestionar aplicaciones. ~ s t es e el periodo de ejecuci6n en el que residen sus aplicaciones. Las aplicaciones que puede desarrollar con estos dos elementos pueden ser programas para controlar piginas Web o componentes para implementar transacciones complejas de bases de datos, o incluso applets de Java, todos ellos distribuidos por la red.
Periodo de ejecucion de JZEE Si bien JZEE asocia 10s API que han existido de una forma u otra durante a l g h tiempo, quizis su aspecto m i s significative sea la abstracci6n de la infraestructura del periodo de ejecucion. Observe que la especificaci6n J2EE no especifica como deberia o podria construirse un periodo de ejecuci6n. Esto provoca una clara demarcaci6n entre las aplicaciones y la infraestructura del periodo de ejecuci6n. Esta demarcaci6n permite al periodo de ejecuci6n abstraer la mayor parte de 10s sewicios de infraestructura que 10s desarrolladores de programas de empresa han intentado construir tradicionalmente por su cuenta. C o m o resultado, los desarrolladores de programas de la aplicaci6n JZEE s61o podian centrar sus esfuerzos en la 16gica de aplicacibn y servicios relacionados, mientras relegaban el periodo de ejecucibn para todos 10s servicios relacionados con la infraestructura. Sin embargo, icuiles son 10s requisitos de infraestructura para aplicaciones de empresa? Es interesante seiialar que el desarrollo de aplicaciones en un entorno de ritmo crecimiento ripido, como Internet, tiene como resultado normalmente diseiios efimeros. Por otro lado, a la hora de considerar 10s aspectos de diseiio a largo plaza, podemos tener dificultades para encontrar un termino medio entre las demandas a corto plazo y a largo plazo. Existen tecnologias que se prestan a un ripido desarrollo y otras tecnologias que permiten construir aplicaciones teniendo en cuenta este tip0 de intereses a largo plazo como la reusabilidad, coste de rnantenimiento, etc. A menudo, estos dos tipos n o se combinan, per0 JZEE es lo suficientemente flexible como para construir aplicaciones que incluyan ambos. La raz6n es que J2EE le permite construir cada capa de su aplicaci6n en combinacibn libre con todas las otras capas. Cada capa puede consecuentemente evolucionar para cubrir sus respectivas necesidades de evolucibn. D c este modo, ajustindose a un sistema disenado sobre interfaces, la implementaci6n es rnuy ampliable. Adernis de especificar una serie de API estbndar, la arquitectura de J2EE tambitn proporciona un medio uniforme de acceder a 10s sewicios a escala de la plataforma a travts de su entorno de periodo de ejecucibn. Estos servicios incluyen transacciones distribuidas, seguridad, mensajes, etc. Antes de pasar a 10s detalles del enfoque de J2EE, examinemos el procesamiento informitico distribuido tradicional. Hasta la llegada de J2EE, el procesamiento informitico distribuido era considerado, en general, programacibn cliente-sewidor. Grabariarnos una aplicaci6n de sewidor implementando una interfaz, una aplicacion de cliente para conectar con el sewidor y entonces iniciar el sewidor y el cliente. Aunque este
Capitulo 1 proceso parece bastante sencillo, en la prictica existen varios obsticulos criticos, dependiendo de la tecnologia utilizada. Por ejemplo, pensemos en un objeto CORBA para construir aplicaciones distribuidas. El procedimiento tipico para construir objetos CORBA de lado servidor empezaria especificando una interfaz, utilizando el Lenguaje de Definici6n de Interfaces (IDL), para cada objeto. Los pasos siguientes incluyen compilar este IDL para generar "stubs" y "esqueletos" para el lenguaje que elija, implementando el objeto basado en el esqueleto, grabando despues la aplicaci6n de cliente, preparando el entorno, etc. En este caso, el stub es la clase que representa el objeto CORBA en el lado cliente. El esqueleto proporciona el metodo con el que es implementada la 16gica del lado servidor. Este procedimiento en si mismo no es complicado y puede automatizarse ficilmente. Como iri aprendiendo en este libro, 10s EJB requieren tambitn algunos de estos pasos y son similares en concept0 a 10s objetos CORBA. Considere ahora que nuestros servidores, al igual que 10s clientes, necesitan acceder a servicios tales como transacciones distribuidas, mensajeria, etc. Para hacer uso de estos servicios, seria necesario que aiiaditramos una importante proporci6n de c6digo de instalaci6n a nuestras aplicaciones. En muchas ocasiones, seri necesario que instalemos y configuremos diferentes soluciones de software intermedio, y que realicemos llamadas API a 10s API especificos de vendedor para acceder a 10s servicios. Ademis de servicios tales como el acceso a bases de datos relacionales, la mayoria de estos servicios son de propiedad o no estindar. El resultado es que nuestras aplicaciones serin mis complejas, invertirin mis tiempo y serin mis caras de desarrollar, gestionar y mantener. Ademis de tener que gestionar todos estos API diferentes, existe otra demanda critica en las aplicaciones del lado servidor. En el lado servidor, 10s recursos son escasos. Por ejemplo, no podemos permitirnos crear el mismo numero de objetos podriamos crear normalmente en aplicaciones del lado cliente. Otros recursos del lado servidor que requieren especial atenci6n incluyen hilos de ejecuci6n (threads), conexiones de bases de datos, seguridad, transacciones, etc. Construir a medida una infraestructura que maneje este tip0 de recursos ha sido siempre un desafio. Esta tarea resulta casi imposible en la economia de Internet. iSe molestaria en construir una reserva de conexibn, o un objeto cache, o "una elegantel' capa de objeto para acceso a bases de datos, cuando su ciclo de vida de desarrollo es s610 de tres meses? Debido a que estos requisitos de lado servidor son bastante comunes a una amplia variedad de aplicaciones, es mis apropiado considerar una plataforma que cuente con soluciones integradas. Esto nos permite separar estos aspectos de infraestructura de 10s aspectos mis directos relacionados con traducir sus requisitos de aplicaci6n en un software que funcione. El periodo de ejecuci6n de J2EE se enfrenta a dichos aspectos. Fundamentalmente, dejamos que sea el vendedor de servidor J2EE quien implemente 10s rasgos especificos de acuerdo con las normas establecidas. Como ya hemos mencionado anteriormente, J2EE no especifica la naturaleza y estructura del periodo de ejecuci6n. En su lugar, introduce lo que se denomina contenedor y mediante 10s API de JZEE, especifica un contrato entre contenedores y aplicaciones. Tendri mis detalles sobre este contrato mis adelante. Antes de examinar con mis detalle 10s contenedores de JZEE, revisemos brevemente 10s API de J2EE.
Los API de JZEE Las aplicaciones distribuidas requieren acceso a una serie de servicios de empresa. Los servicios tipicos incluyen procesamiento de transacciones, acceso a bases de datos, mensajeria, multihilos (multithreading), etc. La arquitectura de JZEE unifica el acceso a estos servicios en un API de servicios de empresa. Sin embargo, en lugar de tener que acceder a estos servicios a travts de interfaces de propietario o no estindar, 10s programas de aplicaci6n en J2EE pueden acceder a estos API mediante el contenedor. Una tipica plataforma J2EE comercial (o servidor de aplicaci6n J2EE) incluye uno o mis contenedores y el acceso a 10s API de empresa viene especificado por la J2EE.
Plataforma J2EE Fijese en que 10s servidores de aplicacidn J2EE no necesitan implementar estos seruicios ellos mismos; 10s contenedores s61o deben proporcionar acceso a cada implementaci6n de servicio a travb de u n API de J2EE. Por ejemplo, una impfementaci6n J2EE puede delegar las llamadas API de Java Message Service a una solucidn de sofmare intermedio orientada a mensajes. Otra implementaci6n podria incluir una sofucidn de software intermedio orientada a mensajes dentro de un contenedor. La especificacion de la plataforma J2EE 1.3 incluye un grupo de extensiones estindar Java que cada plataforrna J2EE debe mantener: 0 JDBC 2.0
Mis especificarnente, JDBC 2.0 Optional Package. Este API rnejora el API estindar de JDBC 2.0 afiadiendo rnedios mis eficientes de obtener conexiones, reserva de conexibn, transacciones distribuidas, etc. Observe que la siguiente versi6n de JDBC, el API de JDBC 3.0, combina la extensi6n API con el API JDBC habitual. Quizis futuras versiones de J2EE incluyan JDBC 3.0. 0 Enterprise JavaBeans (EJB) 2.0 Especifica una estructura de componentes para aplicaciones multidistribuidas multinivel . Proporciona un medio estindar para la definici6n de componentes de lado servidor y especifica una rica infraestructura de period0 de ejecuci6n para albergar cornponentes en el lado servidor. 0 Java Servlets 2.3
El API Java Servlet proporciona abstracciones orientadas a1 objeto para construir aplicaciones Web dinirnicas. 0 Java Server Pages (JSP) 1.2
Esta extensi6n refuerza un poco rnis las aplicaciones Web de J2EE proporcionando desarrollo de aplicaciones Web dirigidas por un rnodelo. 0 Java Message Service (JMS) 1.0 JMS ofrece un API Java para colas de rnensaje y publica y suscribe tipos de servicios de software intermediario orientados al rnensaje. O Java Transaction API (JTA) 1.0
Este API esti destinado a irnplernentar aplicaciones transaccionales distribuidas. 0 JavaMaill.2 Este API proporciona una estructura independiente de la plataforma y del protocolo para construir aplicaciones de e-mail basadas en Java. O JavaBeans Activation Framework (JAF) 1.0
Este API es necesario para el API JavaMail. El API JavaMail utiliza JAF para deterrninar 10s contenidos de un rnensaje MIME (Multipurpose Internet Mail Extension) y deterrnina quC operaciones apropiadas pueden realizarse en diferentes partes de un mensaje. 0 API Java para XML Parsing (JAXP) 1.1 Este API proporciona abstracciones para analizadores XML y API de transformaci6n. JAXP ayuda a aislar analizadores especificos XML, o irnplernentaciones D O M (Document Object Model), o API de transforrnaci6n XSLT de codigos de aplicacidn J2EE. O Java Conector Architecture (JCA) 1.0
Este API ha sido incluido recientemente en J2EE y proporciona un rnedio para integrar cornponentes de aplicacion J2EE para sistemas de informaci6n legados. 0 Java Authenticaction and Authorization Service (JAAS) 1.0 Este API proporciona rnecanismos de autentificacion y autorizacion para las aplicaciones J2EE.
Capitulo 1 La mayoria de estos API son especificaciones, independientes de implernentacion. Es decir, se deberia poder acceder a 10s semicios proporcionados por estos API de un mod0 estindar, con independencia de como son implementados. Los API especificos de J2EE mencionados anteriormente se suman a 10s siguientes API de J2SE: 0
API Java Interface Definition Language (IDL) Este API permite a 10s componentes de aplicacion J2EE invocar objetos CORBA via I I O P (vtase mis adelante).
0 JDBC Core API
Este API proporciona las instalaciones de programaci6n de bases de datos bisicas. O
API RMI-IIOP Proporciona una implementaci6n del habitual API Java Remote Meted Invocation (RMI) sobre Internet Inter.-ORB Protocol (IIOP). Salva la distancia entre las aplicaciones RMI y CORBA. Este es el protocolo de comunicaci6n asignado a utilizar entre contenedores J2EE.
0
API J N D I El API Java Naming and Directory Interface (JNDI) normaliza en acceso a diferentes tipos de semicios de designaci6n y directorio disponibles en la actualidad. Este API esti diseiiado para ser independiente de cualquier implementation especifica de semicio de designation o directorio. J2SE tambien especifica una interfaz proveedora de semicio J N D I (SPI), para ser implementada por proveedores de servicios de designacidn y directorio.
Examinaremos mks detalladamente estos API en posteriores apartados de este capitulo.
Arquitectura J2EE
- Contenedores
Como ya hemos visto en la secci6n anterior, una tipica plataforma comercial J2EE incluye uno o mis contenedores. Pero {qut exactamente un contenedor? U n contenedor J2EE es u n periodo de ejecuci6n para gestionar 10s componentes de la aplicaci6n desarrollados seglin las especificaciones del API y destinados a proporcionar acceso a 10s API de J2EE. Mas alli de la identidad asociada a1 periodo de ejecucirin, J2EE no especifica ninguna identidad para contenedores. Esto se traduce en una gran flexibilidad para conseguir una serie de caracteristicas dentro del periodo de ejecuci6n del contenedor. La siguiente figura muestra la arquitectura de J2EE en ttrminos de sus contenedores y sus API.
Plataforma J2EE
Contenedor de Applet -
HTTP SSL Contenedor Web
Contenedor E3B
I I----+[
Contenedor Chente~ de Apl~cac~dn I
I
JSP
:ervlet
HTTP SSL
i
Esta arquitectura muestra cuatro contenedores: 0
U n contenedor Web para albergar sewlets Java y piginas JSP.
0
U n contenedor EJB para albergar componentes Enterprise JavaBean.
0 U n contenedor applet para albergar applets Java. 0 U n contenedor de aplicaci6n cliente para albergar aplicaciones Java estindar.
En este libro, nuestro centro de atencio'n se limita knicamente a 10s contenedores Web y EJB. Cada uno de estos contenedores proporciona un entorno de periodo de ejecuci6n para 10s respectivos componentes. Los componentes J2EE tambiCn son denominados objetos gestionados, ya que estos objetos con creados y gestionados en el interior del periodo de ejecuci6n del contenedor. En la figura anterior, 10s bloques verticales situados en la parte inferior de cada contenedor representan 10s API de T2EE. Ademis del acceso a estos API a nivel infraestructura. cada contenedor tambiCn implementa el correspondiente API especifico a cada contenedor (API Java Servlet para el contenedor Web y el API EJB para el contenedor EJB). Los rectingulos (servlets, piginas JSP y 10s EJB) de esta figura son 10s programas que se desarrollan y se albergan en estos contenedores. En el lenguaje J2EE, estos programas se conocen como cornponentes de aplicaciones.
Observe que la figura anterior no incluye 10s API J2SE enumerados anteriormente, es decir, el Java I D L , memoria J D B C , RMI-IIOP y J N D I .
Capitulo 1 En esta arquitectura, existen principalmente dos tipos de clientes:
o Clientes Web, que se ejecutan normalmente en navegadores Web. Para estos clientes, la interfaz de usuario es generada en el lado sewidor como HTML o XML y es descargada y despuks convertida por 10s navegadores. Estos clientes utilizan http para comunicarse con contenedores Web. Los componentes de aplicaci6n en 10s contenedores Web incluyen sewlets Java y piginas JSP. Estos componentes implementan la funcionalidad requerida por 10s clientes Web. Los contenedores Web son 10s responsables de aceptar solicitudes por parte de 10s clientes Web y de generar respuestas con la ayuda de 10s componentes de la aplicacion. Otros tipos de clientes relacionados incluyen dispositivos m6viles habilitados por la Web capaces de generar WML (Wireless Markup Language) o cHTML (Compact HTML). Para estos clientes, el contenido puede ser generado directamente, o bien el contenido generado como XML puede ser transformado en estos lenguajes de marcado utilizando hojas de estilo XML. U Los clientes EJB son aplicaciones que acceden a componentes EJB en contenedores EJB.
Existen tres posibles tipos de clientes EJB. La primera categoria esti constituida por 10s clientes de aplicacion. Los clientes de aplicacidn son aplicaciones autosuficientes que acceden a 10s componentes EJB utilizando el protocolo RMI-IIOP. La segunda categoria de clientes de aplicacion est6 formada por componentes del contenedor Web. Es decir, 10s sewlets de Java y las piginas JSP tambikn pueden acceder a 10s componentes EJB a travks del protocolo RMI-IIOP del mismo mod0 que 10s clientes de aplicacion. La d t i m a categoria es otro EJB ejecutado dentro del \ contenedor EJB. Estos se comunican a travks de llamadas estindar de mktodo Java por medio de de una interfaz local (esta caracteristica es una novedad de J2EE 1.3). En 10s dos casos, 10s clientes acceden a 10s componentes de la aplicacion a travPs de sus respectivos contenedores. Los clientes Web acceden alas piginas JSP y a 10s sewlets Java a travks del contenedor Web, y 10s clientes EJB acceden a 10s componentes EJB a travks del contenedor EJB.
Arquitectura de contenedor Despuks de haber analizado las partes integrantes de JZEE, volvamos a nuestro anilisis de la arquitectura y estudiemos la arquitectura de un contenedor J2EE: Contrato de Contenedor --
i. z @
i
-
Componentes de Apl~cac~bn Descriptor de
lrnplernentaclon
Componentes
lrnplernentac~on
lrnplernentac~on
Plataforma j2EE En esta arquitectura, corno desarrolladores de programas estarnos obligados a proporcionar 10s siguientes elernentos: 0
Componentes de aplicaci6n Corno ya hernos visto en la secci6n anterior, 10s componentes de aplicaci6n incluyen servlets, piginas JSP, EJB, etc. En J2EE, 10s cornponentes de aplicaci6n pueden ser incluidos en ficheros en archivo.
0
Descriptores de implementaci6n U n descriptor de irnplernentaci6n es un archivo XML que describe 10s cornponentes de aplicaci6n. Tarnbitn incluye inforrnaci6n adicional requerida por contenedores para gestionar de un rnodo efectivo 10s cornponentes de aplicaci6n.
El resto de esta figura forrna el contenedor. La arquitectura de un contenedor puede dividirse en cuatro partes: 0
C o n t r a t o de contenedores U n conjunto de API especificados por el contenedor, que sus cornponentes de aplicacidn estin obligados a arnpliar o irnplernentar.
0
API de servicio de contenedor Los servicios adicionales proporcionados por el contenedor, que cornhrnente son requeridos por todas las aplicaciones en el contenedor.
0
Servicios declarativos Servicios que el contenedor introduce en sus aplicaciones, basados en la descripci6n de irnplernentaci6n proporcionada por cada cornponente de aplicaci6n, corno la seguridad, las transacciones, etc.
o O t r o s servicios de contenedores O t r o s servicios de periodo de ejecucibn, relacionados con ciclos de vida de 10s componentes, reserva de recursos, recolecci6n de basura, etc. Examinernos a continuaci6n cada uno de 10s elementos anteriores rnis detenidarnente.
Contratos de componentes Corno ya hernos rnencionado anteriormente, el propbsito bisico del contenedor en la arquitectura J2EE es proporcionar un periodo de ejecuci6n para 10s cornponentes de apkaci6n. Es decir, se crean ejernplares de 10s cornponentes de aplicaci6n y se invocan en el JVM del contenedor. Esto convierte a1 contenedor en responsable de la gesti6n del ciclo de vida de 10s cornponentes de la aplicaci6n. Sin embargo, si estin llarnados a ser gestionables en el periodo de ejecuci6n del contenedor, estin obligados a guiarse por ciertos contratos especificados por el contenedor. En otras palabras, las aplicaciones deben ser desarrolladas de acuerdo con un rnarco de operaci6n definido. Para cornprender rnejor este aspecto, considerernos un applet Java. Norrnalrnente, un applet es descargado por el navegador, instanciado e inicializado en el JVM del navegador. Es decir, el applet vive en el periodo de ejecuci6n proporcionado por el JVM del navegador. Sin embargo, para que el contenedor tenga la capacidad de crear, inicializar, e invocar rnttodos sobre cornponentes de aplicacibn, es necesario que 10s cornponentes de aplicaci6n irnplernenten o arnplien ciertas interfaces o clases Java. Por ejernplo, si tornarnos de nuevo el ejernplo del applet, un applet Java esti obligado a arnpliar la clase j ava applet .Applet especificada por el JDK. El JVM del navegador espera que 10s applets amplien esta clase. Esto perrnite al JVM del navegador llarnar a 10s rnttodos init ( ) , st art ( ) , s t o p ( ) y destroy ( ) de sus applets. Estos rnitodos controlan el ciclo de vida de un applet; si su applet no arnplia la clase j ava applet .Applet, el JVM del navegador no cuenta con 10s rnedios para llarnar a estos rnttodos y controlar su ciclo de vida.
.
.
-'En JZEE, todos 10s cornponentes de aplicaci6n son instanciados e inicializados en el JVM del contenedor. Adernis, debido a que 10s componentes de aplicaci6n JZEE son siernpre remotos a1 cliente, 10s clientes n o pueden invocar rnitodos directamente en estos cornponentes; de hecho, 10s clientes realizan solicitudes a1 -senidor de las aplicaciones y es el contenedor el que realmente invoca 10s rnitodos. Puesto que el proceso del contenedor es el h i c o punto de entrada a 10s componentes de la aplicaci6n, es necesario que todos 10s cornponentes de la aplicaci6n sigan el contrato especificado por el contenedor. En JZEE, este contrato esti concretado en interfaces y clases que las clases del usuario irnplementan o amplian, con norrnas adicionales que la definici6n del componente debe seguir. Existe una consecuencia irnportante de este contrato de componente. Todos 10s componentes de aplicaci6n JZEE son gestionados. La gesti6n incluye la ubicacibn, instanciaci6n, inicializaci6n, invocaci6n de semicio y elirninaci6n de componentes del semicio. Estos aspectos del ciclo de vida del componente estin bajo la re~~onsabilidad del contenedor y la aplicaci6n no tiene control directo. Analicemos a continuacion 10s diversos contratos especificados por el JZEE. En el caso de 10s contenedores Web, 10s componentes de aplicaci6n Web deben seguir 10s API de Java Semlet y de JSP. En este modelo, todos 10s semlets Java deben arnpliar la clase j a v a x .S e r v l e t .h t t p . H t t p S e r v l e t , e implernentarciertos rnitodos de estaclase tales comodoGet ( ) , d o p o s t ( ) , etc. Del mismo modo, a1 ser cornpilado, las clases correspondientes a las piginas JSP amplianlaclasejavax. S e r v l e t .j s p . H t t p J s p P a g e . En el caso de 10s contenedores EJB, 10s beans de sesi6n y de entidad de ernpresa deben tener interfaces j a v a x .e j b .EJBHome y j a v a x .e j b . E JBObj e c t especificados, alavez que implementan unainterfaz j a v a x . e j b . S e s s i o n B e a n o j a v a x . e j b . E n t i t y B e a n . Del mismo rnodo, 10s beans orientados a mensajes deben irnplernentar las interfaces j a v a x .e j b . M e s s a g e D r i v e n B e a n y j a v a x . jmx . M e s s a g e L i s t e n e r . Cornoveri en el capitulo 14, las especificaciones e implementaciones de componente tambiin deben seguir ciertas reglas. Aparte de las interfaces, todas estas reglas formafi parte del contrato de componente para componentes EJB.
API de servicio de contenedor Corno hernos visto anteriormente, la plataforma JZEE define un conjunto de extensiones estindar de Java que cada plataforrna debe mantener. Los contenedores J2EE proporcionan una abstracci6n a nivel de semicio de 10s API. Corno resultado, el usuario puede acceder a 10s API de semicio tales como JDBC, JTS, JNDI, JMS, etc. dentro del contenedor, como si el contenedor subyacente 10s implernentara. U n contenedor en la arquitectura de J2EE proporciona una visidn consolidada de varios API de empresa especificados e n la plataforma J2EE. En JZEE, 10s componentes de aplicaci6n pueden acceder a estos API a travis de objetos apropiados creados y publicados en el semicio o implernentaci6n JNDI. Por ejemplo, cuando queremos utilizar JMS en nuestros cornponentes de aplicaci61-1,configuraremos nuestra plataforma JZEE para crear factorias de conexi6n JMS, colas de rnensajes y apartados, y publicar estos objetos en el semicio JNDI. Entonces nuestras aplicaciones pueden consultar el JNDI, obtener referencias para estos objetos, e invocar rnitodos. En este proceso, no importa si la plataforma JZEE tiene una implementaci6n JMS incorporada o si esti utilizando una soluci6n de software intermediario de mensajes de tercero. Consideremos de nuevo 10s applet de Java. Por ejemplo, si queremos reproducir un archivo de audio desde un applet, llamariamos a1 mitodo p l a y ( ) definido en el superclase ( ja v a .a p p l e t . A p p l e t ) , con un URL apuntando a1 archivo de audio. En este caso, la funcionalidad para reproducir archivosde audio es implementada por la superclase. Este es uno de 10s enfoques para la reutilizaci6n de c6digo. Una mejor alternativa a este enfoque es delegar esta funcionalidad en un componente cornfin. Es necesario que un
Plataforma J2EE componente de este tip0 no sea una parte de la misma jerarquia de herencia. Lo unico que se requiere es una referencia a un objeto que implemente esta funcionalidad. Una vez que nuestra aplicaci6n pueda obtener una referencia de este objeto, ~ o d e m o delegar s la funcionalidad "play" a ese objeto. Una importante ventaja de este enfoque es que permite que otros objetos procedentes de mis de una jerarquia de herencia accedan la funcionalidad "play". En el caso de aplicaciones distribuidas es mls complicado, ya que 10s servicios son remotos. S61o como analogia, consideremos el mismo componente de audio ejecutado como un servidor distinto. iC6mo obtenemos una referencia a este componente? La soluci6n es permitir a la plataforma J2EE crear el componente de audio y publicar su nombre en un servicio de designaci6n (es decir, en JNDI) disponible para su aplicaci6n. Esto proporciona un mitodo simplificado de acceso a 10s API de servicio. Tambiin nos permite acoplar diferentes implementaciones de estos servicios sin alterar las aplicaciones utilizando 10s semicios. El siguiente esquema ilustra esta posibilidad:
I
xy de Componente Aud~o Proceso Chente A
Buscar Proxy
-
r
--I
1
lmplementac~onde Componente Audlo Proceso de Serv~dorAudlo
,
Publ~carComponente Audlo
Observe la libre conexi6n entre la implementaci6n y el cliente. Siempre que la interfaz expuesta por el proxy se mantenga sin alterar, la implementaci6n puede ser modificada sin afectar el c6digo cliente. Esta es la forma mis adecuada de abstracci6n en el lado servidor, ya que no s61o utiliza delegaci6n en lugar de herencia, sino que tambiin reduce el acoplamiento. Todos 10s API de servicio J2EE utilizan el enfoque anterior para proporcionar semicios a las aplicaciones. Las siguientes son las implicaciones clave de este enfoque:
,i'
0
Como Gnico estindar que puede establecerse en una variedad de sistemas debases de datos existentes, sistemas de procesamiento de transacciones, servicios de designaci6n y directorio, etc., el API de servicio elimina la heterogeneidad inherente relacionada con la agrupaci6n de estas tecnologias en nuestras aplicaciones.
0
En J2EE, estos servicios tambiin estin integrados estrechamente en el modelo de programacibn. En proximos capitulos, veremos c6mo acceder a estos API sin interrupciones a partir de nuestros componentes de apkaci6n y clientes.
u
O La plataforma J2EE tambiin especifica un mecanismo uniforme para acceder a estos servicios.
Servicios declarativos Uno de 10s aspectos importantes de la arquitectura de J2EE es su capacidad para introducir servicios para componentes de aplicaci6n. Esti basado en declaraciones especificadas fuera de nuestros componentes de aplicaci6n. La arquitectura de J2EE proporciona medios sencillos de especificar tales declaraciones. Se denominan descriptores de implementacih.
Capitulo
1
j U n descriptor de implementaci6n define el contrato entre el contenedor y el componente. C o m o desarrolladores aplicaciones, debemos especificar u n descriptor de implementaci6n para cada grupo de componentes de aplicacibn. Por ejemplo, un conjunto de componentes EJB puede ser descrito conjuntamente en un dnico archivo de descriptor de implernentacion. De mod0 similar, en el caso de 10s contenedores Web, cada aplicacion Web debe tener un descriptor de implementaci6n especificado. Dependiendo del tip0 de componente, ciertos tipos de servicios (tales como transacciones, seguridad, etc) pueden ser especificados en el descriptor de implementaci6n. El prop6sito de este enfoque es minimizar la programaci6n de la aplicacion requerida con el fin de hacer uso de tales servicios. 7
!
;
.
/'El mitodo estindar de invocar servicios es mediante invocaci6n explicita. Por ejemplo, para implementar transacciones para el acceso a bases de datos, podemos empezar por programar una transacci6n antes de acceder a la base datos y realizar o deshacer la transacci6n una vez completados 10s mitodos de empresa. En el caso de invocaci6n declarativa, nuestros componentes de aplicaci6n no necesitan explicitamente empezar y detener transacciones. En su lugar, podemos especificar en el descriptor de implementaci6n que nuestros mitodos de empresa deben ser invocados en una nueva transaccibn. Basindose en esta informaci6n, el contenedor puede iniciar automlticamente una transaccion siempre que 10s mitodos de empresa de las aplicaciones del usuario Sean invocados. En terminos sencillos, u n servicio declarativo es u n servicio o acci6n realizado por el contenedor en nuestro nombre.
\.
I
i . {Como funciona este enfoque? Los contenedores J2EE son, por naturaleza, distribuidos y 10s componentes de la aplicaci6n son remotos a 10s clientes. Por consiguiente, las solicitudes a 10s componentes de aplicacion y las respuestas procedentes de 10s componentes de aplicaci6n tienen lugar en 10s limites del proceso, plataforma y red. Ademis, puesto que 10s componentes de aplicaci6n son mantenidos en el period0 de ejecuci6n del contenedor, el proceso del contenedor es responsable de recibir las solicitudes y de delegarlas a 10s componentes de aplicaci6n adecuados. Por ejemplo, en el caso del contenedor EJB, el contenedor recibe todas las solicitudes del cliente y las delega a 10s objetos EJB pertinentes implemtados en el contenedor. De un mod0 similar, en el caso de 10s contenedores Web, el contenedor Web recibe las solicitudes http y las delega en 10s servlets y en las piginas Web. El siguiente diagrama representa una visi6n simplificada de esta invocacibn. En esta figura, la interfaz remota es lo que utilizan 10s clientes para comunicarse con el EJB en el contenedor. Observe que el proceso del contenedor maneja todas las solicitudes y respuestas intercambiadas por 10s componentes de la aplicaci6n: m
a,
C
lnterfaz Remota
Este enfoque proporciona al contenedor la capacidad para interponer un nuevo servicio antes de +ransferir una solicitud a1 componente de aplicaci6n. En el caso de transacciones declarativas, el contenedor puede comenzar la transacci6n antes de delegar la solicitud entrante en la implicacidn de I mitodo de empresa y terminar la transacci6n tan pronto como vuelta a1 mitodo. -
Plataforma J2EE --
iCuil es la ventaja de este enfoque? Podemos interponer nuevos servicios sin cambiar el componente de aplicaci6n. Mis especificamente, esta funci6n nos permite posponer decisiones sobre tales servicios hasta el periodo de ejecucibn, en lugar del tiempo de disefio. En otras palabras, el contenedor puede reforzar selectivamente nuestros componentes basados en el descriptor de desarrollo. Para contenedores EJB, 10s servicios declarativos incluyen transacciones y seguridad. Ambos pueden ser especificados en descriptores de implementaci6n. En el caso de 10s contenedores Web, podemos especificar las funciones de seguridad requeridas para acceder a componentes en las aplicaciones Web.
Otros servicios de contenedor Los siguientes son algunos de 10s servicios de periodo de ejecucion que proporcionan 10s contenedores: Gesti6n de ciclo de vida de 10s componentes de aplicaci6n Esto conlleva la creation de nuevo ejernplares de componentes de aplicaci6n y su reserva o destrucci6n cuando 10s ejemplares ya no resulten necesarios. 0
Reserva de recursos Los contenedores pueden implementar opcionalmente reserva de recursos, como reserva de objetos o reserva de conexiones. Poblar el espacio de nombre de J N D I basado en el despliegue de nombres asociados a 10s componentes EJB Esta information es proporcionada normalmente en el tiempo de despliegue. Trataremos la implementaci6n en la siguiente secci6n. Poblar el espacio de nombre J N D I con objetos necesarios para utilizar 10s API de servicio del contenedor Algunos de 10s objetos incluyen objetos fuentes de datos para el acceso a bases de datos, colas y factorias de conexi6n de apartados para obtener conexiones con JMS y objetos de transacci6n de usuario para controlar transacciones programlticamente.
0
Agrupamiento En J2EE, 10s contenedores pueden ser distribuibles. U n contenedor distribuible consiste en un numero de JVM ejecutados en una o mls mlquinas anfitrionas. En esta configuraci6n,los componentes de aplicacion pueden ser desplegados en una serie de JVM. Dependiendo del tip0 de estrategia de equilibrio de carga, el contenedor puede distribuir la carga de solicitudes entrantes a una de estas JVM. La agrupacion es esencial para reforzar la reajustabilidad y disponibilidad de las aplicaciones.
Ahora que ya hemos cubierto la arquitectura de las aplicaciones J2EE, examinemos mis de cerca algunos de las diversas tecnologias incluidas en la plataforma J2EE.
Tecnologias JZEE Despuks de haber examinado toda la arquitectura de la plataforma J2EE, queremos ahora abarcar la colecci6n de tecnologias que proporcionan 10s rnecanismos que necesitarnos para construir amplias y distribuidas aplicaciones de empresa. Esta gran colecci6n, formada por tecnologias bastante dispares, puede ser clasificada segun su uso:
o Las tecnologias de componentes
Capitulo 1 Estas tecnologias son utilizadas para albergar la mayor parte de la aplicacibn: la 16gica de ernpresa. Existen tres tipos de cornponentes: piginas JSP, senlets y Enterprise JavaBeans; exarninarernos cada uno de ellos a continuation. 0 Las tecnologias de sewicios Estas tecnologias proporcionan 10s cornponentes de la aplicacion con senicios reforzados para que funcionen de un rnodo eficiente. 0 Las tecnologias de comunicaci6n Estas tecnologias, que son en su rnayoria transparentes para el programador de la aplicacion, proporcionan rnecanisrno para la comunicacion entre diferentes partes de la aplicacion, ya Sean locales o remotas.
Exarninemos a continuaci6n la clasificaci6n de API J2EE y sus tecnologias asociadas.
Tecnologias de componentes C o n cualquier aplicacion, el elernento mis irnportante es el rnodelado de la 16gica de ernpresa necesaria rnediante el uso de componentes o de unidades reusables en el nivel de aplicacion. Anteriormente en este capitulo, hemos descrito un contenedor corno un elernento que alberga el period0 de ejecucion para cornponentes de aplicaci6n, por lo que, aunque el contenedor pueda proveer rnuchos de 10s senicios y gran parte de la infraestructura de cornunicaci6n, es en ultirna instancia responsabilidad del agente de desarrollo crear 10s componentes de aplicacion. Sin embargo, estos cornponentes dependerin de su contenedor para rnuchos senicios, tales corno la gesti6n del ciclo de vida, el enhebrado (threading) y seguridad. Esto nos perrnite concentrarnos en proporcionar la funcionalidad de ernpresa indispensable sin entrar en detalles de sernintica de bajo nivel (nivel contenedor). La plataforrna J2EE ofrece tres tecnologias para el desarrollo de cornponentes. U n aspect0 que debe quedar claro es que la plataforma JZEE n o especifica que una aplicaci6n necesite hacer uso de 10s tres tipos de tecnologias de componentes; en muchos casos, utilizar EJB puede producir u n a sobrecarga.
Componentes Web Estos cornponentes pueden clasificarse corno cualquier otro cornponente que responda a una solicitud H H T P . Se puede realizar otra distincion rnis profunda basada en el contenedor anfitri6n para 10s cornponentes de la aplicacibn. Como ya hernos visto en este capitulo, 10s dos contenedores bisicos de lado del senidor son el contenedor Web y el contenedor EJB.
Sewlets Los sewlets son prograrnas de lado del servidor que perrniten a la bgica de aplicacion ser incorporada a1 proceso solicitud-respuesta HTTP. Los senlets proporcionan un rnedio de arnpliar la funcionalidad del senidor Web para adrnitir contenido dinirnico en HTML, XML, u otros lenguajes Web. Con el lanzarniento de J2EE 1.3, la especificaci6n de 10s Servlets ha alcanzado la versi6n 2.3. Trabajarernos con senlets en 10s Capitulos del5 a1 9.
Las Javasewer Pages (JSP) proporcionan un rnodo de incorporar cornponentes en una pigina y de hacer que realicen su funci6n para generar la pigina que seri enviada el cliente eventualrnente. Una pigina JSP
Plataforma J2EE contiene componentes HTML, cddigo Java y JavaBean. Las piginas JSP son de hecho una extensi6n del modelo de programaci6n del Servlet. Cuando un usuario solicita una pigina JSP, el contenedor Web compila la pigina JSP en un Servlet. El contenedor Web invoca a1 Servlet y devuelve el contenido resultante a1 navegador Web. Una vez que el Servlet ha sido compilado a partir de la pigina JSP, el contenedor Web puede simplemente devolver el servlet sin tener que recopilar cada vez. De este modo, las piginas JSP proporcionan un mecanismo de ensamblaje de piginas dinimico que se beneficia de las diversas ventajas de la plataforma Java. En comparacidn con 10s servlets, que son puro cddigo Java, las piginas JSP son mero documentos basados en texto hasta que el contenedor Web 10s compila en 10s correspondientes servlets. Esto permite una separacidn mis precisa entre la logica de aplicacidn y la 16gica de presentacidn. A su vez, permite a 10s desarrolladores de programas de aplicacidn centrarse en materias de empresa y a 10s disefiadores Web concentrarse en la presentacidn. Con la versidn actual de J2EE, la especificacidn JSP llega a la version 1.2. Los Capitulos 10 a 12 examinan en detalle las piginas JSP. Una arquitectura tipica para una aplicacidn Web que incluya piginas JSP tendria la siguiente estructura:
Navegado
Almacen de Datos
Componentes Enterprise JavaBean Enterprise JavaBean (EJB) 2.0 es un modelo de componente distribuido para el desarrollo de componentes sewros, reaiustables, transaccionales v multi-usuario. Para ex~resarlode un mod0 sencillo, son (ideilmente) ;nidades.de software reusables que contienen 16&a de empresa. Del mismo 10s mod0 que las piginas JSP permiten la separacidn entre la 16gica de aplicacidn y la 16gica de presentacidn, 10s EJB permiten la separacidn entre la 16gica de aplicaci6n y 10s servicios a escala del sistema, permitiendo asi a1 agente de desarrollo concentrarse en 10s temas de dominio de empresa y no programar el sistema. Estos objetos de empresa Enterprise Bean adoptan tres formas bisicas (una vez mas, no es necesario implementarlas todas): beans de sesion, beans de entidad y beans dirigidos por mensaje. Examinaremos 10s EJB en accidn en 10s Capitulos 14 a1 19.
GB
Beans de s d o n Los beans de sesidn se presentan en dos tipos. U n bean de sesi6n de estado es un objeto transitorio utilizado para representar la interaccion de cliente con el sistema; ejecuta la solicitud del cliente en la aplicacion, accediendo a la base de datos, etc. y cuando las operaciones del cliente estin completas es destruido (es decir, existe mientras dura la sesidn del cliente). U n ejemplo de este tip0 de bean es un cliente de aplicacion enviando una serie de solicitudes a una aplicacidn para llevar a cabo un proceso empresarial. En tales casos, un bean de sesi6n de estado puede registrar en estado de la interacci6n entre el cliente y la aplicacidn. La alternativa, un bean de sesion sin estado, no mantiene estado alguno entre las solicitudes del cliente. Generalmente, este tip0 de bean de sesi6n es utilizado para implementar un servicio especifico que no requiere el estado del cliente, por ejemplo, una simple actualizaci6n de base de datos.
Capitulo 1 Beans de entidad U n bean de entidad, por otro lado, es un objeto persistente que modela 10s datos contenidos en el almacen de datos, es decir, es un objeto envoltorio para 10s datos. Por ejemplo, datos sobre una pedido de compra pueden ser modelados utilizando un bean de entidad Purchaseorder que presente una vision agregada de todos 10s datos relacionados con dicho pedido. En comparaci6n con 10s beans de sesi61-1, que pueden ser utilizados por cualquier cliente, muchos clientes pueden acceder a 10s beans de entidad per0 deben mantener una iinica identidad a travks de una clave primaria. De hecho, en la arquitectura del contenedor J2EE podemos elegir entre tener el estado persistente del bean de entidad gestionado por el contenedor o implementarlo "a mano" en el mismo bean. Beans dirigldos por mensaje Los beans dirigidos por mensaje son una clase especial de EJB que no estin destinados a la invocaci6n directa de cliente. El objetivo de 10s beans dirigidos por mensaje es procesar 10s mensajes recibidos via JMS. Los beans dirigidos por mensaje complementan la naturaleza asincrona de JMS proporcionando un medio de procesamiento de mensajes dentro del contenedor EJB. Cuando un cliente de aplicaci6n o una aplicaci6n envia un mensaje via JMS, el contenedor invoca a1 bean dirigido por mensaje adecuado para procesar el mensaje.
e para C o m o ya hemos mencionado en nuestro anilisis anterior, J2EE 1.3 incluye el API JAXP. ~ s t sirve abstraer el parseado XML y 10s API de traducci6n XML. Ademis, hay otros API de Java relacionados con XML que estin siendo desarrollados en la actualidad. Puede encontrar un resumen sobre el tema y mis detalles en la direccidn http://java.sun.com/xml. XML (Extensive Markup Language) influye en c6mo percibimos, procesamos, transportamos y gestionamos datos. XML es un lenguaje autodescriptivo con el que puede enviar datos asi como metadatos. En 10s sistemas de empresa de hoy dia, XML es utilizado para representar datos de empresa tanto en el interior como a travks de aplicaciones. U n o de 10s puntos fuertes de XML es la c o m h utilizaci6n de estos "vocabularios", todos ellos con la misma sintaxis bisica, 10s rnismos analizadores y otras herramientas. Los vocabularios XML compartidos proporcionan mis ficilmente documentos de bkqueda y bases de datos, y un mod0 de intercambiar informaci6n entre diferentes organizaciones y aplicaciones informiticas. Sin embargo, XML puede ser mucho mis que un mecanismo de descripcih: 0 Transformaci6n de
XML
La transformacibn permite al programador copiar un documento XML en una determinada forma basindose en una serie de reglas. Las transformaciones son utilizadas para traducir vocabularios XML similares asi como traducir documentos XML en otros formatos de archivos de base textual como valores delimitados por comas. Este es el tip0 de representaci6n estindar de datos en una empresa. 0 XML y bases de datos
Aunque el modelo de datos XML es inherentemente jerirquico mientras que las bases de datos son esencialmente relacionales (creando algunas dificultades de copia), proporciona un mecanismo de integraci6n de datos existentes en nuevos sistemas. Muchos distribuidores de bases de datos estin afiadiendo en la actualidad funione XML en sus sistemas al reconocer que 10s programadores necesitan recursos para interfacear XML y bases de datos. 0
Comunicaci6n entre servidores
Plataforma J2EE Las aplicaciones complejas de empresa utilizan a menudo software de servidor distintos ejecutados y distribuidos en diversas tecnologias de procesamiento. XML proporciona una capa de abstracci6n para integrar estos sistemas similares. CML puede obtenerse de un servidor, ser manipulado y despuks enviado a otro servidor de tal modo que pueda comprender la solicitud. Aunque no abarcaremos explicitamente XML en este libro, apareceri cuando creemos varios descriptores de implementaci6n J2EE. Para mis informacidn sobre el uso de XML con Java, puede consultar Profesioonf Java y X M L y Referencia para Programadores Java y XML.
Tecnologias de servicio Como ya hemos visto, algunos de 10s servicios de J2EE para componentes de aplicaci6n son gestionados por 10s mismo contenedores, permitiendo asi a1 agente de desarrollo concentrarse en la 16gica de empresa. Sin embargo, en ocasiones 10s desarrolladores de programas considerarin necesario invocar ellos mismos programiticamente algunos semicios utilizando algunas de las diversas tecnologias de servicio.
Aunque todos 10s accesos a 10s datos deberian ser accesibles a travks de un h i c o API estindar de la arquitectura de Conector en el futuro, la conectividad de bases de datos es probablemente uno de 10s servicios clave que 10s desarrolladores de programas implementan en su componente de aplicaci6n. El API JDBC (siglas no oficiales para Java Database Connectivity) proporciona a1 agente de desarrollo la capacidad de conectar con sistemas de bases de datos relacionales. Como veremos en el capitulo 4, permite las consultas transaccionales, la recuperacidn y la manipulacidn de datos desde una base de datos que se ajuste a JDBC. Por el momento, merece la pena destacar que J2EE afiade una extensidn a1 nGcleo API JDBC (que esti incorporado en J2SE) para ofrecer caracteristicas avanzadas, como reserva de conexiones y transacciones distribuidas.
Java Transaction API y Servicio El API Java Transaction (JTA) es un medio para trabajar con transacciones y con transacciones especialmente distribuidas independientes de la implementacidn del gestor de transacciones (elJava Transaction Service (JTS)). En la plataforma J2EE, las transacciones distribuidas estin consideradas generalmente como transacciones controladas por contenedor; por ello, nosotros, como desarrolladores de programas, no deberiamos estar preocupados por las transacciones entre componentes. Sin embargo, el modelo de transaccidn de J2EE es todavia algo limitado y en ocasiones puede que tengamos que realizar el trabajo duro.
La funcidn del API Java Naming and Directory Interface (JNDI) en la plataforma J2EE es doble: 0 En primer lugar,.proporciona 10s medios para ejecutar operaciones estindar en un recurso de servicio directorlo como LDAP, Novel1 Directory Services o Netscape Directory Services. 0 En segundo lugar, una apkaci6n J2EE utiliza J N D I para buscar interfaces utilizadas para crear, entre otras cosas, EJB y conexiones JDBC.
En el pr6ximo capitulo, veremos cdmo utilizar J N D I para acceder a un recurso de servicio directorio.
Capitulo 1 JMS En el entorno de ernpresa, puede que 10s diversos cornponentes distribuidos no estkn siernpre en constante contact0 entre si. Por lo tanto, es necesario que haya algGn rnecanisrno de envio de datos de rnodo asincrono. El Java Message Service UMS) proporciona exactarnente esta funcionalidad para enviar y recibir rnensajes rnediante el uso de software interrnediario orientado al rnensaje.
JavaMail JavaMail es un API que puede ser utilizado para abstraer instalaciones para enviar y recibir e-mail. JavaMail se ajusta a 10s protocolos de correo rnis utilizados en Internet corno IMAP4, POP3 y SMTP, per0 en comparaci6n con JMS es rnis lento y rnenos fiable.
Java Conector Architecture Java Connector Architecture UCA), presentado en la versi6n 1.3, es un rnedio estandarizado por el que las aplicaciones J2EE pueden acceder a una variedad de aplicaciones legadas, norrnalrnente sisternas Enterprise Resource Planning (ERP) corno SAP R/3 y Peoplesoft. La especificaci6n del Conector define una sencilla arquitectura en la que 10s distribuidores de servidores de aplicaci6n J2EE y sistemas legados colaboran para producir cornponentes "plug-and-play" que nos perrnitan acceder al sisterna legado sin tener que tener conocirnientos rnuy especificos sobre c6rno trabajar con 61.
JAAS El servicio Java Authentication a n d Authorization Service proporciona un rnedio para conceder perrnisos basado en q u i h ejecuta el c6digo. JAAS utiliza una arquitectura conectable de rn6dulos de autentificaci6n de mod0 que el usuario pueda introducir rn6dulos basados en diferentes irnplernentaciones de autentificacibn, corno Kerberos o PKI (Public Key Infrastructure).
Tecnologias de comunicacion El Gltirno grupo de tecnologias esti forrnado por las tecnologias que proporcionan 10s rnedios para 10s diversos cornponentes y servicios de la aplicaci6n J2EE para su cornunicaci6n entre si; una aplicaci6n distribuida seria bastante ineficaz si estas tecnologias no proporcionaran el "pegarnento" para unir todos 10s elernentos.
Protocolos de Internet Mientras hablarnos de aplicaciones de n-niveles en este libro, nuestro cliente seri rnuy a menudo un navegador potencialrnente situado en cualquier lugar del mundo. Las solicitudes de un cliente y las respuestas de un servidor se cornunican a travks de tres protocolos principales. HTTP H T T P o Hypertext Transfer Protocol es un protocolo genCrico, sin estado, de nivel aplicaci6n, que tiene muchos usos rnis alli de sus sencillas capacidades corno hipertexto. Funciona sobre una base solicitud/ respuesta. U n cliente envia una solicitud al servidor en forrna de mktodo de solicitud, URI (Uniform Resource Identifier) y versi6n de protocolo, seguido por un rnensaje tipo MIME que contiene rnodificadores de solicitud, inforrnaci6n del cliente y posible contenido de cuerpo en una conexi6n con un
Plataforma J2EE senidor. El servidor a su vez responde con una linea de estado seguida por un mensaje de tipo MIME que contiene informaci6n del servidor, informaci6n meta de entidad y posible contenido entidad-cuerpo.
T C P (Transmisi6n Control P ~ o t o c o l )sobre I P (Internet Protocol) son realmente dos protocolos distintos, que se combinan normalmente en una unica entidad. I P es el protocolo responsable de asegurar que 10s datos son recibidos en ambos extremos de la comunicaci6n a traves de Internet. Cuando tecleamos la direcci6n de un sitio Web en nuestro navegador, el protocolo I P certifica nuestras solicitudes y qu el cumplimiento de esas solicitudes Ilegan hasta su destino. Para mayor eficiencia, 10s datos que son enviados y recibidos entre un cliente y un servidor Web son descompuestos en varias piezas o paquetes. N o todos estos paquetes tienen que tomar la misma ruta a1 ser enviados entre el cliente y el servidor Web. T C P es el protocolo que registra 10s paquetes y certifica que son reunidos en el mismo orden en el que fueron divididos y sin errores. Por lo tanto, T C P y I P trabajan juntos para mover datos en Internet. Por este motivo, casi siempre veremos estos dos protocolos combinados en TCP/IP.
Secure Sockets Layer (SSL) utiliza la criptografia para cifrar el flujo de informaci6n entre el cliente y el servidor. Tambien proporciona un medio para que ambas partes puedan autentificarse entre si. Secure http (HTTPS) se distingue normalmente del http corriente sin cifrar a1 ser servido en diferente numero de puerto (443, por defecto).
Protocolos de objeto remoto En aplicaciones donde 10s componentes se distribuyen normalmente en diferentes niveles y servidores, se requieren algunos mecanismos para utilizar 10s componentes de forma remota, preferiblemente dejando que el cliente ignore que el componente no es local respecto a si mismo. RMl y RMI-IIOP
Remote Meted Invocation (RMI) es uno de 10s mecanismos primarios en las aplicaciones de objetos distribuidos. Nos permite utilizar interfaces para definir objetos remotos. Podemos entonces llamar a metodos en estos objetos remotos como si fueran locales. Los mecanismos de transporte utilizados dependen de cada implementaci6n. Por ejemplo, Sun utiliza Java Remote Meted Protocol (JRMP) sobre TCP/IP, pero otras implementaciones, como BEA WebLogic, por ejemplo, tienen su propio protocolo. RMI-IIOP es una extensi6n de RMI per0 en I I O P (Inter.-ORB Protocol), que nos permite definir una interfaz remota a cualquier objeto remoto que pueda ser implementado en cualquier lenguaje que se ajuste a la asociaci6n O M G y ORB. En el capitulo 3, examinaremos con detenimiento c6mo escribir aplicaciones distribuidas con RMI.
Mediante el uso de JavaIDL, un cliente Java puede invocar llamadas de metodo en objetos CORBA. Estos objetos CORBA no necesitan ser escritos en Java sino implementar meramente una interfaz IDL definida.
Desarrollo de aplicaciones JZEE La especificacidn J2EE concreta 10s siguientes pasos en el proceso de desarrollo y despliegue de aplicaciones.
I. Desarrollo de componentes de aplicaci6n
Durante este paso modelamos las reglas de la empresa en forma de componentes de aplicacion. 2.
Composicion de componentes de aplicaci6n en modulos En este paso, 10s componentes de aplicacion son empaquetados en m6dulos. Esta fase tambikn conlleva proporcionar descriptores de implementaci6n para cada m6dulo.
3. Composici6n de m6dulos e n aplicaciones
Este paso integra mfiltiples m6dulos en aplicaciones J2EE. Requiere ensamblar uno o mis m6dulos en una aplicaci6n J2EE y facilitarle 10s archivos de descriptor. 4.
Despliegue de aplicaci6n En el paso final, la aplicaci6n empaquetada es realmente desplegada e instalada en el sewidor(es) de aplicaci6n de la plataforma J2EE.
La plataforma JZEE especifica mdtiples niveles para empaquetado, adaptacidn, e instalacidn. El empaquetado es el proceso de componer aplicaciones a partir de componentes de aplicaciones. J2EE especifica u n plan de empaquetado de tres niveles para componer componentes en aplicaciones. Estos son: componentes de aplicacidn, mo'dulos y aplicaciones. iCuLl es el prop6sito de estas fases para el desarrollo e implementaci6n de aplicaciones? En J2EE, la arquitectura de aplicaciones emeieza con la descomposici6n de la aplicaci6n en m6dulos y de 10s m6dulos en componentes de aplicacion. Este es un proceso descendente hacia la construcci6n de 10s bloques de construcci6n mis pequefios. La noci6n de empaquetado y despliegue de aplicaci6n en niveles mfiltiples intenta conseguir este prop6sito. En este proceso, componemos componentes de aplicaci6n de grano fino en m6dulos y despuks 10s modulos en aplicaciones.
Funciones de desarrollo e implernentacion de aplicaciones Antes de pasar a examinar detenidamente el proceso de desarrollo e irnplementaci611, desvikmonos momentineamente para analizar quikn deberia hacer quk. La especificaci6n J2EE, ademis de definir un - proceso, tambikn define una serie de funciones en el desarrollo de aplicaciones J2EE: 0
Proveedor del product0 J2EE El Proveedor del prodycto J2EE proporciona la plataforma base J2EE sobre la cual desarrollamos nuestras aplicaciones. Este seri nuestro distribuidor de sewidor que implementa la arquitectura del contenedor y 10s API son definidos por la especificaci6n JZEE.
CI Proveedor de componente de aplicaci6n Es esencialmente el agente de desarrollo de la aplicaci6n quien crea la funcionalidad de la aplicaci6n, aunque es posible subdividir la funci6n en ireas especificas de conocimientos tkcnicos, por ejemplo, agente de desarrollo de Web, agente de desarrollo de EJB, etc. 0
Ensamblador de aplicaciones C o m o veremos en breve, el ensamblador de aplicaciones toma 10s componentes de aplicaci6n y 10s empaqueta a travks de una serie de m6dulos y archivos de descriptores de mod0 que puedan ser implementados a 10s sewidores de producci6n. Desplegador El desplegador toma la aplicaci6n empaquetada, la instala y la configura para el entorno particular de operaci6n en el que seri ejecutada la aplicacibn.
Plataforma J2EE 0
Administrador del sistema El Administrador del sistema es responsable de mantener y administrar la aplicaci6n una vez que ya ha sido implernentada.
0
Proveedor de herramientas El Proveedor de Herramientas proporciona las herramientas que pueden ser de uso en el desarrollo e implernentaci6n de 10s componentes de aplicaci6n.
Observe que esta clasificacio'n de funciones puede ajustarse o no a su aplicacio'n espec$ca y esta clas2ficacidn sdlo deberia considerarse una configuracidn tt'pica que puede servir corno guia.
,Desarrollo de componentes de aplicacion En J2EE, el proceso de desarrollo cornienza con el disefio y el desarrollo de componentes de aplicaci6n. La mayor parte de este libro versari sobre este tema, por lo que no es necesario que profundicemos en ello aqui.
;Composition de componentes de aplicacion en modulos U n m6dulo es utilizado para ernpaquetar uno o rnis cornponentes de aplicaci6n relacionados del misrno tipo. Ademis de 10s cornponentes de aplicaci6n, cada rn6dulo incluye un descriptor de irnplementaci6n que describe la estructura del rn6dulo. Hay tres tipos de rn6dulos en J2EE: A
'
.
0
M6dulos Web U n m6dulo Web es una unidad desplegable compuesta de Senlets de Java, piginas JSP, bibiliotecas de etiquetas, archivos JAR de biblioteca, docurnentos HTML/XML y otros recursos publicos tales corno irnigenes, archivos de clase applet, etc. U n rn6dulo Web es ernpaquetado en un archivo Web Archive, tarnbih conocido corno archivo WAR. U n archivo WAR es similar a un archivo JAR; la diferencia radica en que el archivo WAR contiene un directorio WEB- I N F con la descripci6n de irnplernentaci6n contenida en un archivo Web. x m l . Conoceremos mis detalles de 10s rnbdulos Web y su empaquetado en pr6xirnos capitulos.
0
Modulos EJB U n rn6dulo EJB es una unidad desplegable cornupuesta de un EJB, asociado a archivos JAR de biblioteca y recursos. Los rn6dulos EJB estin ernpaquetados en archivos JAR, con un descriptor - archivo JAR. de implernentaci6n (e j b- j a r .x m l ) en el d i r e c t o r i o ~ I~N~F ~del
0
M6dulos Java U n rn6dulo Java es un grupo de clases de cliente Java empaquetados en archivos JAR. El descriptor de irnplernentaci6n para un rn6dulo Java es un archivo a p p l i c a t i o n - c l i e n t .x m l .
Composicion de modulos en aplicaciones El nivel rnis alto de ernpaquetado esti en forrna de aplicaciones. Cada aplicaci6n J2EE es una unidad independiente de c6digo dentro de un caj6n virtual propio. Norrnalrnente, 10s contenedores J2EE cargan cada aplicaci6n utilizando un cargador de clase diferente de rnodo que cada aplicaci6n queda aislada del
Capitulo 1 resto. El objetivo de este aislamiento es permitir a las multiples aplicaciones JZEE coexistir en un contenedor JZEE. Una aplicaci6n JZEE consiste en uno o mds mddulos compuestos en un archivo Enterprise Archive (EAR). U n archivo EAR es similar a un archivo "TAR;. la diferencia es que el primer0 contiene un archivo a p p l i c a t i o n . xml (situado en el d i r e c t o r i o ~ INF) ~ ~ ~ que - describe la aplicacibn:
iCudl es la funcidn de 10s mdtiples archivos de descriptor en la figura anterior? Los componentes de aplicaci6n de menor tamafio pueden ser adaptados mientras son integrados en m6dulos. Esto requiere el uso de un descriptor de implementacidn en un mddulo. Sin embargo, no toda la informacidn relacionada con la implementaci6n final sobre una plataforma JZEE estard disponible en el momento del ensamblado de m6dulos. Ademis, necesitamos medios para especificar quk m6dulos componen la aplicacidn. La ventaja de esta estructura es que permite la reutilizaci6n a diferentes niveles. Los componentes de aplicaci6n pueden ser reusados en miiltiples mddulos Web. Por ejemplo, 10s componentes Web relacionados con el registro de usuario pueden ser empaquetados en diferentes m6dulos Web responsables de 10s servicios de pedido y de compra on-line. De un mod0 similar, 10s mddulos pueden ser reusados en multiples aplicaciones de mod0 que un m6dulo EJB para la gesti6n del carro de la compra n o necesita ser restringido a una Gnica apkaci6n, sino que puede ser empaquetado en mdtiples aplicaciones de comercio on-line.
Sin estos medios de empaquetado reusables, el objetivo de la reutilizacidn de componentes d o se alcanzaria parcialmente. A1 definir la estructura anterior, J2EE permite una reutilizacidn mris refinada de 10s componentes de aplicacidn.
Implementation de la aplicacion Finalmente, la implementaci6n de aplicacidn es el proceso de instalacidn y adaptaci6n de 10s m6dulos empaquetados sobre la plataforma JZEE. Este proceso conlleva dos pasos: 0
Preparar la aplicaci6n para su instalaci6n sobre un servidor de aplicacidn JZEE. Esto conlleva copiar 10s archivos EAR sobre el servidor de aplicaci6n, generando clases de implementaci6n adicionales con la ayuda del contenedor, e instalar finalmente la aplicaci6n sobre el servidor.
Plataforma J2EE O Configurar la aplicaci6n con la inforrnaci6n de la aplicaci6n especifica del senidor. U n ejernplo seria la creacion de fuentes de datos y factorias de conexiones, ya que la creaci6n real de estos objetos es especifica del senidor de aplicaci6n.
En estos rnomentos deberia tener una idea rnis cornpleta de la tipologia del paisaje J2EE. En particular, hernos visto c6rno J2EE arnplia la arquitectura multi-nivel tradicional de procesarniento distribuido para incluir el concept0 de contenedores. Hernos exarninado las partes constituyentes de esta arquitectura de contenedor, con relaci6n a:
O El contrato de cornponentes O Senicios de contenedor
o Senicios declarativos O Otras instalaciones de periodo de ejecuci6n Los siguientes son 10s puntos clave de este examen: O J2EE es una arquitectura centrada en el contenedor. U n contenedor en rnis que un simple periodo
de ejecuci6n: proporciona varios niveles de abstracci6n. En pr6xirnos capitulos, exarninaremos como estas abstracciones sirnplifican la irnpelernentaci6n de aplicaciones. O J2EE reconoce la necesidad de cornponer 10s cornponentes en rn6dulos y rnodulos en aplicaciones.
Es un intento de normalizar la reutilizaci6n de cornponentes de aplicaci6n y m6dulos.
O J2EE representa un enfoque rnuy intuitive para construir aplicaciones. Mientras que el proceso de disefio es descendente, el proceso de irnplernentaci6n es ascendente y es un proceso de composici6n, que cornpone rn6dulos a partir de cornponentes y aplicaciones a partir de rn6dulos. Despues de concluir nuestro anilisis introductorio de la perspectiva de J2EE de la prograrnaci6n Java de lado senidor, cornenzarernos un recorrido detallado examinando de cerca la b6squeda de senicios utilizando JNDI.
Servicios de directorio y JNDI Las interfaces J N D I (Java Naming and Directory Services Interfaces) estin disefiadas para simplificar el acceso a la infraestructura de directorio utilizada en el desarrollo de aplicaciones de redes avanzadas. Los directorios son un tip0 especial de bases de datos que proporcionan ripido acceso a sus almacenes de datos. Las bases de datos son consideradas normalmente el modelo relational de almacCn de datos por excelencia, como Oracle, Microsoft SQL Server, etc. En contraste con esto, una base de datos de directorio almacena informaci6n de forma jerirquica y optimizada para la lectura. Normalmente, hemos tenido que utilizar diferentes API para acceder a distintos servicios de directorio, como el servicio de informaci6n de Sun Network Information Service (NIS) o Lightweight Directory Access Protocol (LDPA). Sin embargo, J N D I proporciona un API estindar para acceder a cualquier tipo de directorio. J N D I tambiCn nos permite almacenar y recuperar objetos Java en la red, por ejemplo, del servidor de aplicaci6n adaptado a J2EE, como BEA WebLogic. En este capitulo, responderemos a las siguientes preguntas: 0
iQuC es un servicio de directorio?
0
iQue distingue a J N D I de un API de directorio tradicional!
0
iQuC es LDPA y c6mo lo utilizamos para trabajar con un servicio de directorio?
Ademis, examinando algunos programas de ejemplo, demostraremos de primera mano las aplicaciones pricticas del uso de J N D I para gestionar la informaci6n del directorio.
Servicios de designacion y de directorio "La red es el ordenador" es una frase que Sun Microsystems ha utilizado para vender sus productos de software y hardware. Es tambikn el dogma de la exitosa programaci6n Java. Una de las razones por las que Java es tan popular es porque ha conseguido que la programaci6n de redes sea mis ficil que con otros
Capitulo 2 lenguajes, como con C. Esto se debe a que Java es mucho mis que una especificaci6n de lenguaje. Java incorporada 10s sistemas de redes en su API central, mientras que lenguajes tales como C requieren una bibilioteca externa para reproducir la misma funcionalidad. Las funciones de red que incorpora Java garantiza el Cxito de este leguaje debido a que el numero de ordenadores conectados que utilizan 10s protocolos estindar de Internet ha crecido a un ritmo excepcional. Los dispositivos se situan normalmente en una red para facilitar su gesti61-1, ahorrando tiempo y, a su vez, dinero. Por ejemplo, en un complejo de edificios un sistema medioambiental en red puede informar a un servidor central. Este servidor puede informar sobre el estado de todos 10s sistemas de aire acondicionado y termostatos de 10s diferentes edificios a 10s ingenieros medioambientales. Desde esta fuente central, 10s ingenieros pueden saber cuindo una unidad se esti sobrecalentando, o cuindo deben planificar 10s servicios de mantenimiento. Si el sistema medioambiental no estuviera conectado en red, 10s miembros del equipo tendrian que comprobar cada dispositivo de forma individual, lo que supondria una tarea laboriosa y larga cuando se tratara de docenas de edificios. Por supuesto, aunque tenemos dispositivos en red y un gran lenguaje de desarrollo como Java, puede resultar dificil combinarlos de un mod0 efectivo. Siempre que se afiade un dispositivo a la red, la informaci6n de configuraci6n debe ser adaptada. Esta informaci6n de configuraci6n incluye propiedades tales como una direcci6n IP, un nombre de dominio, las prestaciones de cada dispositivo de red y 10s privilegios de usuario para cada dispositivo. Esta informaci6n esta disponible normalmente para el dispositivo mismo, per0 no siempre lo esti para el mundo exterior. Por ejemplo, cuando establecemos una nueva estaci6n de trabajo en la red, con frecuencia necesitamos configurarla para utilizar una impresora de red especifica. A menudo no es posible descubrir las funciones de las impresoras que estin disponibles, porque las impresoras no ofrecen esta informaci6n. Utilizando el servicio de directorio y Java, las prestaciones y la configuraci6n de la impresora pueden ser incorporadas a la red. Los dispositivos pueden consultar a la impresora para descubrir, por ejemplo, si puede imprimir en color. Los disefiadores del entorno J2EE y sus API comprenden estos problemas. Por este motivo, el API Java Naming and Directory Interfaces (JNDI) se convirti6 en una parte fundamental de J2EE. Descubriri que pricticamente todas las aplicaciones J2EE utilizan J N D I en algun momento. Para entender J N D I , necesitamos una comprensi6n bisica de lo que es un servicio de designaci6n y directorio. TambiCn necesitamos comprender por quC es importante que J N D I proporcione una interfaz normalizada para estos servicios.
Servicios de designacion Un servicio de designaci6n es un servicio que permite la creaci6n de un nombre estdndar para un conjunto determinado de datos. En Internet, cada host tiene un nombre de dominio completo y cualificado, Fully Qualified Domain Name (FQDN), como www.wrox.com o www.coe.unt.edu. U n F Q D N se construye a partir de un hostname, cero o mis nombres de subdominio, y un nombre de dominio. Por ejemplo: -
Hostname www.coe.unt.edu
-
-
Subdominio
www
coe
www.wrox.com
www
-
www.p2p.wrox.com
www
P ~ P
I
Dominio
Servicios de directorio y JNDl Cada F Q D N es unico, lo que significa que s61o se permite un www.wrox.com y un www.coe.unt.edu. Utilizando nombres de subdominios y de dominios, 10s sistemas que comparten el mismo nombre de anfitri6n siguen considedndose entidades separadas. Por ejemplo, www.p2p.wrox.com es diferente de www.wrox.com. En este caso, el subdominio p2p.wrox.com esti realmente por debajo del dominio raiz de wrox.com obteniendo su nombre de espacio hnico.
Servicios de directorio Un servicio de directorio es un tip0 especial de base de datos optimizado para acceso de lectura utilizando varias ticnicas de indizaci6n, almacenamiento en memoria y acceso a disco. La informaci6n contenida en un servicio de directorio se describe utilizando un modelo de informaci6n jerirquica. El modelo de inforrnacion jerirquica que emplean 10s servicios de directorio contrasta con el modelo de informaci6n relacional empleado por las bases de datos, como Oracle y Microsoft SQL Server, que estin creadas para manejar transacciones. Una operaci6n sblo se realiza con kxito si un conjunto de operaciones rnis pequeiias son realizadas con kxito. U n servicio de directorio tambikn es diseiiado normalmente de mod0 que pueda ser distribuido y copiado. U n s e ~ c i de o directorio siempre t e n d d un servicio de designacibn, per0 un servicio de designaci6n no siempre tiene un servicio de directorio. U n ejemplo sencillo de un servicio de directorio es un listin telef6nico. U n listin telef6nico permite a1 usuario encontrar ripidamente el nhmero de tekfono de una persona, siempre que el usuario conozca el nombre de la persona cuyo numero esti buscando. Si nos quedamos un momento con este ejemplo, podemos subrayar 10s beneficios de 10s servicios de directorio en red. Es decir, un servicio de directorio s61o es tan Gtil como la actualidad de su informacidn y la eficacia de realizar una busqueda. Los recursos estiticos, tales como copias fisicas de listines telef6nicos, guias de televisi6n, etc., se tornan obsoletas poco despuks de ser publicadas y norrnalmente s610 ofrecen un medio de acceso (por ejernplo, rnediante el "apellido" en el caso de un listin telef6nico). U n servicio de directorio electr6nic0, por otro lado, es claramente rnis dinimico y permite mucha rnis flexibilidad de bhsqueda. La informaci6n que se recibe probablemente estk actualizada en el momento de la
consults. Existen rnuchos servicios de directorio (y seudo-directorio) en uso en las redes en la actualidad. U n servicio de directorio muy utilizado es el Domain Naming Service (DNS) utilizado en Internet. D N S acepta u n F Q D N y devuelve una direccidn IP. Este servicio es esencial para Internet ya que una comunicaci6n eficaz entre dos ordenadores confia en que cada sistema conoce la direcci6n I P del otro. Las direcciones I P consisten en la actualidad en 32 bit, por ejemplo 198.137.24 0.92, mientras que un hostname toma la forrna www.wrox.com. Los ordenadores estin acostumbrados a tratar con nhmeros, per0 la mayoria de 10s humanos son rnis diestros a la hora de recordar nombres (es mucho rnis ficil recordar www.wrox.com que recordar 198.137.24 0. 92). El sistema D N S es un ejemplo de un servicio de directorio altamente especializado. Cuando introducimos el hostname en un navegador, el ordenador obtiene la direcci6n I P del servidor via DNS. Analizaremos rnis detenidamente el lado prictico del sistema DNS con un ejernplo en partes posteriores del capitulo.
DNS nos proporciona en realidad algo ma's que direcciones ZP. Por ejemplo, 10s nombres de las ma'quinas responsables de encaminamiento de correo, pero sigue siendo rnuy especializado en sus funciones.
Las organizaciones a rnenudo utilizan uno o rnis de 10s siguientes servicios de directorio de prop6sito general: 0
Novell Directory Services (NDS)
0 Network Information Services (NIS/NIS+) 0
Active Directory Services (ADS)
0 Windows N T Domains
Aunque el Semicio N T Domains no es un verdadero servicio de directorio, son muchos 10s que intentan utilizarlo corno tal. Cada uno de estos servicios de directorio proporciona rnis inforrnaci6n que la simple copia del nornbre de I P que obtenernos de DNS. Cada servicio de directorio tarnbikn perrnite que inforrnaci6n sobre usuarios sea alrnacenada (nornbres de usuario y contrasefias), grupos de usuario (para control de acceso) y ordenadores (ethernet y direcciones IP). NDS y ADS albergan rnis funciones (corno la localizaci6n de irnpresoras de red y software) que NIS o N T Domains. Corno hay tantos servicios de directorio (cada uno con su protocolo) y corno tenernos tantos sisternas en nuestras redes, han surgido algunos problernas irnportantes. En esencia, se reducen a dos ternas clave: 0 Mantener un registro de usuarios. 0 Mantener un registro de recursos de red corno ordenadores e irnpresoras.
U n rnarco particularrnente dificil seria aquel en el que 10s usuarios necesitarian acceder a: 0 U n sisterna Novell (que utilice NDS) para uso cornGn de archivos e irnpresi6n. 0
Una cuenta en una unidad Windows N T para ejecutar Microsoft Office.
0
Una cuenta en una unidad U N ~ X(utilizando NIS) para hacer uso del e-rnail y publicar piginas Web.
Por desgracia para 10s gestores de red, ninguno de estos servicios de directorio puede interactuar ficilrnente entre si, lo que dificulta bastante a1 desarrollador de aplicaciones tradicionales interactuar con varios servicios de directorio diferentes. Corno consecuencia, 10s usuarios suelen tener a1 final diferentes nornbres de usuario y contrasefias para cada sisterna. Si un usuario se da de baja, puede resultar dificil asegurar que todas sus cuentas son elirninadas. Los vacios de seguridad tienen h g a r en forrna de cuentas "huerfanas", que son cuentas que pertenecen a usuarios que ya no estin en una organizaci6r1, aunque todavia tienen libre acceso a 10s sisternas. Una soluci6n a estos problernas es utilizar JNDI, que proporciona un API estindar para una variedad de servicios de directorio. Sin embargo, debido a que no todo el rnundo utiliza Java, es necesario que exista otro rnodo de facilitar la cornunicaci6n de inforrnaci6n de directorio entre sisternas.
EL protocolo Lightweight Directory Access Protocol (LDAP) fue desarrollado a principios de 10s afios noventa corno protocolo de directorio estindar. LDAP es ahora probablernente el protocolo de directorio rnis popular y, debido a que J N D I puede acceder a LDAP, invertirernos algGn tiernpo en aprender corno aprovechar LDAP para rnejorar las aplicaciones Java con JNDI.
LDAP puede remontar su origen a1 protocolo X.500 (tambibn conocido corno "Heavy" Directory Access Protocol), que estaba originalmente basado en 10s protocolos de red O S I (un primer "competidor" de 10s protocolos de Internet).
Servicios de directorio y JNDl El usuario interactuari a rnenudo con un servidor que ha sido especificarnente construido para LDAP, corno es el caso de iPlanet Directory Server. Sin embargo, LDAP puede ser enfrentado a cualquier tip0 de alrnactn de datos. Por ello, 10s servicios de directorio de mayor aceptaci6n cuentan en la actualidad con un frontal LDAP de algdn tipo que incluye NIS, NDS, Active Directory e incluso Windows N T Domains. LDAP define c6mo 10s clientes deben acceder a 10s datos e n el servidor. Sin embargo, n o especifica c6mo deben ser almacenados 10s datos en el sewidor.
Los datos en LDAP estin organizados en forrna de irbol jerirquico, llarnado Directory Information Tree (DIT), o Arbol de Inforrnaci6n de Directorio. Cada "hoja" del DIT es conocida corno una entrada y la prirnera entrada en un DIT se denornina entrada raiz. Una entrada cornprende un Distinguished Name (DN), o Nornbre Diferenciado, y cualquier nurnero de pares de valor atributo. El D N es el nornbre de una entrada y debe ser unico, igual que la clave Bnica de una tabla de base de datos relational. U n D N rnuestra c6rno la entrada esta relacionada con el resto del DIT, igual que el nornbre de la ruta de un archivo rnuestra c6rno tste se relaciona con el resto de 10s archivos de un sisterna. La ruta hacia un archivo en un sisterna se lee de izquierda a derecha a la hora de leer desde la raiz a1 archivo. U n D N se lee de derecha a izquierda a la hora de leer desde la raiz a la entrada, por ejernplo:
La parte situada a la izquierda de un D N se denornina Relative Distinguished Name (RDN), o Nornbre Diferenciado Relativo, y esti forrnado por un par de valor atributo que se encuentra en la entrada. El R D N en este ejernplo s e r i a u i d = s c a r t e r . Los atributos LDAP a rnenudo utilizan rnnernottcnicas corno nornbres. ~ s t o son s algunos de 10s atributos LDAP rnis cornunes:
1
Atributo LDAP
Definici6n
Cn
Nornbre cornun
Sn
Apellido
Givenname
Primer nornbre
Uid
I D de usuario
Dn
Nornbre Diferenciado
mail
Direcci6n de e-mail
I
Los atributos pueden tener uno o rnis valores. Por ejernplo, un usuario puede tener rnis de una direcci6n de e-mail, por lo que necesitarin rnis de un valor para su atributo m a i l . Los valores de atributo pueden ser texto o datos binarios y se hace referencia a ellos en paresnornbre/valor. Hay tarnbitn un atributo especial llarnadoob j e c t c l a s s . El atributoob j e c t c l a s s de una entrada especifica q u t atributos son necesarios y qut atributos estin perrnitidos en una entrada en particular. A1 igual que 10s objetos en Java, las clases de objeto en LDAP pueden ser arnpliadas. Cuando una clase de objeto es arnpliada para una entrada en particular, la clase de objeto rnantiene 10s atributos existentes, per0 10s nuevos atributos pueden ser especificados.
Capitulo 2 ~ s t es e un ejemplo de entrada LDAP (sobre las que hablaremos rnis adelante en este capitulo) representado en el formato LDAP Data Interchange Format (LDIF), que es el mod0 mis comlin de mostrar 10s datos LDAP en un formato legible: d n : uid=scarter, ou=People, o=fedup.com cn: S a m Carter sn: Carter givenname: S a m o b j ectclass: t o p objectclass: p e r s o n objectclass: organizationalPerson objectclass: inetOrgPerson o u : Accounting o u : People 1: Sunnyvale uid: scarter mail: scarterFfedup.com telephonenumber: t1 408 555 4798 facsimiletelephonenumber: t1 408 555 9751 roomnumber: 4612
Los atributos tambikn tienen reglas de concordancia. Estas reglas indican a1 servidor como decidir si una entrada concreta concuerda o no con una determinada consulta. Las posibles reglas de concordancia son estas: Regla de concordancia
I
I
Significado
DN
El atributo esti en forma de un Nombre Diferenciado
Case-Insensitive String (CIS)
El atributo puede concordar si el valor de la consulta es igual a1 valor del atributo, con independencia del caso
Case-Sensitive String (CSS)
El atributo puede concordar si el valor de la consulta es igual a1 valor del atributo incluido el caso
Telephone
Es lo mismo que CIS except0 que caracteres como "-" y son ignorados a la hora de determinar la concordancia
Integer
La concordancia de atributo es determinada utilizando s61o nGmeros
Binary
El atributo concuerda si el valor de la consulta y el valor del atributo son 10s mismos valores binarios (por ejemplo, consultar una base de datos LDAP para buscar una foto concreta)
"0"
La definici6n de atributos, las reglas de concordancia de atributos y la relaci6n entre clases de objetos y atributos estin definidas en el esquema del servidor. U n servidor contiene un esquema predefinido pero, siempre que el servidor se ajuste a1 protocolo LDAP v3 tal y como se define en RFC 2251 (http:l/ www.ietf.org/rfc/rfc2251.txt), el esquema puede ser ampliado para incluir nuevos atributos y clases de objeto. Los servidores LDAP tienen otras ventajas. Admiten referentes (apuntadores hacia otros directorios LDAP en 10s que residen datos), de mod0 que un Gnico servidor LDAP puede buscar millones de entradas a partir de la consulta de un solo cliente y 10s datos LDAP pueden ser replicados para mejorar la fiabilidad y aumentar la velocidad. LDAP cuenta tambikn con un modelo de seguridad muy fuerte que utiliza ACL para proteger 10s datos que se encuentran en el interior del servidor y ajustindose a 10s protocolos de Secure Socket Layers (SSL), Transport Layer Security (TLS) y Simple Authentication and Security Layer (SASL). L D A P estd teniendo una creciente aceptacio'n como servicio de directorio central para sistemas de red. Para mds informaci6n acerca de L D A P deberia consultar Implementando LDAP por Mark Wilcox, de Wrox Press, ISBN 1-861002-21-1.
Servicios de directorio y JNDI
Introduction de JNDI Aunque LDAP esta creciendo en popularidad y en uso, le queda todavia mucho camino que recorrer hasta llegar a ser omnipresente. Otros servicios de directorio tales como NIS son todavia muy utilizados y es posible que sigan sikndolo durante mucho tiempo todavia. O t r o aspect0 es que las aplicaciones de empresa necesitan con frecuencia ajustarse a las normas de procesamiento distribuido existentes, tales como C o m m o n Object Request Broker Architecture (CORBA), que se utiliza mucho en muchas grandes organizaciones para permitir que diferentes tipos de aplicaciones interacthen entre si. CORBA es una arquitectura independiente del lenguaje y de la plataforma utilizada que permite la programacion de aplicacionesdistribuidas, en la que una aplicaci6n en una miquina puede acceder a una funcion de una aplicacion diferente situada en una miquina diferente como si estuviera llamando una funcion interna. CORBA utiliza el servicio COSNaming (CORBA Object Service) para definir la posicion de 10s objetos disponibles. Para superar estas dificultades, se ha creado un API estindar de Java para que interactfie con 10s servicios de designation y directorio. Este API es anilogo a1 mod0 en el que 10s desarrolladores de programas utilizan JDBC para interactuar con todo tipo de bases de datos. JNDI es fundamental para el desarrollo a largo plazo de Java, en particular de la iniciativa Enterprise JavaBeans (EJB). El significado de EJB para J2EE queda reflejado en el hecho de que una larga proporci6n de este libro esti dedicado a EJB. Empezando por el capitulo 16, veremos de primera mano la importancia de JNDI para la funcionalidad de EJB. U n componente clave de la tecnologia EJB es la capacidad para almacenar y recuperar objetos en la red. U n servicio de directorio va a ser el almackn primario de datos para objetos estables Java, que son recuperados de la red en mis ocasiones de las que son almacenados. Esto ocurre porque, cuando 10s objetos son cargados de la red, queremos poder localizarlos ripidamente y un servicio de directorio nos permite una ripida busqueda y recuperation de datos. Estos datos pueden ser cualquier cosa, incluido un registro de un usuario particular de datos binarios, como un objeto Java serializado. Los siguientes diagramas le ayudarin a ilustrar la relacion entre 10s servicios de directorio, JNDI y LDAP. El primer diagrama muestra la relacion entre un cliente y una variedad de servicios de directorio. Cada servicio de directorio requiere su propio API, que afiade complejidad y sobrecarga de codigo para nuestra aplicaci6n de cliente:
,
API NIS
API NDS
,
Dorninios NT
Este diagrama puede simplificarse utilizandoJND1. Hay todavia miltiples servidores y multiples API por debajo, per0 para el creador de la aplicacion aparece como un 6nico API:
Capitulo 2
Cliente
JNDI
Proveedor de Sewicio LDAP
Proveedor de S e w ~ c ~NDS o
API LDAP
API NDS
?
?
Sewldor LDAP
Sewidor NDS
Asi, como desarrolladores de programas, nos resulta mis ficil crear aplicaciones de red porque podemos concentrarnos en un finico API. Sin embargo, todavia tenemos que enfrentarnos a problemas potenciales porque no todos 10s proveedores de servicios J N D I estdn creados del mismo modo. Los proveedores de servicios en terminologia J N D I son 10s dispositivos que permiten la interaccidn con diferentes servicios de directorio. Cada servicio de directorio es claramente diferente (nombran sus entradas de forma diferente y tienen diferentes capacidades), por lo que 10s desarrolladores de programas todavia construyen aplicaciones que son mayores y mis proclives a errores.
Y un aspect0 mis importante si cabe es que puede ser dificil integrar sistemas que puedan comprender LDAP pero sean incapaces de utilizar Java. Finalmente, mostramos cdmo J N D I y LDAP pueden trabajar juntos, ofreciendo la soluci6n mas elegante:
1
A
LDAP
I
,
I
I
L
T
NIS
N DS
NT
Servicios de directorio y JNDI Aqui utilizamos J N D I para comunicar con varios servidores LDAP. El creador de programas solo tiene que preocuparse por un protocolo en particular (LDAP) y un API (JNDI). Por supuesto, estamos confiando en que 10s distribuidores proporcionan interfaces a sus protocolos de propiedad. Sin embargo, esto no es un problema ya que, para estos servicios de directorio de gran aceptacion, hay productos adicionales que nos permiten comunicarnos con ellos via LDAP.
Las concesiones Aunque J N D I proporciona un API comun para programacion a diferentes servicios de directorio, hay algunas concesiones que deben realizarse: D Una concesion indica que hay mucho sobregasto. Por ejemplo, cada objeto DirContext (10s
objetos que utiliza J N D I para interactuar con un servicio de directorio) debe ajustarse a un numero de mktodos, muchos de 10s cuales nunca utilizari. Cuando implemente un objeto DirContext,es sencillo dejarlo vacio de mod0 que no cause problemas con su aplicacion, per0 si ariade peso extra en tkrminos de memoria y de tiempo de compilaci6n durante la ejecucion de programa. Veremos un ejemplo de esto mis adelante, en este mismo capitulo.
O Ademis, para que J N D I pueda mantener una interfaz comun, no siempre se ajusta a todas las funciones del servicio de directorio. U n buen ejemplo de 6ste es el comando LDAP compare.Nos permite comparar un valor particular de un atributo en una unica entrada en el servidor LDAP. El semidor LDAP debe devolver un c6digo resultado en lugar de una serie de resultados de busqueda completa, convirtiendo asi la operacidn de comparacion en un trimite ligero y ripido. Sin embargo, J N D I no se ajusta a una verdadera comparacion LDAP, porque LDAP es el unico semicio de directorio que apoya esta operaci6n. En su lugar, J N D I realiza una sencilla busqueda que recupera fisicamente la entrada en la memoria del servidor y realiza la opera4611 de comparacion en la aplicacion. El resultado es el mismo para la aplicacion per0 ya no contamos con 10s beneficios de la comparacion real LDAP. 0 Finalmente, n o es posible obtener acceso direct0 a la conexion del servidor de directorio, lo que
sipifica que es muy dificil implementar la reserva de conexion o comprobar la expiracion de una aplicaci6n. Para la mayoria de las aplicaciones, estos inconvenientes no suponen un serio problema. J N D I proporciona un API comun a una variedad de servicios de directorio, que esti incluido como parte estindar de Java, del mismo mod0 que JDBC proporciona un API estindar a las bases de datos relacionales. En algunos caso, J N D I puede ser el unico API disponible para un semicio de directorio en particular como es el caso de D N S o de un senidor de aplicacion Java como BEA WebLogic. Sin embargo, en algunos casos, las aplicaciones si necesitan acceso de bajo nivel a1 servicio de directorio y, si la aplicaci6n no necesita ninguno de 10s servicios que ofrece J N D I (corno almacenamiento y recuperation de objetos Java), puede que queramos optar por un API Java de bajo nivel. Por ejemplo, en LDAP esti el Netscape Directory SDK para Java, que es en realidad m6s elaborado que el API JNDILDAP. Es un SDKde c6digo abierto, dispon~bleen http://www.mozilla.org/directory/. J N D I puede que tampoco sea la mejor soluci6n cuando una aplicacion necesita manipular archivos en el sistema de archivos local. Si 10s objetos Java como 10s objetos Datasource para programacion JDBC no deben ser cargados, es mejor en este caso utilizar las clases estindar disponibles en el paquete j ava . io.
iPor que utilizar JNDI cuando tenemos LDAP? Entonces, ipor qu6 necesitamos J N D I si podemos comunicar con 10s sistemas via LDAP? Asimismo, ipor quk necesitamos LDAP cuando tenemos J N D I ? Para responder a estas preguntas, estudiemos como podemos utilizar J N D I o LDAP de forma independiente.
LDAP sin JNDI LDAP es un buen mod0 de convergir el acceso a datos de directorio mediante un unico protocolo. Resulta util n o solo en la programacion Java sino t a m b i h para otros tipos de aplicaciones. Por ejemplo, LDAP es un buen mod0 de proporcionar un libro de direcciones de red basado en un estindar (la mayoria de 10s paquetes de e-mail cuentan con la capacidad de consultar un servidor LDAP para busquedas de direcciones de e-mail) o simplemente de mantener un registro de 10s dispositivos de una red. J N D I ofrece la capacidad de comunicar directamente con diferentes servicios de directorio de red cuando no necesitamos LDAP. Por ejemplo, puede que necesite determinar si alguien ha accedido a una aplicacion determinada basada en su pertenencia a un grupo NIS concreto, o puede que necesite recuperar un registro MX en un servidor DNS. J N D I facilita la tarea a1 creador de programas en estos casos proporcionando un API consistente en vez de tener que aprender como hacer lo mismo utilizando diferentes grupos de API.
JNDI sin LDAP Aunque podria proporcionar un servicio similar a LDAP para sus aplicaciones Java a traves de JNDI, esto so10 seria util para sus aplicaciones Java y probablemente tendria que repetirlo en cada aplicacion Java que grabe que necesite este tip0 de servicio. LDAP es un estindar abierto mantenido por Internet Engineering Task Force (IETF). Esto significa que es accesible desde diversos clientes y distribuidores. Esta es una de las extraordinarias caracteristicas de Internet y la raz6n por la que 10s protocolos basados en Internet han reemplazado a 10s protocolos de propiedad como medios primarios de comunicaciones en red. LY XML? Cuando XML fue lanzado por primera vez, hubo cierto debate sobre la posibilidad de que reemplazara a todas las tecnologias anteriores incluido Java y LDAP. Por supuesto, esto no ocurri6. En su lugar, XML se ha convertido en el estindar de facto para datos persistentes, en especial para situaciones en las que necesite intercambiar datos persistentes entre aplicaciones grabadas en diferentes lenguajes de aplicaciones (por ejemplo, entre Visual Basic y Java). XML t a m b i h tiene su funci6n en LDAP y en JNDI. Hay una especificaci6n XML concreta para LDAP llamada Directory Services Markup Language (DSML) que esti siendo desarrollada principalmente para distribuir informacidn de directorio a travks de un ~ r o t o c o l ode base XML-RCP como SOAP. Consiste en un Ienguaje de marcado para representar servicios de directorio en XML. Si quiere mis detalles, vaya a http://www.dsrnl.org/ .
DSML esti disefiado para reemplazar el mod0 estindar de intercambio de datos LDAP externos a1 protocolo LDAP. El estindar actual es el formato LDAP Data Interchange Format (LDIF) y ise es el que utilizaremos para mostrar nuestros ejemplos en este capitulo.
Ahora que ya tenemos un conocimiento bisico de 10s servicios de directorio, J N D I y LDAP, es el momento de ensuciarnos las manos trabajando. Para utilizar J N D I tal y como se describe en este capitulo necesitaremos lo siguiente:
O JDK 1.3 de Sun, que incluye J N D I estindar, o J N D I Software Development Kit (SDK) 1.2.2 (disponible en http://java.sun.com/jndi/). O U n servidor de directorio que cumpla las normas LDAP v3. El servidor Directorio de Netscape, disponible en http://www.iplanet.com/download/download/index.htrnl, se utilizaen este capitulo.
Sewicios de directorio y JNDI Todos 10s ejemplos que encontrari en este capitulo utilizan 10s datos de prueba a r i u s .corn que viene en este servidor de directorio. Aunque J N D I esti incorporado en JDK 1.3 y superior, puede que todavia necesite obtener el archivo 1dap.jar de J N D I 1.2.2 para conseguir toda la funcionalidad, incluida la capacidad de utilizar 10s controles LDAP y de almacenar/recuperar objetos RMI en un servidor LDAP.
Instalacion de JNDI ~ s t o son s 10s pasos generales a seguir para empezar a funcionar en un sistema estindar: 0
Obtener informaci6n de su administrador de servidor LDAP o instalar un servidor que cumpla con 10s requisitos LDAP v3. Yo he utilizado varios servidores LDAP para diversos desarrollos, incluido openLDAP (http://www.openldap.org) en Red Hat Linux 6.2, el servidor LDAP gratis de Eudora para Windows (http://www.eudora.corn) y 10s servidores Iplanet 4 & 5 Directory (http:/1 www.iplanet.corn) tanto en Red Hat Linux 6.2 como en Windows 2000.
0
Instalar JDK 1.3, que contiene J N D I y el proveedor LDAP bisico. Si no esti utilizando funciones avanzadas de LDAP como controles, no necesitari instalar nada mis except0 JDK 1.3. Si esti explorando funciones avanzadas LDAP, lea la pigina J N D I en http://java.sun.com/JNDI/ para mis informaci6n.
Ahora ya estamos preparados para utilizar J N D I y LDAP.
Proveedores de servicios JNDI El usuario no puede utilizar J N D I sin utilizar un proveedor de servicios, por lo que primer0 debemos entender el concepto de proveedor de servicios. U n proveedor de servicios es u n grupo de clases Java que le permite comunicar con u n servicio de directorio de u n mod0 similar a1 que 10s dispositivos JDBC le permiten comunicar con una base de datos. - -
-
--
--
Para que un proveedor de servicios estk disponible para su uso en J N D I debe implementar la interfaz Context. La mayoria de 10s proveedores de servicio que utilizari es probable que implementen la interfaz DirectoryContext, que extiende la interfaz Context para capacitar servicios de directorio. Esto significa que s610 tenemos que aprender a manejar J N D I para saber que las llamadas API conectan a un semicio de designaci6n o de directorio, mientras que el proveedor de servicios se preocupa de 10s detalles aburridos como el protocolo de red y 10s valores codificado/decodificado. Por desgracia, 10s proveedores de servicios no son la panacea para el uso de servicios de directorio. Debemos saber algo sobre el servicio de directorio subyacente de modo que podamos nombrar nuestras entradas correctamente y construir correctas consultas de busqueda. A diferencia de las bases de datos relacionales, 10s servicios de directorio no comparten un lenguaje de consulta comun como SQL. En J N D I 1.2,los proveedores de servicios pueden ajustarse a un concepto de federaci6n donde un proveedor de servicios puede pasar una operaci6n a otro proveedor de servicios si no entiende el designaci6n o el esquema de la operaci6n. Por ejemplo, si quisikramos encontrar el registro XM (este
Capitulo 2 contiene el sewidor de e-mail de destino preferido para un dominio) para un dominio concreto de DNS, per0 nuestro proveedor inicial de servicio era LDAP, no podria responder a la consults. Si hubiera federacibn, podria pasar la solicitud a1 siguiente proveedor de servicios de la lista de federaci6n y, si fuera un proveedor de servicios DNS, podria trarnitar la solicitud por nosotros. En una situaci6n ideal, esto deberia resultar transparente para el programador de la aplicaci6n. Sin embargo, corno esta es una caracteristica nueva, todavia n o ha sido probada ni implementada por cornpleto. En conc~usi6n,un proveedor de servicios permite a nuestras aplicaciones J N D I comunicar con un servicio de designaci6n/directorio. El resto de las interfaces, clases y excepciones giran todas alrededor de nuestra interacci6n con un proveedor de servicios.
Como obtener proveedores de servicios JNDI Si descargarnos el SDK JNDI, veremos que, junto con el API y la documentaci6n, se incluye una serie de proveedores de servicios existentes. Estos incluyen proveedores para LDAP, NIS, C O S y el registro RMI y sistema de archivos. Muchos distribuidores diferentes tambikn facilitan proveedores de servicios para otros servicios de directorio, o corno sustitutos para 10s proveedores por defecto de Sun. Por ejemplo, Novel1 tiene un proveedor de servicios para NDS, mientras que tanto IBM corno Netscape cuentan con proveedores de servicios alternativos para LDAP. Resulta ficil cambiar entre proveedores de servicios. Por ejemplo, para utilizar el proveedor de servicios LDAP de Sun por defecto realizariamos una llamada corno ksta: // Especlflcar qu6 c l a s e u t l l i z a r para rluestro e n v . p u t ( C o n t e x t . I N I T I A L CONTEXT FACTORY, "corn. s u n . j n d i . 1 d a p . L d a p C t x F a c t o r y " ) ;
proveedor
JNDI
Ahora para utilizar el proveedor de servicios LDAP de IBM simplemente sustituiria com.sun.jndi.ldap.LdapCtxFactorypor el nombre completo del paquete del proveedor de servicios LDAP de IBM del siguiente modo: / / E s p e c i f i c a r qu6 c l a s e u t i l i z a r p a r a n u e s t r o e r ~ v p. u t ( C o n t e x t . I I I I T I A L CONTEXT FACTORY, "corn. ibrn. j n d i . L D A P C t x F a c t o r y t ' ) ;
proveedor
JIIDI
Puede encontrar una lista de proveedores de servicios actuales en http://java.sun.com/products/jndi/ serviceproviders. htrnl.
Como desarrollar su propio proveedor de servicios Puede que tambikn necesite implernentar su propio proveedor de servicios si necesita utilizar un servicio de directorio (corno 10s dorninios de Windows N T o Bayan Vines) que todavia no tiene un proveedor de servicios. En el SDK JNDI, Sun facilita un ejemplo de c6mo grabar un proveedor de servicios. Esta tutoria J N D I esti disponible en http://java.sun.com/products/jndi/tutoriaI/index,htrnl. Sun tarnbikn proporciona un docurnento P D F que describe el proceso de grabar un proveedor de servicios en ftp://ftp.javasoft.com/ docs/jndi/jndispi.pdf. El proveedor de servicios LDAP de Netscape esti disponible corno proyecto de abierto en http://www.rnozilla.org~directory/.
Servicios de directorio y JNDl
Java y LDAP Antes de que comencemos a examinar activamente el uso de LDAP en Java, debemos analizar brevemente el uso comun de LDAP en las aplicaciones de Java. En la actualidad, hay tres aplicaciones bisicas de LDAP en Java:
CI Control de acceso 0
Servicio de piginas blancas
0
Directorio de procesamiento distribuido
Examinemos estas aplicaciones mis detenidamente.
Todas las aplicaciones dictan quC usuarios pueden acceder a ellas. Este acceso puede desde permitir el inicio a cualquier usuario que haga clic en el icono de la aplicaci6n hasta permitir el acceso unicamente a un usuario que se ajuste a un esciner de retina. La mayoria de las aplicaciones se encuentran entre estos dos extremos. El control de acceso puede descomponerse en autentificaci6n y autorizaci6n.
Autentificacion La autentificacibn consiste en determinar q u i h es la persona que esti utilizando un elemento de software. Debido a la naturaleza de la informitica, nunca podemos estar cien por cien seguros de quikn es el usuario, per0 varios mecanismos de autentificaci6n aumentan las probabilidades de que el usuario sea quien dice ser. La autentificacion requiere el uso de un secret0 cornpartido, cuya forma mis comun es una contraseiia. El usuario facilita un nombre de usuario y una contraseha. El nombre de usuario se utiliza para buscar el registro de la persona en cuestidn en una base de datos (esta base de datos puede ser un simple archivo plano como el archivo p a s s w d U N I X o una sofisticada base de datos como LDAP) y si la contraseiia dada es la misma que la almacenada en la base de datos, entonces asumimos que el usuario es quien dice ser. La autentificaci6n basada en una contraseiia es la mis sencilla per0 uno de 10s mktodos menos seguros; puesto que las contraseiias son introducidas con el teclado, pueden ser detectadas en el trinsito por las redes o pueden ser ficilmente descifradas por alguien sin escrupulos que acceda sin autorizaci6n a la base de datos de contraseiias. En el actual mundo de Internet, la mayor amenaza para las contraseiias (mis all5 de preguntar a1 usuario personalmente por su contraseiia) es viajar por la red libremente. Por lo tanto, es mejor tomar medidas para proteger las contraseiias a la hora de viajar por la red. Dos mecanismos muy comunes son M D 5 y Secure Socket Layers (SSL). En MD5 el cliente crea en primer lugar una refundici6n MD5 de la contraseiia antes de introducirla en la red. El servidor compara entonces esta refundici6n con la que ha almacenado en su base de datos. Aunque este metodo evita que alguien adivine la contraseiia de texto y que se registre en otros sistemas, no evita que alguien robe la contraseiia refundida. Esta contraseiia refundida robada puede ser utilizada igual que una contraseiia de texto robada para acceder a1 sistema (conocido como ataque "man in the middle", algo asi como "hombre en el medio"). O t r o inconveniente es que la mayoria de 10s sistemas no almacenan sus contraseiias como M D 5 (aunque ciertas implementaciones BSD s i l o hacen) porque se puede ver forzado a cambiar las contrasefias de todos antes de poder implementar este sistema. C o n SSL toda la conexi6n de red esti cifrada. Esto no s61o protege la contraseiia sino que tambikn protege cualquier dato transferido entre el cliente y el servidor. Esta es la raz6n por la que SSL se utiliza
Capitulo 2 con frecuencia para proteger aplicaciones de e-comercio. TambiCn resulta util en LDAP porque 10s servidores LDAP a menudo contienen datos sensibles como numeros de identification personal, numeros de licencia de dispositivos, etc. N o queremos que estos datos viajen de forma insegura por la red igual que no queremos que lo hagan las contraseiias. SSL tambien aiiade otra forma de autentificacion en conjunto: el certificado digital. Los certificados digitales utilizan el cifrado publico de claves para reforzar el proceso de autentificacion. Bajo el cifrado pGblico de claves, el usuario cuenta con una clave privada a la que solo 61 tiene acceso. Todos 10s datos cifrados por la clave privada solo pueden ser descifrados por la clave publica y viceversa. El servidor tiene acceso a su clave publica. Con SSL (que cifra toda la transferencia de datos), el servidor envia al usuario algunos datos para cifrar con su clave privada. El usuario cifra 10s datos y 10s devuelve a1 servidor. Si el servidor puede descifrar 10s datos con la clave publics y 10s datos coinciden, entonces se asume que se trata del usuario. El estindar de certificado digital (X.509) es una extension del estindar de servicios de directorio original. De este modo, LDAP es uno de 10s modos mis eficientes de gesti6n de certificados digitales. Sin embargo, hay que sefialar que esta autentificacion de usuario ocurre en realidad despub de que el servidor SSL haya sido autentificado. LDAP tiene la capacidad de ajustarse a un amplio espectro de servicios de autentificaci6n incluido contraseiias, certificados digitales y el protocolo Simple Authentication and Security Layer (SASL).
Autorizacion Despuks de haber autentificado a alguien, necesitamos determinar quk les esti permitido hacer. Por ejemplo, podriamos decidir que solo 10s miembros de 10s Enanitos tienen derecho a acceder a 10s archivos de BlancaNieves. Tambikn podriamos aiiadir granularidad rnis fina indicando simplemente si alguien tiene acceso o no. Por ejemplo, podriamos establecer que 10s miembros del conse j o Jedi tienen plenos derechos sobre elementos de la base de datos Fuerza, mientras que 10s miembros de 10s Caballeros Jedi tienen capacidad para editar ciertos elementos en la base de datos Fuer za,mientras que padawan solo tiene capacidad de leer la base de datos Fuerza. Podemos utilizar LDAP para desarrollar sofisticadas politicas de autorizaci6n.
Servicios de paginas blancas Los servicios de piginas blancas permiten a alguien buscar usuarios basindose en atributos contenidos en sus entradas. Por ejemplo, puede buscar la direccidn de e-mail de Mark Wilcox y obtener el numero de telkfono de la oficina de Ingenieria, el numero de edificio de Recursos Humanos, etc. Se llaman piginas blancas porque este tip0 de informaci6n es similar a1 tip0 de informaci6n que puede encontrar en las piginas blancas de telkfonos. Este tip0 de servicios son 10s rnis publicos de todas las operaciones LDAP y son para lo que muchos usuarios, si no todos, utilizan LDAP. En Java, lo estamos situando en segundo lugar porque la mayoria de 10s servicios de piginas blancas se facilitan mediante un cliente LDAP que se encuentra en un paquete de email como Netscape Messenger o Microsoft Outlook en vez de a travCs de una aplicaci6n Java. Las aplicaciones Java realizan normalmente esta funcion bien como segundo plano de una interfaz LDAP de pigina Web o para proporcionar servicios de flujo de trabajo en una aplicacion Java de empresa. Como ejemplo, estudiemos una sencilla situacidn en la que Juan introduce una solicitud de orden de compra (PO) electronics de 100 artilugios de la marca Acme. La aplicaci6n de compra tiene una regla comercial que establece que despuks de que alguien introduzca una solicitud (PO) debe ser enviada a1 encargado de autorizaciones de P O de su grupo. Por lo tanto, la aplicacion consulta LDAP para saber quikn es el autorizador de P O para el grupo de Juan en LDAP y les envia una notification de e-mail utilizando el atributo de e-mail LDAP del autorizador.
Servicios de directorio y JNDI
Directorio de procesamiento distribuido Uno de 10s segmentos de crecimiento mis ripido de programacidn de servidor es la programacidn de red distribuida, donde una aplicacidn utiliza cddigo que realmente reside independientemente de la aplicacion ejecutada. El c6digo puede estar en una JVM independiente (o miquina similar tipo servidor CORBA) o en una miquina fisica diferente situada a1 otro extremo del mundo. A menudo utilizamos este tip0 de programacidn para facilitar la reutihaci6n del cddigo de legado existente o para mejorar el rendimiento descargando un gran volumen de procesamiento en una miquina distinta. En Java, hay tres arquitecturas distribuidas diferentes disponibles:
O Remote Meted Invocation (RMI) O Common Object Request Broker Architecture (CORBA) O Enterprise JavaBeans (EJB) Las tres arquitecturas proporcionan un servicio de registro que una aplicacidn de cliente utiliza para localizar el codigo distribuido. Debido a que su especificacidn fue desarrollada despuks de JNDI, EJB utiliza J N D I para sus servicios de registro. RMI y CORBA utilizan sus propios servicios independientes de registro. Uno de 10s problemas de estos servicios es que no proporcionan un mecanismo que permite buscar en su registro para saber quk objetos estin disponibles para su uso. Con J N D I y LDAP el usuario puede proporcionar a estos servicios referencias indirectas con el objeto Reference JNDI. Por ejemplo, puede tener una entrada con un nombre de "Real Time S t o c k Q u o t e s e r v i c e " que tiene un atributo que contiene la localizacidn de red real para el objeto RMI o CORBA. Este tip0 de servicio facilita la comprensidn de su c6digo y le otorga mis flexibilidad en su aplicaci6n. Por ejemplo, si necesita desplazar un determinado objeto distribuido a un nuevo servidor, en lugar de tener que cambiar todas las aplicaciones que referencian ese objeto, s61o tiene que cambiar su posici6n en LDAP y todas las aplicaciones de cliente actualizarin sus posiciones automiticamente la pr6xima vez que referencien el objeto. LDAP tambikn puede almacenar otros atributos descriptivos en una entrada, de modo que el usuario podria almacenar mejores descripciones de su objeto en el directorio para construir piginas blancas para objetos. Quienes han estado implicados en proyectos de sus compaiiias para el desarrollo de libreria de codigos centralizadas encuentran a menudo que el desarrollo del cddigo era la parte ficil; conseguir que el c6digo sea ficil de encontrar en la parte dificil. Utilizar LDAP como un directorio de clase es una soluci6n a estos problemas. Podriamos afiadir otros elementos a la descripci6n de nuestro ejemplo de objeto almacenado. Por ejemplo, podriamos aiiadir elementos como el lenguaje de desarrollo utilizado, una anotacidn sobre su propdsito y el nombre del creador del programa o del equipo de desarrollo.
Configuration de la aplicacion LDAP tambikn puede utilizarse para almacenar informaci6n de configuracidn sobre una aplicacibn. Esto es especialmente Gtil cuando la aplicaci6n la utiliza el mismo usuario per0 en diferentes miquinas y seria util proporcionar la misma informaci6n de configuraci6n sin tener en cuenta la miquina utilizada por el usuario para acceder a ksta. A continuacidn dejaremos de hablar en tkrminos hipotCticos y de explicar 10s conceptos bisicos para introducirnos en la prictica. En el resto de este capitulo, veremos algo de c6digo real y cdmo realizar operaciones LDAP bisicas con JNDI.
Capitulo 2
Operaciones LDAP Antes de que podamos realizar cualquier tipo de operaci6n en un senidor LDAP, debemos en primer lugar obtener una referencia y una conexi6n de red para el servidor LDAP. Tambikn debemos especificar c6mo queremos estar seguros con respecto a1 servidor, bien de forma anonima o como un usuario autentificado. Muchos servidores LDAP accesibles a Internet permiten a l g h tip0 de acceso an6nimo (generalmente funciones de s61o lectura para atributos como direcciones de e-mail y n6meros de telkfono), per0 LDAP tambikn se ajusta a caracteristicas de seguridad muy avanzadas a travks de ACL que dependen de quien autentifica la conexi6n. Por ejemplo, un servidor LDAP puede tener diversos niveles de derechos para cualquier entrada determinada: Usuarios an6nimos pueden acceder a la direcci6n de e-mail y al nfimero de tekfono de una empleado.
o El empleado puede ver la entrada completa de dichos usuarios per0 s6lo puede modificar ciertos atributos como el nfimero de telkfono, la contrasefia y el nfimero de despacho de la oficina. 0
El gestor de un usuario puede actualizar el nfimero de telkfono de un empleado y el nhnero de despacho de la oficina per0 ningun elemento mas. Tambikn puede acceder a1 registro cornpleto del empleado. U n grupo reducido, 10s Administradores d'el Directorio, tiene plenos derechos sobre el servidor completo incluida la posibilidad de afiadir y eLminar cualquier entrada.
Operaciones LDAP estandar Existen algunas operaciones estindar en LDAP. Son las siguientes: O
Conexi6n a1 servidor LDAP
O
Asociaci6n a un servidor LDAP (puede considerar este paso como autentificaci6n)
O
Realizaci6n de una serie de operaciones LDAP: 0 Bfisqueda del servidor 0 Adici6n de una nueva entrada
0
0
Modificaci6n de una entrada
O
Eliminaci6n de una entrada
Desconexion de un servidor LDAP
Analizaremos cada una de las operaciones anteriores, realizando demostraciones con ejemplos siempre que sea pertinente.
Conexion al servidor LDAP con JNDl Primero debemos obtener una referencia para un objeto que implemente la interfaz Dircontext. En la mayoria de las aplicaciones, utilizaremos el objeto InitialDirContext que tome una tablade
Capitulo 2 Para asociar especificarnente a1 semidor, debernos facilitar el rnedio con el rnCtodo para nuestra autentificacih (por ejernplo, "simpleM,SSL, o SASL). DespuCs debernos especificar el D N de la entrada que desearnos asociar y la contrasefia de la entrada: Hashtable
env
r~ewHashtable ( ) ;
=
//
Asi envia en i d y l a e n v . p u t ( C o n t e x t . PROVIDER e n v . p u t ( C o n t e x t . SECURITY e n v . p u t ( C o n t e x t.SECURITY
c o n t r a s e f ~ acomo t e x t o e n l a URL, "myhost") ; AUTHENTICATION, " s i m p l e " ) ; P R I N C I P A L , MGR D N ) ; env.put(Context.SECUR1TY C R E D E N T I A L S , MGR P W ) ;
//
Obtener DirContext
una
ctx
cor~exitr~
referencia a un contexto d e dlrectorio n e w I n i t i a l D i r C o n t e x t (env) ;
=
Seguridad simple, SSVTLS y SASL La Gltirna especificacidn LDAP, LDAP v3, perrnite tres tipos de seguridad:
0
SASL
Estudiernos cada tip0 sucesivarnente. Simple
Seguridad simple significa que el usuario s61o necesitari au~entificara1 servidor utilizando I D y contrasefias de texto estindar sin ningGn cifrado en la red. Este es con diferencia el rnis cornGn y el rnenos seguro de 10s distintos rnCtodos de autentificacih. Es inseguro por dos rnotivos: el prirnero consiste en que 10s I D y contraseiias de 10s usuarios son transrnitidas a1 semidor a travCs de una red pGblica, donde cualquiera puede robar 10s I D y las contrasefias de la red; en segundo lugar, nada garantiza que la persona que introduce el I D y la contrasefia de usuario es el verdadero titular de ese I D y de esa contrasefia.
El protocolo Secure Socket Layer fue desarrollado por Netscape Communications para mejorar la seguridad de las transacciones de base Web. Se ha convertido en una norrna oficial llarnada Transport Layer Security (TLS), per0 todavia se denornina a rnenudo SSL. SSL le perrnite cifrar su transacci6n cornpleta en la red, dificultando a cualquiera la tarea de robar la inforrnaci6n (corno su I D o sus contraseiias). SLL estindar n o verifica la identidad de la persona que introduce el I D y la contrasefia de usuario per0 si certifica que la rniquina desde la que el usuario esti introduciendo el I D y la contrasefia es "el verdadero servidor". La rnayoria de 10s servidores que implementan SSL tarnbikn se ajustan a 10s certificados cliente (10s certificados son archivos de texto que son utilizados para confirmar la identidad del servidor y del cliente) para la autentificacibn del usuario. En vez de presentar un I D y una contrasefia de usuario al sisterna, puede presentar un certificado a1 servidor. Si el certificado que presenta coincide con un certificado perrnitido, el acceso esti garantizado.
Los certificados se consideran mks seguros porque son dificiles de falsificar. Sin ernbargo, 10s certificados se almacenan normalmente como un archivo en una mkquina de usuario local, lo que significa que la mdquina cliente estk comprometida, entonces puede utilizarse un certificado del mismo modo que puede utilizarse un ID y una contraseiia robada. Cuando 10s certificados son
Servicios de directorio v JNDl almacenados localmente, debe desarrollarse u n mecanismo para recuperarlos si la mdquina en la que esta'n almacenados falla. Los certifi;cados pueden ser almacenados en tarletas inteligentes en lugar de archivos en una mciquina local para mayor seguridad y fiabilidad. La emisidn y gestidn de cert$icados de cliente se encuentra todavia en fuses tempranas de desarrollo. SASL Simple Authentication and Security Layer (SASL) es un estindar de Internet para implementar mecanismos de autentificacion ademis de 10s mktodos Simple o SSL. Existen dos mecanismos SASL conocidos. U n o es el MD5 que ya hemos visto con anterioridad, basado en la comparacibn de contrasefias refundidas. M D 5 no cifra la transaccion y no resuelve el problems de "quikn introduce la contrasefia". Si la contraseiia MD5 refundida es robada en su camino hacia el servidor, un hacker podria utilizarla para acceder al sistema, del mismo mod0 que si se tratara de texto. Sin embargo, si hace que resulte mis dificil adivinar la contrasefia original por lo que, si un hacker roba la contrasefia refundida, no podri adivinar la contrasefia original para intentar utilizarla para acceder a otros sistemas. El segundo mecanismo SASL de uso extendido se denomina Kerberos. Kerberos cifra la transaccion y, en una red con conocimiento de Kerberos, es muy ficil implementar un entorno de unico registro debido a1 mod0 de funcionamiento de Kerberos. Sin embargo, gestionar una red Kerberos supone rnucho tiempo y muchos recursos, por lo que muchas organizaciones no han implementado Kerberos todavia. Puede grabar ficilmente sus propios mecanismos SASL, si su sewidor LDAP se ajusta a ellos. Asi, seria posible capacitar la autentificacion biomktrica, una vez e s t i disponible (o si su organizacibn ya tiene acceso a la tecnologia). La autentificacion biomktrica hace uso de parte del cuerpo del usuario, como su huella dactilar o su iris, para el I D y la contrasefia de usuario. Estos sistemas son muy seguros.
Autentificacion en LDAP v2 y LDAP v3 En LDAP v2, todos 10s clientes tenian que autentificarse a si mismos antes de ejecutar cualquier operacion. En LDAP v3, sin embargo, si un cliente no se autentificaba a si mismo antes de ejecutar una operacion, se asumia que la conexion era autentificada anonimamente.
Busqueda en un servidor LDAP La operacion rnis comun en cualquier servidor LDAP es la operacion de bfisqueda. Cualquier aplicacion LDAP avanzada utiliza la b ~ s q u e d acomo funcionalidad central. En esencia, todas las funciones de busqueda toman un controlador de conexion LDAP, la base desde la que iniciar la busqueda, el espectro de la busqueda y el filtro de la busqueda. U n filtro de bhqueda es como una consulta SQL en la que indica a1 sewidor 10s criterios a utilizar para encontrar entradas que cumplan 10s criterios. Las busquedas siempre utilizan un nombre de atributo y un valor que buscar. Los filtros utilizan 16gica y comodines booleanos. Algunos servidores, como el servidor de Directorio Netscape, se ajustan a capacidades de consulta incluso mis avanzadas, del tip0 "suena como", por ejemplo.
Para 10s ejemplos de busqueda de esta seccidn, accederemos a 10s datos de muestra arius.com que esta'n incorporados a Netscape Directory Server.
Capitulo 2
Filtros LDAP de ejemplo Algunos filtros LDAP tipicos aparecen en la siguiente tabla: Descripcih
Filtro LDAP
I Buscar todos lor usuarios con apellido Carter Buscar todos 10s usuarios con apellido que empiece por "Ca" Buscar todas las clases de objeto del tip0 GroupofUniqueNames que tengan "Managers" en su Nombre Comhn
sn = Carter s n = Ca*
( c n = * Managers * ) (objectclass=groupof~niquenames)) (h
En JNDI, utilizamos el mitodo de bhqueda de la interfaz D i r C o n t e x t . Esto devolveri un objeto N a m i n g E n u m e r a t i o n si la bhqueda es realizada con 6xito. Mis adelante, en esta secci6r1, mostraremos 10s distintos modos de manipular 10s valores de este objeto para obtener atributos y valores de cada entrada recibida.
Determinar el alcance de LDAP Cuando realiza una bhqueda, debe especificar el nodo (a1 que nosotros hacemos referencia como la base) del irbol que desea iniciar, asi como el alcance la busqueda. El alcance define exactamente qu6 proporci6n del irbol desea buscar. Hay tres niveles de alcance. Alcance
Descripcih
LDAP-SCOPE-SUBTREE
Este alcance comienza en la entrada base y busca todo lo que se encuentra por debajo, incluida la entrada base.
LDAP-SCOPE-ONELEVEL
Este alcance busca el irbol completo empezando un nivel por debajo de la entrada base. N o incluye la entrada base.
LDAP-SCOPE-BASE
Este alcance buscahicamente laentrada base, Gtil si deseaobtener s61o 10s atributos/valores de una entrada.
A continuaci6n examinaremos estos tres niveles de alcance con la ayuda de algunos diagramas.
LDAP-SCOPE-SUBTREE La primera figura, a continuaci6n, ilustra una bhqueda utilizando LDAP-SCOPE-SUBTREE:
Servicios de directorio v JNDl
Search Base= dc=a~r~us, dc=com root
Aqui ofrecemos un ejemplo de busqueda u t i l i z a n d o ~ ~ ~ P - S C O P E - O N E L E V E L :
Search Base; d c = a ~ r ~ udc=corn s
'
root
Finalmente, presentamos una b h q u e d a U ~ ~ ~ ~ ~ ~ ~ ~ O L D A P - S C O P E - B A S E :
Capitulo 2
Search Base= dc=airlus, &=corn -. -
root
7
Ejecucion de una busqueda JNDI Jealizamos una busqueda utilizando el metodo s e a r c h ( ) de un objeto que implementa la interfaz DirContext (como laclase I n i t i a l D i r ~ o n t e x t ) El . requisito minimo para esto es la base de busqueda y el filtro, aunque hay otros parimetros que podemos utilizar para ayudar a gestionar 10s resultados. Deberiamos destacar que en la mayoria de 10s API de LDAP debemos especificar el alcance como un parimetro en el metodo de blisqueda LDAP. En JNDI, sin embargo, el alcance seconfipra en el objeto S e a r c h C o n t r o l s , que es un parimetro opcional a1 de la funcibn s e a r c h ( ) de la interfaz DirContext (la clase I n i t i a l D i r C o n t e x t proporciona una implementacibn de la funcibn s e a r c h ( ) ). Por defecto, esti establecido en subtree. La blisqueda es en realidad ejecutada con cualquier objeto que tenga que implemente I a i n t e r f a z D i r C o n t e x t , como l a c l a s e I n i t i a l D i r C o n t e x t . Para nuestro primer ejemplo,mostraremos un ejemplo de busqueda muy sencillo, en el que el filtro de busqueda es " s n = C a r t e r " . Este devolveri todas las entradas que tengan un apellido (el atributo especificado por el mnem6nico "sn") Carter. El primer ejemplo es una busqueda anbnima. Los ejemplos no estin basados en G U I para facilitar la comprensibn de lo que esti ocurriendo, per0 no hay ningun motivo por el que no puedan ser incluidos en una GUI. Recuerde que todos 10s cbdigos fuente para 10s ejemplos descritos en este capitulo pueden ser descargados en h t t p : / ~ . w r o x . c o mEl. c6digo queda como sigue: / / B6squeda an6nima est6ndar import java. util .Hashtable; import java.util.Enumeration;
import j avax. naming. +; import j avax.naminq.directnry. * ; public class JNDISearch
{
/ / Implementacihn de cor~texto inicial public static String INITCTX = "corn.sun. jndi. 1dap.LdapCtxFactory"; public static String MY HOST = "ldap://localhost:389"; public static String MY SEARCHBASE = "o=Airius.com"; public static String M Y FILTER = " (sn=Carter)"; public static vcid mainiString args [ I ) [
/ / Hashtable para informaci6n del medio Hashtable env = new Hashtable(); / / Especificar qu6 clase utilizar para nuestro proveedor JNDI env.put(Context.INITIAL CONTEXT FACTORY, INITCTX); / / Especificar host y puerto a utilizar para servicio d e directorio env. put (Context.PROVIDER URL, MY HOST) ;
/ / Obtener una referencia para un context0 d e directorio DirContext ctx = n e w InitialDirContext (env); / / Especificar el alcance d e la bhsqueda SearchControls constraints = n e w SearchControls ( ) ; cor~straints.setSearchScope(SearchContro1s.SUBTREE SCOPE);
/ / Realizar la b6squeda real. Le otorgamos un base de bfisqueda, un filtro / / y las restricciones contenidas en el alcance d e la bfisqueda NamingEnumeration results = ctx.search(MY SEARCHBASE, MY FILTER, constraints) ; / / Ahora exarninamos 10s resultados d e la bfisqueda while (results ! = null & & results.hasMore()) [ SearchResult sr = (SearchResult) r e s u l t s . n e x t 0 ; String dn = sr.getName0; System.out .println("Distinguished Name is " + d n ) ; Attributes attrs for
I I I Despuks de compilar y ejecutar este c6dig0, el resultado debe aparecer de mod0 similar a 10s resultados que aparecen en la siguiente captura de pantalla:
Capitulo 2
Como funciona el programa de busqueda Realizamos una bdsqueda utilizando el m e t o d o s e a r c h ( ) de un objeto que implements la interfaz D i r C o n t e x t (con10 la clase ~ n i t i a l ~ i r c o n t e x tEl) .requisite minimo para esta blisqueda es la base de bhsqueda y un filtro. Existen otros parimetros que podemos utilizar para ayudar a gestionar 10s resultados. Si la bdsqueda se realiza con &xito,se obtendri un objeto ~ a m i n g ~ n u m e ri ao tn . Despuks de obtener el context0 inicial (a1 que fijamos la variable c t x ) , especificamos el alcance de la blisqueda. Si no especificamos un alcance, JNDI asumir6 un alcance s u b t r e e , por lo que esta linea siguiente es en realidad redundante per0 resulta litil para mostrar c6mo especificar el alcance. Analicemos ahora el proceso de funcionamiento de este c6digo. En primer lugar, establecemos en alcance desubtree:
DespuCs de especificar el alcance, podemos realizar la verdadera bdsqueda del siguiente modo: / / Ej e c u t a r l a v e r d a d e r a b d s q u e d a N s m i n g E n u m ~ r a t i i ~ rre~. s u l t s = ctx.searchIMY-SEARrHBASE, cMonstraints;;
MY-FILTER,
La clase N a m i n g E n u m e r a t i o n es equivalente a la clase SearchResults de SDK Netscape Directory para Java. Cada elemento del o b j e t o ~ a m i n g ~ n u m e r a t i ocontendri n un o b j e t o ~ e a r c h ~ e s uque l t podemos recuperar: SearchResul t
sr
=
[ S e a r c h R e s u l t ) results . n e x t
( ) ;
Servicios de directorio y JNDl Despuis podemos obtener el D N de una entrada: String
dr,
=
sr.getName ( 1 ;
Para obtener 10s atributos de una entrada utilice el metodo g e t A t t r i b u t e s () de la clase SearchResults: Attributes
attrs
=
sr.gttAttributes 1 ) ;
Este metodo devolveri un objeto concreto que implements la i n t e r f a z ~ t t r i b u t e s(la clase ~ n i t i a l ~ i r ~ o n td ee vxute l v e u n o b j e t o ~ a s i c A t t r i b u t e s ) . Despues de conseguir un o b j e t o ~ t t r i b u t e (recuerde s que es una clase de colecci6n), podemos entonces repasar 10s atributos utilizando un objeto N a m i n g E n u m e r a t i o n como iste: = a t t r s . q e t A l 1 ( ) ; r ~ e . h a s M o r e E l e r n e r , t s( 1 ; ) . A t t r i b u t e a t t r = I A t t r i t j ~ ~ t e ) r ~ e . nf e) ; x t Strin3 attrID = attr.qetID();
L L i N a r n i n q E n u m t r a t i o r 1 tie
System.t~ut.println[attrID + frlr
":");
a t t r . g e t A l 1 ( i ;vsls. h a s M o r e E l e r n e r ~ t s1 ) ; 1 S.i"tem.~:8~~t.prir~t1r~("\t" + v a l s . r l e u t E l e m e r ~ (t ) ) ; ( E r , l u m e ~ - a t i o nv a l s
{
=
{
I
La clase N a m i n g E n u m e r a t i o n nos ofrece mktodos que podemos utilizar para examinar cada atributo obtenido en nuestra bhsqueda. Cadaelemento del o b j e t o ~ a m i n g ~ n u m e r a t i ocontendri n un objeto A t t r i b u t e que representa un atributo y sus valores. Cada elemento del o b j e t o ~ t t r i b u t es e un objeto que ha implementado la i n t e r f a z ~ t t r i b u t e(la clase I n i t i a l D i r C o n t e x t u t i l i z a o b j e t o s B a s i c A t t r i b u t e ) . E l m i t o d o g e t I D ( ) delainterfaz ~ tr i bt u t e devuelve el nombre del atributo. El mitodo g e t ~ l( )l de la i n t e r f a z ~ trt i b u t e devolveri un objeto E n u m e r a t i o n Java estindar, al que podemos acceder para obtener 10s valores del atributo individual. En todos 10s servidores LDAP hay ciertos atributos que no estarin disponibles para usuarios an6nimos debido a 10s controles de acceso sobre el servidor. Tambiin hay ciertos atributos que puede que s61o estkn disponibles para ciertos usuarios privilegiados (la escala salarial, por ejemplo, puede que sblo sea visible para el departamento de Recursos Humanos).
Busqueda autentificada El siguiente apartado muestra cbmo podemos modificar el ejemplo para una blisqueda autentificada: import import
ja v a . u t i l . H a s h t a b l e ; j a v a .u t i l .E n u m e r a t i u n ;
import import public
ja v a s . n a m i n g . *; j a v a s . r ~ a r n i n g . d i r e c t o r y .+ ; c l a s s JNDISearchAuth { tatic String t a t i c S t rirlg tatic String tatic String t a t i c S t rirlg
public public public public public
s s s s s
public
static
-
INITCTX "com.sun.jr~di.ldap.LdapCtxFact~~ry"; MY HOST = " l d a p : / / l o c a l h o k ; t : 3 8 9 " ; MGR D N = " u i d = k v a u g h a n , o u - P e o p l e , o=airius.cornn; MGR-PW = " b r i b e r y " ; MY-SEARCHBASE = " o = A i r i u s . corn";
S t r i n g MY-FILTER
=
" ( s n = C a r t e r ) ";
Capitulo 2
public static void main(String args[] 1 [ try I / / Hashtable para informacihn del rnedio Hasiltable env = new Hashtable ( ) ; / / Especlflcar la clase a utlllzar para nuestro proveedor JNDI env.put[Car~text.INITIAL~CONTEXT~FAI_'TORY, INITCTX); / / Infarmacihn de sequridad / / Nos autentifica a1 servidar env .put (Context.PROVIDER [JRL, MY HOST) ; env.put(Context.SECUR1TY AUTHENTICATION, "simple"); env.put (Context.SECURITY PRINCIPAL, MGR D N ); env.put(Context.SECURITY~CREDENTIALS, MGR-PW); //
Resto de la clase sir, alterar ClirContext ctx = new IrlitialDirCorltext( e n v );
Este segundo ejemplo de blisqueda es el mismo que el primero, except0 en que nos hemos autentificado a1 servidor. Por ello, si intenta compilar y ejecutar este ejemplo, veri que produce exactamente el mismo resultado que antes. Observe que por defect0 el servidor LDAP devuelve todos 10s atributos de la bGsqueda. Sin embargo, puede que haya ocasiones en las que no deseemos estos resultados porque s610 nos interesen ciertos atributos.
Servicios de directorio v JNDI
Restringir 10s atributos presentados En nuestro tercer ejemplo, solicitamos que s61o se muestren 10s atributos nombre comdn (cn) y direcci6n de e-mail ( m a i 1): import import
java.util.Hashtab1e; j ava. u t i l . Enumeration;
ivpqrt import public
j a v a x . naming. *; j a v a x . n a m i n g . d i r e c t c > r y. j ; c l a s s JNDISearzhAttrs {
/ / 1 m p l e r r t e r ~ t a c i ; ~ rd~e z ~ ) n t e x t o i n i c i a l p u b l i c s t a t i c S t r i n g INITCTX = "corn. s u n . j r d i . l d a p . L d a p C t x F a c t o r y Y ' ; MY-HOST = " l d a p : / / l o c a l h o s t : 3 8 9 " ; MY-SEARCHBASE = " o = A i r i u s . corn";
public public
statlc static
String String
public
static
S t r i n g MY-FILTER
=
" ( s n = C a r t e r )";
/ / E s p e c i f i c a r quk a t r i b u t ~ se s t 6 b u s c a n d o p u b l i c s t a t i c S t r i n g MYpATTKSII = [ " c n " , " r n a i l " ] ; public s t a t i c void rnain(String a r g s [ ] ) [ try i / / H a s h t a b l e p a r a i n f o r m a c i 6 n d e l rnedio H a s h t a b l e e n v = new H a s h t a b l e ( ) ; / / E s p e c i f i c a r qu6 c l a s e u t i l i r a r para nuestro proveedor e n V . p u t ( C o n t e x t . INITIALpCONTENTpFACTORRi, I N I T C T S ) ;
JNDI
e n v . p u t ( C o n t e x t . PROVIDERpURL, MY-HOST) ; / / O b t e n e r u n a r e f e r e n c i a a un c o r j t e x t o d e d i r t c t o r i o D i r C o n t e x t c t x = new I n i t i a l D i r C o n t e x t ( e n v ) ; SearchControls
constraints
=
new
SearchControls ( ) ;
cor~strair~ts.setSearct~Scope(SearchCor~trols.SUBTREE-SCOPE); Namir~gEnurneratim r e s u l t s = c t x . s e a r c h ( M Y SEAKCHBASE,MY FILTER, c o n s t r a i n t s ) ; w h i l e ( 1 - e s u i t s ! = r ~ u l l & & r e s u l t s . hasMcre ( ) ) { SearchResult s r = (SearchResult) r e s u l t s . n e x t ( ) ; S ~ L - i n gijrl = s r . g e t N a m e ( ) + ", " + MY-SEARCHBASE;
i f
" + dn);
S y s t e r r 1 . 5 u t . p r i r ~ t l r (j " D i s t i n g u i s h e d Name
is
Attributes
M Y ATTKS);
(ar
==
ar
null )
=
ctx.getAttributes (dn,
{
Systern.out.println("Entry " + d n " h a s none a f
1 else for
t
the
specified
attributes\nM);
{
( i n t i =O;i
I
Capitulo 2
Como acabamos de especificar 10s atributos nombre com6n y mail, esta vez el resultado restringido sera el siguiente:
Li diferencia entre este cddigo y nuestros ejemplos de bdsqueda anteriores es que ahora limitnmos el ndmero de atributos que deseamos recuperar. Hemos creado una matriz s t r i n g que enumeraba los atributos que deseabnmos: r ' 1 1 P 1 i c s t a t i c S t r i r i q MY-A'l'TRS[I
=
("cr~","mail");
Para recuperar este conjunto de atributos utilizamos en metodo g e t A t t r i b u t e s ( ) de la interfnz D i r C o n t e x t , donde facilitamos el DN de una entrada especifica y la matriz de atributos. Attributes
a r
c t w . q ~ t A t t r i b u t e s( d n ,
=
MY-ATTRS);
Esto devolveri un objeto Attribute. Podemos entonces recuperar un o b j e t o ~ tr ti b u t e en particular de un o b j e t o ~ t t r i b u t e s : Attribute
a t t r
=
ar.getl"cn");
Servicios de directorio v JNDI Llegados a este punto, deberiarnos enfatizar que, aunque recuperar un conjunto concreto de atributos de una entrada particular es rnuy ripido, n o resulta rnuy prictico para busquedas generales. En una busqueda LDAP general, el usuario final no va a conocer 10s Nornbres Diferenciados existentes de las entradas que esti buscando. Por ello, tendrernos que buscar en un servidor LDAP y recuperar un conjunto de entradas. En J N D I (en oposicion a Netscape Directory SDK para Java), esta busqueda devolveri todos 10s atributos asociados con cada entrada individual. Si realizarnos entonces llarnadas posteriores a getAtt r ibutes ( ) para recuperar un subgrupo corno en el ejernplo anterior, sera necesaria otra llarnada al senidor LDAP y recuperar el subgrupo de atributos. Este procedimiento es ineficiente porque requiere que utilicernos rnernoria extra para todos 10s atributos y ancho de banda extra para la cornunicacidn extra. La rnemoria extra es necesaria porque nuestra aplicaci6n debe rnantener 10s datos de 10s resultados de la busqueda LDAP para nosotros 10s procesemos. Para rneiorar el rendirniento en nuestras aolicaciones Tava. debernos reducir el volurnen de rnernoria aue utilizarnos porque el recolector de residuos de JVM puede tardar en reaccionar, o disrninuir notablernente el ritrno de la aplicacion, ya que reclama rnis mernoria. A rnedida que rnejora la capacidad del recolector de residuos y se reduce el precio de la mernoria, puede que lo utilicernos sin pensirnoslo dos veces. Sin embargo, existe otra irea potencial de problemas y se trata del hecho de que requiere que utilicernos multiples conexiones de red, alli donde s610 habriarnos utilizado una bajo un nivel rnis bajo de API LDAP. d
,
Esto no significa que no debarnos utilizar JNDI, sino que debemos cornprender las irnplicaciones de su uso. Tarnbien podernos utilizar J N D I para adadir nuevas entradas a1 senidor, elirninar entradas y rnodificar las entradas existentes. A continuacidn, exarninarernos estas operaciones.
Utilizar J N D I para aiiadir entradas a un senidor LDAP resulta, de hecho, rnis dificil que con otros SDK de LDAP. Esto se debe a que el objetivo primordial de J N D I es leery escribir objetos Java en la red. Una consecuencia de esto es que un programador debe saltar obsticulo~adicionales, corno crear una clase Java para cada tipo de entrada que quiera afiadir a1 senidor LDAP. Aqui estudiarernos corno aiiadir y rnodificar una simple entrada en el senidor LDAP pero rnis adelante, en este rnisrno capitulo, aprenderernos c6mo utilizar el senidor LDAP corno rnernoria de un objeto. Para alrnacenar una entrada en un senidor LDAP utilizando JNDI, debernos asociar un objeto a un Nornbre Diferenciado (DN). Esto significa que cada objeto que alrnacenarnos en el senidor (ya sea una sencilla entrada de persona o una clase Java serializada) debe tener un D N asociado. Recuerde que un D N es el nombre exclusivo que debe poseer cada entrada en un senidor LDAP. Si carnbiarnos a un senicio de directorio diferente (corno NDS), todavia ser6 necesario contar con un nornbre exclusivo para cada objeto. Si todo esto le parece excesivo, so10 recuerde que se convertiri en algo secundario con el tiernpo y que hacernos esto (proporcionar un nornbre exclusivo) cada vez que guardarnos un archivo en el disco duro. Ningun archivo del sistema de archivos puede cornpartir nornbre con otro archivo. Si querernos tener dos archivos con el nornbre miarchivo. txt, debernos guardarlos en directorios diferentes de nuestro sisterna de archivos; de lo contrario, una version borrari a la otra. Para alrnacenar incluso una simple entrada en el senidor LDAP, debernos crear una clase que irnplernente la interfaz DirContext. Esta interfaz define cdrno debe ser alrnacenado el objeto (ya sea una persona o una clase Java serializada) en el senidor del directorio y recuperada del senidor. Por ejernplo, si tiene un objeto Person,su clase especificari cdrno construir su D N , cdrno almacenar 10s atributos disponibles (por ejemplo, nombre cornpleto, direccidn de e-mail, nurnero de telkfono, I D de usuario, contraseria, etc.) y proporcionar varios rnecanisrnos para rnanejar 10s datos recuperados. La interfaz DirContext tarnbikn proporciona muchas forrnas sofisticadas de rnanejo de datos y es la interfaz bisica para construir un proveedor de senicios de directorio.
Capitulo 2 Del mismo modo que con cualquier otro DSK LDAP, una operaci6n de adici6n solamente puede ser ejecutada por un usuario autentificado con derechos para aiiadir una nueva entrada en el servidor. Los ACL de LDAP pueden ser configurados de modo que 10s usuarios s61o puedan aiiadir entradas en determinadas partes del irbol de directorio. Nuestra siguiente muestra de c6digo presenta una clase P e r s o n muy sencilla que implements la interfaz D i r C o n t e x t . La mayoria de 10s metodos de la interfaz no estin verdaderamente implementados (except0 ; ' para capturar excepciones) porque no 10s necesitamos en este ejemplo tan sencillo. Observe que esta clase se 'deriva del ejemplo D r i n k . j ava encontrado en el tutorial de JNDI (http://java.sun.com/products/jndi/tutorial). Los metodos que implementamos aqui, g e t A t r i b u t e s ( ) y el constructor, nos permiten almacenar/ recuperar 10s datos en una clase Person como entradas LDAP tradicionales. El resto de 10s metodos que no implementamos por completo son utilizados primordialmente para construir proveedores de servicios completes. En su lugar, simplemente capturamos excepciones aiirmando que no nos ajustamos a1 servicio concreto. Los nuevos objetos tambikn deben conformarse a1 esquema del servidor LDAP; de otro modo, las entradas no serin aiiadidas. Resultari mis ficil explicar como aiiadir una entrada con J N D I si explicamos en el c6digo a medida que vamos avanzando. Una vez mis, observe que el c6digo fuente completo de este ejemplo esti disponible para su descarga en la pigina Web de Wrox. En primer lugar, nuestra declaraci6n de clase. Fijese en que explicamos que implementaremos 10s mktodos para la i n t e r f a z D i r C o n t e x t : import j a v a . u t i l . + ; import j avax. naming . + ; import javax. naming .directory.+; public class Person implements DirContext String type; Attributes myAttrs;
1
A continuaci6n, tenemos nuestro constructor. Este constructor toma varias cadenas que utilizaremos para construir una clase de objeto i n e t o r g p e r s o n : public Person(String uid, Strinq givenname, Striri'g sn, String ou, String mail) { type = uid;
Utilizaremos la clase B a s i c A t t r i b u t e s para ahacenar nuestros atributos y sus valores. A1 especificar t r u e en el constructor Bas i c A t t r i b u t e s estamos indicindole que ignore el caso de nombres de atributos a la hora de realizar bGsquedas de nombres de atributo: myAttrs
=
n e w BasicAttributes (true);
Para aiiadir un atributo multivalor, necesitamos crear un nuevo objeto Bas i c A t t r i b u t e , que requiere el nombre del atributo en su constructor. Aiiadimos entonces 10s valores del atributo con el metodo a d d ( ) : Attribure o c = n e w BasicAttribute ("objectc1ass"); oc. add ("ir~etOrgPersoi-1") ; oc. add ( " o r q a n i z a t i o r ~ a l P e r s o r ~;" ) oc.add("person"); oc.add("top"); Attribute ouSet = new BasicAttribute("ouW); ouSet.add("People"); ouSet .add ( o u );
Servicios de directorio v JNDl
String cn
=
givenname
+
" " + sn;
Finalmente, aiiadimos todos nuestros atributos a1 objeto B a s i c A t t r i b u t e s : myAttrs .put ( o c ); myAttrs.put (ouSet); myAttrs.put("uidW, uid); myAttrs.put ("cn", e n ) ; myAttrs.put ("sn", sn); myAttrs. put ("givenriame", givenname) ; myAttrs.put ("mail", mail);
C u a n d o g e t A t t r i b u t e s ( ) es Ilamado, devuelve nuestro o b j e t o ~ a s i c ~r it bt u t e s cuando es solicitado por un nombre en forma de cadena. Esti diseiiado para devolver hicamente 10s atributos de una entrada especifica pero, puesto que esta clase s61o albergari una entrada, no va a ser Ilamada. Presentamos una manera de implementar si fuera del siguiente modo: publlc Attributes getAttributes(Strir13 name) thruws NamingException if ( ! name. equals ( " " ) ) { throw r~ew N a m e N o t F o u r l d E x c e p t l o n i i ;
{
I return myAttrs;
1 Este mttodo tiene la misma funci6n que el primer g e t A t t r i b u t e s ( ) per0 s61o es invocado cuando el nombre ha pasado el objeto Name: public Attributes getAttributes (Name name) throws NamirigException return getAttributes (name.tostring ( ) ) ;
{
I El siguiente mttodo devuelve unicamente 10s atributos enumerados en la matrizd String ids. El nombre String deberia ser un DN: public Attributes getAttributes(String name, String[] i d s ) throws NaminqExceptior~ { if ( ! name.equals("")) { throw n e w NameNotFoundExceptioni) ; 1 Attributes answer = new BasicAttributes ( t r u e ); Attribute target; for (irk i = 0; i < ids.length; i t + ) { target = rnyAttrs.get (ids[i]) ; if (target ! = null) { answer.put(target);
I 1 returrj ar~swer;
I Esta implementaci6n es similar a ]as de otros mttodos g e t A t t r i b u t e s ( ) , except0 en que toma un objeto~ame: public Attrioutes getAttributes ( N a m e name, String [ I throws NamingExceptiori {
ids)
Caoitulo 2 return
g e t A t t r i b u t e s ( n a m e . t o s t r i r ~ q( ) ,
ids);
I El metodo t o s t r i n g ( ) es utilizado para la codificaci6n: public String tostring ( return type;
)
{
Finalmente, las siguientes lineas se utilizan para implementar metodos que un proveedor de servicios
JNDI (como la clase I n i t i a l D i r C o n t e x t ) utilizaria para proveer a una aplicaci6n de semicios tales como lectura de entradas desde el directorio o la autentificaci6n a1 servidor: //
No u t i l i z a d o p a r a e s t e e j e m p l o p u b l i c O b j e c t l o o k u p (Name n a m e ) t h r o w s N a m i n g E x c e p t i o n t h r o w new O p e r a t i o n N o t S u p p o r t e d E x c e p t i o r ~( ) ;
{
1 p u b l i c O b j e c t l o o k u p ( S t r i r i g name) t h r o w s N a m i n g E z c e p t i o n t h r o w new OperationNotSupportedException ( ) ;
{
I p u b l i c v o i d b i n d ( N a m e name, O b j e c t o b j ) t h r o w s t h r o w new O p e r a t i o n N o t S u p p o r t e d E x c e p t i o r ~ ( ) ;
NamingException
{
I El c6digo fuente completo para este ejemplo y para todos 10s ejemplos de este libro esti disponible para su descarga en http://www.wrox.com/ o en http://www.AnayaMultirnedia.es.
.
A continuaci6n, demostramos la clase J N D I A ~j ~ a v a , que utiliza la clase P e r s o n , desarrollada anteriormente, para ahadir una entrada de Mark Wilcox a1 servidor LDAP (ya hemos visto gran parte de este c6digo) : import import
java.util.Hashtable; j a v a . u t i l . Enurneratior!;
import import
ja v a x . n a m i n g . * ; javax.naming.directoryYi;
public
class
JNDIAdd
{
/ / Implementacihn d e contexto p u b l i c s t a t i c S t r i n g INITCTX public public public public
irllcial "corn. s u n . j r ~ d i l. d a p . L d a p C t x F a c t o r y W ;
=
s t a t i c S t r i n g MY-HOST = " l d a p : / / l o c a l h o s t : 3 8 9 " ; = "uid=kvaughan, ou=People, s t a t i c S t r i r ~ g MGR-DN s t a t i c S t r i n g MGR-PW = " b r i b e r y " ; s t a t i c S t r i n g MY-SEARCHBASE = " o = A i r i u s . corn";
p u b l i c s t a t i c void main(Strir1g a r q s [I ) { try i / / H a s h t a b l e p a r a i r ~ f o r m a i c b n d e l medio H a s h t a b l e e n v = new H a s h t a b l e ( ) ; / / E s p e c i f i c a r qu6 c l a s e u t i l i z a r p a r a rluestro
proveedor
o=airius.cornW;
JNDl
~ ~ ~ . ~ U ~ ( C ~ ~ I ~ ~ X ~ . I N I T I A L ~ ~ C O NI N T IETX CTX ~)F; A C T O R Y , er~v.put(Context.PROVIDERenv.putiContext.PROVIDER_URL,MYHOSTI;URL,MYYHOST); e n v . p u t ( C o r ~ t e x tS.E C I I R I T Y Y A U T H E N T I C A T I O N , " s ~ m p l e " ; e r l v . p u t ( C o n t e x t . SEC~JRITYYPRINCIPAL,14GRRDN) ;
r e f e r e n c i a p a r a un c o n t e x t o d e new I n i t i a l D i r C o n t e x t ( e r h v ) ;
directorio
=
P e r s o n ( " m e w i l c o x " , "Mark", "Wilcox", "ou=Accounting", " m e w i l c o x @ a i r i u s .corn") ;
c t x . b l n d ( " u i d = m e w l l c o x ,o u = P e o p l e , o = a i r i u s . o m , catch(Exceptior1 e ) { e.printStackTrace ( ) ; S y s t e m . e x i t ( 1 );
p);
I I 1
En primer lugar, debernos crear un nuevo objeto Java que irnplernente la interfaz DirContext igual que nuestra clase Person del siguiente rnodo: Person
p
=
new
Persori("rnewilcox", "Mark", "Wilcox", " o u = A c c o u r ~ t i n y " , " r n e w i l c o x @ a i r i u s .corn") ;
Entonces asociarnos un nornbre (especificarnente el D N de la entrada) a este objeto en nuestro contexto actual con el metodo bind ( ) de la interfaz DirContext del siguiente rnodo: c t x . b i n d ~ " u i d = r n e w i l c o x , o u = P e o p l e ,o = a i r i u . c o r n ,
p);
La interfaz Ini tialDirContext realizari una operation de adicion LDAP. Tornari todos 10s atributos que hernos situado en nuestra clase Java y 10s codificari para su transferencia a un servidor LDAP. Corno hernos utilizado la clase BasicAttributes para construir nuestros atributos, Cstos serin alrnacenados/recuperados corno datos LDAP estindar y no corno puros objetos Java. Esto significa que si alrnacena sus datos LDAP de este rnodo, cualquier otro cliente LDAP, independienternente de que estC escrito en C , Per1 o Visual Basic, todavia podri acceder a ellos. DespuCs de cornpilar y ejecutar con Cxito nuestros archivos de clase Person. j ava y JNDI .j ava, podernos ver el resultado exarninando nuestro directorio airius .corn del servidor Netscape Directory Server. En 61 deberiarnos poder ver nuestra nueva entrada:
i M d W & Tyler
A
Pee TY(Cr
A L€eurrh A Randy Uhch A Jell Vnu$m A UrstmVcq#Im
+ Mahwv-
A Jell v ~ d ~ r A Andy
w*o
C BTsJWa*?r
A b w Walrcf A Jomwsr A CecsW s b x a ~uqwtvace A DaWWd iEncwad
C ~
c u s A 7obaW d A PJanwc
~
d
Haciendo doble clic en el nombre destacado, podemos comprobar que todos nuestros detalles han sido afiadidos de acuerdo con nuestro c6digo:
Modificar una entrada Tan pronto como afiada una entrada a un servidor LDAP, necesitari modificarla. Los motivos pueden ser diversos, incluido un cambio en la contraseria de usuario, la actualizaci6n de la configuraci6n de una aplicaci6n, etc. Las modificaciones realizadas a una entrada se hacen con las clases Modi f i c a t i o n 1t em y Bas icAtt r ibut es. Cuando realizamos una modificaci6n, h a puede ser de tipo A D D (ariadir), REPLACE (reemplazar) o DELETE (borrar). La modificacion REPLACE ariadiri un atributo si 6ste no existe todavia.
Tambikn debemos ser conscientes de que si realizamos un reemplazamiento en un atributo que tiene multiples valores sin enviar 10s valores extra junto con nuestro valor de reemplazamiento, todos 10s valores s e r h eliminados. -
--
-
Una vez mis, las modificaciones deben ser realizadas por un usuario autentificado y tales modificaciones" que pueden realizarse estarin determinadas por 10s derechos que la entrada asociada tiene sobre una entrada determinada. Por ejemplo, 10s usuarios pueden generalmente cambiar sus contraseiias per0 no pueden cambiar nada mis, mientras que 10s asistentes administrativos normalmente pueden modificar n ~ m e r o sde tel6fono y direcciones de correo. Normalmente se necesita un administrador de bases de datos para realizar tareas tales como cambiar un I D de usuario. El c6digo que se muestra a continuacih muestra c6mo podemos modificar 10s atributos de la entrada de Mark Wilcox que aiiadimos en el ejemplo anterior: ~rnportjava.utl1 .Hashtable; import j ava. u t i l . Enu~neratior~; import import
j a v a x . n a r r ~ i r c q .' ;
public
class
j avax. r~amir~g.directory * ;.
JNDIMod
{
/ / Implernentaci6n d e c.jrjte,.ti p u b l i c s t a t i c S t r i n g IIIITSTX public public public public
s s s s
public
static
tiy
t t t t
a a a a
t t t t
i i i i
c Strinq c String c String c String
inicial =
"com.sun.jr~di.1dap.LdapCtory";
MY-HOST = "ldap://localhost:389"; "uid=kvaughan, su=People, MGR-DN MGR-PW = " b r i b e r y " ; M Y -SEARCHBASE = " o = A i r i u s . c o m " ;
-
v ~ i dr n a i n ( S t r i r 1 q
o=airius.
LXIII";
args[]) {
I
//
H a s h t a b l e par a l n f ~ r m a c l h n d e l H a s h t a b l e env = new H a s h t a b l e i ) ;
medlo
//
E s p e c i f i c a r que c l a s e u t i l i z a r para n u e s t r o proveedor e n v . p u t ( C o n t e x t . I N I T I A L ~ C 0 N T E X T T F A C T O P P P f ,INITCTX) ; env. put erl.J.put erjv. p u t env. put
//
JNDI
( C o n t e x t . PROVIOER URL, M Y HOST) ; ( c o n t e x t . SECIJRIT
Obtener DirContext
una ctx
r e f e r e n c i a p a r a un c o n t e x t o d i r e c t o r i o rlew I n i t i a l D i r C o n t e x t ( e r ~ ' ~ ) ;
new BasizAttribute ("telephor~er~umber", "940-555-2555"); new RasicAttribute("l", "Waco");
new Modificatior~Item(DirContext.REPLACE ATTRIBUTE, mod0) ; new ModificatioriItem( DirContext .ADD ATTRIBIJTE, mod1 ) ;
/ / DirContext. DELETE ATTRIBUTE not showr, here ctx.modifyAttriljutes("uid=mewi~zox,nu=Peop?e,o=airius.com", m o d s ) ; catch(Exception e ) [ e.printStackTrace ( ) ; System.exit ( 1 ) ;
i
Para rnodificar una entrada utilizarnos la c ~ a s e ~ o d i f i c a t i o n ~ La tem c~ase~odification~temtorna un tipo de modificaci6n (por ejernplo ADD, REPLACE o DELETE) y un objeto A t t r i b u t e como B a s i c A t t r i b u t e . ~ s t es e un ejernplo que nos perrnite afiadir un nuevo atributo, localidad (el atributo l), con un nuevo valor de "waco" en la entrada: Attribute modl = new RasicAttribute ("l", "Waco") ; m o . 3[l ~ j = new Mo~3ificationItemlPirContext .ADLl-ATTRIBUTE, modl) ;
La rnodificacion real es realizada por el mCtodo D i r C o n t e x t , m o d i f y A t t r i b u t e s tenernos un ejernplo de este proceso:
()
. A continuaci6n,
ct:i.modif yAttributes ( " ~ ~ i d = m e w i l c ~ou=People,o=airius. ;x, corn", mods) ;
Una vez mls, se modifica la entrada en un sewidor LDAP utilizando LDAP tradicional y no corno objeto de mod0 que cualquier otro cliente puede todavia acceder a estos datos. Esta vez, cuando examinemos la entrada de Mark Wilcox en el Senidor Directorio y hagarnos clic en A d v a n c e d ...p ara obtener una visi6n detallada, verernos que el ncmero de teltfono y la localidad han sido afiadidos a1 directorio:
Servicios de directorio v JNDl
File
Edit
View
-
.--
Email address First name Full name
- .
-.
. .
I mew~kox@air~us.com
1
1 Mark 1Msrk Wllcox
~ a sname t lw~lcox
Object class
Organizational Unit
I I
1 organizationalPerson person
1ou=Accounting
Telephone number 1930-555-2555
I
User ID
) mew~lcox OK
I
Cancel
I
Help
I
Eliminar una entrada Finnlmente, necesitari eliminar las entradns de su servidor LDAP. Esto s e consigue ficilmente invocando el n1Ctodo des t rovcontext ( ) de la interfaz Dircontext. con el nombre diferenciado d e la entrada que necesita ser climinada. Normalmente, las operaciones de borrado estln restringidas a los administradores de bases de datos LDAP. kste es nuestro ejemplo modificado para eliminar una entrada:
Capitulo 2
public
static
S ~ L - i r i gMY-ENTRY
=
"uid=mewilcox,
o u = P e o p l e , o=ai r i u s . com";
p u b l i c s t a t i c ;/(?id mail~l!Strirlg a r g s [ ] ) { try i / . ' H a s h t a b l e p a r a i n f o r m a c i S n d e l medio H a s h t a b l e erlv = r~tew H a s h t a b l e ( ) ;
//
O t i t ? r ~ e r una D i r C ~ > r j t e x tc t x
]
~ ? f e r e r t c i a paL-3 un c o n t e x t o d e rlew I n i t i a l D i r C o r , t e x t (env) ;
Jirectorio
=
c t x . J e s t r o b - S u b c o n t e x t ( M Y -ENTRY) ; catrh(Exception e ) { e.printStackTrace ( ) ; System.txit(1);
!
La unica diferencia real del c6digo de este ejemplo es esta linea:
Por ello, despuks de compilar y ejecutar este programa, borrari nuestra entrada del servidor LDAP Hasta aqui, esto ha sido un vistazo a vuela pluma sobre LDAP. Si quiere mis informacidn existen un gran n6mero de fuentes. Wrox Press ha dedicado por completo un libro a este tema, Implementando LDAP 71-por Mark Wilcox, ISBN 1-261002-21-1, o bien puede consultar la Web del GurG de LDAP en la direcci6n http://www.Idapguru.com/
Almacenar y recuperar objetos Java en LDAP Uno de 10s atributos mis importantes de JNDI es su capacidad para utilizar la red como almacin de objetos. Esto significa que podemos utilizar la red para compartir objetos Java con versiones distribuidas de una aplicaci6n o con aplicaciones dispares. Por ejemplo, podriamos crear una clase que calcule el impuesto de venta sobre un articulo. Este tip0 de clase podria ser utilizado potencialmente por nuestro departamento de ventas para crear 6rdenes de compra y por nuestra oficina de contabilidad para hacer sus cuentas. Podemos utilizar casi cualquiera de 10s proveedores J N D I disponibles para almacenar nuestras clases, pero uno de 10s modos mis Gtiles es utilizar un servidor para que realice este proceso. Existen varias razones por las que preferiria utilizar LDAP como su almacin de datos: O Ventaja de un recurso centralizado existente
Ventaja de normas abiertas existentes LDAP esti disponible en la red "fuera de la caja" LDAP esti optimizado para un acceso de lectura extremadamente ripido
Servicios de directorio v JNDI O
LDAP tiene un fuerte sistema de seguridad incorporado
J N D I le permite almacenar diversos tipos de objetos relacionados con Java en el senidor LDAP: 0
Entradas del directorio LDAP estindar Proporciona la capacidad de manipular 10s datos del directorio estindar ( i n e t o r g p e r s o n , g r o u p O f U n i q u e N a m e s , o b j e c t c l a s s e s , etc). Los datos del directorio estindar son de menor tamafio (y, por lo tanto, rnis ficil de acceder y de modificar) y pueden ser compartidos entre diferentes lenguajes. La capacidad de mantenerse neutral con respecto a1 lenguaje con datos de directorio es de vital importancia en una gran empresa, donde varios lenguajes diferentes (por ejemplo, Java, C / C + +, Visual Basic, Cobol, etc.) pueden ser utilizados para el desarrollo de programas.
0
Obietos lava serializados , " Nos proporciona la capacidad de almacenar y recuperar objetos Java que han sido serializados (10s obietos actuales Y todas las clases relacionadas Y almacenadas en formato binario) en el senidor LDAP. Probablemente, el formato rnis ficil de utilizar pero tambiCn el que requiere mayor ancho de banda y espacio de almacenamiento. Este formato s610 es comprensible por Java en apoyo a la persistencia de objetos. Los dos usos rnis comunes de objetos Java serializados son 10s objetos EJB y JDBC Datasource.
0 Referencias
Como ya hemos debatido anteriormenre, las plataformas de procesamiento distribuido como CORBA y RMI utilizan registros para registrar las clases de objetos que exponen. Sin embargo, estos registros no facilitan la capacidad de buscar en ellos y le obligan a codificar la posici6n del senidor en la aplicaci6n. U n objeto R e f e r e n c e de Java permite almacenar datos en el senidor del directorio como referencia indirecta a la verdadera posici6n del objeto. Por ejemplo, podria tener un objeto almacenado en tiempo real en un senidor RMI. En lugar de codificar la posici6n del registro RMI en la aplicaci6n, puede conectar a un senidor LDAP y localizar el objeto " c n = R e a l Time S t o c k Q u o t e " , que contiene el URLRMI para el objeto stock. Esto reduce la necesidad de recompilar la clase cada vez que desplace la clase stock a un registro diferente y facilita la lectura del c6digo. La opcion a utilizar para almacenar 10s objetos dependeri de la aplicaci6n que esta construyendo y de como necesita acceder a 10s datos. Estudiaremos estos tres objetos con rnis detalle en las siguientes secciones.
LDAP tradicional Las organizaciones desearin a menudo acceder a 10s datos del senicio de directorios desde varios clientes utilizando lenguajes diferentes. U n uso muy extendido de un servicio directorio es el de autentificaci6n de usuario. Resulta obvio que almacenar datos de autentificaci6n de usuario en un formato que s61o Java puede utilizar reduce el nhmero de aplicaciones que pueden hacer uso del directorio para autentificacion. Esto, a su vez, aumenta el coste de 1as actividades empresariales porque en ese caso necesita otro servicio de directorio para facilitar senicios de autentificacidn a aplicaciones que no pueden acceder a objetos Java. Algunas aplicaciones n o necesitarin autentificaci6n per0 podrin beneficiarse del listin de direcciones del servicio de directorio. Por ejemplo, su programa de e-mail puede utilizarlo para encontrar la direcci6n de e-mail de compaiieros de trabajo, su departamento de marketing puede utilizarlo para crear cartas de formato fusionado, mientras que 10s desarrolladores Web pueden utilizarlo para crear un portal adaptado a cada usuario. Cada una de estas aplicaciones puede construirse utilizando Java como lenguaje de desarrollo. Fundamentalmente, su compaiiia puede
Capitulo 2 reducir significativamente su sobregasto manteniendo datos constantes sobre sus empleados y sus clientes en una base de datos central. Una de las ventajas de almacenar datos de este mod0 es que es posible tratar cada entrada como un objeto en Java per0 otros lenguajes no tienen por quk estin orientados a objetos para poder acceder a 10s datos.
Java serializado Sin embargo, si tenemos un numero creciente de aplicaciones Java que necesitan acceder al repositorio central de objetos Java preconstruidos, podemos utilizar la serialization Java para almacenar esos objetos en el senidor LDAP. Entonces, cuando una aplicacion necesita un objeto determinado (por ejemplo, un dispositivo de representacidn 3D), puede recuperarlo del senidor LDAP, s61o cuando sea necesario, y luego recuperarlo. Otra caracteristica positiva es que, a la hora de actualizar el dispositivo de representacibn, todas las aplicaciones que estin utilizando el dispositivo tendrin acceso a la actualizaci6n sin tener que remendar las aplicaciones finales.
Referencias Java Finalmente, si nos encontramos en un medio dominado por Java, puede que queramos aprovechar las ventajas de las referencias Java. Las referencias reducen 10s requisitos de almacenamiento y ancho de banda para almacenar y recuperar entradas porque no almacenan el objeto completo en el directorio; en su lugar, so10 almacenan componentes clave necesarios para reconstruir el objeto en una clase factoria. C o n frecuencia, 10s componentes almacenados son un U R L que apunta a la verdadera l o c a h a c i 6 n del objeto. Por ejemplo, si creamos un objeto de impresora estindar, podemos construir un P r i n t e r F a c t o r y que puede adoptar 10s siguientes parimetros: O
Localizaci6n de la red
o Opciones de color (monocromo, en color) 0 E~~ecialidades (postdatas, plotter grifico) O Estado actual (sin papel, on-line)
Estos parimetros pueden ser trasladados a P r i n t e r F a c t o r y y siempre devolverin un objeto P r i n t e r que nuestra aplicaci6n puede utilizar para imprimir. Reduce el ancho de banda y el almacenamiento porque solo es necesario almacenar 10s parimetros anteriores. Resultan mis ficiles de manejar para un programador de aplicaciones porque parte de la referencia es el nombre del paquete completamente cualificado, por lo que no tenemos que incluirlo con nuestra aplicaci6n; s610 necesitamos asegurarnos de que JVM puede encontrar el paquete.
Si desea ma's informaci6n sobre el uso de J N D I y L D A P como almacin de objetos Java, puede dirigirse a la pagina oficial J N D I en http:l/java.sun.com/jndi.
Aunque LDAP es una parte importante de una red de senicios de Internet y, a pesar de que mucha gente utiliza J N D I para poder utilizar LDAP en sus aplicaciones Java, LDAP no es la linica opcidn disponible.
Servicios de directorio y JNDI LDAP tiene sentido cuando es necesario gestionar information demogrifica que no cambia per0 que, con mucha frecuencia, es necesario acceder a ella muy ripidamente. Sin embargo, hay ocasiones en las que se necesita acceder a datos que no pueden ser almacenados en LDAP, como es el caso de las entradas DNS o Enterprise JavaBeans. Aunque el resto del capitulo se centra en el servicio de nombres de dominio, Domain Naming Service (DNS), debemos sefialar que fuera de LDAP, el lugar en el que utilizaremos J N D I con mis frecuencia es EJB y otros servicios J2EE de un servidor de aplicacion. Veremos algunos ejemplos mis adelante. La raz6n por la que nos centramos en D N S en este momento, en oposicion a una muestra J2EE completa, es que 10s ejemplos de este capitulo esperan demostrar la flexibilidad de J N D I a1 utilizar ejemplos mis sencillos de 10s que seria posible utilizar con EJB.
Ejemplo de aplicacion DNS Para demostrar como utilizariamos las mismas clases J N D I bisicas per0 con diferentes proveedores de servicios, presentaremos una variation de la aplicacion JNDISearch que ya utilizamos en nuestra secci6n LDAP.
Para esta secci6n se requiere el proveedor de servicios J D N I D N S que se encuentra disponible en Java Developer's Connection y que sera' incluido en J D K 1.4 (ya esta' disponible en la instalaczdn de J D K 1.4 beta). Los archivos relevantes son d n s . j a r y p r o v i d e r u t ils . jar, que deberian localizarse en classpath a1 ejecutar el prograrna. Tanto LDAP como D N S tienen entradas. A cada entrada se accede mediante un nombre exclusive (en LDAP, es el Nombre Diferenciado, y en DNS, el nombre canbnico). Ambos servicios son construidos en jerarquia; recuerde que ksta es una de las caracteristicas de un servicio de directorio. D N S tiene un mod0 perfectamente definido de construir el irbol (empezando por 10s dominios del nivel superior como .com, .es, .net, seguidos por dominios de segundo nivel como yahoo. com, seguidos por subdominios y anfitriones). LDAP, por otro lado, no tiene reglas establecidas para construir sus estructuras de irbol (por ello encontrari D N S tipo o=Acme Inc, c=US o o=acme . corn o dc=acme,dc=com). Ambos servicios tienen entradas que contienen atributos con uno o mas valores. LDAP tiene clases de objetos que pueden definir diferentes tipos de entradas. D N S so10 contiene entradas en referencia a anfitriones de Internet. LDAP tiene un potente modelo de seguidad basado en autentificacion; DNS no lo tiene. Ya hemos examinado 10s fundamentos de esta aplicacion anteriormente, por lo que no invertiremos mucho tiempo explicando 10s detalles. Nos centraremos en las partes especificas de DNS. import import
java.util.Hashtable; java . u t l l . Enumeratior~;
import import
j a v a x . naming. *; ja v a x . naming . d i r e c t o r y .
public
class
public
try i //
JNDISearchDNS
s t a t i c void
*;
{
main ( S t r i n g a r g s [ ]
Hashtable para informaichn d e l H a s h t a b l e eriv = new H a s h t a b l e i ) ;
)
{
medio
Capitulo 2 Observe que estamos cambiando nuestra factoria de proveedor de c o m . s u n . j n d i . d n s . L D A P C t x f a c t o r y a c o m . s u n . jndi.dnsContextFactory.Puestoque estamos cambiando nuestra factoria, necesitamos cambiar nuestro proveedor URL asi como cambiar de l d a p : / / a d n s : / / . Los nGmeros 12 9.120.210.252 hacen referencia a la direcci6n I P del servidor D N S con el que nos comunicaremos: //
E s p e c i f i c a r q u 6 c l a s e u t i l i z a r p a r a n u e s t r o p r o v e e d o r JNDI env.put ("java.narning. f a c t ~ r y ~ i r ~ i t i a l " , " c o m . s u n . j n d i . d n s . D n ~ C 0 n t e ~ t F a ~ t 0 r;y " ) e n v . p u t ("java.r~arning.provider.ur1", " d n s : / / 1 2 9 . 1 2 0 . 2 1 0 . 2 5 2 / " 1 ;
La variable instancia, d n s - a t t r i b u t e s , contiene la lista de atributos que deseariamos obtener de un determinado host, pero existe garantia alguna de que todos estos atributos estin a nuestro alcance. Por ejemplo, si el servidor no es un servidor de correo, n o tendri registro XM. 0 puede que el administrador DNS n o tenga la informaci6n O S en el campo H I N F O (abajo) por razones de seguridad (si un intruso puede determinar el O S host para una determinada miquina, entonces podria centrar su ataque utilizando herramientas para violar el O S en cuesti6n): String
dns-attributes
[I
=
{
"MX", " A " , "HINFO" ]
;
Aqui obtenemos el objeto inicial D i r C o n t e x t e intentamos recuperar 10s atributos para el host llamado www .u n t edu:
.
/ / Obtener DirContext Attributes
u n a r e f e r e n c i a p a r a un c o n t e x t 0 d e d i r e c t s r i o c t x = new I n i t i a l D i r C o n t e x t ( e n v ); a t t r s l = ctx.getAttributes("www.unt.edu", d n s -a t t r i b u t e s ) ;
A continuacion, comprobamos que obtenemos algo de DNS. La raz6n por la que podemos no obtener resultados es que puede que no haya anfitriones que coincidan con nuestro hostname en el servidor DNS. i f }
( a t t r s l == n u l l ) 1 Systern.out . p r i n t l n ( " h o s t else {
has
none
of
the
speclfled
attributes\nn);
Ahora imprimimos nuestros resultados, utilizando el mismo algoritmo que hemos utilizado antes: f o r (itnt : = 0 ; z c d n s a t t r i b u t e s . l e n g t h ; z + + ) { Attribute a t t r = a t t r s l .get (dns attributes [z]) ; i f
( a t t r != n u l l ) { S y s t e m . o u t . p r i n t ( d n s a t t r i b u t e s [ : ] t": " ) ; f o r ( E n u r n e r a t i o r , v a l s = a t t r . g e t A l 1 ( ) ; v a l s . h a s M o r e E l e r n e n t s ( ) ;) S y s t e r n . o u t . p r i n t l r ~ ( v a l s . r ~ e x t E l e r n e( nj t) ;
1
I
]
catchiException e ) { e.printStackTrace ( ) ; S y s t e r r ~ e. x i t ( 1 );
1
La captura de pantalla que aparece a continuacion muestra 10s datos que probablemente reciba de DNS:
{
Servicios de directorio y JNDI
En este ejemplo, hay dos atributos para la entrada D N S que coinciden con www.unt.edu. Hay un registro A que indica la direccion I P del host y hay un registro H I N F O , que afirma que el servidor ejecuta actunlmente U N I X . C o m o puede ver, el cambio d e prowedores en J N D I resulta realmente ficil.
Resumen Los servicios de directorio son una parte importante del entorno de servicios en red. Los directorios proporcionan la capacidad para asociar nombres comprensibles (y recordables) para el usuario con la infornlaci6n que 10s ordenadores necesitan procesar (por ejemplo, nombres d e dominio para direcciones I P o nombres cornunes para referencias Java). T a m b i h nos permiten buscar direcciones d e e-mail y asociar permisos para entornos seguros. L D A P nos ofrece u n protocolo de red estindar para comunicar con servicios de directorio, mientras que J N D I proporciona un API estindar para que Java se comunique con LDAP y con servicios de directorio especializados que n o son accesibles via L D A P (como DNS). DespuCs d e esta breve introdi1cci6n a 10s servicios de directorio, J N D I y LDAP, debe tener una visibn general d e 10s principios bisicos y ya pueda aventurarse en su uso a partir de aqui. Continuaremos nuestro viaje a travks d e algunos d e 10s elementos fundamentales d e la programaci6n de empresn en el siguiente capitulo, examinando con detenimiento el procesamiento condicionado por R i i I .
Procesamiento distribuido
El procesamiento informitico distribuido se ha convertido en un tkrmino frecuente en el vocabulario de programaci6n actual. Hace referencia a1 paradigma de diseiio de aplicaciones en el que 10s programas, 10s datos que procesan y las computaciones reales se extienden por la red, bien para aprovechar el poder de procesamiento de multiples computadoras o debido a la naturaleza inherente de una aplicacion que comprenda diferentes m6dulos. RMI (Remote Method Invocation) permite la comunicaci6n objeto-objeto entre diferentes miquinas virtuales Java, Java Virtual Machines (JVM). Las JVM pueden ser entidades distintas situadas en el mismo o en diferentes ordenadores; incluso una JVM puede invocar mktodos pertenecientes a un objeto almacenado en otra JVM. Esto permite a las aplicaciones invocar mktodos de objetos localizados remotamente, compartir recursos y procesar cargas en sistemas. Los mktodos pueden incluso aprobar objetos que una miquina virtual no ha encontrado nunca, permitiendo la carga dinimica de nuevas clases cuando sea necesario. Esta es realmente una caracteristica muy fitil. Si queremos que dos aplicaciones Java se ejecuten en diferentes miquinas virtuales para que se comuniquen entre si, existen otros dos enfoques de base Java ademis de M I :
o Sockets 0 Java Message Service (JMS)
La programaci6n bisica de red con Sockets es flexible y suficiente para la comunicaci6n entre programas. Sin embargo, requiere que todas las partes implicadas se comuniquen via protocolos referentes a aplicaciones, cuyo diseiio es complejo y puede ser susceptible de errores. Por ejemplo, consideremos una aplicaci6n cooperativa, como una sencilla aplicaci6n de chat, por ejemplo: para que participen multiples clientes primer0 necesitariamos diseiiar a l g h tip0 de protocolo y desputs utilizar Sockets para comunicarse en ese protocolo con el servidor. M I , por otro lado, es un sistema distribuido que utiliza Sockets internamente sobre TCP/IP.
Capitulo 3 La diferencia entre RMI y JMS es que en RMI 10s objetos quedan residentes y estin asociados a las miquinas virtuales (aunque 10s argumentos de mktodo y 10s retornos, asi corno 10s stubs, viajan por la red), rnientras que en JMS 10s rnensajes (objetos) viajan asincr6nicarnente por la red desde una JVM a otra.
La arquitectura RMI Antes de estudiar c6rno funcionan 10s mecanisrnos RMI, definarnos algunos tkrrninos utilizados con frecuencia.
Para citar la especificaci6n, "En el modelo de objeto distribuido de Java, un objeto remoto es un objeto cuyos mitodos pueden ser invocados desde otra miiquina virtual de Java, potencialmente en un host diferente. Un objeto de este tip0 es descrito por una o miis interfaces remotas, que son interfaces Java que declaran 10s mitodos de un objeto remoto. La invocaci6n de mitodos remotos, Remote Method Invocation (RMI), es la acci6n de invocar un mitodo de una interfaz remota en un objeto remoto." El prop6sito de RMI es crear objetos en distintas JVM y actuar corno objetos locales. La JVM que invoca a1 objeto remoto es conocida norrnalrnente corno un cliente y la JVM que contiene el objeto rernoto es el servidor. U n o de 10s aspectos rnis importantes del disefio RMI esti en su deseada transparencia. Las aplicaciones no saben si un objeto es rernoto o local. Una invocaci6n de metodo en un objeto rernoto tiene la rnisrna sintaxis que una invocaci6n de rnktodo en un objeto local, aunque en el fondo sucede rnucho de lo que alcanza la vista.
En RMI, el tirmino "servidor" no hace referencia a un servidor fisico o a una aplicaci6n sin0 a un finico objeto remoto que tiene mitodos que pueden ser invocados remotamente. De un mod0 similar, el tirmino "cliente" no hace referencia a una miquina cliente sino que en realidad se refiere a1 objeto invocando un mitodo remoto en un objeto remoto. El mismo objeto puede ser tanto un cliente como un servidor. Aunque obtener una referencia a un objeto rernoto es ligerarnente diferente a obtenerla para objetos locales, una vez tenernos la referencia, utilizarnos el objeto rernoto corno si fuera local. La infraestructura de RMI interceptari autorniticarnente la llarnada del mitodo, encontrari el objeto rernoto y procesari la solicitud remotarnente. Esta transparencia de posici6n inchye incluso recoleccidn de residuos.
A un objeto remoto siempre se accede a travis de su interfaz remota. En otras palabras, el cliente invoca mitodos en el objeto s610 despuis de asignar la referencia a la interfaz remota. La implernentaci6n RMI es construida esencialrnente a partir de tres capas de abstracci6n:
Capa de Stubs/Skeletons Esta capa intercepta llamadas de metodo realizadas por el cliente a la referencia de la interfaz y redirige estas llamadas a un objeto rernoto. Es conveniente recordar que 10s stubs son especificos del lado cliente, rnientras que 10s skeletons se encuentran en el lado servidor. 0
Capa de referencia remota
Procesamiento distribuido con RMI Esta capa maneja 10s detalles relacionados con la interpretaci6n y la gesti6n de referencias realizadas por clientes a 10s objetos remotos. Conecta clientes con objetos remotos que estin siendo ejecutados y exportados en un senidor por un vinculo de conexidn uno-a-uno. Capa de transporte Esta capa esti basada en conexiones TCP/IP entre miquinas de una red. Proporciona conectividad bisica, asi como algunas estrategias de penetraci6n de cortafuego.
0
El siguiente diagrama muestra estas tres capas, junto con una interrupci6n de la capa de transporte. Las descripciones de la parte derecha representan las capas OSI (OSI esti descrito de forma concisa en http:// www.webopedia.com/rERMOS/OSl. htrnl):
.
. I
,
Capa de apl~caclon,
I Objeto rernoto
rnetodo en el
Ii
0bjet0 rernoto
I
.t
/
Stub
I
4
A Capa de referencla remota
t
Capa de presentaclon
Skeleton
f
Capa de referencla
I
rernota
4L
I
Capa de seslon
Capa de transporte
Capa de red
, I
lnterfaz de hardware
+
lnterfaz de
1
hardware
j
Capa de vinculos de datos
Esta arquitectura en capas proporciona una buena flexibilidad de implementacidn sin afectar a la arquitectura de aplicaci6n. Cada una de las capas pueden ser reforzada o reemplazada sin afectar a1 resto del sistema. Por ejemplo, la implementaci6n de la capa de transporte puede ser reemplazada por un distribuidor con el protocolo User Datagram Protocol (UDP) en lugar de TCP, sin afectar a las capas superlores.
A continuacidn, examinaremos algunas de estas capas mis detenidamente.
Capa de Stub y Skeleton Para conseguir la transparencia de posici6n, RMI introduce dos tipos especiales de objetos conocidos como stubs y skeletons que cumplen las funciones de una interfaz entre una aplicaci6n y el resto del sistema RMI. El prop6sito de esta capa es transferir datos la Capa de Referencia Remota mediante marshaling (disposici6n) y unmarshaling. Marshaling hace referencia a1 proceso de convertir 10s datos u
objetos transferidos en flujo de bytes y desempaquetando, que es el proceso contrario, es decir, convertir el flujo en un objeto o en datos. Esta conversi6n se consigue mediante serializaci6n de objetos. La capa de stubs y skeletons de RMI se encuentra justo por debajo de la apkaci6n en si y esti basada en el modelo de disefio Proxy. En el uso RMI del modelo Proxy, la clase stub desempefia el papel del proxy para la implementacion del servicio remoto. El skeleton es una clase asistente generada por RMI para ayudar a1 objeto a comunicarse con el stub en el vinculo RMI. El skeleton mantiene una conversaci6n con el stub; lee 10s parimetros para la llamada de mktodo desde el vinculo, realiza la llamada a1 objeto de implementaci6n del servicio remoto, acepta el valor de vuelta y graba el valor de vuelta en el stub. Resumiendo, el modelo Proxy fuerza las llamadas de mitodo a travks de un proxy que actua como sustituto, delegando todas las llamadas en el objeto real de mod0 transparente para el llamador original Detalles espec$cos sobre el diseiio de me'todos proxy estan mks alli del objetivo de este libro, pero pueden encontrarse en Diseiio de Me'todos, Elementos reutilizables de software orientado a objetos Erich Gamma, et. al. ( I S B N 0-201-63361-2) o me'todos en Java: U n catklogo de diseiios de me'todos reutilizables ( I S B N : 0-471333-15-8).
Analicemos ahora 10s stubs y 10s skeletons con mas detalle.
El stub es un objeto del lado cliente que representa (o actua como un proxy para) el objeto remoto. El stub tiene la misma interfaz, o lista de mktodos, que el objeto remoto. Sin embargo, cuando el cliente invoca un mktodo stub, el stub envia la solicitud mediante la infraestructura RMI al objeto remoto (via skeleton), que es el que realmente la ejecuta. El siguiente apartado enumera la secuencia de eventos ejecutados por el stub en detalle: 0
Inicia una conexi6n con la VM remota que contiene el objeto remoto
0
Escribe y transmite (marshaling) 10s parimetros en la VM remota
0
Espera el resultado de la invocaci6n de mktodo
0
Lee (unmarshaling) el valor de vuelta o la excepci6n de retorno Devuelve el valor a1 llamador
El stub oculta la serializaci6n de 10s parimetros del mktodo (10s parimetros deben ser serializables; el paso de parimetros seri estudiado detenidamente posteriormente) y la comunicaci6n en red con el objetivo de presentar a1 llamador un sencillo mecanismo de invocaci6n. En la VM remota, cada objeto remoto puede tener su skeleton correspondiente.
Skeletons En el lado servidor, el objeto skeleton se encarga de 10s detalles de "posici6n remota" de modo que el objeto remoto no tenga que preocuparse por ellos. En otras palabras, podemos codificar un objeto remoto del mismo que si fuera local; el skeleton aisla a1 objeto remoto de la infraestructura M I . Durante las solicitudes de mitodo remoto, la infraestructura RMI invoca automiticamente el objeto skeleton de mod0 que kste pueda ejercer su poder. A continuaci6n, una enumeracidn de 10s eventos en detalle: 0
Lee (unmarshaling) 10s parimetros para el mitodo remoto (recuerde que estos parametros han sido escritos y transmitidos (marshaling) por el stub en el lado cliente)
o Invoca el metodo en la implementaci6n del objeto remoto
Procesamiento distri buido con RMI 0
Escribe y transmite (marshaling) el resultado (valor devuelto o excepcion) al llamador (que es entonces leido ( ~ n m a r s h a l i n por ~ ) el stub)
El J D K contiene la herramienta rmic que crea 10s archivos de clase para stubs y skeletons. Los detalles sobre rmic puede encontrarlos en el paquete de J D K u on-line en: http://java.sun.co~j2se/l.3/docsltooldocs/tools. html
Capa de referencia remota La capa de referencia remota define y se ajusta a la semintica de invocaci6n de la conexion RMI. Esta capa proporciona un objeto j a v a . rmi . server. RemoteRef especifico de JRMP (Java Remote Method Protocol: siguiente secci6n) que representa un descriptor para el objeto remoto. Un Remotestub utiliza una referencia remota para realizar una invocacion de metodo a un objeto remoto.
En J D K 1.2 y versiones posteriores, 10s stubs utilizan un tinico mitodo, invoke (Remote, Met hod, O b j ec t [ ] , 1ong) en la referencia remota para llevar a cabo la escritura y transrnisidn (marshaling) de para'metros, la ejecucidn de mitodo remoto y la lectura (unmarshaling) del valor devuelto. La implementaci6n Java 2 SDK de RMI atiade una nueva semintica para la conexidn cliente-servidor: objetos remotos activables (como veremos mas adelante). Otros tipos de semintica de conexion tambikn son posibles. Por ejemplo, con multidifusi6n, un h i c o proxy podria enviar una solicitud de metodo a m ~ i l t i ~ l e s implementaciones simultineamente y aceptar la primera respuesta (que mejoraria el tiempo de respuesta y, posiblemente, la disponibilidad). En el futuro, se espera que Sun atiada semintica de invocaci6n adicional a RMI.
Capa de transporte La capa de transporte realiza las conexiones de red basadas en flujos de datos en TCP/IP entre JVM y e s responsable de configurar y gestionar dichas conexiones. Aunque dos JVM estkn funcionando en la misma computadora fisica, se conectan a traves de su pila de protocolo de red TCP/IP de su ordenador host. RMI utiliza un protocolo de conexion llamado Java Remote Method Protocol URMP) sobre TCP/ IP (una analogia es http sobre TCP/IP).
JRMP esta' especificado en http:lljava.sun.com/productsljd~l.2/docs/guide/rmi/spec/rmiprotocol.doc.html. Es importante destacar que JRMP es espec@o de la "implementacio'n" Sun. Implementaciones alternativas, como BEA WebLogic, NinjaRMI, ObjectSpace's Voyager, etc., no utilizan JRMP pero, en su lugar, utilizan su propio protocolo de conexidn. Sun e IBM ban desarrollado conjuntamente la siguiente versidn de RMI, llamada RMI-IIOP, que estk disponible con Java 2 S D K versidn 1.3 (o por separado). En vez de utilizar JRMP, RMI-IIOP utiliza Object Management Group ( O M G ) Internet Inter-ORB Protocol ( I I O P ) para comunicar entre clientes y seruidor. I I O P tambie'n permite la integracidn con objetos C O R B A . A partir de JDK 1.2, el protocolo JKMP fue modificado para eliminar la necesidad de skeletons y, en su lugar, utilizar el proceso de reproducci6n para realizar la conexion al objeto de servicio remoto. De este modo, solo necesitamos generar clases stub en implementaciones de sistema compatibles con JDK 1.2 y versiones anteriores. Para generar stubs, utilizamos la opci6n -v1.2 con rmic.
Para una descripcidn detallada de cdmo fue modificado JRMP para eliminar 10s skeletons, consulte las descripciones de CallData, Operation y Hash en la especificacidn JRMP en http:// java.sun.com/productsljd~l.2/docs/guide/rmi/spec/rmi-protocol.doc3.hmtl.
Capitulo 3 La reproduccidn es u n API del paquete j a v a . l a n g . r e f l e e t en J2SE que permite a1 cddigo Java descubrir informacidn sobre 10s campos, mktodos y constructores de clases cargadas en period0 de operacidn y operar sobre ellos.
La capa de transporte RMI esti disefiada para realizar una conexibn entre clientes y servidor, enfrentindose incluso a obsticulos de la red. Aunque la capa de transporte prefiere utilizar mGltiples conexiones TCP/IP, algunas configuraciones de red conciben una Gnica conexi6n TCP/IP entre un cliente y servidor (por ejemplo, algunos navegadores restringen 10s applet a una sola conexi6n de red de vuelta a su servidor host). En este caso, la capa de transporte multiplexa m6ltiples conexiones virtuales en una Gnica conexi6n TCP/IP. La capa de transporte en la implementacidn RMI actual esta' basada en T C P pero, una vez ma's, una capa de transporte basada en U D P puede ser sustituida en una implementacidn diferente.
Localization de objetos remotos Hay todavia una pregunta crucial a la que todavia no hemos respondido. iC6mo encuentra un cliente el objeto? Los clientes encuentran servicios remotos utilizando un servicio de designaci6n o de directorio. Esto puede parecer una 16gica circular. iCbmo puede un cliente encontrar el servicio de designacibn? Es sencillo: un servicio de designaci6n o de directorio es ejecutado en un numero de host y de puerto que el cliente ya conoce (por ejemplo, un puerto conocido en un host publico). RMI puede buscar claramente estos servicios diferentes de directorio con Java Naming and Directory Interface (JNDI), que ya ha sido descrito en el capitulo anterior. El servicio de designaci6n RMI, un registro, es un objeto remoto que sirve como servicio de directorio para clientes manteniendo una asociaci6n de nombres tipo Hashtable con otros objetos remotos. N o es necesario tener un Gnico registro en un determinado host fisico. Un objeto es libre para empezar su propio registro. El rendimiento del registro lo define la interfaz j a v a . rmi . r e g i s t r y . R e g i s t r y . RMI incluye una sencilla implementacibn de esta interfaz llamada Registro RMI (la herramienta rmi r e g i s t r y con JDK tambien puede ser iniciada programiticamente). El Registro RMI se ejecuta en cada rniquina que "alberga" objetos remotos y acepta solicitudes de servicios, por defect0 en el puerto 1009. En terminos sencillos, un objeto remoto es asociado a un nornbre en este registro. Siempre que 10s clientes deseen invocar metodos en este objeto remoto, obtienen una referencia a 6ste buscando el nornbre. La bGsqueda devuelve una referencia remota, un stub, a1 objeto. RMI tambien proporciona otra clase, la clase java.rmi.Naming que sirve como punto de interaccibn del cliente con el objeto que sirve de registro en el host para esta b~squeda:
/ Blisqueda reglstro / -4 Nornbrado
1 Blisqueda.' 1 nornbrado
I
Procesamiento distribuido con RMI
Es importante n o confundir java.rmi.Naming con el contexto JNDI. Aunque proporcionan 10s mismos servicios, la clase Naming localiza especificamente objetos e n el registro RMI. Sun facilita u n proveedor J N D I para RMI que permite a 10s clientes buscar objetos RMI utilizando u n contexto JDNI. Este registro RMI de base J N D I puede ser descargado desde http:/fiava.sun.corn/productsfindi/ Los mktodos de la clase Naming toman, como uno de sus argumentos, un nombre que es un j ava .lang .st ring formateado como URL. Examinemos estos mitodos y sus d e s ~ r i ~ c i o n e s :
1
Metodo
Descripcion
Public static void bind (String name, Remote obj)
Asocia el ob'eto remoto a un nombre string. El nombre mismo es el lormato MI URL descrito a continuaci6n.
Public static String [ I list (String name)
Devuelveun array de 10s nombres asociados en el registro.
Public static Remote lookup (String name)
Devuelve una referencia, un stub, para el objeto remoto asociado a1 nombre especifico.
Public static void rebind (String name, Remote obj)
Reasocia (disocia el nombre si yaesti asociado y lovuelve a asociar) el nombre especificado si ya est6 en uso en un Nuevo objeto remoto. Esto puede ser peligroso si diferentes aplicaciones utilizan el mismo nombre en el registro per0 resulta util en el desarrollo.
Public static void unbind (String name)
Elimina la asociaci6n con el nombre especificado.
Los mktodos en la clase Naming y en la interfaz Registry tienen idknticas firmas y capturan varias excepciones (que estudiaremos en la siguiente secci6n). Hay una serie de acontecimientos que tienen lugar cuando un cliente invoca una busqueda para un determinado URL en la clase Naming. Primero, se abre una conexi6n Socket al host en el puerto especificado (utilizando una factoria de Socket cliente si es necesario). A continuaci6n, puesto que la implementaci6n de registro en el host mismo es un objeto remoto, se devuelve un stub desde el host al registro remoto. Este stub actua como el proxy cliente para el registro. Posteriormente, se realiza la busqueda Regist ry . lookup ( ) en este stub y devuelve otro stub para el objeto remoto que ha sido registrado con k l en el servidor. Finalmente, una vez que el cliente tiene un stub para el objeto solicitado, interactua directamente con el objeto en el puerto al que ha sido exportado.
-
El URL adopta la siguiente forma: rml: / / < h o s t P n a m e > [ : i r j a m e -s e r v i c e p o r t > ] / < s e r v i c e -r l a m e >
donde: 0
host-name es un nombre reconocido en la red de irea local (LAN) o un nombre DNS en
Internet 0
name-service-host necesita ser especificado s61o si el servicio de designaci6n esti siendo
ejecutado en un puerto distinto del puerto por defect0 1099
o
service-name es el nombre string al que se asocia el objeto remoto en el registro
Para facilitar este proceso en la miquina host, un programa servidor expone el servicio de objeto remoto ejecutando la siguiente secuencia de eventos:
Capitulo 3 1. Crea un objeto local
2. Exporta ese objeto para crear un servicio de escucha, que espera a que 10s clientes conecten y soliciten el servicio 3. Registra el objeto en el Registro M I con un nombre phblico
El c6digo expuesto a continuaci6n resume estos pasos: //
C r e a r e l o b j e t o . La e x p o r t a c i 6 n t i e n e H e l l o S e r v e r o b j = new H e l l o S e r v e r ( ) ;
/ / A s o c i a r e l o b j e t o a url nornbre e n e l / / i n i c i a d o con a r ~ t e r i o r l ~ d a d Narning.rebird ( " / H e l l o S e r v e r " ,
obj
lugar
registro
en
el
que
constructor
ha
sido
) ;
Existe unaclase similar a la clase Naming, j ava . rmi . registry. LocateRegistry, que tienevarios metodos para obtener directamente una referencia al registro y para iniciar el registro. Como ya hemos indicado, iniciar el registro (ya sea mediante la herramienta o programiticamente) s61o consiste en exportar el objeto remoto que implements la interfaz Registry.
El m e t o d o L o c a t e R e g i s t r y .g e t R e g i s t r y (String host) no contacta con el registro en el host sin0 que busca en el host para certificar que existe. Por ello, aunque este metodo di6 resultado, est? no significa necesariamente que un registro sea ejecutado en el host especificado. Unicamente devuelve un stub que puede entonces acceder a1 registro.
JDK tiene una herramienta llamada rmiregistry que inicia el registro en el host con el siguiente comando: ~ r n i r t q i - t r y J - D j a v a .security.policy=
En cambio, para iniciar el registro con sus valores por defecto: start
rrniregistry
Recuerde que el registro es un objeto que se ejecuta en una JVM. El marcador- J se utiliza para pasar parimetros, como el archivo de politica, a JVM. Tambikn puede iniciar programaticamente el registro con el me'todo LocateRegistry. createRegistry (int port) o elma'sdetallado Loca teRegistry. crea teRegistry (int p o r t , RMIClientSocketFactory c s f , R M I S e r v e r S o c k e tFa ct o r y ss f).Ambos me'todos devuelven el stub, implementando la i n t e r f a z j a v a . rmi. registry. Registry.
Archivos de politica Al codigo se le conceden permisos en lo que se denomina archivos de politica. Si buscamos en el directorio % JAVA-HOME% \ j re \l i b \ S e c u r i t y, encontraremos el archivo de politica por defecto para nuestra JVM llamado j ava. policy. Este archivo puede ser editado manualmente o utilizando el programa de herramientas de politica que encontramos en %JAVA-HOME%\bin-directory. Antes de continuar con un ejemplo, nos desviaremos para examinar las excepciones en M I .
Procesamiento distribuido con RMI
Excepciones RMI C o m o ya hemos mencionado anteriormente, RMI es un sistema distribuido que utiliza Sockets sobre TCP/IP. En este entorno redificado, pueden fallar muchos elementos. Es importante que el cliente conozca de algGn mod0 las excepciones de mod0 que puede manejarlas del mod0 adecuado y asi solventar problemas a medida que vayan surgiendo. Por ejemplo, n o queremos que un cliente espere indefinidamente una entrada en el Socket si la red falla o n o es posible alcanzar el host. Para que el cliente sea consciente de tales condiciones, todo metodo remoto debe lanzar la excepci6n j a v a . r m i . R e m o t e E x c e p t i o n (o una de sus clases superiores como j a v a . i o . I O E x c e p t i o n o j a v a . l a n g .E x c e p t i o n ) . ~ e m o t e ~ x c e p t i o n e n u n a e x c e p c i 6genericay n hay subclases especializadas que son lanzadas (y capturadas) en condiciones especificas. Estas excepciones estin descritas en la siguiente tabla:
.
Lanzada por ciertos metodos de la clase j a v a r m i .Naming (concretamente-bind ( ) , r e b i n d ( ) y u n b i n d ( ) ) y metodos de la interfaz ~ ci v ta t i o n ys ~ tem(que estudiaremos en breve ,para indicar ue el llamador no tiene permiso para ejecutar la accidn s o L l t a d a p o r la Iamada del metodo. Lanzada si existe un intento de asociar un objeto en el registro a un nombre que ya tiene una asociaci6n. Observe que esta excepci6n n o es lanzada (en las mismas condiciones) si se utilizarebind ( ) .Sm embargo, el uso de r e b i n d ( ) puede no ser correct0 en todos 10s casos. ConnectException
Lanzada si una conexi6n es rechazada el host remoto para una llamada de metodo remoto.
ConnectIOException
Lanzada si una I O E x c e p t i o n tiene lugar durante la realizaci6n de una conexi6n a1 host remoto para una llamada de mitodo remoto.
MarshalException
Lanzada siocurreunaj a v a . i o . ~ ~ ~ x c e ~ t i o n d u rlaescrituray ante trasmisi6n (marshaling) de la cabecera, argumentos, o valor de retorno de llamada remota para una llamada de metodo remoto. Lanzada si se realiza un intento de invocar un mitodo sobre un objeto que ya n o existe en la miquina virtual remota. Si se lama esta exce ci6n slgnrf~caque el objeto ha sido recogido por el recolector de resi&os o n o exportado. Suele ocurrir que elcliente o clientes n o consiguen repetidamente renovar sus alquileres k t o s expiran. Si esto ocurre,por ejemplo, la red se obstruye con trifico o falla. Es lmportante tambikn recodar que el stub con el cliente d o es d i d o mientras estivivo el servidor RMI. Si no desea que el objeto remoto sea recolectado como residuo, debe mantenerlo vlvo en el JVM servidor almacenando una referencia a1 objeto de implementaci6n en una variable estitica. Como objeto disponible localmente, n o sera recolectado como residuo nisi uiera incluso en el caso de que 10s clientes Sean ampliamente inalcanza%les. Lanzada si realiza un intento de l o o k u p ( ) (buscar) o u n b i n d ( ) (desasociar) en el registro un nombre que n o tiene ningGn vinculo asociado.
La tabla continua en la pdgina siguiente
Capitulo 3 Excepcidn
Descripcidn La super clase c o m h para una serie de excepciones relacionadas con la comunicaci6n que puedan tener lugar durante laejecuci6n de una llamada de mttodo remoto.
ServerError
Lanzada como resultado de una llamada de metodo remoto si laejecuci6n del mktodo remoto en la miquina servidor lanza j a v a .l a n g .E r r o r .
ServerException
Lanzada como resultado de una llamada de metodo remoto si la ejecuci6n del metodo remoto en la miquina servidor l a n z a ~ e m oet ~ x c ei o~nt.
S t u b N o t F o u n d E x c e p t i o n Lanzada si unaclase stubvilidano pudiera ser encontradaparaun objeto remoto a1 ser exportado. UnexpectedException
Lanzada si el cliente de una llamada de metodo remoto recibe, como resultado de la llamada, una excepci6n comprobada que no se encuentra entre 10s tipos de excepciones comprobadas declaradas en la clalisula "throws" del mttodo en la interfaz remota. Lanzada si tiene lugarj a v a . n e t . ~ n k n o w n ~ x c e ~ t i o n d u r alan t e creaci6n de una conexi6n a1 host remoto para una llamada de metodo remoto. Puede ser lanzada durante el proceso de unmarshaling (lectura) de 10s parimetros o de 10s resultados de una llamada de mttodo remoto si: O Ocurre una exception durante la lectura (unmarshaling) de la cabecera de llamada. O Si el protocolo para el valor de retorno no es vilido. Q Si ocurre una IOException durante la lectura (unmarshaling) de 10s
parametros (en el lado servidor) o en el valor de retorno (en el lado cliente).
Desarrollo de aplicaciones con RMI Grabar aplicaciones cliente-servidor utilizando RMI conlleva seis pasos fundamentales: 1. Definir una interfaz remota
2. Implementar la interfaz remota 3. Grabar el cliente que utiliza 10s objetos remotos 4. Generar stubs (proxys de cliente) y skeletons (entidades de servidor)
5. Iniciar el registro y registrar el objeto 6. Ejecutar el servidor y el cliente
Estudiemos cada paso desarrollando una sencilla aplicaci6n como ejemplo para obtener experiencia prictica y acelerar la comprensi6n de cada paso.
Procesamiento distribuido con RMI
Definir la interfaz remota Una interfaz rnanifiesta las operaciones expuestas y el prograrnador cliente no necesita tener conocimiento de la irnplernentaci6n (la interfaz en este caso tarnbitn sirve corno rnarcador para la JVM). Una interfaz rernota, por definicibn, es un conjunto de mttodos que pueden ser invocados rernotarnente por un cliente: 0
La interfaz remota debe ser declarada p6blica o el cliente obtendri un error a1 intentar cargar un objeto rernoto que implernente la interfaz remota, a no ser que el cliente estt en el rnismo paquete que la interfaz rernota.
EI
La interfaz rernota debe arnpliar la interfaz j a v a . rrni
0
Cada mttodo debe lanzar una excepci6n j ava . r m i .RemoteException (o una superclase de RemoteException).
LI
Si 10s rnttodos rernotos tienen cualquier objeto rernoto corno parirnetros o tipos devueltos, deben ser tipos de interfaces, no clases de implernentaci6n.
Observe que la intelfaz j a v a . rmi no tiene rnttodos. Sdlo se utiliza corno un marcadorpor la JVM, de un modo similar a corno la intelfaz j a v a . i o . s e r i a1 i z abl e es utilizada para marcar objetos corno serializables. Para nuestro ejemplo, definirernos nuestra interfaz rernota de este modo: public
interface
HelloInterface
extends
java.rrni.Rernote
{
/ / E s t e m6todo e s l l a r n a d o p o r c l i e n t e s r e m o t o s y e s l m p l e m e n t a d o / / p o r e l o b l e t o rernoto. p u b l i c S t r l n g sayHello ( ) throws j a v a . rmi.RernoteExcept~on; i -
--
Si su objeto implementa otras interfaces, manthgalo separado de la interfaz Tambiin puede reducir a1 minimo el numero de objetos registrados en el registro con un modelo de diseiio Factoria o con un unico objeto factoria.
lmplementar la interfaz remota La clase de implementaci6n es la clase real que proporciona la irnplernentaci6n para mttodos definidos en la interfaz remota. Java. rmi .server. RemoteObj ect arnplia la funcionalidadproporcionadapor la clase j ava. 1ang.Object en el dominio rernoto ignorando 10s rnttodos equals ( ) , hashcode ( ) y tostring ( ) .
Recuerde que elgentrico j ava .rmi .server. RemoteObj ect es una claseabstracta y describe el funcionamiento de objetos rernotos.
.
La subclase abstracta j a v a rmi .server. RemoteS erver describe el funcionamiento asociado con la implernentaci6n del servidor y proporciona la semintica bisica para ajustarse a referencias rernotas (por ejernplo, crear, exportar a un puerto deterrninado, etc.). Java.rmi .server. Remoteserver tienedos subclases:
O
j a v a . r m i . s e r v e r . U n i c a s t R e m o t e O b j e c t : defineunobjetorernotonoreplicadocuyas referencias s61o son vilidas rnientras esta el sewidor estk activo.
0
j a v a . r m i . A c t i v a t i o n . A c t i v a t a b l e : claseconcretaquedefineelfuncionarnientopara instanciado a solicitud d e objetos rernotos (vkase secci6n posterior sobre activaci6n).
El siguiente diagrarna rnuestra las dos subclases y sus. rnktodos contenidos en relaci6n con la clase
U n objeto puede presentar funcionarniento rernoto corno resultado de 10s siguientes factores: 0
La clase arnplia j a v a . r m i . R e m o t e s e r v e r o una de sus subclases (incluidos otros objetos rernotos). Sin embargo, la clase debe invocar u n o de 10s constructores superclase de rnodo que pueda ser exportada.
0
La clase se exporta a si rnisrna explicitarnente pasindose a si rnisrna ( " t h i s ") a diferentes forrnas dernktodos ~ n i c a s t ~ e m o t e ~ b j ee cx pt .o r t o b j e c t ( ) .
El tkrrnino "exportar" encierra la serna'ntica que irnplica la capacidad de u n objeto rernoto para aceptar solicitudes. Esto conlleva escuchar en u n Socket (servidor) TCP. Observe que rnriltiples objetos pueden escuchar en el rnisrno puerto (viase la seccidn sobre Sockets para rna's inforrnacidn).
Procesamiento distribuido con RMI Ademis de istas, la clase debe implementar una o mis interfaces remotas que definen 10s mitodos remotos.
Una clase remota puede definir cualquier mktodo pero s61o 10s mktodos en la interfaz remota pueden ser invocados remotamente. La clase de implernentacion de objeto remoto H e l l o S e r v e r para nuestro ejemplo es del siguiente modo: import import import import
public Helloserver() throws RemoteEzception ( super(); / / Llamar a1 coristructor superclase para exportar este objeto
I public String sayHello ( ) throws RemoteExcept lor1 ( return "Hello World, the current system time is "
+
new D a t e ( ) ;
1
1
Observe que el cddigo fuente para este ejemplo (y para todos 10s ejemplos de este libro) esta' disponible para su descarga en h t t p : / ~ . w r o x . c o m .y en http://ww.AnayaMultimedia.es.
Grabar el cliente que utiliza 10s objetos remotos El cliente realiza una bcsqueda en el registro en el host y obtiene una referencia al objeto remoto. Recuerde que es de vital importancia difundir a la interfaz remota. En RMI, 10s clientes siempre interactcan con la interfaz, nunca con la implementaci6n del objeto: import j ava. rrni . * ; public class Helloclient
I
public static void rnainistring args[]) [ if ( S y s t e m . g e t S e c u r i t y M a r ~ a g e r ( ) == null) { System.setSecurityManager(new RMISecurityManager());
Generar stubs y skeletons Ahora que tenemos la interfaz remota y las irnplementaciones, podemos generar stubs y skeletons (o s610 stubs en Java 1.2) con la herramienta rmic despuks de haber compilado las clases. N o olvide configurar el directorio desde el que esti trabajando en su ruta de clase; despuks puede utilizar la siguiente linea en una ventana de comando: rmic v 1 . 2 HelloServer
Observe yue el indicador -vl . 2 suprime la generacidn de skeletons.
Registrar el objeto Ahora que ya tenemos la interfaz y la implementacibn, necesitamos poner este objeto a disposition de 10s clientes asociindolo a un registro. Esto permitiri a 10s clientes buscar el objeto en el host por un nombre String. Los stubs y 10s skeletons (si es que hay alguno) son necesarios para el registro. Despuks de todo, es el stub objeto el que va a ser pasado desde el registro a 10s clientes. Con frecuencia se Cree err6neamente que el objeto debe estar asociado a un registro para ser utilizado. En realidad, esto n o es cierto. El objeto esti disponible para su uso en el momento en que es exportado con kxito. Puede funcionar como cliente, invocar un metodo en otro objeto y pasarse a otro objeto.
El siguiente c6digo muestra c6mo registramos nuestro objeto: import j ava. rmi . * ; public class RegisterIt
I
~ ~ u b l i static c void main (String args [ I ) { try 1 / / Instanciar el objeto HelloServer obj = n e w HelloServer ( ) ; System.out .printlr~ ("Object instantiated: Naming. rebind ("/HelloServer", o b j ) ; System.out .println ("HelloServer bound 1r1 } catch (Exception e ) ( System.out.prlntln(e);
"
+
obj )
;
registry") ;
I I I Existen dos mktodos en la clase j a v a . r m i .Naming que pueden asociar un objeto en el registro: 0
El mktodo b i n d ( ) asocia un objeto a un nombre cadena (string) y lanzar una excepcih ja v a .r m i . ~ l r e a d y ~ o u n d ~ x ci eo np st; laasociaci6n yaexiste
0
El mCtodo r e b i n d ( ) , como ha sido utilizado anteriormente, sustituye cualquier asociaci6n existente por una nueva
El registro debe estar siendo ejecutado para que el objeto se asocie. Puede ser iniciado por la herramienta programiticamente, como ya hemos explicado. Iniciamos el ejecutable con la siguiente linea de comando: rmiregistry J-Djava.seci~rity.policy=registerit.policy
Procesamiento distribuido con RMI La politica de seguridad es necesaria debido al modelo de beguridad de Java 2. El registro necesita perniisos para abrir Sockets (un Socket e n un extremo de una conexibn T C P ) que e s t i n restringidos a extensiones estindar en el archivo d e politica p o r defecto. N u e s t r o archivo de politica para este ejemplo, registerit .policy,concede todos 10s permisos: grant 1 / / P e r r n i t t tvdo p o r a h o r a p e r m i s s i o n j a v a . securit y .A1 1 P r r m i r i ' i o r i ; ,
.
; #
Naturaln~ente,n o utilizariamos esta politica e n un e n t o r n o de produccibn. P o r defecto, hay un 6nico archivo d e politica del sistema y un ilnico archivo de politica de usuario. El archi\;o de politica de sistema est;iloca~izadopordefcctoen;: JAVA-HOMEF\lib\Security\ java. policy (utilice barra oblicuacon Solaris), mientras que el archivo d e politica d e usuario se encuentra p o r defecto e n -USER-HOME% \ j ava. policy. Consulte la docunientaci6n de herran~ientaincluida en su J D K si desea m i s detalles sobre Ins politicas. Es conveniente recordar que a1 iniciar el registro todas las clases y stubs deben estar disponibles e n la ruta d e clase, o Csta n o deberia estar configurado e n absolute, para ajustarse a la c a r p dininiica.
Ejecutar el cliente y el servidor Para ejecutar el cliente debemos primer0 compilar y ejecutar el archivo Regis terIt. Despuis, necesitamos abrir todavia otra ventana de comandos, de modo que tengamos una ventana ejecutando el rceistro RMI, otra eiecutando el prorrrama Reqister It y la tercera para eiecutar la clase Helloclient especificando nuestro archivo de politica de seguridad:
-
.
,,.:,,
<,
- ~ ~ j a ~ : a . . c ~ ~ ~ : ~ . 1 c i t y . p 1 ~ 1 i ~ ~ j ; = ~ - ~ : ~H~z il ~h lt S + lt i~e ir t~. t~ ~ ~ ~ l i ~ : j ,
El resultado de este sencillo ejcmplo deberia ser el siguiente:
.
El gestordeseguridad j ava .rmi RMIsecurit yManager amplia la clase j ava . lang . SecurityManages y proporciona el contexto de seguridad en el que ejecutar las aplicaciones RMI. Si n o se ha configurado ningun mecanismo d e seguridad, 10s stubs y las clases s61o p o d r i n ser cargados desde la ruta d e clase local y n o desde el host o desde la clase de c6digo (vCase la secci6n posterior sobre clases cargadas dinaniicamente). Este gestor protege a las aplicaciones de la descarga d e codigo n o seguro via invocaciones de m i t o d o remoto. En J D K 1.3, n o hay realmente necesidad de configurar W I s e c u r i t yManager debido al control de acceso basado e n la politica. Ademis, recuerde que el gestor de seguridad e n JDK 1.3 invoca AccessController .checkPermission (Permission) por defecto y se refiere a un archivo de politica para certificacibn de permiso.
N o hay en realidad ninguna raz6n para establecer el gestor de seguridad R M I S e c u r i t y M a n a g e r si un programa RiMI desempefia un papel puramente de servidor en todos sus vinculos de cornunicaci6n. R M I S e c u r i t y M a n a g e r (y 10s gestores de seguridad definidos por el usuario y obtenidos ampliando R M I S e c u r i t y M a n a g e r ) tiene como objetivo controlar las clases cargadas dindrnicamente por una aplicaci6n cliente para el control de seguridad. Si el cliente tiene acceso a las definiciones de objeto para el host, tampoco hay ninguna raz6n para utilizar R M I S e c u r i t y M a n a g e r en el lado cliente.
Pasar parametros en RMI L.1
semantics habitual para mktodos en una unica JVM ehti gobernada por dos reglas: Si el tip0 pasado es una primitiva, el parjlmetro o resultado es pasado por valor. Sin embargo, si el tip0 pasado es u n objeto, el objeto es entonces pasado por referencia.
Cuando un tip0 de datos primitivos es pasado con10 parlmetro a un mitodo, la JVM sirnplemente copia el valor y pasa la copia al mktodo (o la devuelve de iste). Por otro Indo, un objeto reside en el bloque de memorin y una (o rnis) referencias acceden a1 61. Al ser pasado a un mitodo, se realiza una copia de la variable referencia (aurnentando en uno la cuenta de referencia al objeto) y se sitGa en b pila, y la copia va siendo pasada. Dentro del metodo, el c6digo utiliza la copia de la referencia para acceder al objeto. Al invocar cualquier metodo en la referencia, el estado actual del objeto original cambia. Si se altera la referencia en si misma, no se produce ningJn cambio en el objeto original. Sin cmbargo, alterar el objeto al que apunta la referencia si altera el objeto inicialmente creado. Por ello, ique sen~inticase utiliza cuando la invocaci6n de mitodo remoto conlleva pasar parimetros o aceptar un valor de retorno? La respuesta a estn pregunta depende de si 10s parametros son tipos de datos prirnitivos, objetos u objetos remotos. Examinernos estos tipos de parirnetros con detenimiento.
Parametros de primitivas Cuando un tipo de datos primitivos es pasado con10 parimetro a un mitodo remoto, o bien devuelto desde Cste, el sisterna RMI lo pasa por valor. Una copia del tipo de datos primitivos es enviada al mktodo remoto y el mktodo devuelve una copia de la primitiva desde su JVM. Estos valores son pasados entre cliferentes JVM en un formato e s t h d a r independiente de la rniquina permitiendo a las JVM ejecutadas en diferentes plataformas que se cornuniquen entre ellas de forrna fiable.
Parametros de objeto Una referencia a un objeto no tiene sentido a travCs de mdtiples JVM puesto que 10s puntos de referencia a un valor en el bloque y diferentes JVM no comparten la memoria crimulo. RMI envia el objeto, no su referencia, entre JVM. Es en realidad el objeto el que es pasado por valor, no la referencia al objeto. De un mod0 similar, una copia del objeto cornpleto es devuelta al programa Ilamador. Un objeto J a w puede ser sencillo o puede referir a otro objeto Java en una estructura cornpleja tip0 grlfico. Puesto que RMI debe enviar al objeto referenciado y a todos 10s objetos a 10s que referencia, utiliza la serialization de objeto RMI, RMI Object Serialization, para transformar el objeto en un formato lineal que puede ser entonces enviado por la red. La serializaci6n de objetos esencialmente extiende un
Procesamiento distribuido con RMI objeto y cualquier objeto que este referencie. Los objetos serializados pueden ser deserializados en la memoria de la JVM remota y preparados para su uso por un programa Java. Pasar grandes grificos de objetos puede suponer mucho tiempo de C P U y mucho ancho de banda de red. Intente que 10s argumentos de objeto para mktodos remotos y 10s resultados de &tos sean sencillos para mayor optimizaci6n. Los objetos pasados deben implementar la interfaz j a v a . i o . s e r i a l i z a b l e o java.io.Externalizab1e.
Parametros remotos Pasar objetos remotos como argumentos de metodo o tipos de retorno no es lo mismo que pasar otros objetos. U n programa cliente puede obtener una referencia a un objeto remoto a traves del programa RMI Registry o esta puede ser devuelta a1 cliente desde una llamada metodo (vease el e j e m p ~ o ~ e l l o ~ oenr l d la siguiente seccion). Pasar objetos remotos es muy importante, especialmente para retrollamadas. Fijese en el siguiente c6digo: H e l l o I n t e r f a c e obi M s g I n t e r f a c e rnsg =
( H e l l o I n t e r f a z e ) Narnir~g.lookup("/HelloServer"); ob? .getMsg ( ) ;
=
?Que ocurre cuando M s g I n t e r f a c e es, en si misma, un objeto remoto que ha sido exportado a1 servidor? RMI no devuelve una copia del objeto remoto. Sustituye el objeto remoto por el stub, lo serializa y lo envia a1 cliente. Como apunte, podemos decir que si el cliente envia este objeto remoto de vuelta a1 servidor como otro argumento, el objeto es tratado todavia como un objeto remoto en el servidor y no como local al servidor (aunque lo es). Aunque este pueda parecer un encabezamiento de rendimiento, es crucial para preservar la integridad de la semintica. Considere otro caso: ?quk ocurre cuando el metodo remoto devuelve una referencia a t h i s ? public
class
ThisServer
e x t e n d s UnicastRernoteObject implements H e l l o I n t e r f a c e [
p u b l i c T h i s S e r v e r ( ) t h r o w s RenioteException[ super ( ) ;
i public HelloInterface return this;
sorneMett1od0 t h r o w s
RernoteException
I
En el c6digo servidor, this hace referencia a la implementaci6n del servidor que reside en la JVM del servidor. Sin embargo, 10s clientes no tienen contact0 direct0 con la otra JVM. Tratan con el proxy del objeto del servidor, el stub. Detras de esto, RMI comprueba 10s parametros de entrada y de salida desde un metodo remoto para ver si implementan la interfaz Remote. Si lo hacen, son claramente reemplazados por el stub correspondiente. Esto provoca en el cliente la ilusi6n de que estin trabajando con 10s objetos locales porque incluso elementos como this pueden ser intercambiados entre diferentes JVM.
Recuerde que 10s archivos de clase en si mismos nunca son serializados, s61o 10s nombres de las clases. Todas las clases deberian poder ser cargadas durante la deserializaci6n utilizando 10s mecanismos habituales de carga de clases.
El recolector de residuos distribuidos U n o de 10s objetivos de diseiio para las especificaciones de RMI era mantener la perspectiva del cliente de objetos remotos igual que la de otros objetos dentro de su propia JVM. Esto irnplica que 10s objetos rernotos tarnbien deben estar sujetos a la recoleccion de residuos. El sisterna RMI proporciona un algoritmo de recoleccion de residuos distribuidos de contado de referencias basado en Modula-3's Network Objects. Internamente, el servidor mantiene un registro de que clientes han solicitado acceso a1 objeto rernoto. Cuando se realiza una referencia, el servidor marca el objeto como sucio y, cuando todos 10s clientes han suprimido la referencia, el objeto es marcado como limpio. U n objeto limpio es marcado para recoleccion de residuos y reclamado cuando se ejecuta el recolector de residuos. Ademis del mecanismo de cuenta de referencias en el servidor, cuando un cliente obtiene una referencia, tiene en realidad un alquiler del objeto por un tiempo deterrninado. Si el cliente n o renueva la conexion realizando llamadas sucias adicionales al objeto remoto antes de que expire el period0 de alquiler, el recolector de residuos distribuidos asume entonces que el objeto remoto ya no e s t i referenciado por ese cliente (la referencia es considerada como muerta) y el objeto remoto puede ser recolectado como residuo.
.
U n objeto remoto puede implementar la interfaz j a v a . r m i s e r v e r . U n r e f e r e n c e d . ~ s t tiene e un mitodo, u n r e f e r e n c e d ( ) , que es invocado por el periodo de ejecucion RMI cuando ya n o hay clientes que alberguen una referencia viva. Esto permite a1 recolector de residuos distribuidos ( D G C ) cornprobar si alguna referencia remota sigue en uso. El tiempo d e alquiler es controlado por la propiedad de sistema j ava .r m i dgc .leasevalue. (Su valor e s t i e n milisegundos y el valor p o r defect0 es d e 10 minutos.)
.
Obviamente, toda esta suciedad, limpieza y estos alquileres nunca son visibles para usuarios o clientes. El mecanismo D G C es completamente transparente, se encuentra oculto en la capa de stubs-skeletons y esti abstraido en elpaquete j a v a . r m i .d g c . Es importante recordar que un objeto remoto puede ser recolectado como residuo, quedando indisponible para 10s clientes (lo que tiene con10 resultado habitualmente la exception j a v a . r m i .C o n n e c t E x c e p t i o n ) . Debido a esta sernintica de recolecci6n de residuos, un cliente debe estar preparado para tratar con objetos remotos que hayan "desaparecido". En el servidor, si n o quiere que su objeto "desaparezca", debe siempre retener una referencia explicita de mod0 que n o sea tomada por el recolector de residuos. N o olvide que el registro (en si mismo, un objeto remoto) actua como un cliente para el objeto servidor y, por lo tanto, mantiene un alquiler con el objeto. Por ello, incluso si 10s clientes "reales" se desconectan de un servidor, el metodo u n r e f e r e n c e d ( ) puede n o ser invocado en el objeto servidor mientras que el registro mantiene un alquiler. Considere la siguiente versi6n modificada del mismo ejemplo H e l l o w o r l d que dernuestra c6mo funciona la recolecci6n de residuos y d m 0 puede ser utilizado el metodo u n r e f e r e n c e d ( ) .Ya hemos estudiado c6mo puede un cliente obtener una referencia a un objeto remoto como resultado de una invocaci6n de metodo con anterioridad en la secci6n sobre pasado de parimetros. Este ejemplo utiliza este concepto. Modificamos la interfaz para devolver un objeto remoto en lugar de una cadena (string): import
j a v a . rrni. *;
Procesamiento distribuido con RMI
p u b l i c i n t e r f a c e H e l 1 , j I n t e r f a c e e x t e r ~ d s j a v a . r m i . Remate [ p u b l i c MsgInter-f a c e getMsg ( ) throws RemoteExceptian, E x c e p t i o n ; 1
La implementacidn del objeto remoto de esta interfaz es tambien bastante sencilla: i r n ~ ~ import import impart
~j a~v ra .t j ava. java. j ava.
public
class
i o . i; rml. *; rrni.~erver.~; u t i l . Date; Helloserver
public HelloServer ( ) super();
ehtends IJnicastRemoteObject implements H e l l o I n t e r f a c e {
t l i r ~ ~ wR s ernoteException
{
p u b l i c M s q I r t t e r f a c e qetMsq ( ) t h r o w s RemoteEsception, r e t u r n ( M s g I n t e r f a c e ) new M s g S e r v e r ( ) ;
Exception
{
M s g I n t e r f a z n o tiene metodos y s610 se utiliza para marcar el objeto que es pasado como remoto: import import
java.io.Seriali:able; java.rmi.server.*;
public
interface
MsqInterface
extends
j a v a . rmi .Remote
[
1
La sencilla implementacidn de esta interfaz e s t i disefiada para interceptar 10s eventos del objeto imprimiendo informaci6n cuando el objeto es creado, cuando ya no es referenciado, cuando se finaliza y despues se elimina. Este objeto tambien implements la interfaz Unreferenced y el metodo u n r e f e r e n c e d ( ) . El m e t o d o u n r e f e r e n c e d ( ) seri invocado cuando no haya referencias de cliente al objeto; se invoca f i n a l i z e ( ) justo antes de que el objeto sea recolectado como residuo: import import import
java.io.Serialirab1e; java.rmi.server.+; j ava .r m i . * ;
public
class
MsqServer
/ / E s t a b l e c e r un / / de esta clase private
static
contador para
int
/ / C o n t e r ~ e r un i d private i n t id;
e x t e n d s UnicastRemoteObject implemerits M s g l n t e r f a c e , S e r i a l i z a b l e , el
nhmero
3e
instancias
creadas
counter; para
la
instancia
del
imbjeto
p u b l l c MsgServer ( ) ttjr,>ws RernoteException { super ( ) ; S y s t e m . o u t . p r i n t l n [ " C r e a t e d Msg:" + c o u n t e r ) ; c,>unter++; s e t I d ( counter); I
public void f i n a l i z e 0 super. f i r t a l i r e ( ) ;
throws
Throwable
Syster~~.aut,printlr~("Finalizer called
I
{
f o r Msg:
"
+
Unreferenced
id);
{
Capitulo 3 publlc void unreferenced(){ Systern.out. p r i n t l n ("The unreferenced ( )method c a l l e d
// //
for
s i e s n e c e s a r i o , i n v o c a m o s a q u i u r ~ e x p o r t o b j e c t ya que e s t e u t i l i z a n d o u n e x p o r t o b j e c t ( e s t e , c l a r o ) ;
que
Msg:
" + i d );
r ~ ohay
r~adie
I
p r i v a t e void s e t I d ( i n t i d ) { this.id=id;
I
I El programa de registro sigue siendo el mismo de 10s ejemplos anteriores: irnpsrt
j a v a . rrni
.-;
p u b l i c s t a t i c voicj, r n a i r l i s t r i r ~ g a r g s [ ] ) { try i Hellc~Ssr..ler o b j = r~ew HellL'Server ( ) ; Naming. r e b i r d ( " / H e l l o S e r v t r " , o b j ) ; S y s t e m . o u t . p r l r ~ t l (r "~H e l l ~ . ~ S e r v e br q u n d I cat(:h ( E x c e p t l , : ~ r e ~) { Sy~ttm.out.printlr~(ej;
in
r s t j i : : t i y U );
Modificamos el cliente ligeramente para crear multiples instancias del objeto r e m o t o M s g S e r v e r ( ) en el servidor (instanciamos explicitamente un objeto en el metodo g e t M s g ( ) ). Necesitamos realizar esta operacion para nuestra demostraci6n porque la JVM ejecuta el recolector de residuos distribuidos (igual que el habitual recolector de residuos), solo cuando "cree" que es necesario reclamar memoria: import
j a v a . rrni
public
class
.+ ;
HellcClient
{
p u b l i c s t a t i c v o i d r n a i r ~ ( S t r i n ga r g s [ 1 ) { i f ( S y s t e m . g e t S e c ~ i r i t y M a r ~ a g (e )r == r t 1 ~ 1 1 ){ System. s e t S e c u r i t y M a n a g e r (new RMISecurityManager ( ) ) ;
I i
try
HelloInterfact obj = (Hellolnterface) Narnir~g.l~~okup("/HelloSer~v'er"); f o r ( i n t i = 0; i < 1 0 0 ; i + + ){ M s g I n t e r f a c e rnsg = o b j . g e t M s g ( ) ;
I
1 catch (Ezception e )
{
Systeni.out.prir~tlr~("HelloClier~te x c e p t i o n :
"
+
e);
I I I
Inicie el sewidor despues de compilar las clases y de generar 10s stubs (y 10s skeletons si es necesario) para H e l l o S e r v e r y p a r a M s g S e r v e r con 10s siguientes elementos (cambiando la ruta c o d e b a s e cuando proceda; consulte la pr6xima secci6n para mis detalles sobre c o d e b a s e ) : j a v a c + .j a v a rrnic - v 1 . 2 H e l l o S e r v e r rrnic - v 1 . 2 MsqServer
Procesamiento distribuido con RMI
Una vez mis, puede que desee experinientar con la propiedad del valor de alquiler asi corno con las opciones -ms ); -nix para configurar el bloque de memoria para este ejemplo. Aqui tiene un fragment0 de
LeaseCheckIntervtd en s u n . r m l . t r a n s p o r t . DGcImpl es leido desde la propiedad s u n . r m i . d g c , c h e c k I n t e r v a 1 sin tener en cuentn el valoractualde la variable l e a s e v a l u e . Esto provoca un retraso de cinco minutos a1 eliminar objetos no utilrzados, incluso si l e a s e v a l u e se fija en u n valor menor. Para e v i u r este problems, fije la propiedad s u n . r m i . d g c . c h e c k I n t e r v a 1 en la mitad de la configuraci6n de lava. rmi.dgc. leasevalue.
Clases de carga dinarnica Hemos hablado anteriormente sobre c6mo las referencias, 10s stubs, 10s parimetros y las factorias de sockets son enviadas al cliente y sobre c6mo las definiciones de clase no lo son. El cargado de clase dinimico hace referencia a este filtimo, haciendo que las definiciones e s t h disponibles. El cargado dinimico de clase lleva en Java bastante tiempo y esta capacidad para cargar e instanciar dinirnicarnente clases es un concept0 muy eficaz. Los applet, por eiernplo, son descargados a1 navegador del cliente desde un servidor webeyson ejecutados en l a j ~ ~ ~clienie. d e l Esto proporciona al perio-do de ejecuci6n del cliente la capacidad para acceder a aplicaciones que nunca han sido instaladas en su sisterna. Se da por sentado que el lector esti familiarizado con el funcionarniento de 10s applet y c6rno utilizan la propiedad codebase. Resumiendo, c o d e b a s e es el lugar desde el que el cargador de clase carga clases en la JVM. Esto significa que las clases pueden ser desplegadas en un lugar central, corno un servidor Web, para un sistema distribuido y todas las aplicaciones del sistema pueden descargar 10s archivos de clase para operar. Hay dos importantes propiedades de sisterna en RMI:
Capitulo 3 0
Java.rmi.server.codebase
Esta especifica el URL (una localizaci6n file : / /, ftp : / / o ht t p : / / ) desde donde se puede acceder a las clases. Si un objeto es pasado c'omo argument0 de metodo o tip0 de retorno, la JVM cliente necesita cargar 10s archivos de clase para ese objeto. Cuando RMI serializa el objeto, inserta el URL especificado por esta propiedad junto a1 objeto. 0
Java.rmi.server.useCodebaseOn1y
Esta propiedad es utilizada para notificar a1 cliente que debe cargar clases unicamente desde la posici6n de base de codigo, codebase. Repasemos el proceso de exportaci6n y registro de un objeto remoto y observ6moslo a trav6s de una lupa: 0 A1 instanciar el objeto remoto y registrarlo con el registro (nuestro programa Regis terI t de 10s ejemplos anteriores), la base de c6digo es especificada por la propiedad j ava .rmi .server. codebas e.
Cuando se realiza la llamada bind 0 , el registro utiliza esta base de codigo para ubicar el stub para el objeto. Recuerde que el registro mismo es un cliente para el objeto. Una vez se ha conseguido esto con exito, el registro asocia el objeto a un nombre y la base de c6digo es guardada junto con la referencia a1 objeto remoto en el registro. O Cuando un cliente solicita una referencia a1 objeto remoto, el registro devuelve el stub al
cliente. El cliente busca la definicidn de clase del stub en su ruta de clase local (siempre se busca antes la ruta de clae que la base de cbdigo) y entonces carga la clase local. Si la definici6n de clase de stub n o se encuentra en la ruta de clase, el cliente intentari recuperar la definici6n de clase de la base de c6digo del objeto remoto que ha sido almacenado en el registro. 0 La definition de clase para el stub y cualquier otra clase que necesite, como factorias de Sockets,
son descargadas a1 cliente JVM desde la base de codigo http o ftp. 0
Cuando todas las definiciones de clase estin disponibles, el mitodo proxy del stub llama el objeto en el servidor.
Utilizando las dos propiedades y el rnecanismo de descarga, pueden establecerse cinco configuraciones potenciales para distribuir clases: 0 Cerrada
N o hay carga dinimica y todas las clases estin ubicadas en las JVM respectivas y son cargadas desde la ruta de clase local ( java . rmi . server. codebase no configurado). 0
Dinhrnica lado cliente En el cliente, algunas clases son cargadas desde la ruta de clase local y otras desde la base de c6digo especificado por el servidor.
0 Dinhrnica lado servidor
Es similar a la configuraci6n dinimica lado cliente. Algunas clases en el servidor son cargadas localmente y otras desde la base de c6digo especificado por el cliente (por ejemplo, en el caso de retrollamadas desde el servidor a1 cliente).
o
Cliente de autoarranque Todo el c6digo de cliente es cargado desde el codebase mediante un pequefio programa en el cliente (cargador de autoarranque). Servidor de autoarranque Igual que el anterior, s61o que en el lado servidor. El servidor utiliza un pequefio programa (cargador de autoarranque).
Procesamiento distribuido con RMI Hay dos clases, j a v a . r m i .R M I S e c u r i t y M a n a g e r y j a v a . r m i .RMIClassLoader,quecomprueban el context0 de seguridad. El sistema RMI s61o descargari clases de ubicaciones remotas si ha sido enviado un gestor de seguridad. El R M I C l a s s L o a d e r tiene un mttodo importante: public static Class loadClass(String codebase, String name)
Este mttodo carga la clase desde la base de c6digo especificada. Otras formas de sobrecarga de este mttodo toman un URL para una base de c6diog o una lista de cademas de m~iltiplesURL. Tomemos el ejemplo HelloWorld y configurtmoslo en la configuraci6n cliente de arranque y sewidor de arranque. Esta configuraci6n es habitualmente la mis popular debido a su flexibilidad. Descargaremos: 0 Todas las clases del cliente, incluida la clase cliente, al cliente desde el sewidor Web. 0 Todas las clases del sewidor, incluida la clase sewidor, desde un sewidor Web central.
S61o necesitaremos una sends clase de arranque para el cliente y una para el sewidor. Primero, vamos a retocar un poco la clase H e l l o W o r l d de modo que se conecte a] sewidor a1 ser instanciada: import java.rmi.'; public class Helloilient
{
public Helloclient [ ) ( try ( HelloInterface obj = [HelloInterface) Naming.lookup( "rmi://localhost/HelloServer"); String message = obj . sayHello ( ) ; System.out .prir,tln( m e s s a g e ); ! catch [Exception e ) 1 System.out .println ("HelloClient excepciton: * 1
+ e) ;
Ya esti. Mantenemos la implementaci6n remota ( H e l l o s e r v e r . j a v a ) y la interfaz ( H e l l o I n t e r f a c e . ja v a ) igual queennuestro ejemplo initial. Escribamos ahora una clase de arraque, bootstrapped, (en lugar del archivo R e g i s t e r ~t que utilizamos anteriormente) que inicie el sewidor. Accede a la propiedad c o d e b a s e y carga la clase de sewidor desde la base de c6digo u t i l i z a n d o ~ ~ ~ ~ l a s s r: ~oade import import import import import
public class Dynamicserver { public static void mairt[String args[])
{
/ / Crear e instalar un gestor de seguridad if (System.getSecurityManager() == null) { Systern.setSecurityManager(new RMISecurityManager());
1
Capitulo 3 Praperties p = System.getProperties ( ) ; String url = p.getPrsperty ( " j ava. rmi .server.codebase") ; Class serverclass = RMIClassLoader.loadClass(url, "HelloServer"); ( ) ) ; Naming. rebind ( " / H e l l a S e r v e r " , ( R e m o t e )s e r v e r c l a s s .r~ewIr~star~ce System.out.println("He11oServer bound ~n registry"); catch (Exception e) [ System.out . p r i n t l n ( e );
I
I
I I
Cuando la clase descargada es instanciada con n e w I n s t a n c e ( ) , el constructor para la clase es invocado (nuestro constructor H e l l o S e r v e r ( ) ) y el objeto es exportado en el constructor y registrado con el registro. Los cinco pasos que ya hemos descrito en este capitulo (Desarrollo de aplicaciones con RMI), suceden conjuntamente entre el servidor y el registro. Existe un programa de arranque similar para el cliente que accede a la propiedad codebase y carga la clase cliente. Cuando la clase cliente descargada es instanciada, conecta a1 servidor y busca el objeto. Una vez mis, 10s pasos de 1 a 5 suceden entre el cliente y el registro: import import import public
j a v a . rmi. RMISecurityMar~ager; j a v a . rnii .server.RMIClassLoader; java.uti1.Properties; class DynamicClier~t J,
p ~ ~ b l i DynamicClient() c throws Exceptisn [ Properties p = System.getProperties[); String url = p.getProperty ("java.rmi.server. codebase") ; Class clientClass = RMIClassLoader. loadClass ( u r l , "He1 1oClient") ; / / Start the client clientclass. newInstar~ce( )
;
I public static void main (String args[]) [ System. setSecurityManager ( n e w RMISecurityManaqer try i D y n a m i ~ C l i e n t d c = n e w Dyr~amicClier~t ( ) ; 1 catch (Exception e) { Systern.out.println ( e );
( ) ) ;
I
Compile todas las clases y genere 10s stubs. Ahora necesitamos situar 10s archivos de clase H e l l o W o r l d en un servidor Web de modo que D y n a m i c s e r v e r pueda descargarlos en el periodo de ejecucidn. Para este ejemplo, utilizaremos un pequefio servidor HTTP de prueba de Sun llamado C l a s s F i l e S e r v e r (tambikn incluido en el c6digo fuente). Sitfie 10s cuatro archivos de clase para el ejemplo H e l l o W o r l d en un directorio ( \ p u b l i c h t m l ) en el servidor HTTP. Primero, inicie el registro RMI utilizando: r m i r e g i s t r y -J-Djava.security.p'i1icy=1egisterit.po1icy
despu& inicie el servidor HTTP. Para ClassFileServer seria algo asi (asumiendo que ClassFileServer se encuentra en el classpath): java ClassFileServer
Procesamiento distribuido con RMI El primer parirnetro de esta linea de comnndo especifica el puerto en el que se ejecuta el servidor y el segundo pnrimetro es la fuente .para que . lob archivos sean servidos. Probablernente, resultari un poco m i s ripido configurar un archivo por lotes para ejecutar estos comandos.
-
Entonceb, ejecutanios D y n a m i c s e r v e r especificando c o d e b a s e c o m o servidor Web:
Finalmente, e j e c u t e D y n a m i c C l i e n t , proporcionando de nuevo c l c o d e b a s e :
2 C u a n d o inicianios el DynamicServer, Cste accede a la base de c6digo descarga la clabe de implenientaci6n y esporta el objeto U El registro utiliza el c6digo de base para descargar el btub y asociar el objeto, registrando la basc de
c6digo de utilizada d
C u a n d o inicia el D y n a m i c c l i e n t , contacta de nuevo con la base de c6digoy descarga la clase de cliente y el stub, e invoca un metodo en el objeto servidor
Resumiendo los pasos para ejecutar el ejeniplo: Nota: In fuente descargable contiene archivo por lotes de prueba para ejecutar el c6digo. LI I n i c i e r m i r e g i s t r y :
i Inicie cl servidor de archivo de clase. Aseglirese de que las clases cornpiladas del primer ejeniplo H e l l o W o r l d asi conlo 10s stubs, e s t i n disponibles en la carpeta public-html :
Obberve que t o d o s los archivos de cliente HelloWorld, de servidor y s t u b se ubican en un s o l o lugar. La linica distribuci6n para el servidor es una clase y el linico archivo n e c e s ~ r i opara la distribucibn d e cliente es una clase:
Capitulo 3
Hernos visto anteriorrnente corno un cliente puede obtener una referencia a un objeto remoto corno resultado de una invocacion de rnktodo. De hecho, en realidad vimos en el ejemplo de D G C corn0 un objeto rernoto puede ser pasado dinimicarnente. Recuerde que habiarnos destacado inicialrnente que cliente y sewidor son tkrminos utilizados para describir un rol, no ubicaciones fisicas o arquitecturas. U n cliente tambikn puede ser un objeto remoto. En rnuchas situaciones, un sewidor puede necesitar realizar una llarnada rernota a un cliente, por ejernplo, datos de progreso o notificaciones administrativas. U n buen ejemplo seria una aplicaci6n chat donde todos 10s clientes son objetos remotos.
1. El objeto 2 lnvoca un rnetodo rernoto en el objeto 1 y se pasa a si mlsrno corno un pararnetro para ese rnetodo
2. El objeto 2 ut~l~za la referenc~aque ha obtenldo corno resultado (1)e lnvoca un rnetodo en esa referenc~a
I
N o hay nada de particular en la comunicaci6n entre pares o en las retrollarnadas entre objetos rernotos. Todo lo que ocurre es que una referencia rernota es pasada y que 10s rnktodos son invocados en esa referencia. Tomemos en mismo ejernplo H e l l o w o r l d que examinamos en un principio y modifiquernoslo para dernostrar las retrollamadas. La interfaz r e m o t a , H e l l o I n t e r f a c e , tiene un metodo que toma u n c l i e n t I n t e r f a c e corno argumento: public interface HelloInterface extends java.rmi.Remote { String sayHello(Client1nterface app) throws java.rmi.RemoteException;
I Para el cliente, la ClientInterface es tambien muy sencilla, con un solo metodo: public interface ClientInterface extends java.rmi.Rernote { void popup(String n s g ) throws java.rmi.RemoteException;
1 ~ e l l o ~ e r vi emrP ~ e m e n t a ~ e l 1 o 1 n t e r f aecinvocael e metodopopup ( ) e n c l i e n t I n t e r f a c e corno se muestra a continuaci6n: import import import import
class Helloserver extends 1JrlicastRernoteObject implements HelloIr,terface {
public Helloserver super ( ) ;
( )
throws RemoteExceptlon
{
1 public String s a y H e l l o ( C l i e r ~ t I r ~ t e r f a c ce a ) throws RemoteExceptinr~ { ca.popup("This is a message from the server!"); return "Hello World, the current system time is " + new D a t e ( ) ;
I El cliente que invoca mitodos en el servidor necesita ser un objeto remoto en si mismo. Escribamos un sencillo applet para demostrar esto. El applet se exporta a si mismo y empieza a escuchar llamadas de entrada invocando explicitamente el m i t o d o ~ n i c a s t ~ e m o t je e~cbt .e x p o r t O b j e c t ( t h i s ) (una forma sobrecargada de este m i t o d o le permite especificar tambiin el puerto): impart impart impart import import
java.applet.*; lava. awt . * ; j ava. io. Serializable; j ava. rmi. * ; j ava. rrni. s e r v e r . * ;
public
class CallbackApplet extends Applet implements ClientIr~terface, Serializable {
Strir,g message = " - n / a - " ; Frame f =new Frame(); Label 11= rlew Label i " public void ir~it( 1 1 f.add(l1); try i / / Exportar el objeto U n i c a s t R e r n o t e O b j e ~ t ~ e s p o r t O b j e c t( t h i s ) ; Strir,g host = "rrni://" + getCodeBase().getHost()+ "/HellaServer"; HelloIr,terface nbj = (HelloInterface )Naming.lookup ( h o s t ); message = obj . s a y H e l l o ( ( C l i e n t I n t e r f a c e )t h i s ); 1 catch (Exception e ) { Systern.out .println ("HelloApplet exceptian: " t e ) ;
I I
/ / Mostrar el rnerisaje en la applet public void paint(Graphics g ) { g.drawString(rnessage, 25, 5 0 );
I / / Implementar la interfaz public void popup(Strir1g t x t ) throws RemoteException{ ll.setText(txt); f.setSize(100,lOO); f.show0;
I I Cuando el applet es cargado, localiza el objeto servidor e invoca el mitodo remoto. Se pasa a si mismo como argument0 para ese mitodo. C o m o resultado, el stub es transportado a1 servidor y el servidor puede ahora invertir 10s roles. A c t ~ como a un cliente para este applet y puede invocar el m i t o d o POPUP ( ) .
Capitulo 3 Necesitamos una simple pigina H T M L para este applet ( A p p l e t .h t m l ) :
Es tan sencillo c o m o esto. Generamos 10s stubs para el cliente y el servidor ejecutando r m i c en er utilizando la C a l l b a c k A p p l e t y H e l l o s e r v e r . Inicie el registro y r e g i s t r e ~ e l l o ~ e r v con61 misma clase R e g i s t e r 1 t que hemos utilizado anteriormente. El applet debe ser cargado desde u n servidor W e b en el host (recuerde que 10s applet sin firmar pueden conectar de nuevo con el servidor) y puede utilizar su propio servidor W e b o el de prueba C l a s s F i l e S e r v e r utilizado en el ejemplo anterior. Todas las clases que el cliente necesita deben estar accesibles en el servidor Web. Las definiciones de archivo de clase stub de ~ a l l b a c k ~ ~deberian ~ l e t estar disponibles en la ruta de clase de objetos del servidor o deberian ser cargadas dinimicamente como hemos visto anteriormente. Tamhien puede probar las aplicaciones utilizando AppletViewer. Configure las preferencias e n A p p l e t Viewer como"unrestricted". Escriba u n archivo H T M L con el siguiente codigo ( ~ p p l e t v i e w e .rh t m l ) : cht rnl> capplet (:debase=". " / t, t 11, i ?
~ : ~ : ~ d e = " C a l l b a c l . : A p p lcel ta. s c "
width=300
heigt,t=266>
Ejecute el ejemplo despuks de iniciar el registro y el servidor desde el mismo directorio como el archivo H T M L y 10s archivos de clase. applttviewer
-J-Pjava.
security.poiicy=reglsttrit . p o l i c y A p ~ , l e t V i e w e r h . tml
Finalmente, a1 ejecutar este ejemplo, obtenemos algo parecido a esto:
Applet
(
I
Hello World, the current system time is Fn Aug 1 7 1 g:57:ll BST 2001
This is a message from the sewer!
Procesamiento distribuido con RMI
Activacion de objeto Los objetos remotos que hemos analizado hasta el momento son instancias de la clase j a v a . r m i .U n i c a s t R e m o t e O b j e c t y tienen una caracteristica principal. Son accesibles en todo momento, incluso cuando no hay clientes ejecutando. Consideremos un marco hipotktico en el que el numero de objetos remotos, o de recursos utilizados por ellos en un servidor sea alto. Esta situaci6n fue identificada como un importante cue110 de botella en Java 2 , por lo que se introdujo el concept0 de activaci6n. La activacion de objetos permite ejecutar objetos remotos dependiendo de la necesidad. Es decir, cuando se accede a u n objeto remoto "activable" (via invocacion de metodo), si ese objeto remoto n o estd siendo ejecutado en ese momento, el sistema inicia la ejecuci6n del objeto e n una JVM apropiada. RMI utiliza la activaci6n lenta: es aquella en la que la activaci6n de u n objeto es aplazada hasta el primer uso de u n cliente, la primera invocaci6n de mitodo. Entonces, icuil es la diferencia entre un objeto activable y el habitual objeto remoto desde la perspectiva de un cliente? Ninguna. Para el cliente, todo el mecanismo de activacion es transparente y el cliente nunca es consciente de lo que esti ocurriendo detris de la escena. Las referencias a1 objeto remoto pueden ser consideradas referencias lentas o imperfectas. Las referencias a objetos activables contienen informacion persistente de descripci6n que permite la activation del subsistema para saber que el objeto deberia estar iniciado si no esti ya siendo ejecutado. Despuks de que una referencia activable sea utilizada por primera vez, la capa de referencia remota cambia a referencia remota regular de mod0 que no tenga que pasar por el sistema de activaci6n posteriormente. Puesto que el sistema de activaci6n puede cambiar la referencia lenta a referencia remota activa, las referencias a objetos activables estin siempre disponibles. Sin embargo, las referencias a un objeto remoto no sobreviven despuks de un fallo del sistema o de reiniciar. Para comprender la verdadera semintica de utilizar el modelo de activacibn, debemos familiarizarnos con algunos tkrminos utiles:
O Activador El activador es un componente principal en el sewidor. Facilita la activaci6n del objeto remoto registrando toda la informacidn necesaria para activar un objeto y es responsable de iniciar instancias de las JVM en el sewidor si es necesario. 0
G r u p o de activaci6n U n grupo de activacion crea instancias de objetos en su grupo e informa a su monitor sobre 10s diferentes estados activos y pasivos. La analogia mas cercana a un grupo de activation es un grupo thread (hebra). U n grupo de activaci6n es en esencia una instancia cornpleta, independiente de la JVM que existe unicamente para albergar grupos de objetos activados. Esta nueva JVM es iniciada por el activador cuando asi se requiere. Pueden existir multiples grupos de activaci6n.
O Monitor de activaci6n Cada grupo de activaci6n tiene un monitor de activaci6n que registra el estado de un objeto en el grupo y el estado del grupo en su conjunto. El monitor de activaci6n es creado cuando se activa el grupo. O Sistema de activaci6n El sistema de activaci6n proporciona un medio para registrar grupos y objetos activables para ser activados dentro de esos grupos. Trabaja en estrecha relaci6n con el activador, que activa objetos
Capitulo 3 registrados mediante el sistema de activaci6n y con el monitor de activacibn, y obtiene informacidn sobre objetos activos e inactivos, y grupos inactivos. El modelo de activaci6n y sus implementaciones asociadas aparece resumido en la siguiente tabla:
I
Entidad
Implementaci6n
Implementado como
Activador
java. rmi. activation-Activator
Interfaz (observe que el activador es en si mismo un objeto remoto).
Grupode activaci6n
java.rmi.activation.ActivationGroup
Claseabstracta.
Monitor de activaci6n
j a v a . r m i . activation.ActivationMonitor
Interfaz.
Sistemade activaci6n
java.rmi.activation.ActivationSystem
Interfaz.
El mecanismo de activacion utiliza identificadores y descriptores. Aunque pueda parecer excesivo, merece la pena recordar estos puntos:
0 Cada objeto activable tiene un I D y un descriptor.
o
Cada objeto activable pertenece a un grupo de activacion. El grupo mismo tiene un I D y un descriptor.
El grupo de activacion U n grupo de activaci61-1,como ya hemos dicho anteriormente, se utiliza para mantener un grupo de objetos activables. El grupo de activaci6n esti asociado a un identificador de grupo ( j a v a . r m i . A c t i v a t i o n . ~ c t i v a t i o n ~ r o uypa ~ n~d)e s c r i ~ t o r d e g r u p o ( j a v a . r m i .a c t i v a t i o n . A c t i v a t i o n ~ r o u p D e s c queidentifican ) y describenelgrupodeactivaci6n respectivamente. U n grupo de activaci6n es creado explicitamente como resultado de invocar el mktodo ActivationGroup.createGroup(): public
static ActivationGroup createGroup(ActivationGroup1D id, ActivationGroupDesc desc, long incarnation)
donde:
0 i d e s el identificador del grupo de activacih 0
d e s c es el descriptor del grupo de activaci6n
0 i n c a r n a t i o n es el n ~ m e r ode personification del grupo de activaci6n (cero en la creaci6n inicial de un grupo) A c t i v a t i o n G r o u p I ~ademis , de identificar el grupo de forma exclusiva dentro del sistema de activacion, tambikn contiene una referencia al sistema de activacion del grupo. Esto permite al grupo interactuar con el sistema siempre y cada vez que sea necesario. Todos 10s objetos con el mismo A c t i v a t i o n G r o u p I D son activados en la misma JVM.
Procesamiento distri buido con RMI U n A c t i v a t i o n G r o u p D e s c contiene la informacidn necesaria para crear o recrear el grupo en el que activar objetos. Contiene: O
E l n o m b r e d e ~ l a s e d e l g r u ~Recuerdeque o. j a v a . r m i .a c t i v a t i o n . A c t i v a t i o n G r o u p e s una clase abstracts y el activador ( r m i d ) proporciona internamente su implementacidn concreta (par ejemplo, la clasesun. r m i . s e r v e r . A c t i v a t i o n G r o u p I m p l ) .
0 La ubicacibn de la clase del grupo. O
U n objeto escrito y transmitido (marshaled) que puede contener datos de inicializaci6n especificos del grupo.
que especifica las opciones A c t i v a t i o n G r o u p D e s c contiene una clase interna~ommand~nvironment de entorno de arranque para las clases de implementaci6n de A c t i v a t i o n G r o u p . Esto permite un control exacto sobre las opciones de comando utilizadas para iniciar la JVM descendiente (un C o m m a n d E n v i r o n m e n t nulo hace referencia a 10s valores por defecto de r m i d ) . A c t i v a t i o n G r o u p D e s c puede ser creado utilizando uno de 10s dos constructores especificados a continuaci6n: O
Construir un descriptor de grupo que utilice la omisi6n del sistema para la implementaci6n de grupo y la localization de c6digo:
O Especificar una implementaci6n de grupo y un entorno de ejecuci6n alternativo para set utilizado por el grupo: ActivationGroupDesc(String className, String location, Marshalledobject data, Properties overrides, ActivationGroupDesc.CommandEnvironment cmd)
Hemos dado un ripido repaso a 10s grupos de activacidn. Veamos ahora algo de cddigo que resume la creacidn de grupos de activacibn: / / Crear el descriptor d e grupo Properties env = new Properties ( 1 ; env.put ("java.security.po1icyYY,"fi1e://%BOOKHOME%/Ch03/Activatable/ registerit .policy") ; ActivationGroupDesc mygroupdes = n e w ActivationGroupDesc(props, n u l l ) ;
/ / Obtener una referencia a1 sistema d e activaci6n ActivationSystem mysystem= ActivationGroup.getSystem();
/ / Registrar el descriptor de grupo con el sistema de activaci6n y obtener el id del grupo id ActivationGroupID groupid=y system.registerGroup(mygroupdes); / / Ahora que tenemos el id y el descriptor podemos crear el grupo explicitamente Activatior~Group.createGroup(groupid, mygroupdes, 0);
Igual que A c t i v a t i o n G r o u p I D es un I D para el g r u p o , A c t i v a t i o n I D es un I D para el objeto. Una vez que el objeto es registrado con el sistema de activacidn, se le asigna un A c t i v a t i o n I D . Contiene dos elementos esenciales de informacibn:
o Una referencia remota a1 activador del obieto
Procesamiento distribuido con RMI O
Invocando el mktodo e s t i t i c o ~ c t i v a t a b l .e r e g i s t e r ( A c t i v a t i o n D e s c d e s c )
.
o Instanciando el objeto mismo utilizando el primer o el segundo constructor de la clase A c t i v a t a b l e (que toma A c t i v a t i o n I D como parimetro). Este registra y exporta el objeto. O
Exportando el objeto explicitamente mediante el primer o el segundo mitodo e x p o r t o b j e c t de l a c l a s e A c t i v a t a b l e que toma u n A c t i v a t i o n I D , la implementaci6n de un objeto remoto y un numero de puerto como argumentos. Este registra y exporta el objeto.
()
Detris de las escenas esti ocurriendo lo siguiente:
o Cuando se genera un stub para un objeto activable, contiene information especial sobre el objeto. Esta informaci6n incluye el identificador de activaci6n e informaci6n sobre el tipo de referencia remota del objeto. 0 El activador localiza el descriptor de activaci6n del objeto y el grupo de activaci6n. Si el grupo de
activacion en el que deberia estar este objeto n o existe, el activador inicia una instancia de una JVM, crea un grupo de activacion y despuks envia la solicitud de activaci6n a ese grupo. El grupo de activaci6n carga la clase para el objeto y lo instancia (utilizando constructores especiales que toman varios argumentos, como veremos pronto). Cuando el objeto es activado, el grupo de activaci6n devuelve una referencia de objeto a1 activador (ksta es una referencia serializada o marshaled). El activador graba el identificador de activaci6n y el pareado de referencia y devuelve la referencia viva a1 stub. El stub envia entonces invocaciones de metodo mediante esta referencia viva directamente a1 objeto remoto (la referencia viva es como cualquier otra referencia). Resumamos todo lo que hemos visto hasta ahora volviendo a ejecutar el ejemplo H e l l o w o r l d para convertirlo en activable.
Convertir objetos en activables C o m o hemos visto, existen algunas entidades cooperantes en el marco de trabajo de la activacion que hacen todo sea posible:
o El objeto. O
El programa envoltorio que registra el objeto. Es similar al programa RegisterIt que utilizamos anteriormente. Normalmente realiza unas llamadas de metodo a1 sistema de activaci6n para proporcionar detalles sobre c6mo deberia ser activado el objeto.
O
La tercera entidad es el demonio (daemon) de activacidn que graba informacibn, igual que el registro, sobre cuindo y quk hacer con 10s objetos (este daemon es r m i d ) .
Teniendo en cuenta estas entidades, 10s pasos para convertir un objeto en activable pueden resumirse del siguiente modo: O
Elobjeto debeampliarlaclase j a v a . r m i . A c t i v a t i o n . A c t i v a t a b l e enlugardelaclase U n i c a s t R e m o t e O b j e c t (existe una alternativa a esto que examinaremos posteriormente).
0 El objeto debe incluir un constructor especial que tome dos argumentos, su identificador de
activaci6n de t i p o ~ c t i v a t i o ny~sus ~ , datos de activaci6n opcionales, un j a v a r m i .M a r s h a l l e d O b j e c t . Este es distinto de 10s objetos remotos no activables, que incluyen un constructor sin argumento. Este constructor especial es llamado por el sistema RMI cuando activa el objeto.
.
Capitulo 3 0 U n descriptor de activation (java . rmi .Activation.Activation~esc) debe ser creado y
registrado con el activador (rimd). Es importante destacar que la interfaz remota del objeto n o necesita ser cambiada o modificada en n i n g h caso. Es logic0 porque solo estamos cambiando la implementation de la instancia del objeto, n o la perception exterior del objeto.
Paso 1:Crear la interfaz remota N o se diferencia de lo que teniamos anteriormente: lrnprt
j ava
.r m i .
+
;
Paso 2: Crear la implernentacion del objeto Esta clase arnplia j ava. rmi .Activation .Activatable eimplementa la interfazremota (puesto que la clase Activatable amplia RemoteObj ect). Ademis, debe contener un constructor de dos argumentos que tomaActivationID yMarshaledObj ect como argumentos. Este constructor debe llamar a 10s constructores de superclase adecuados para asegurar la inicializacion: i m F > o r t j a v a . 1 - n i l . '; irnp(,rt j a v a . rnii. a c t i v a t i o n . * ; import j a v a . u t i 1 .Date; public
class
HelloServel-
e s t e r ~ d sActivatable
implenier~ts H e l l o I n t e r f a c e
H e l l o S e r v e r ( A c t i T ~ a t i o r ~ IiD d , Marshaledobject d a t a ) throws RemoteExceptior~ { / / R e q i s t r a e l o b j e t o c o n una a s t i T J a c i 6 n d e l s i s t e m a / / R e g i s t r a r l c ~ 7 e s p o r t a r l o en u r ~ p u e r t o a r ~ i r ~ i m o superiid, 0 ) ;
publiz
p ~ b l i i : S t r i n g s a y H e l l o ( ) thrt-.:h..- R e m o t e E x c e ~ ' t i i , n l l . e t ! l r r ~" H r l l ' - ~ W o r l d , t h e ' : u r r e n t system time i s
"
+ ~r.eh, D a t e ( ) ;
Paso 3: Registrar el objeto con el sistema Esta clase contiene toda la informacion necesaria para registrar el objeto, sin crear verdaderamente una instancia del objeto: import import import
j a T / a .r m i . * ; j a v a . rmi . a c t i v a t i o n . * ; j ava. u t i l . Properties;
~ , ~ ~ b cll ia sc s
RegisterIt
!
p u b l i c s t a t i c v o i d m a i r ~ ( S t r i r ~ a~rgg s [ ] ) t h r o w s E x c e p t i o r ~ ~{ try i / / I t n s t a l a r url g e s t o r d e s e g u r i d a d System. s e t S e c u r i t y M a n a g e r (new RMISezurityManager i ) ) ;
{
Procesamiento distribuido con RMI
/ / Crear el grupo Properties env = new Froperties ( ) ; env.put ("java.security.policy", "file://%BOOK HOME%/Ch03/Activatable/ activation/reqisterit.policy"); ActivationGroupDesc myqroupdes = new ActivationGroupDesc (ertv,null) ; ActivationGroupID mygroupid = ActivationGroup.getSysteni(). registerGroup(rnygroupdes);
/ / Crear los detalles sobre el objeto Activatior~Desc obj ectdesc = new ActivationDesc ("HelloServer", "file://%BOOK HOME%/Ch03/Activatable", null);
/ / Registrar el descriptor de activaci6n con el activador HelloIrlterface rnyobject = (HelloInterfacejActivatable .reqister(objectdesc); / / Asiiclar el stub a un r~ornbre del reqistro rmi Naming. rebind("helloObject", myobject); / / Salir Systern.out .println ( " D o r ~ e ";)
Casi hemos terminado. Ahora podemos utilizar el viejo cliente que grabamos para nuestro ejemplo inicial y ejecutarlo con 10s mismos argumentos de politica y arranque: import
]
a v a .rrni . * ;
public class HelloClient
[
public static void rnain(Strinq arqs[]) { if (arqs.length < 1) { System.out.println ("Usage: java HelloCllent "); System. eslt ( I ) ; 1 else { try I HelloIrlterface server
}
=
( H e l l v 1 n t e r f a c e ) N a r n i n g . lookup (
Compile 10s archivos y despuis genere 10s stubs y 10s skeletons para el objeto remoto. Inicie el sistema de Activaci6n utilizando la utilidad r m i d y luego inicie nuestro programa que registra nuestros objetos activables: rmid J - D j a v a . s e c u r i t y . p o l i c y = r e q i s t e r i t . p o l i c y
Capitulo 3 Ahora podelnos ejecutar el a r c h i w Regis t e r I t: - P j - r ~ ~ . : : e , : ' ~ r i t ! ; . p ~ l i r 2 y = r ~ ~ t? .i p~r t. el ir ci y -Cmi ;1'.>a. r m i : : e ~ . i e r .r : . ~ . . l e b r 7 . c r . = f i 1//3;E?OOi':_ e: HOPlL'i/i'hlj?/A~:t i v ~ L a t , l ~ / Ke~i:?rcrIt
j
.
Finalmente, podemos utilizar el clientc, c o m o rnucstra la siguicnte pantalla de salida:
jese en que deberia tener tres o cuatro ventanas d e lineas de comandos abiertas para este ejemplo: J Rmiregistry
J Rmid
Ll RegisterIt 1 3 Helloclient
Las dos ultimas podrian ejecutarse en una ventana.
Alternativa a ampliar la clase Activatable En ocasiones puede que n o sea posible ampliar la c l a s e ~ civatable t si el objeto remoto necesita ampliar otra clase. Por ejemplo, si estamos escribiendo un applet que queremos convertir e n activable o e n objeto remoto, nuestro applet necesitaria ampliar j ava .applet .Applet y e n Java n o existe la herencia rndtiple.
Ya henios visto anteriurmente que era posible convertir un objeto en remoto exportando el objeto directamente utilizando uno de 10s mktodos d e exportaci6n de la clase j ava rmi .UnicastRemoteObj ect,envezdeamp~iar~ac~ase~nicast~ernote~bj ect.
.
Esiste una alternativa similar para 10s objetos activables. Al hablar sobre descriptores de activation hemos mencionadu un metodo exportob j ect ( ) Es posible registrar y exportar un objeto invocando cualquiera de los niCtodos de exportacion d e la clase j ava .Activation .Activatable.
.
Rescribamos nuestra clase activable Helloserver para demostrar esto, manteniendo igual el resto:
puhlic
class HelluServer
puhlic
impl.ements H e l l o I n t e r f a c e
H ~ l l o S e r v e r [ A c t i v a t i c ~ n Iid, t~ tht-ows RemoLeExcept l o r ] (
(
Marshaledobject
/ I R e q i ~ t r a r l o y e x p n r t a r l o e n u n puerto anbnlrno Activatable.export0bject [ t h i s , i d , 0 ) ; / / OF, /
&
data)
Procesamiento distribuido con RMI Activatable. r-xpsrt0bject(this, id, 0 , new S o r n e R M I C l i e n t S o c k e t F a c t ' 5 r y c s f 0 , new S n r n e R M I S e r v e r S o c k e t F a c t n r y ( ) ) //OR Activatable.exportObject(this, " . " , data, false, 0 ) ; //OR P.ctivata~le.exportObject(this, data, false, 0, new S o r n e R I ~ I I C l i e n t S o c k e t F a c t o r y( new S n r n t R M I S e r v e r S o c k e t F a c t o r y ( */ 'I.",
)
,
) ) ;
1
public Strir,g ~ a y H e l l ~ !ttlrk?ws ) RemoteExcey;tinr~{ return "Hello Igi'~-ld,the current system timr i-" i
t
r~ew Date ! ) ;
En el ejemplo anterior, dos de 10s constructores presentados tornan factorias de socket como argumentos. Trataremos las factorias de socket en breve. Por ahora, s610 recuerde que puede pasar factorias de socket como argumentos a sus objetos activables.
lniciar multiples JVMs sin recurrir a rmid r m i d o el activador mismo es un objeto remoto y se ejecuta en una JVM. Cada objeto que es activado es activado en su JVM del grupo de activaci6n pero, en ocasiones, puede ser deseable producir una JVM independiente para cada objeto activable (por ejemplo, en una gran aplicaci6n desearia eliminar el h i c o punto de fallo aislando objetos en diferentes JVM). Es muy sencillo si tenemos en cuenta lo que mencionarnos a1 referirnos a A c t i v a t i o n G r o u p I D , es decir, "Todos 10s objetos con el mismo A c t i v a t i o n G r o u p I D son activados en la misma JVM". Para iniciar mdtiples JVM, el objeto debe tener un A c t i v a t e G r o u p I D diferente o, en otras palabras, debe estar en un grupo de activaci6n independiente. El siguiente c6digo muestra c6mo el mismo objeto H e l l o S e r v e r es registrado de forrna distinta de mod0 que cada objeto tenga u n A c t i v a t e G r o u p I D diferente (y, por consiguiente, un grupo de activaci6n diferente). ~ s t es a la clase que registra nuestros objetos activables: import j ava. rmi. + ; import java. rmi. activation.+; import java.uti1. Properties; public class RegisterIt { public static void rnain(Strir1g [ 1 a r g s ) { try I //Instalar un gestor de seguridad S y s t e r r ~ . s e t S e c u r i t y M a r l a g e r( n e w RMISecurityl4anager (
) ) ;
//
crear otra para una nueva VM Properties erlv = new Properties ( ) ; env.put ( " java. s e c u r ~ t y Y p o 1 i c y Y ' , "file://%BOOK HOME%/Ch03/Activatable/MultiVM/ registerit.policy"); ActivationGroupDesc mygroupdes = new ActivationGroupDesc [er~v, r~~lll) ; ActivationGroupID mygroupid = A c t i v a t i o n G r o u p . g e t S y s t e r n ( ) .registerGroup(mygroupdes); ActivatinnGroup. createGroup (mygr~1upii3,rnygroupdes, 0 ); ActivatinnDesc objectdesc = new ActivationDesc ("HelloServer",
Capitulo 3 "file://%BOOK HOME%/Ch03/Activatable/MultiVM/", null ) ; HelloIrlterface myobject == (HelloIr~terface)Activatable.register( obj ectdesz); Naming. rebind ("hello0bjecttt,myobject) ; / / Registrar otro id de grupo ActivationGroupID mygroupid 2
El cliente inicia la nueva JVM en el servidor debido a la activaci6n lenta (activaci6n la primera vez que el metodo es invocado): i m p f ~ r tj ava. rml. * ; public class HelloClient
/ / Producir la sequnda VM en el servidor HelloInterface obj 2 = (HelloInterface)tlaminq.lookup( "rmi://" t arqs[O] t "/helloObject 2"); 2;j)iolH ly e as.2jb oinltnirp. tu om e.tsy Sjb o( sayHe110 ( ) ) ; System.out .prir~tln }
Si ejecutamos este ejemplo v observamos 10s procesos a1 ejecutar el cliente, veremos que se utilizan dos VM de Java:
Procesamiento distribuido con RMI
Archivo
-I
Opciones
--
---
Nombre de lmagen
--
--
Nombre de usuarlo
-
CPU
Uso de
...
A
explorer.exe java.exe
Isass.exe mstask. exe NAVAPSVC.EXE NAVAPW32.EXE NPSSVC.EXE ns-admin-exe ns-slapd.exe Psp.exe realplay .exe U M o s t r a r procesos de todos los usuarlos
3rocesos: 23
Uso de CPU: 13%
[xi&ETl
:
Carga de transacciones: 1740801
Desactivacion La activaci6n permite a un objeto ser iniciado a petici6n; sin embargo, no desactiva automiticamente un objeto. La decisi6n de desactivar un objeto queda en manos del mismo objeto. U n objeto activable puede desactivarse a si mismo invocando el metodo Activatable.inactive(ActivationID i d ) . Es importante saber la diferencia entre eliminar un objeto del registro y desactivar un objeto. La desactivaci6n es un estado temporal, permitiendo al sistema de activacih reiniciar el objeto mis tarde, mientras que a1 eliminarelobjeto m e d i a n t e ~ c t i v a t a b l e. u n r e g i s t e r ( A c t i v a t i o n I D i d ) , iste queda eliminado permanentemente del sistema de activaci6n. O t r o m i t o d o utilesel m e t o d o ~ c t i v a t a b l e. u n e x p o r t O b j e c t ( R e m o t e o b j , b o l e a n f o r c e ) que puede utilizarse para deshacer la exportaci6n del objeto. El b o o l e a n o es utilizado para forzar al objeto a ser no expoetarse incluso si hay llamadas pendientes o en progreso.
Caoitulo 3
Aunque la activation puede ser u n gran avance en rendimiento cuando el numero de objetos de u n sistema es alto, aliviando el drenaje de 10s recursos, debe tener cuidado a1 decidir corn0 y cuindo utilizarla. El sobregasto necesario para crear y reactivar un objeto inactivo es importante. Puede suponer crear una nueva JVM, cargar, verificar clases y deserializar u n estado de objeto persistente. U n objeto deberia normalmente decidir en tiempo seguro mantenerse vivo. Una buena estrategia de desactivacion podria basarse en el tiempo transcurrido desde la ultima Ilamada.
A continuacion, dirigiremos nuestra atencion a la capa Secure Sockets (SSL). Esta section presupone que el lector esti familiarizado con 10s Sockets T C P I I P y la redificacion en Java.
Sockets de adaptacion y SSL U n socket es un extremo de comunicacion. Dos sockets en colaboraci6n, uno en la miquina local y el otro en la miquina remota, forman una conexion. Esta distincion entre sockets y conexiones es muy importante. Hay dos tipos de sockets, sockets de conexi6n y sockets de escucha, tambiin conocidos como sockets cliente y servidor, respectivamente. U n socket de conexion existe en cada extremo de una conexion T C P abiertay es abstraido por las clases j a v a . n e t . S e r v e r s o c k e t y j a v a . n e t . s o c k e t . U n socket de escucha no e s t i asociado a ninguna conexi6n T C P per0 solo existe como una abstraction para permitir al nucleo T C P decidir q u i proximas conexiones son aceptadas y quiin obtiene el nuevo socket de conexion aceptado. En cualquier momento, RMI tiene algunos sockets de escucha, uno para cada puerto escuchador (normalmente solo uno porque RMI exporta todos 10s objetos en el puerto "por defecto" si n o se especifica un puerto concreto en el mitodo e x p o r t ( ) examinado anteriormente). RMI tambiin crea sockets de conexion para conexiones de salida y para conexiones de entrada. El numero de conexiones de salida solo depende del numero de llamadas de salida concurrentes. La sencilla regla es la siguiente:
o Si un hilo quiere realizar una llamada remota y todas las conexiones a1 extremo estin en uso, entonces el RMI abre una nueva conexion para transportar la llamada 0
Si una conexion e s t i libre (es decir, si n o hay ninguna llamada en progreso utilizando la conexion), entonces el RMI la reutilizari para la siguiente llamada remota
RMI produce un hilo para escuchar cada socket de escucha (normalmente tambiin uno). Cuando RMI acepta una nueva conexion, crea un nuevo hilo (y un hilo controla la nueva conexion y el otro vuelve para aceptar una nueva conexion). Cuando la conexion se cierra, su hilo asociado tambiin se cierra. Los hilos de control de conexiones producidos por RMI n o estin de ning6n mod0 serializados. Si las llamadas llegan a la vez, son ejecutadas en hilos concurrentes. Las llamadas todavia pueden sincronizar objetos Java per0 RMI n o realiza esa sincronizaci6n de forma automitica (el objeto remoto es responsable de su propia sincronizacion, ya sea por mCtodos sincronizados o por bloqueo sincronizado). U n punto habitual de confusion es que si el stub remoto es devuelto por una llamada remota, el cliente puede en ocasiones realizar dos conexiones a1 servidor. Esto ocurre porque el subsistema distribuido de recolecci6n de residuos necesita realizar una llamada D G c d i r t y ( ) para notificar a1 servidor que una nueva entidad alberga una referencia a1 objeto remoto.
.
Procesamiento distribuido con RMI Puede utilizar netstat para controlar 10s sockets de escucha. La siguiente captura de pantalla muestra 10s sockets justo despuis de que se inicie el registro en 1099. Helloserver es exportado a 2000 y esta' asociado a1 re~istro. La columna de la izauierda enunzera 10s sockets abiertos de la ma'nuina. La u primera linea es para el registro, la segunda para el objeto. La tercera muestra que un socket ha sido abierto por el objeto a1 registro y la riltinza linea nruestra el socket abierto por el registro a1 objeto.
Una n~ejoranotable que ha sido afiadida a RMI desde la entrega 1.2 de Java ha sido la capacidad de utilizar factorias de sockets de adaptaci6n basados en el modelo de disefio Factory. En lugar de utilizar 10s sockets convencionales en TCP/IP, cada objeto tiene la capacidad de utilizar su propio tip0 de socket. Esto permite al objeto procesar datos (cn vez dc pasnrlos simplemente), ya sen antes de ser enviado al socket o despues de ser recibido por Cste. En J D K l.l.x, fue posible crear un.1 subclase de adaptation j ava . rml .RMISocket Factory que produjo un socket d e adaptaci6n. difcrcnte a 1ava .net . Socket,para ser utilizado por la capa de transporte de RMI. Sin embargo, n o fue posible para la factoria de socket instalada producir diferentes tipos de sockets para diferentes objetos. Por ejemplo, en J D K 1.1, una factoria de socket de RMI n o podia producir sockets Secure Sockets Layer (SSL) para un objeto y utilizar el Java Remote Method Protocol (JRMP) directaniente sobre T C P / I P para un objeto diferente en la misma JVM. Adenlis, antes de la versi6n 1.2, era necesario que rmiregist ry utilizara hnicamente el protocolo de socket de adaptaci6n del usuario. La factoria d e socket afectaba a1 sistema completo y n o s61o a un objeto. Para entender q u i significa realmente esta afirmaci6n, veamos primer0 donde intervienen 10s sockets de arquitectura M I , sus tipos y sus prop6sitos: Posici6n
Socket d e servidor
Socket d e cliente
Rcgistro RMI
Abre un socket d e servidor (puerto por dcfecto 1099) y espera solicitudes de:
Utiliza un socket de cliente para establecer una conexi6n a un objeto servidor justo despues de haberse registrado.
U Servidores para asociar, reasociar,
y desasociar in~plementacionesde objeto. Clientes que desean localizar servidores. Servidores RMI (implementaci6n remota).
Abre un socket de servidor en un puerto especificado por el usuario via m i t o d o exportOb j ect ( ) o, por defecto, a un puerto local aleatorio; es utilizado para aceptar conexiones de las res uestas enwadas por el cliente (el s t u t ) .
U n socket d e cliente es utilizado mientrasseconectaalre istro,en concreto para registrar a implementaci6n del servidor.
Clientes RMI (objetos que invocan metodos remotos).
N o s e utiliza.
Los sockets de cliente son utilizados para la comunicacion con el registro RMI, ara localizar la implementacidn i e servidor araconseguirqueelrnktodoRd l a m e a1 servidor.
9
Capitulo 3
\
/'
,
-1 ,~Naming.bind('HelloSe~eV,obj;) \ >.
Objeto
'
,remOto I' _ , , '
,
1';
i
! I
Socket de S e ~ d 0 Ir
Socket de servidor
t
9I
i
Devuelve el stub
1
Socket de cliente
1
13
. Cl~ente 1 - - Invocac~onde metodo
-
-
.
-
Cuando un cliente ejecuta una operaci6n de "blisqueda", se realiza una conexi6n a1 socket de servidor en el r m i r e g i s t r y . En general, puede crearse o no una nueva conexi6n para una llarnada rernota. La capa de transporte RMI acumula conexiones para usos futuros. Si alguna conexi6n existente, y a1 menos una de ellas esti libre, entonces se reutiliza; de no ser asi, la implementaci6n actual crea sockets adicionales a peticibn. Por ejernplo, si un socket existente esti siendo utilizado por una llamada existente, entonces se crea un socket nuevo para la nueva Ilamada. Normalmente, hay como minimo dos sockets abiertos puesto que el recolector de residuos distribuidos necesita realizar llamadas remotas cuando 10s objetos remotos son devueltos desde el servidor. Un cliente no tiene control explicit0 sobre las conexiones a un servidor, ya que las conexiones son gestionadas en el nivel de la capa de transporte RMI. Las conexiones expirarin si se mantienen sin utilizar durante un tiempo. Corno puede ver, existe un numero de puntos de comunicacidn y sockets que son utilizados en este proceso de comunicacidn de tres vias entre el cliente, el registro y el objeto. Es tambikn importante destacar que el registro s61o es necesario para localizar un objeto por su nombre. Una vez que el objeto esti localizado, hay comunicaci6n directa entre el objeto y el cliente. U n objeto puede especificar que clases de factoria son necesarias para que alguien se comunique con este tipo de socket a travts del constructor j a v a . r m i . s e r v e r . U n i c a s t R e m o t e O b j e c t ( o j a v a . r m i .a c t i v a t i o n . A c t i v a t a b 1 e para ese asunto). Instancias de esas factorias s o n u t i h a d a s para crear instancias de 10s tipos de sockets deseados: protected UnicastRernoteObject(int port, RMIClientSocketFactory RMIServerSocketFactory ssf)
csf,
C o m o hemos explicado en la tabla anterior, una vez que el cliente ha localizado un objeto, utiliza un socket de cliente para conectar a1 socket de cliente que esti escuchando el objeto. La factoria de socket de cliente debe implementar la interfaz j a v a . r m i . s e r v e r . m I S o c k e t F a c t o r y . Elsocket de cliente es creado desde esta instancia d e ~ ~ ~ ~ o c k e t ~invocando a c t o el r ~ m k t o d o c r e a t e s o c k e t ( ) que devuelve una instancia del tip0 de socket adaptado al servidor y a1 puerto especificados: public
Socket createsocket (String host, int port)
La factoriadesocket deservidordebeimplementarlainterfazj a v a .r m i .s e r v e r . R M I S e r v e r S o c k e t F a c t o r y y proporcionar una implernentaci6n para el metodo c r e a t e s e r v e r S o c ke t ( ) . El socket de servidor es creado (para empezar a escuchar llamadas entrantes) invocando la implernentacion de rnetodo en la clase de factoria de socket de servidor:
Procesamiento distribuido con RMI public Serversocket createServerSocket(int port)
Esto es especialmente fitil cuando se desea cifrar la comunicaci6n entre 10s objetos. Por ejemplo, utilizando SSL o TLS. Examinemos un ejemplo de c6mo se puede realizar. Primero necesitariamos un par de cosas, siendo la principal un proveedor de seguridad que proporciona una implementaci6n del protocolo SSL en Java. Muchos productos terceros disponibles hacen esto. SSL y TLS proporcionan ambos cifrado y certificaci6n. En realidad, Transport Layer Security (TLS) es la nueva norma de Internet Engineering Task Force (IETF) y est6 basada e n SSL. Las especificaciones SSL puede encontrarlas en http:llhome.netscape.comlenglsecurityl y las especificaciones TLS se encuentran en RFC 2246 en http:llwww.ieff.org.lrfclrfc2246.&t. Los detalles sobre las implementaciones SSL de fuente abierta (SSLeaylOpenSSL) puede encontrarlas en http:llwww. opnessl. org. ,
Sun ofrece Java Secure Sockets Extension USSE) que implements una versi6n Java de 10s protocolos SSL y TLS e incluye funcionalidad para el cifrado de datos, autentificacidn de servidor, integridad de mensaje y autentificacion optional del cliente. El ejemplo examinado aqui utiliza JSSE. Necesitara' descargarlo de f o n a independiente para J2SE (1.2 o 1.3) y sera'n incluido en J2SE (1.4), vkase http://java.sun.com/products,!jsse/para ma's infonacidn.
Se va producir un rendimiento suplementario y la comunicaci6n va a ser muy lenta debido a la complejidad del acuerdo inicial y el cifrado que supone. El mod0 en el que el proveedor implementa el algoritmo afectari tambiin el rendimiento. Por ejemplo, una implementation nativa como GoNative Provider (http:/ /www.rtfm.corr\/puretls/gonative.html) es mis ripida que su equivalente Java. Intenternos primer0 analizar quC parte de la comunicaci6n queremos/necesitamos cifrar. El registro de designaci6n es implementado como un servicio RMI estindar por lo que 10s intentos de registrar y buscar servicios supondrin el establecimiento de conexiones de red. Si necesita que la comunicaci6n con el registro tenga lugar en sockets seguros, el registro de designaci6n obviamente necesitari escuchar sobre sockets seguros de servidor. U n mod0 muy direct0 de conseguirlo es que el servidor inicie su propio registro de designacion. Este registro se beneficiari entonces del apoyo SSL del servidor. El servidor necesitari invocar y configurar explicitamente una factoria de socket e iniciar el registro: RMISocketFactory.setSocketFactory (some vendor provided factory); LocateRegistry.createRegistry(somep~rt);
La factoria de socket SSL puede entonces ser instalada en el cliente antes de buscar el objeto y todo quedari asegurado por SSL. Puesto que el mismo socket n o puede escuchar en dos puertos, seria necesario ejecutar dos registros: u n o seguro y u n o normal, si necesitara buscar e n diferentes protocolos. La mayoria d e 10s vendedores proporciona u n registro seguro con la implementaci6n Java-SSL que puede ser utilizado si n o estd iniciando el registro programdticamente. En la mayoria de 10s casos, s6lo es importante y necesita cifrado la comunicaci6n entre 10s objetos, no la bGsqueda; esto es lo que estudiaremos en el siguiente ejemplo. Para que la comunicaci6n tenga lugar sobre
Capitulo 3 SSL o TLS, necesitamos dos cosas: claves y certificados. Para mis informaci6n sobre estos dos elementos, consulte 10s vinculos a la documentaci6n SSL y TLS. Antes de seguir adelante, generamos4as claves y certificados utilizando la utilidad JDK k e y t o o l . ~ s t es a una herramienta de gesti6n de certificados utilizada para gestionar pares de claves pfiblicas/privadas y certificados asociados que deben ser utilizados en auto-autentificacih y en servicios de integridad y autentificacidn de datos, utilizando firmas digitales. En un entorno comercial, probablemente utilizaria k e y t o o l para generar una solicitud de certificado y utilizaria esa solicitud para obtener un certificado de una Autoridad de Certificados (CA) como Verisign (http://www.verisign.com). Para nuestros prop6sitos, generaremos un certificado autofirmado (un certificado de la CA autentificando su propia clave pliblica). En otras palabras, utilizaremos nuestras propias claves y certificados utilizando la opci6n - g e n k e y en k e y t o o l . Ejecute la utilidad k e y t o o l con parimetros similares a istos:
Podemos coniprobar el certificado utilizando k e y t o o l de un mddo distinto:
Esto genera un almacin de claves llamado " w r o x " que contiene las claves y el certificado auto-firmado y contiene la contraseiia "secreta".
Consulte la documentacidn adjunta a J D K para m i s detalles sobre c6mo utilizar kqytool, las claves y 10s certificados en la arquitectura de seguridad de Java 2. Finalmente, tambiCn exportamos el certificado generado a un archivo c l i e n t i m p o r t . cer para el uso de clientes que u t i l i c e n k e y t o o l : L : e y ~ c ~ , =-~elx ~ ' r . i t -t:eystore %BOOK_HOME%\Ch03\SSL.\. k e y s t o r e s e c r e t - f i l e c l l e n t i m p o r t . c e r -alias w r o x
-store$ass
Recuerde que n o estamos utilizando SSL basado en navegador en ningkn fragment0 de estos ejemplos. Si desea utilizarlo, necesitard generar certificados con el algoritmo RSA (utilice la opcidn -keya lg en keyt 001).Para esto, necesitard instalar un proveedor que ofrezca la implementacidn del algoritmo RSA puesto que J D K 1.2 n o se ajusta a esta implementacidn. Para nuestros propdsitos, el proveedor JSSE contiene una implementacidn y el apoyo RSA estd incorporado en J D K 1.3. Tambibn, la implementaci6n J C E de libre distribuci6n disponible en http://www.openjce.orges un buen proweedor de API de seguridad. Volvamos ahora a1 ejemplo H e l l o w o r l d que utilizamos anteriormente y rescribimoslo, para asegurar la comunicaci6n de objeto a objeto. D e nuevo, la interfaz remota se mantiene igual:
Procesamiento distribuido con RMI import java.rmi.Remote; import java.rmi.RemoteException; public interface HelloInterface extends Remote { public String sayHello ( ) throws RernoteException;
Ahora rescribimos la implementaci6n remota de esta interfaz: import j ava. rmi . * ; import java.rmi.server.UnicastRemoteObject; import java.uti1. Date; public
class HelloServer extends UnicastRemoteObj ect implements HelloIrjterface { public H e l l o S e r v e r O throws RemoteException { super ( 0 , n e w MyClientSocketFactory ( ) , n e w MyServerSocketFactory
( ) ) ;
I public String sayHello() { return "Hello World, the current system time is
"
t new Date();
I 1
Observe que la h i c a diferencia es que pasamos nuestras propias factorias de adaptaci6n que serin utilizadas para este objeto en lugar de las factorias por defecto. Ahora utilizamos el mismo programa que utilizamos antes para registrar este objeto remoto: import j ava. rmi. + ; public class RegisterIt
{
public static void main(String a r g s [ ] ) [ try 1 / / Ir~stanciar el objeto HelloServer obj = n e w HelloServer ( ) ; System. o u t .println ("Object instantiated" tobj ) ; Naming. rebind ("/HelloServer", obj ) ; System. o u t .println ("HelloServer bound i n registry" ) } catch (Exception e) { System.out.println(e);
;
1
I I
Estas sentencias que hemos pasado tan ficilmente son las factorias de sockets. Examin6moslas ahora en detalle. La c l a s e ~ ~ ~ e r v e r ~ o c k e t y~ es a cutilizadapara tor crear instancias del socket de servidor en el puerto a1 que fue exportado el objeto. Esta clase debe implementar la interfaz j a v a . rmi .server. ~ ~ ~ ~ e r v e r ~ o c k e t ~ a debeserserializable ctoryy (parafacilitarposibles transportes en la red). El intercambio seguro entre el cliente y el servidor conlleva un intercambio de claves y certificados y el socket creado debe primer0 inicializar la comunicacidn con el cliente antes de intercambiar ningGn dato. La implementaci6n JSEE nos permite realizar esto en unas cuantas lineas de c6digo. Abrimos el almacin de claves (que hemos generado) del archivo utilizando su contraseiia, inicializamos la implementaci6n SSLITLS y devolvemos una instancia de un socket seguro: import import import import import
j a v a .i o . + ; j ava. net. + ; j a v a . rmi. server. + ; java.security.+; javax.net. s s l . + ;
Capitulo 3 import javax.security.cert.*; import com.sun.net . s s l . + ; publlc class MyServerSocketFactory
implements RMIServerSocketFactory, Serializable { / / Implementar el metodo d e interfaz publlc Serversocket createServerSocket(int port)throws IOException { SSLServerSocketFactory s s f = null; try i / / Configurar el gestor de seguridad para la autentlficacibn de servldor char [ I passphrase = "secret". toCharArray ( ) ; //
Obtener un contexto para el protocolo. Podemos utilizar SSL o TLS seg6n sea necesario SSLContest ctx = SSLContext. getIr~stance( " T L S " ); KeyManagerFactory k m f = K e y M a n a g e r F a c t o r y . g e t I n s t a r ~ c e( " S u n X 5 0 9 " ); / / Abrir el almacen d e claves con la contraseAa / / e inicializar el contexto SSL con este alrnackn d e claves KeyStore k s = KeyStore.getInstance ( " J K S " ); ks. load ( n e w FileInputStrearn keystore"), passphrase) ; kmf.init(ks, p a s s p h r a s e ) ; ctx. init (krnf.getKeyMar1agers ( ) , null, null); s s f = ctx.getServerSocketFactory ( ) ; catch (Exception e ) { e.printStackTrace0; ( ' I .
}
I r e t u r n ssf.createServerSocket(port);
1
La factoria de socket de cliente es utilizada para crear instancias de 10s sockets de cliente que conectan alas instancias de 10s sockets de servidor generados en la factoria anterior. Se supone que el proveedor JSSE tarnbikn esti instalado en la rniquina cliente: import import import import
Socket createsocket (String host, int port) throws IOException
{
/ / Obtenemos la factoria d e socket SSL por defecto. SSLSocketFactory factory = (SSLSocketFactory)SSLSocketFactory.getDefault(); SSLSocket socket = lSSLSocket)factory.createSocket.(host, port); return socket;
El cliente se rnatiene igual: import java.rmi.Narning; import ]ava.rmi.RemoteExceptian; public class Helloclient
{
public static void main(String a r g s [ ] ) { if (args.length < 1 ) {
Procesamiento distribuido con RMI System.uut .println ( " U s a g e : j a v a System.exit{l);
Helloclient
" ) ;
1 try{ HellaIntetfacr
1
nb]
= ! H e l l o I r ~ t e r f a c e ) E l a m i n gl .u o k u p (
"rmi://" t args[O] + "/HelloServer"); S y z t e m . o i ~ t . p r i n t l n["Got a r e m o t e r e f e r e n c e " + obj ) ; S y s t e r n . o u t . p r l n t l r ~ i o b j. s a y H e l l o ( ) ) ; catch (Exception e ) 4 System.out.println(e);
I
El archivo ssl .policy que utilizarnos aqui es en realidad el misrno que utilizarnos en 10s ejemplos an teriores: grant [ permission
I
java. secutity.Al1Permission;
;
Ahora podemos cornpilar las clases y generar 10s stubs para Helloserver utilizando el rmic ernpaquetado con el JDK.
Es preciso exarninar dos pequeiios detalles antes de ejecutar el ejernplo. Para que el cliente interactue e intercarnbien contraseiias y certificados con el servidor, debe confiar en el proveedor del certificado digital. En otras palabras, conio nuestro certificado es auto-generado, la mdquina virtual cliente debe: Importar explicitarnente el certificado en el almacen de claves que esti utilizando y rnarcarlo corno certificado confiable Utilizar el rnisrno alrnackn de claves que utilizanios en el servidor Para la segunda opcibn, el proveedor JSEE debe ser instalado en la rndquina cliente (si es diferente del servidor) en uno de dos rnodos posibles: 0 Estiticarnente en el archivo j ava .security 0 Dinirnicamenteutilizando~ecurity. addprovider (new com.sun.net.ssl.internal.ss1.Provider 0 ) ;
Para detalles m b espec$cos sobre estos me'rodos de ins&alnci6n, el lector puede recwrrir a la docwmenmcicin JSSE.
El cliente puede iniportar el certificado desde el archivo que hernos generado anteriormente, clientimport. cer, al alniacCn de claves que esti utilizando y rnarcarlo corno confiable utilizando keyt ool con la sentencia -import:
Capitulo 3 Una vez realizado esto, primero necesitamos iniciar el registro en el servidor (ejecutar rmiregistry): r n i i r e < ~ i . s t r y- J - D j a v a . s e c u r i t y . ~ ~ r . l i c y = s s l . ~ " ~ L i c y
registrar entonces el objeto con el registro:
-
1;1.:a - c l a s s ~ a t h % C L A S S P A T H S - U j a v a . . s e c u r i t y . ~ c ~ l i c ~ ~ = . pc, '?~Lli c y E s ] a v a . r r n i . s ~ r v e r . c ~ ~ ~ e k a i l ~ = f i 1 r : / / r ( -l H BOOMOE +~/ 1 3 h O ? / S - C L / R?qi~trrIt
Recuerde instalar con cuidado JSEE. Ponga 10s archivos jar en su localizaci6n \lib\exte instale el proveedor en su archivo java. Security (viase el archivo INSTALL.txt dentro del lote JSEE para rnis detalles). Si tiene mliltiples entornos de period0 de ejecucion, aseglirese de editar el archivo de seguridad correcto. La solucion rnis sencilla es configurar el PATH para que s61o apunte el JDK que esti utilizando.
Ahora ejecute el cliente y especifique,el aln~acende claves a utilizar utilizando la propiedad JSSE j a v a x . net. ssl . truststore. Este es el~lmacknde claves en el que ha sido importado el certificado o el mismo almacen de datos como servidor.
Si queremos que el cliente sea un applet, necesitamos primer0 resolver algunos puntos de configuration: 3 El cliente debe tener una JVM J2SE 1.2 (o posterior). En el momento de publicaci6n de este libro, Netscape 6 y 6.1 son 10s Gnicos navegadores con soporte J2SE 1.2. Por lo tanto, probablemente
necesitemos instalarel mddulo complementario de Java. (Este mddulo es de descarga Gnica y actualiza automiticamente laJVM del navegador a la Gltima versi6n. Funciona tanto con IE como con Netscape.) U La JVM cliente debe tener el almacen de claves y 10s certificados adecuados instalados.
0 La JVM cliente deberia tener la politica correcta, permitiendo que 10s sockets sean abiertos de nuevo al servidor. 0 La JVM cliente deberia tener el proveedor de seguridad instalado o tener 10s permisos de seguridad adecuados de mod0 que pueda instalarse un proveedor de seguridad dinimicamente.
O Puede acceder a mls informaci6n y descargas para el modulo complementario de Java en http:// java.sun.com/products/pluginl.
Procesamiento distribuido con RMI Examinemos el siguiente applet. Es sencillo, similar a1 ejemplo que hemos visto antes, except0 que se trata de un applet. Es importante captar que el applet n o tiene nada que ver con la configuraci6n SSL del navegador. La conexi6n SSL tiene lugar a nivel del socket RMI. La clase de factoria de socket de cliente es descargada dinimicamente y se realiza la conexi6n segura a1 servidor: import import import import
public class SSLHelloApplet extends Applett String message
=
"-n/a-";
HelloInterface obj
=
null;
/ / Obtener una referencia a1 objeto durante el inicio del applet public void init ( ) [ try I Security. addprovider ( n e w com. sun. net. ssl. internal. ssl. Provider ( ) ) ; String host="rmi://" + getCodeBase().getHost() + "/Helloserver"; HelloInterface obj = (HelloInterface)Naming.lookup( "rmi://localhost/HelloServer"); message = obj . sayHello ( ) ; 1 catch (Exception e ) { System.out.println(e);
1 / / Mostrar un mensaje en el applet public void paint(Graphics g)[ g.drawString(message, 25, 5 0 );
1 1
A continuaci6n, la pigina HTML ( i n d e x . html) para el applet anterior. Esta pigina es convertida utilizando la herramienta conversora HTML empaquetada con el m6dulo complementario de Java. Cuando un cliente se encuentra con esta pigina, si no existe una versi6n compatible, el JRE 1.3 seri descargado del URL especificado. (La pigina Web de Sun en este caso):
