Panel Formación Arquitectura de sistemas J2EE: 2009

miércoles, 4 de marzo de 2009

Road Map

Día 1 del curso: Teoría

Día 2 del curso: Teórico Práctico

Día 3 del curso: Teórico Práctico

Día 4 del curso: Teórico Práctico

Construyendo una aplicación Java EE más compleja.
Integrando Tomcat y JBoss. (Escalabilidad)
Cuando las cosas no van bien "Problemas típicos".
Administrando múltiples aplicaciones en los servidores de aplicaciones.
Escalabilidad.
Tunnig.
Conclusiones del curso.

viernes, 13 de febrero de 2009

Construyendo una aplicación JEE más compleja

1. Desplegando Ears con acceso a BBDD: Aquí tenemos que configurar como siempre el acceso al DataSource. Es parecido a las aplicaciones WEB pero no idéntico. Aquí no hay estándares sólo leer documentación de JBoss. Tendremos que trabajar sobre los descriptores persistence.xml, jboss-app.xml y mysql-ds.xml.

lunes, 9 de febrero de 2009

Construyendo una aplicación Java EE sencilla

1. Gooles está discutiendo la implantación de un Bus midelware que no sabe si se decantará por un ORB o una arquitectura SOA pero mientras tiene claro que tiene que poner el servicio de agenda fuera del contenedor de servlets y ponerlo en servidor de aplicaciones para que se pueda acceder de forma remota por otro sistema.

2. Aplicaiones WEB: Atención a los descriptores para acceder a recursos JNDI: En nuestro ejemplo de TestDB.war se ha añadido un descriptor jboss-web.xml dentro del WEB-INF que es imprescindible ¿Estandar? No lo creo. Es la pelea constante de cada servidor de aplicaciones. Películas interesantes de JBoss

3. ¿Cómo es la arquitectura Java EE?:

4. Ventajas:

Arquitecturas más escalables
Arquitecturas abiertas

5. Desplegando el ear HelloWorld:

¿Cómo accedemos?
¿Qué librerías necesitamos?
Aplicación 3

Cuando las cosas no van bien "Problemas típicos".

1. La aplicación no funciona. ¿Qué hacemos?

Construyendo una aplicación web más compleja

1. Goole pide una nueva funcionalidad a la aplicación: listado de la agenda. Acme incorpora un framework para facilitar del desarrollo. Struts.

2. Código defectuoso del acceso a datos y de liberación de recursos, buen uso de JDBC.

¿Qué síntomas tenemos?
¿Siempre aparece?¿ampliamoslas conexiones del Pool?
¿Se resuelven los problemas?

3. Aquí el objetivo es dimensionar el servidor para una carga mayor de trabajo.

jueves, 5 de febrero de 2009

Cuando las cosas no van bien "Problemas típicos"

Los problemas encontrados hasta ahora son:

No se ha fijado correctamente el JAVA_HOME y el tomcat no arranca.
Se toca incorrectamente el fichero server.xml, y el tomcat no arranca.
Se tocan carpetas de una aplicación web, por ejemplo la de imágenes y esto hace que una de las aplicaciones no funcione correctamente.
Se toca incorrectamente el web.xml y causa que la aplicación correspondiente no funcione en absoluto.

Introducción a la administración del servidor JBoss

1. Instalando el JBoss 4.0.4-GA:

Para EJB 3.0

2. Repasando la estructura de directorios:

3. Configurando del DataSource para MySQL:

Enlaces de Interés:

miércoles, 4 de febrero de 2009

Construyendo una aplicación web más compleja

1. Gooles ya se ha decidido a migrar el 100% de la funcionalidad de la aplicación Agenda a arquitectura WEB 1.0

Incorporar la funcionalidad del listado.

2. Atención a las diferencias de los entornos:

Desarrollo: Pocos datos, poco significativos.
Integración: Un poco mayores
Porducción: ¿cuantos?

Construyendo una aplicación web sencilla

0. Sistemas de Gooles instala una aplicación tipo HelloWorld con acceso a la BBDD MySQL.

1. Gooles está contento con los desarrllos de ACME y está preparado para incorporar aplicaciones Web 1.0:

Tiene servidores Tomcat operativos
Tiene entornos de pruebas operativos
Tiene entorno de producción operativos.

2. Encarga a ACME que la aplicación Agenda, de momento Login>Alta, se pueda acceder por la WEB por que están migrando la arquitectura de Cliente Servidor a WEB.

