04/02 Visto en Clase

Servlet-->
JSP--> Java Server Pages
MVC--> Modelo Vista Controlador

El Controlador recibe la peticion del html, la cual se recoge mediante un metodo y devuleve una Vista (.jsp) q contacta con el Modelo(en el cual hemos metido información dinámica)
La vista es un .jsp. Desde el jsp la forma de hablar con el modelo es a traves del signo ${ }

05/02

Si la aplicacion no funciona y no sabemos q pasa:
- Paramos el Tomcat
- ANT --> clean (borra todo codigo compilado)
- ANT --> Undeploy (borra la aplicacion del servidor)
- ANT --> deploywar (desplegamos la aplicacion)
- Arracamos el Tomcat

Desarrollo: Respuesta a una solicitud web
1. Nuevo metodo en controlador y anotación indicando la solicitud web y devolviendo el nombre del jsp.
2. Creamos el jsp correspondiente.
3. Incluimos en el modelo la información dinámica y accedemos desde el jsp a través ${clave}.

Instalación de Maven
- Descomprimimos la carpeta maven en C
- Modificar la variable de enotrno path, sin borrar su ruta, añadiendole la ruta de nuestro jdk y maven al final, con un ; y \bin detras de cada una q añadimos.
ej: %path%;C:\Archivos de programa\Java\jdk1.6.0_03\bin;C:\Archivos de programa\Java\jdk1.6.0_03\bin;C:\apache-maven-2.0.8\bin
- Creamos 2 variables de entorno nuevas con las siguientes rutas:
JAVA_HOME: C:\Archivos de programa\Java\jdk1.6.0_03
M2_HOME: C:\apache-maven-2.0.8
- Abrimos la consola y ejecutamos lo siguiente: mvn --version
- Seguidamente abrimos el archivo de configuración de esta aplicación para echarle un vistazo, la ruta del archivo es la siguiente: C:\apache-maven-2.0.8\conf y se llama settings.xml
En este archivo nos pone donde van a descargarse todas las librerias : Default: ~/.m2/repository

Pasos a seguir con MAven y APPFuse:
1. cd workspace
2. mvn archetype:create -DarchetypeGroupId=org.appfuse.archetypes -DarchetypeArtifactId=appfuse-basic-spring -DremoteRepositories=http://172.16.1.51/repository-DarchetypeVersion=2.0.1 -DgroupId=com.mycompany.app -DartifactId=myproject2
3. mvn eclipse:eclipse
4. mvn -Declipse.workspace=C:\tamara\j2ee eclipse:add-maven-repo
5. mvn install

MySql

MySQL es un sistema de gestión de base de datos relacional, multihilo y multiusuario con más de seis millones de instalaciones.^[1] MySQL AB desarrolla MySQL como software libre en un esquema de licenciamiento dual. MySQL AB pertenece a Sun Microsystems desde enero de 2008.

Polimorfismo

En Java, el polimorfismo de métodos se implementa con la sobrecarga de métodos: métodos con el mismo nombre, y mismo número y tipo de argumentos.

Una variable también puede ser polimórfica, es decir, cambiar de forma o de clase de objeto al que referencia durante la ejecución de un programa. El polimorfismo de una variable en Java está limitado de tal forma que una variable que referencia a un objeto sólo puede especializarse, tal y como ocurre en la vida real.

Ejemplo con polimorfismo en el método canta y en la variable fulanito

class Persona{

private String nombre;

protected String cancion;

public void canta(){System.out.println("la la la");}

} //End Persona

class Ladron extends Persona{

private int ganancias;

public void canta(){System.out.println("Yo no he sido");}

public void roba(int n){ ganancias= ganancias + n; }

} //End Ladron

class Juez extends Persona {

public void canta() {System.out.println("Soy la ley");}

} //End Juez

public class Poli5 {

// ejemplo de polimorfismo de mensaje canta

public static void main(String args[])

{

Persona fulanito = new Persona();

Ladron ladroncito = new Ladron();

Juez juececito = new Juez();

fulanito.canta(); // canta una persona

fulanito = ladroncito;

fulanito.canta(); // canta un ladrón

fulanito.roba(100);

//error de compilación: fulanito es Persona. ¿Solución?

fulanito = juececito;

fulanito.canta (); // canta un juez

}

} // End Poli5