Arquitecturas JSP Model 1
Arquitecturas JSP Model 2

3. Aplicaciones WEB:

Repaso a los ficheros de configuración
¿Que vamos a utilizar?

Introducción a la administración del servidor Tomcat

1. Arquitecturas involucradas, estamos ya con un servidor:

2. Instalando el Tomcat:

¿De donde saco la información? > Tomcat 5.x
¿Qué versión estoy instalando? > apache-tomcat-5.5.25
¿Qué JDK necesito? > leyendo la documentactión (por ejemplo en %CATALINA_HOME%/RUNNING.txt) podemos leer que necesita JRE 1.5 o superior.
¿Variables de entorno? > %CATALINA_HOME% para evitar problemas cuando se lanzan con tareas programadas donde los paths relativos muchas veces no funcionan. O por ejemplo el arranque y parada del tomcat desde cualquier directorio.
¿Que versión de APIs soporta? > Servlet 2.4 and JavaServer Pages 2.0.

3. Configuración:

%CATALINA_HOME%/bin/catalina.bat: Fichero de arranque donde se pueden definir variables de entorno importantes para cambiar la configuración del Tomcat, como puede ser el JAVA_HOME el CATALINA_HOME
%CATALINA_HOME%/common: Directorio donde se dejan los jars que se quieren compartir con todas las aplicaciones web.
%CATALINA_HOME%/conf/server.xml: Fichero de configuración donde se configuran cosas muy importantes como, los puertos donde escuchan los conectores HTTP, HTTPS el número de threads con los que puede trabajar el tomcat y también para configurar los pooles de conexión a la BBDD y otros objetos que se deseen acceder por JNDI.
%CATALINA_HOME%/logs: Donde se escriben por defecto los logs del servidor tomcat. Es conveniente que todas las aplicaciones escribiesen los logs en este directorio, para tenerlos centralizados y poder facilitar el backup de estos.
%CATALINA_HOME%/server/: Es el propio tomcat como aplicación web y todos los binarios (jars) que componen el propio servidor.
%CATALINA_HOME%/webapp/: Donde se instalan las aplicaciones web.
web.xml: Fichero de configuración de la aplicacion.

4. Arranque y parada:

%CATALINA_HOME%/bin/catalina.bat run
%CATALINA_HOME%/bin/catalina.bat stop
Otras opciones es ejecutar directamente %CATALINA_HOME%/bin/startup.bat (Esta forma tiene la pega de que cuando no arranca el tomcat no sabes porqué, ya que la consola se cierra). Para apagar %CATALINA_HOME%/bin/shutdown.bat

5. Configurando del Pool de conexiones de una aplcación web:

Empezando por la documentación oficial

6.Seguridad: Atención al equipo de producción que aquí las cosas son muy serias

¿Ejemplos desactivados?
Acceso a la consola de administración: Hay que dar de alta al usuario en el el fichero tomcat-users.xml de %CATALINA_HOME%/conf tal como se explica en la documentación.
Lo mejor eliminar todo

martes, 3 de febrero de 2009

Construyendo una aplicación Java sencilla

1. Preparando en entorno básico:

Instalando el JDK: j2sdk-1_4_2_08-windows-i586-p
Fijando las variables de entorno: JAVA_HOME y Path
Comprobando que todo ok: java -version

2. Programando nuestro primer programa un helloworld: Ejemplo 1.

Editor de Texto:
Codificar una clase que admita como parámetro de entrada una cadena (nuestro nombre) y saque por consaola "Hola" "bienvenido al curso de Arquitecturas Java EE". La nomenglatura de paquetes es org.munimadrid.cursos.jee.ejemplo1.*
Compilando generamos el .class: java -c
Empaquetamos la aplicación: Generamos el jar.
Desplegamos: ¿Cómo? pues como nos digan el departamento de sistemas del cliente por ejemplo:
```
- Aplicaciones/
|
|- aplicacion_1/
|
|- bin
|- lib
|- logs
```

Ejecutando el programa: Classpath y comandos de arranque java -cp...
¿Se puedefacilitar el lanzamiento del programa? SI, creando un script. Por ejemplo run.bat.

3. Mejorando la aplicación para que pueda estar en producción:

Como hemos dicho el departamento de sistemas tiene definido que todos los logs se escriban en fichero en el directorio logs.
Añadiendo la librería Log4J.
Volvemos a realizar todos los pasos anteriores para compilar empaquetar y ejecutar.

4. Ya somos todos programadores Java:

¿Las cosas pueden ir mal con estos pequeños programas?
ClassNotFound Exception, problemas de memoria.

5. Nos preparamos para montar una empresa de software y dar servicio a Gooles Company:

Montar los entornos de Integración y Pruebas
Montar el entrono de producción.
¿Como nos organizamos?

6. Instalamos la BBDD MySQL que es la BBDD con la que trabaja Gooles:

Un esquema para desarrollo
Otro para pruebas e integración
Otro para producción
Nos instalamos el cliente de acceso a la BBDD.

8. Nos encargan una aplicación Agenda con arquitectura tipo cliente servidor que es la arquitectura que utilizan en la empresa.

Login
Alta de Usuario
Listado

9. ¿Que librerías necesitamos utilizar?

Log4j
JDBC
Drivers

10. Manos a la obra.

Preparándose para SOA

Arquitecturas para SOA: SCA

Arquitecturas para SOA

Conclusiones en las arquitecturas Java EE: 3

Arquitecturas III

Futuras Arquitecturas

Conclusiones en las arquitecturas Java EE: 2

Arquitecturas II

Arquitecturas III

lunes, 2 de febrero de 2009

Servicios y API de Java EE 1.5

Servicios que debe implementar todo servidor de aplicaciones Java EE:

HTTP: Protocolo HTTP
HTTPS: HTTP + SSL
Java™ Transaction API (JTA): Api para transacciones
RMI-IIOP: Protocolo de comunicaciones compatible con CORBA
Java IDL: Acceso a servicios CORBA
JDBC™ API: Acceso a Bases de Datos.
Java™ Persistence API: API de persistencia con el modelo ORM (Object Relational Mapping)
Java™ Message Service (JMS): API para comunicaciones asíncronas.
Java Naming and Directory Interface™ (JNDI): Servicio de Directorio
JavaMail™: API de envío de mails, SMTP,POP3 ...
JavaBeans™ Activation Framework (JAF): Mime-types
XML Processing: SAX, DOM, StAX, APIs para manejo de XML.
Java EE™ Connector Architecture: Arquitectura de connectores
Java™ Authentication and Authorization Service (JAAS): Seguridad y Autenticación
Java™ Authorization Service Provider Contract for Containers (JACC)
Web Services: JAX-RPC para SOAP y JAX-WS para WebService
The Java™ Management Extensions (JMX): Gestión de Componentes
Enterprise Edition Deployment Specification: Wars, Ears

¿No hay nada de SOA Service-Oriented Architecture? NO

¿Y todo termina aquí? NO

La JVM: Conceptos Generales

1. Arquitectura general (Java Specification Request JSR 924)

2. ¿Cómo funciona la carga de las classes para ejecutarse?

Proceso de carga "Loading": En este proceso se valida que se el formato de los ficheros (bytescodes) es válido. El proceso se hace por los Classloaders que tiene la JVM, siguen una arquitectura gerárquica, donde el control lo tiene siempre el Boostrap ClassLoader que es el nativo de la JVM y seguidamente el resto de ClassLoader de la aplicación. Antes de cargar una clase estos classloader siempre llaman al ClassLoader padre para ver si lo tiene y esa es la forma de protegerse por ejemplo contra código malicioso o clases "falsas" del API de Java.
Proceso de "lincado" "Linking": Verificación y Seguridad. Se verifica que el código no pueda hacer accesos no deseados a resursos del sistema ni ejecutar código malicioso. En el caso de los appletes la seguridad es mucho más restrictiva y está "supervisada" el sandbox.
Procesos de inicialización "Initializing": Se inicializan los objetos para su ejecución.

3. Area de Datos: Runtime Data Areas:

Hilos de ejecución "pc Program Counter":Cada método de una clase se ejecuta por un único thread de la JVM. Muy importante tener esto presente en la programación Java junto con la siguiente característica. De serie sólo los métodos son thread safe y si están bien programados.
Pila de la JVM "Java Virtual Machine Stacks": Cada hilo tiene supila y se gestiona dinámicamente accediendo a recursos del Heap de memoria de la JVM.
Heap de memoria: Es toda la memoria que se comparte con todos los threads de la JVM. Se deja libertad al que implementa la JVM a implementar la gestión automática de la emoria. Típicamente hay un "garbage colletor" recolector de basura con sus algoritmos de actuación. También se deja libertad para inicializar y configurar la gestión de memoria por parte de la máquina virtual. Aquí es donde entra en juego las diferentes opciones comerciales a la hora de adquirir una JVM.