Restricción en Java al polimorfismo sintáctico: cambio a subclases o especialización.

Verificación estática de tipos: tiempo de compilación.

Casos de uso

Los diagramas de UML se pueden dividir en estáticos (aportan una visión estática del sistema) y dinámicos (aportan una visión dinánica del sistema).

Los diagramas estáticos:

· Diagrama de casos de uso

· Diagrama de clases

· Diagrama de objetos

· Diagrama de componentes

· Diagrama de despliegue

Los diagramas dinámicos:

· Diagrama de estados

· Diagrama de actividad

· Diagramas de interacción:

o Diagrama de secuencia

o Diagrama de colaboración

Diagramas de casos de uso.

Los diagramas de casos de uso muestran la funcionalidad del sistema desde la perspectiva que tienen los usuarios y lo que el sistema debe de hacer para satisfacer los requisitos propuestos. Pueden mostrar el comportamiento de un sistema completo o de una parte.

Los elementos básicos que se utilizan son:

1. Actores: Son los diferentes usuarios y el papel que representan dentro del sistema.

2. Caso de uso: Representan todo lo que el usuario puede realizar dentro del sistema

3. Relaciones: Para asociar los elementos anteriores.

Comunicación

Generalización

Extensión (*)

Inclusión (*)

(*) En estas dos se deben de poner también las letras (include, o exclude).

Ejemplo:

Contenedor EJB

Con la tecnología J2EE Enterprise JavaBeans es posible desarrollar componentes (enterprise beans) que luego puedes reutilizar y ensamblar en distintas aplicaciones que tengas que hacer para la empresa.
El desarrollo basado en componentes promete un paso más en el camino de la programación orientada a objetos. Con la programación orientada a objetos puedes reutilizar clases, pero con componentes es posible reutilizar n mayor nivel de funcionalidades e incluso es posible modificar estas funcionalidades y adaptarlas a cada entorno de trabajo particular sin tocar el código del componente desarrollado.
En este momento podemos ver un componente como un objeto tradicional con un conjunto de servicios adicionales soportados en tiempo de ejecución por el contenedor de componentes. El contenedor de componentes se denomina contenedor EJB y es algo así como el sistema operativo en el que éstos residen. Recuerda que en Java existe un modelo de programación de objetos remotos denominado RMI. Con RMI es posible enviar peticiones a objetos que están ejecutándose en otra máquina virtual Java. Podemos ver un componente EJB como un objeto remoto RMI que reside en un contenedor EJB que le proporciona un conjunto de servicios adicionales.

Servicios proporcionados por el contenedor EJB

• Manejo de transacciones: apertura y cierre de transacciones asociadas a las llamadas a los métodos del bean.
• Seguridad: comprobación de permisos de acceso a los métodos del bean.
• Concurrencia: llamada simultánea a un mismo bean desde múltiples clientes.
• Servicios de red: comunicación entre el cliente y el bean en máquinas distintas.
• Gestión de recursos: gestión automática de múltiples recursos, como colas de mensajes, bases de datos o fuentes de datos en aplicaciones heredadas que no han sido traducidas a nuevos lenguajes/entornos y siguen usándose en la empresa.
• Persistencia: sincronización entre los datos del bean y tablas de una base de datos.
• Gestión de mensajes: manejo de Java Message Service (JMS).
• Escalabilidad: posibilidad de constituir clusters de servidores de aplicaciones con múltiples hosts para poder dar respuesta a aumentos repentinos de carga de la aplicación con sólo añadir hosts adicionales.
• Adaptación en tiempo de despliegue: posibilidad de modificación de todas estas características en el momento del despliegue del bean.

Funcionamiento de los componentes EJB

El funcionamiento de los componentes EJB se basa fundamentalmente en el trabajo del contenedor EJB. El contenedor EJB es un programa Java que corre en el servidor y que contiene todas las clases y objetos necesarios para el correcto funcionamiento de los enterprise beans.