3. Cuando las cosas van mal Excepciones típicas:

UnsupportedClassVersionError, NoClassDefFoundError en proceso de carga de clases.
StackOverflowError, OutOfMemoryError en consumo de los recursos de memoria de la JVM

4. ¿Cómo se parametrizan las JVM?

Esto no está en las especificaciones JSR y por tanto cada fabricante tiene las suyas.
Nosotros durante el curso utilizaremos la JVM de SUN.
¿Cuales son los parámetros?

5. Enlaces de interes

JVM
http://en.wikipedia.org/wiki/Java_Virtual_Machine
http://www.jcp.org/en/jsr/detail?id=924
http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html
http://blogs.sun.com/watt/resource/jvm-options-list.html

Classpath
http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/classpath.html

ClassLoader
http://java.sun.com/developer/technicalArticles/Networking/classloaders/

Frameworks: Más allá de SUN y JSR

Veamos
unos cuantos ejemplos

Integración y despliegue:

Pruebas:

Vista Controlador (WEB):

Persistencia:

Interfaz de Usuario

Graficos:

Utilidades:

y muchos mas.....

domingo, 1 de febrero de 2009

Conclusiones en las arquitecturas Java EE

Desde mi experiencia hay tres posibilidades y cada una con sus riesgos:

Arquitectura I

Arquitectura II

Conceptos básicos de servidores de aplicaciones en Java EE

1. Contenedores WEB o servidores WEB: Son los encargados de interceptar las peticiones HTTP/HTTPs y servir los contenidos, normalmente estáticos como son, imágenes, multimedia, HTML, XHTML, js, WML,chmtl etc...No están sujetos a ninguna especificación salvo implementar como mínimo el protocolo HTTP y MIME-types, pero lo normal es que ofrezcan algún tipo de scripting, cgi o plugin para ejecutar programas para generar contenido dinámico, como puede ser el mod_perl de apache.

Historia: El primer servidor web se desarrolló en el CERN por Tim Berners-Lee en 1989, el inventor del system de hypertexto y fundador del 3WC.

Ejemplos:

- Apache
- IIS
- Google Web Server

2. Contenedores de Servlet: Son servidores que cumplen como mínimo con las especificaciones de Servlets, JSP y aplicaciones WEB fijadas por el JCP. Esto va a condicionar que tipo de API está disponible para el equipo de desarrollo y la forma de empaquetar y desplegar las aplicaciones web. Casi sin excepción implementan completamente el protocolo HTTP/HTTPS y en muchas ocasiones se utiliza directamente como servidor web y en la literatura se les puede nombra como "web container".

Historia: El API de Servlets comenzó en 1997 versión 1.0 y actualmente estamos en la 2.5 apunto de salir la 3.0.

Ejemplos:

- Tomcat
- Jetty

3. Servidores de aplicaciones Java EE y contenedores de EJB: Son servidores que cumplen las especificaciones Java EE, publicadas en el JCP. Aquí la competencia es enorme y hay multitud de opciones.

Historia: Las primeras especificaciones salieron en el 1999 J2EE 1.2. Actualmente estamos con la Java EE 5 y está prevista la finalización de las especificaciones de la Java EE 6 en mayo 2009

Ejemplos:

- JBoss: Red Hat
- Geronimo: Apache Software Fundation
- JOnAS: ObjectWeb
- GlassFish: SUN
- WebLogic: Oracle
- Websphere: IBM
- JRUN: Adobe
.........

Conceptos básicos de arquitectura Java EE

Servicios y APIs de Java EE:

Conceptos básicos de Arquitectura Java

La arquitectura de Java Standar Edition

Conceptos Básicos de Java

Enlaces de interés

JVM (detalles)

Conceptos básicos arquitectura y patrones de diseño

Enlaces de Interés:

Alcance y objetivos

Objetivos

Entender los perfiles que intervienen en todo el proceso de implantación de aplicaciones Java EE en los servidores de aplicaciones del entorno de producción y como la arquitectura Java EE permite delimitar las responsabilidades de cada uno de ellos en las distintas fases y durante la ejecución de los aplicativos.
En definitiva entender las capas que hay en la arquitectura y quien es responsable de que cada una de ellas funcione correctamente y así poder detectar los problemas lo antes posible.
Supondremos que disponemos de una empresa de software para concentrarnos no en el desarrollo de aplicaciones Java que es tema de otro curso, de desarrollo de aplicaciones Java EE, si no en su gestión desde que el equipo de desarrollo realiza la entrega de la aplicación "supuestamente" finalizada.
Aquí empieza el curso. Así que va de ese viaje la mayoría de las veces largo y complejo que emprende la aplicación cuando el desarrollador dice "en mi máquina funciona".
A lo largo de la semana veremos cuantos imprevistos pueden surgir en ese viaje.

Dinámica

Vamos a simular todo el proceso de implantación de aplicativos Java EE desde su construcción hasta su implantación en los servidores de producción. Yo como formador haré del rol de la empresa "ACME Desarrollo" que desarrolla software.
Una serie de alumnos harán de empresa "ACME Pruebas" , que pasarán las pruebas funcionales, en el entorno de pruebas y sus servidores.
Una serie de alumnos harán de soporte de producción de la empresa Gooles y darán el soporte correspondiente.
Durante los tres días de prácticas iremos creado software con una funcionalidad muy fácil pero con más exigencias en cuanto su escalabilidad, empezaremos con aplicaciones de Cliente Servidor y terminaremos con aplicaciones Java EE con arquitecturas multicapa. Como es normal ACME Desarrollo no siempre hace bien su software y veremos como se detectan los fallos.
A lo largo de estas instalaciones y pruebas simularemos las incidencias más habituales, como se detectan y los planes de contingencia posibles.

¿Qué material vamos a utilizar?

Contenidos formativos y comunicación: e-learnig http://panel-formacion-jboss.blogspot.com/
Desarrollo: Eclipse
Servidor: Tomcat
Servidor: JBoss
BBDD: MySQL,Oracle
Conectividad: FTP

¿Qué conocimientos tenéis de Java EE?
¿Qué esperáis del curso de Arquitecturas J2EE?

"Roadmap" del curso

Día 1 del curso: Teoría

Día 2 del curso: Teórico Práctico

Día 3 del curso: Teórico Práctico

Día 4 del curso: Teórico Práctico

Construyendo una aplicación Java EE más compleja.
Integrando Tomcat y JBoss. (Escalabilidad)
Cuando las cosas no van bien "Problemas típicos".
Administrando múltiples aplicaciones en los servidores de aplicaciones.
Escalabilidad.
Tunnig.
Conclusiones del curso.

Indice de contenidos teóricos del curso

1. Conceptos básicos Arquitectura y patrones de diseño:

Arquitecturas cliente-servidor
Arquitecturas multicapa de Java EE y patrones generales

2. Conceptos básicos de Arquitectura Java:

JDK
JVM
Classpath
ClassLoader
Configuarción de JVM

3. Conceptos básicos de arquitectura Java EE:

¿Qué APIs componen la arquitectura Java EE?
Repaso a los APIs más utilizados en las aplicaciones Java EE
Frameworks estandar

4. Conceptos básicos de servidores de aplicaciones en Java EE

Contenedores
Apache, Tomcat y Jboss

5. Introducción a la administración de Tomcat

Conceptos básicos
Instalación
Configuración
Gestión y creación de diferentes instancias.
Despliegue de aplicaciones web.
Dependencias entre las distintas aplicaciones desplegadas.
Gestión de memoria
Logs
Pool de conexiones

6. Introducción a la administración de JBoss

Conceptos básicos
Instalación
Configuración
Gestión y creación de diferentes instancias
Despliegue de aplicaciones Java EE
Dependencias entre las distintas aplicaciones desplegadas.
Gestión de memoria
Logs
Pool de conexiones
JMS

7. Cuando las cosas van mal los Servidores de aplicaciones.

Delimitando responsabilidades entre el servidor de aplicaciones y las aplicaciones.
Consumo excesivo de memoria
Consumiendo recursos de la BBDD
Problemas de deadlock.

miércoles, 4 de marzo de 2009

viernes, 13 de febrero de 2009

lunes, 9 de febrero de 2009

jueves, 5 de febrero de 2009

miércoles, 4 de febrero de 2009

martes, 3 de febrero de 2009

lunes, 2 de febrero de 2009

domingo, 1 de febrero de 2009

miércoles, 28 de enero de 2009

Bibliografía de Interés

Formadores

Contenido del curso

Enlaces de Interés

Archivo del blog