En la figura siguiente puedes ver una representación de muy alto nivel del funcionamiento básico de los enterprise beans. En primer lugar, puedes ver que el cliente que realiza peticiones al bean y el servidor que contiene el bean están ejecutándose en máquinas virtuales Java distintas. Incluso pueden estar en distintos hosts. Otra cosa a resaltar es que el cliente nunca se comunica directamente con el enterprise bean, sino que el contenedor EJB proporciona un EJBObject que hace de interfaz. Cualquier petición del cliente (una llamada a un método de negocio del enterprise bean) se debe hacer a través del objeto EJB, el cual solicita al contenedor EJB una serie de servicios y se comunica con el enterprise bean. Por último, el bean realiza las peticiones correspondientes a la base de datos.

El contenedor EJB se preocupa de cuestiones como:

• ¿Tiene el cliente permiso para llamar al método?
• Hay que abrir la transacción al comienzo de la llamada y cerrarla al terminar.
• ¿Es necesario refrescar el bean con los datos de la base de datos?

representación de alto nivel del funcionamiento de los enterprise beans.

Anotaciones

En programación, una Anotación Java es una forma de añadir metadatos al código fuente Java que están disponibles para la aplicación en tiempo de ejecución. Muchas veces se usa como una alternativa a la tecnología XML.

Las Anotaciones Java pueden añadirse a los elementos de programa tales como clases, métodos, campos, parámetros, variables locales, y paquetes. Al contrario que las etiquetas añadidas a la documentación Java y procesadas con las herramientas tales como XDoclet, las Anotaciones Java son completamente accesibles al programador mientras que el software se ejecuta usando reflexión.

Las Anotaciones toman la forma de una declaración de interfaz con un caracter @ precediéndola, y marcada opcionalmente con meta-anotaciones, como se ve debajo:

 @Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD})

Las Anotaciones permiten al programador declarar en su código fuente
cómo debe comportarse el software. Esto es un ejemplo de cómo las
construcciones de la Programación declarativa pueden añadirse al lenguaje procedimental.

EJBs en JBoss

EJBs en JBoss

La arquitectura de EJBs en JBoss está basada en la funcionalidad que provee la clase Proxy del paquete java.lang.reflect (esta clase apareció en la versión 1.3)

La clase Proxy es una clase especial que nos permite interceptar un conjunto de métodos definidos en un interfaz.

Para una breve explicación ver: http://www.javalobby.org/java/forums/t18631.html

Cuando nosotros en JBoss, hacemos un lookUp del Interfaz Home o del Interfaz Remoto de un EJB, lo que obtenemos en realidad es una clase de tipo Proxy que encapsula la funcionalidad de ambos interfaces. La imágen que se muestra a continuación explica un poco toda esta arquitectura (esta imágen está obtenida de la documentación de JBoss)

Toda esta arquitectura nos ahorra el problema de tener que compilar los EJBs para crear los stubs y los skeletons.

Todas las invocaciones a los métodos de la clase Proxy son delegadas sobre el ClientContainer, que está compuesto por una cadena de Interceptores (clases que extienden la clase org.jboss.proxy.Interceptor que serán los manejadores reales de la funcionalidad). Nosotros podemos añadir o quitar funcionalidad modificando la cadena de interceptores.

El único que no podemos eliminar es el último interceptor, que será el que gestiones la comunicación con el servidor. Este último interceptor podrá ser RMI, RMI en cluster, HTTP, HTTP en cluster, CORBA etc... . En el lado servidor, existirá un componente (detached invoker) que hablará con el cliente (último invoker de la cadena) y nos pondrá en contacto con el contenedor de EJBs a través del servidor JMX de MBeans: (la imágen también está obtenida de la documentación de JBoss)

Toda esta arquitectura de EJBs es modificable en el fichero de configuración:
\server\\conf\standardjboss.xml

También podemos cambiar la configuración de esta arquitectura para un EJB usando su descriptor jboss.xml.