miércoles, 12 de marzo de 2008

Escribiendo una aplicación en Struts

En este ejemplo se estudiará como implementar una aplicación Web mediante el uso de Struts, será acompañado de pedazos código, disponibles en el apéndice B en su totalidad, para que el usuario pueda correrlo y analizarlo desde su computadora.
Estructura de los Archivos e Instalación

Las aplicaciones Web poseen una estructura de archivos definida para poder ejecutarse en un contenedor de Servlets, como el Tomcat de Apache, esta estructura por lo regular no se modifica y solamente se le agregan algunas librerías para poder correr una aplicación utilizando Struts (Figura 1).

Figura 1.- Estructura de los directorios


Para obtener e instalar Struts se debe obtener una versión de la herramienta en la dirección http://struts.apache.org/download.cgi. Dentro del archivo comprimido de la distribución, existe un directorio llamado lib que se debe copiar a la carpeta WEB-INF. Esta carpeta contiene todos los archivos JAR que utiliza la aplicación (Figura 2). Al momento de compilar los archivos java se debe asegurar que los archivos contenidos dentro de la carpeta lib estén en el classpath.



Figura 2 archivos JAR de la distribución de Struts
Componentes de Struts

Como se mencionó en el capítulo anterior, el MVC es parte fundamental de Struts, para explicar como encajan las partes de este patrón, se explicará un ejemplo modificado del clásico “Hola Mundo”.
Elementos de la Vista

La vista esta conformada de dos JSPs: index.jsp y hola.jsp, dentro de index.jsp se declara una forma que hace referencia a la acción hola.do, esta compuesta de un campo de texto y un botón para enviar la forma. El campo de texto tiene un atributo name = “nombre” que especifica un nombre lógico para la forma.


Escriba su nombre:




Para el manejo de formas, Struts provee una clase llamada ActionForm que se debe extender para darle funcionalidad. Dentro de la subclase, por cada campo dentro de la forma, se debe declarar una variable instancia con el mismo nombre que se asignó al atributo name en el código HTML, para cada variable se deben escribir métodos get y set como se muestra en el siguiente ejemplo:

/*
* HolaForm.java
*/
package aldo.ejemplo;

//area de imports
import javax.servlet.http.HttpServletRequest;
import org.apache.struts.action.*;
/**
*
* @author Aldo A. Solis
*/
public class HolaForm extends ActionForm{

/** Esta variable sirve para guardar el nombre del usuario */
private String nombre;

/**
* Sirve para obtener la variable nombre
* @return variable String nombre
*/
public String getNombre(){
return this.nombre;
}

/**
* Sirve para asignar un nombre a la variable
* @param nombre cadena que se asignará
*/
public void setNombre(String nombre){
this.nombre = nombre;
}

public void reset(ActionMapping map, HttpServletRequest req){
this.nombre = "";
}

public ActionErrors validate(ActionMapping map,
HttpServletRequest req){
ActionErrors errors = new ActionErrors();
if((nombre == null) || (nombre.length() < 1))
errors.add("nombre", new ActionMessage("error.nombre"));
return errors;
}
}

Adicionalmente se pueden sobrescribir los métodos reset y validate que tienen funcionalidades específicas. El método reset es invocado para reinicializar las variables a un valor dado por el programador, mientras el método validate se usa para validar que los datos no tengan errores de captura o valores nulos.

El archivo hola.jsp tiene la función de desplegar un letrero con el nombre que el usuario introdujó en index.jsp, esto mediante la siguiente línea de código:

Hola <%= request.getAttribute("nombre")%>



La línea anterior pide un atributo llamado “nombre” dentro del request y lo despliega en la página.
Elementos del controlador

Struts implementa el controlador mediante la clase ActionServlet del paquete org.apache.struts.action, es importante aclarar que esta clase es concreta, es el servlet principal de nuestra aplicación y no se necesita extender para poder usar el framework.

Toda aplicación Web debe tener un descriptor de despliegue (conocido en inglés como deployment descriptor) llamado web.xml, en este archivo se debe especificar el uso de Struts de la siguiente manera:






action


org.apache.struts.action.ActionServlet



config
/WEB-INF/struts-config.xml






action
*.do




El desarrollador indica al framework las acciones, las formas y otros atributos mediante un archivo de configuración que por convención se llama struts-config.xml y tiene los siguientes campos para la aplicación “Hola Mundo”:



"-//Apache Software Foundation//DTD Struts Configuration 1.2//EN"
"http://jakarta.apache.org/struts/dtds/struts-config_1_2.dtd" >




type="aldo.ejemplo.HolaForm"/>



type="aldo.ejemplo.HolaAction"
name="forma"
scope="request"
input="/index.jsp"
validate="true" >
path="/hola.jsp" />




La etiqueta form-beans sirve para declarar las clases que representan formas HTML, en el atributo name se escribe un nombre lógico con el que se le hará una referencia futura y en type se especifica el nombre completo de la clase.

Dentro de la etiqueta action-mappings se especifican las acciones, en este caso tenemos una sola acción pero por lo regular se tendrá más de una. La etiqueta action describe los atributos de una acción, en path se indica el nombre de como se llamará al recurso sin el “.do” (dado que esta terminación sirve para llamar al ActionServlet) y agregándose una diagonal al principio. El atributo name sirve para especificar el ActionForm que se usará por esta Action mediante su nombre lógico, validate indica si se llamará o no al método validate del ActionForm, así como input debe tener el nombre del JSP al que se redireccionará si validate regresa algún error.

La etiqueta forward especifica un nombre lógico y una página JSP, que el Action utiliza para continuar con el flujo de la navegación.

ActionServlet funciona más a detalle es la siguiente manera:

1. Recibe peticiones por parte de la vista, está puede ser un JSP.
2. Delega la petición a un objeto RequestProcessor, cuya clase se encuentra en el mismo paquete del ActionServlet y se encarga de seleccionar e invocar a la Action que corresponde a la petición. La clase RequestProcessor sigue para cada petición del usuario los siguientes pasos:

* Identifica la acción que se quiere usar por la petición del usuario
* Obtiene el nombre de la clase correspondiente a la acción.
* Si es la primera petición a la clase, crea una instancia para su uso futuro
* Llena una clase de tipo ActionForm asociada con esta petición, con los datos de la forma.
* Se llama al método executede la clase, pasando referencias al bean con los datos de la forma, al HttpServletRequest y al HttpServletResponse relacionado, así como un objeto ActionMapping que contiene información acerca de los recursos de donde proviene y hacia donde va el flujo de la navegación.

3. A su vez una Action manipula el estado y la lógica de nuestra aplicación y en lugar de mandar a la siguiente página, regresa un objeto ActionForward en el que se indica que recurso se encargará de la respuesta hacia el usuario.
4. El RequestProcessor, a través del objeto ActionForward, se encarga de mostrar o redireccionar a la siguiente página.



Para crear una acción se debe extender la clase org.apache.struts.action.Action y sobrescribir el método execute que tiene la siguiente firma:

public ActionForward execute( ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response )

El siguiente ejemplo muestra como implementar el Action de la aplicación “Hola Mundo”:

/*
* HolaAction.java
*/
package aldo.ejemplo;

// librerias necesarias
import org.apache.struts.action.*;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;



/**
* Esta clase se encarga de sobre-escribir el método execute
* que extiende de la clase Action, recupera una forma tipo
* HolaForm, y obtiene la variable nombre, después agrega el
* atributo nombre al request y decide la siguiente página a
* mostrar.
*
* @author Aldo A. Solis
*/
public class HolaAction extends Action{

public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response){

// Recuperamos la forma
HolaForm forma = (HolaForm) form;
// Obtenemos el nombre introducido por el usuario
String nombre = forma.getNombre();
// Hacemos una instancia del modelo
HolaModelo modelo = new HolaModelo();
// Llamamos a un método del modelo
nombre = modelo.mayusculas(nombre);
// Agregamos al request el atributo nombre
request.setAttribute("nombre", nombre);
// Seleccionamos la siguiente pagina “DecirHola”
// definida en el struts-config.xml
ActionForward fwd = mapping.findForward("DecirHola");
return fwd;
}
}
Elementos del Modelo

El modelo es lo que al desarrollador le interesa. En el modelo se lleva acabo la lógica aplicativa del sistema Web que se esta desarrollando. Struts no provee elementos que faciliten al desarrollador la implementación del modelo, ya que es responsabilidad del programador hacerlo. A continuación se muestra el modelo utilizado por la aplicación ejemplo:

/*
* HolaModelo.java
*/
package aldo.ejemplo;

public class HolaModelo {

/**
* Invierte una cadena
* @param cadena String a modificar
* @return String modificado
*/
public String voltear(String cadena){
String nuevaCadena=new String(" ");
System.out.println(cadena);
for (int i=cadena.length()-1; i>=0; i--){
String tmp = cadena.substring(i,i+1);
nuevaCadena = nuevaCadena.concat(tmp);
}
return nuevaCadena;
}

/**
* Convierte una cadena a mayúsculas
* @param cadena String a modificar
* @return String modificado
*/
public String mayusculas(String cadena){
return cadena.toUpperCase();
}

/**
* Convierte una cadena a minúsculas
* @param cadena String a modificar
* @return String modificado
*/
public String minusculas(String cadena){
return cadena.toLowerCase();
}
}
Correr la aplicación

Para correr la aplicación se deben compilar las clases y copiar los paquetes generados al directorio classes dentro de WEB-INF, por otra parte se deben copiar también las páginas o JSPs encargadas de la vista a la carpeta raíz, una vez tenida la estructura mostrada en la figura 3.1, se procede a copiar la carpeta de la aplicación al directorio de nuestro contenedor de Servlets. La aplicación funciona de la siguiente manera:

1. El sistema pregunta al usuario su nombre
2. El usuario lo escribe y presiona el botón enviar (Figura 3)





Figura 3 Programa corriendo

3. El sistema procesa la solicitud
4. El sistema despliega un resultado (Figura 4)



Figura 4 Resultado del programa



Cualquier duda o sugerencia.
Ing. Aldo A. Solis Zenteno

sábado, 1 de marzo de 2008

Hibernate

Usar JDBC es complejo y muy dependiente de la estructura de los datos. Sería más natural y mucho más sencillo trabajar directamente con objetos, pero es imposible con las BBDD relacionales, y las BBDD orientadas a objeto están todavía muy verdes.

La mejor opción entonces es utilizar un motor de persistencia, que es el componente software encargado de traducir entre objetos y registros. Un motor de persistencia de código abierto es Hibernate, que nos permitirá hacer cosas como poder guardar un objeto en la base de datos simplemente con session.save(miObjeto) o borrarlo con session.delete(miObjeto).

Usa el mecanismo de reflexión de Java, que permite a un objeto en ejecución examinarse y manipularse a sí mismo, en contra de, por ejemplo, JDO, que necesita que modifiquemos los archivos de las clases.

Vamos a tener un archivo properties (hibernate.properties) o un archivo xml (hibernate.cfg.xml) para la configuración, una serie de JavaBeans que son las clases a persistir y en las que cada campo se asociará con una columna de la BBDD, y un archivo xml por cada una de estas clases (NombreClase.hbm.xml) que indica el mapping entre objetos y relaciones.

Este sería el aspecto del JavaBean que representa una sucursal en una supuesta aplicación:







}
Y este el del fichero de mapping de hibernate correspondiente:


















































Como vemos la etiqueta class se utiliza para asociar nuestra clase a una tabla concreta de la base de datos. Las etiquetas que se sitúan por debajo de class nos permiten definir la relación entre las propiedades de la clase y las columnas de la base de datos. La etiqueta id se usa para identificar el campo que actuará como clave primaria e indicar el tipo que va a tener (Long en este caso), así como la columna de la base de datos en la que se almacenará el campo y la forma de generar la clave (en este caso, native, que depende de la base de datos que usemos; podríamos haberle indicado por ejemplo que simplemente fuera sumando 1 cada vez con increment, o incluso crear nuestra propia clase generadora). A continuación tenemos una serie de etiquetas property, una por cada propiedad, que funcionan de forma parecida a id, indicando el nombre de la propiedad de la clase (atributo name) su tipo (atributo type) y la columna a la que se mapea (atributo name de column).


Como sabemos, las tablas también pueden tener relaciones entre ellas. En Hibernate podemos declarar relaciones N:M mediante la etiqueta many-to-many, 1:N con one-to-many y N:1 con many-to-one



Ahora que ya hemos visto como indicarle a Hibernate la correspondencia entre nuestras clases y las tablas de la BBDD, vamos a ver cómo utilizaríamos esta API.

Lo primero que tendríamos que hacer para empezar a utilizar Hibernate sería crear un nuevo objeto Configuration para poder indicarle dónde se encuentra el archivo de configuración:

Configuration cfg = new Configuration();
cfg.configure(RUTA_ARCHIVO_CONF);

A partir del hibernate.cfg.xml podemos crea un SessionFactory, que es el objeto mediante el cual abrimos nuevas sesiones de Hibernate.

SessionFactory sessionFactory = cfg.buildSessionFactory();
Session session = sessionFactory.openSession();

Para insertar objetos en la BBDD usaremos el método save(Object objeto) de Session, para insertar o actualizar si ya existe saveOrUpdate(Object objeto), para borrar delete(Object objeto) y para cargar un objeto desde la BBDD get(String clase, Tipo id) o load(String clase, Tipo id) que devuelven el objeto de la clase indicada por el primer parámetro y con identificador el segundo parámetro si es que existe en la BBDD.

Para hacer búsquedas en la base de datos podemos usar find(String consulta) que devuelve una lista con los resultados, o iterate(String consulta) que devuelve un iterador, o bien crear un objeto Query usando createQuery(String consulta) y llamar más tarde al método find() del Query. La consulta en todos los casos estará escrita en un lenguaje similar a SQL propio de Hibernate llamado HQL (Hibernate Query Language). Otra opción sería trabajar con objetos Criteria.

miércoles, 13 de febrero de 2008

MyApp Spring Desarrollo 2

http://groups.google.com/group/ceac-j2ee/web/myapp-spring-desarrollo-2?hl=es

jueves, 7 de febrero de 2008

conectar clase con base de datos



1---[creamos] laclase por ejemplo Libro.java
1.1 necesitamos id,constructor vacio , metod setters and getters
2----creamos libro.hbm.xml y indicamos propiedades presitentes
3----creamos Librodao y su implimentacion LibroDaohibernate
3.1 modificamos applicationContacte-Hibernate.xml para indicarle el nuevo dao
4----Creamos LibroManager y su implimentacion libroManagerImpl
4.1---modificamos aplicactoonContext.xml para injectar el dao en el manager____>spring
5----Modificamosel controlador para que reciba Libros.html


paso1

miércoles, 30 de enero de 2008

JBoss


JBoss es una implementación Open-Source de un "EJB Container"; es mediante este tipo de productos que es posible llevar acabo un desarrollo con EJB's "Enterprise Java Bean's" . Este tipo de producto ("EJB Container") generalmente no es distribuido como producto individual y por esta razón se le pudiera considerar a "JBoss" como un producto diferente mas no único

La declaración anterior merece un poco más detalle, la gran gamma de productos en este ramo de Java ( J2EE para ser más exactos ) han sido comercializados como "Java Application Servers"

Como se observa en la siguiente gráfica un "Java Application Server" se encuentra compuesto por dos partes: un "Servlet Engine" y un "EJB Engine", dentro del "Servlet Engine" se ejecutan exclusivamente las clásicas aplicaciones de Servidor (JSP's ("Java Server Pages") y Servlets) , mientras el "EJB Engine(Container)" es reservado para aplicaciones desarrolladas alrededor de EJB's "Enterprise Java Bean's" .

Java Application Server


Casi todos los "Application Servers" en el mercado hoy en día son conocidos como "Fully J2EE Compliant", este termino implica que se cumplen todas las especificaciones J2EE definidas por "Sun" y es aquí donde es notable la diferencia con JBoss।

Cuando utiliza un "Application Server" como alguno de los siguientes ("Fully J2EE Compliant"):

· WebLogic

· Websphere

· Oracle 9i Application Server

· Sun Application Server (Previamente Netscape Enterprise o Kiva)

No existe una clara distinción entre el "Web-Container" y "EJB Container", esto es, es posible ejecutar tanto JSP/Servlets así como EJB's, sin embargo, el ambiente se encuentra altamente integrado para que sea transparente (al menos para el programador final) la comunicación entre JSP/Servlets y EJB'

El producto JBoss es únicamente un "EJB Container" y es por esto que generalmente se utiliza en conjunción con un "Web-Container", el "Web-Container" puede ser cualquiera disponible en el mercado, sin embargo, cuando obtenga JBoss incluirá Tomcat proporcionado como "Web-Container", aunque lo anterior no restringe a JBoss para operar con otro "Web Container" como ServletExec , la única ventaja de utilizar el "Web Container" incluido con JBoss será en tiempo de coordinación/configuración entre JBoss|"x" Web-Container, y siendo que un ambiente utilizando EJB's es altamente complejo es preferible concentrarse en algo que ya ha sido utilizado y depurado.

El resto de esta guia se basa en la utilización de JBoss con el "Servlet Engine" Tomcat y/o estableciendo comunicación directa con JBoss como lo demuestra la linea roja punteada de la gráfica inicial



Message Driven Bean

Este tipo de beans ( MDB ) permite a las aplicaciones procesar mensajes de forma asíncrona a través del servicio JMS ( Java Messaging Service ). Este servicio funciona a través de colas de mensajes, que es donde los clientes envían sus peticiones, y estas colas son controladas por los Message Driven Beans, los cuales procesan los mensajes que hay en ellas y ejecutan ciertos servicios dependiendo del mensaje procesado. Este tipo de beans se aproximan más a la forma conceptual de los Stateless Session Bean en el sentido que son beans que no deben almacenar estado alguno. Cuando un mensaje llega a la cola el contenedor hace una llamada al método onMessage del Message Driven Bean y en este método el bean debería invocar a métodos de otros sesión bean o realizar la lógica de negocio de debiera ejecutar ( es más conveniente no tener aquí lógica de negocio, sino hacer invocaciones a métodos de otras clases que sí se encarguen de realizar lógica de negocio ). Para declarar un MDB sólo hemos de establecer la anotación @MessageDriven a una clase que implemente la interface MessageListener, e indicar el nombre de la cola del contenedor ( la cuál es accesible vía JNDI ) que va a controlar el MDB. Veamos un ejemplo :
@MessageDriven( mappedName = "jms/Queue" )
public class AsynchronousService implements MessageListener {

public void onMessage( Message message ) {
TextMessage textMessage = (TextMessage)message;
System.out.println( textMessage.getText() );
}
}

Entity Bean

Un Entity Bean es una clase ( POJO ) que representa una tabla de una base de datos, y cada instancia de esta clase representa un registro de la tabla, es decir, con los entity beans lo que conseguimos es crear un mapeo entre las propiedades de una clase y los campos de una tabla। Además de este mapeo también vamos a poder especificar las relaciones que tienen las clases entre sí ( uno a uno, uno a muchos, muchos a uno y muchos a muchos ). Todo Entity Bean debe de tener una clave primaria que identifica a ese registro de forma única dentro de la tabla. Todas estas configuraciones las vamos a realizar a través de anotaciones, y el API que se encarga de gestionar todos los aspectos relativos a la persistencia es JPA ( Java Persistent API ). Vamos a ver un ejemplo. Vamos a crear una entidad llamada Team, para lo cual veremos que lo único que vamos a tener en cuenta es establecer una anotación @Entity al principio de la clase, una anotación @Id para indicar cuál es la propiedad que representa la clave primaria, y por último una anotación @OneToMany para indicar que un equipo puede estar compuesto por muchos jugadores y que éstos sólo pueden pertenecer a un equipo :
@Entity
public class Team {

private int id;
private String name;
private Date foundationDate;
private Collection players;

@Id
public int getId() {
return id;
}

public void setId( int value ) {
id = value;
}

public String getName() {
return name;
}

public void setName( String value ) {
name = value;
}

public Date getFoundationDate() {
return foundationDate;
}

public void setFoundationDate( Date value ) {
foundationDate = value;
}

@OneToMany
public Collection getPlayers() {
return players;
}

public void setPlayers( Collection value ) {
players = value;
}

}
A continuación vamos a crear la Entidad Player, que al igual que la entidad anterior va a tener una anotación @Entity, otra anotación @Id, y por último una anotación @ManyToOne para establecer una relación bidireccional entre las dos entidades :
public class Player {

private int id;
private String name;
private Team team;

@Id
public int getId() {
return id;
}

public void setId( int value ) {
id = value;
}

public String getName() {
return name;
}

public void setName( String value ) {
name = value;
}

@ManyToOne
public Team getTeam() {
return team;
}

public void setTeam( Team value ) {
team = value;
}

}

Stateful Session Bean

Al contrario que en los beans de sesión sin estado, los stateful session bean, como su nombre indica, sí tienen estado. Lo que esto significa es que dentro de la sesión del usuario estos beans van a almacenar datos en variables de instancia, y esos datos van a tener un significado concreto durante toda la convesación mantenida entre el cliente y el bean. Un ejemplo típico de bean de sesión con estado es un carro de la compra, en el cual, durante la sesión de usuario, éste va agregando productos en el carro a través de una lista. Tras ir agregando productos llegará un momento en el que el usuario quiera efectuar la compra, para lo cuál tendrá que realizar previamente un registro de sus datos, especificar la dirección de entrega, indicar el número de su tarjeta de crédito, etcétera, y finalmente confirmará la compra de los productos seleccionados. Como vemos, todos estos datos hay que almacenarlos en unas variables, que son las que conforman el estado del bean. Al igual que los Stateless Session Bean, los Stateful también deben de implementar una interface que puede ser Local o Remote :
@Local
public interface CartServiceLocal {

public void addProduct( Product product );
public void removeProduct( Product product );
public Collection getProducts();
}
Y la implementación de esta interface sería el Stateful Session Bean :
@Stateful
public class CartService implements CartServiceLocal {

private List products;


public void addProduct( Product product ) {
products.add( product );
}

public void removeProduct( Product product ) {
products.remove( product );
}

public Collection getProducts() {
return products;
}

}

Stateless Session Bean

Un bean de sesión sin estado es aquél que no dispone de variables de instancia en las cuales se guarden datos que puedan ser compartidos entre los distintos métodos del bean. Es decir, se trata de un bean que por lo general contará con una serie de métodos que realizarán un trabajo determinado e independiente y que el resultado de las operaciones realizadas dentro de cada uno de los métodos no dependerá de ningún ?estado? relativo a la conversación que mantiene el cliente con el bean. Como puede ser que a través de mis palabras no quede suficientemente claro a qué me refiero creo que va a ser mejor que veamos un ejemplo. Tomemos como ejemplo un bean que se encarga de gestionar las operaciones básicas que podemos realizar con un cliente, como son consultar un cliente, guardar un cliente y borrarlo. En primer lugar tendríamos que crear una interface :
public interface CustomerServiceLocal {

public void saveCustomer( Customer customer );
public Customer getCustomer( Long id );
public Collection getAllCustomers();
public void deleteCustomer( Long id );

}
Podemos ver que se trata de una simple interface que no tiene ninguna característica particular. Todo bean de sesión sin estado es necesario que disponga de una interface y la que hemos definido arriba es perfectamente válida para nuestro servicio de clientes. Si no la hubiéramos creado y hubiéramos definido directamente el bean sin la creación de la interface, hubiera sido el propio contenedor quién la hubiera creado por nosotros. La intefaz debiera de tener una anotación, que le indicara si se trata de una interface Local o Remote. Si el bean va a ser utilizado por una clase que se ejecute dentro de la misma JVM en la que se ejecuta el bean de sesión entonces la interface podría ser Local, y si el bean va a ser llamado por una clase que se ejecuta en una JVM distinta entonces la interface tendría que ser Remote. Por defecto, si no se indica nada, será tratada como una interface Local. Ejemplo de interface local :
@Local
public interface CustomerServiceLocal {

public void saveCustomer( Customer customer );
public Customer getCustomer( Long id );
public Collection getAllCustomers();
public void deleteCustomer( Customer customer );

}
Ejemplo de interface remota :
@Remote
public interface CustomerServiceRemote{

public void saveCustomer( Customer customer );
public Customer getCustomer( Long id );
public Collection getAllCustomers();
public void deleteCustomer( Customer customer );

}
Ahora nos faltaría crear el bean propiamente dicho :
@Stateless
public class CustomerService implements CustomerServiceLocal {

@PersistenceContext()
private EntityManager em;


public void saveCustomer( Customer customer ) {
em.persist( customer );
}

public Customer getCustomer( Long id ) {
Query q = em.createQuery( "SELECT c FROM Quiz c WHERE c.id = :id" ).
setParameter( "id", id );

return (Customer)q.getSingleResult();
}

public Collection getAllCustomers() {
return em.createQuery( "SELECT c from Customer c" ).getResultList();
}

public void deleteCustomer( Customer customer ) {
em.remove( customer );
}

}

EJB

Por todos es sabido que el modelo de programación propuesto por la versión 2.1 de EJB conllevaba una serie de inconvenientes que limitaron mucho el uso de esta especificación y conllevó la aparición de soluciones open source que suplían las carencias que presentaba EJB 2.1. Bajo mi punto de vista las soluciones open source que más han marcado el desarrollo empresarial dentro de la plataforma Java han sido Hibernate y Spring Framework, y en la nueva versión de Java Enterprise Edition se han incorporado muchas de las características de estos frameworks para procurar a los desarrolladores una plataforma de desarrollo bastante más sencilla que su predecesora versión 1.4. En este post voy a tratar de explicar cuáles son los distintos tipos de Enterprise Java Bean y cuáles son los propósitos de cada uno de ellos : Stateless Session Bean, Stateful Session Bean, Entity Bean y Message Driven Bean. Debido a que éste pretende ser una breve explicación a los tipos de Entreprise Bean existentes, no voy a entrar en detalles tales como ciclo de vida de los mismos y otros tipos de características.

sábado, 26 de enero de 2008

easyMock

EasyMock es una libreria muy util para hacer pruebas unitarias con JUnit. Nos sirve para crear cualquier objeto fantasma (mock) y hacer que devuelva un resultado concreto para una entrada concreta.

Ejemplo de test


import junit.framework.TestCase;
import org.easymock.EasyMock;


public class AutoTest extends TestCase{

private Fabrica fabrica;

@Override
protected void setUp() throws Exception {
super.setUp();

fabrica = EasyMock.createMock(Fabrica.class);

Motor motorFerrari = new MotorImpl(2500);
Ferrari ferrari = new Ferrari();
ferrari.setMotor(motorFerrari);
EasyMock.expect(fabrica.getFerrari()).andReturn(ferrari).times(5);

Motor motorPorche = new MotorImpl(1000);
Porche porche = new Porche();
porche.setMotor(motorPorche);
EasyMock.expect(fabrica.getPorche()).andReturn(porche).times(5);

EasyMock.replay(fabrica);
}

public void testCilindrada() {

Automovil porche = fabrica.getPorche();
Motor motorPorche = porche.getMotor();
assertEquals(motorPorche.getCilindrada(), 1000);

Automovil ferrari = fabrica.getFerrari();
Motor motorFerrari = ferrari.getMotor();
assertTrue(motorFerrari.getCilindrada() > motorPorche.getCilindrada());
}
}


Interfaz fábrica

public interface Fabrica {

Automovil getPorche();

Automovil getFerrari();

}

Clase Auto

public abstract class Auto {

private Motor motor;

public Motor getMotor() {
return this.motor;
}

public void setMotor(Motor motor) {

this.motor = motor;
}
}


Interfaz Automovil

public interface Automovil {

public Motor getMotor();

}

Clase Ferrari

public class Ferrari extends Auto implements Automovil { }


Clase Porche

public class Porche extends Auto implements Automovil { }


Interfaz Motor

public interface Motor {

public int getCilindrada();

}


Clase Motor

public class MotorImpl implements Motor {

private int cilindrada;

public MotorImpl(int cilindrada) {

this.cilindrada = cilindrada;
}

public int getCilindrada() {
return this.cilindrada;
}
}

viernes, 25 de enero de 2008

servidor de aplicaciones

Se trata de un dispositivo de software que proporciona servicios de aplicación a las computadoras cliente. Un servidor de aplicaciones generalmente gestiona la mayor parte (o la totalidad) de las funciones de lógica de negocio y de acceso a los datos de la aplicación. Los principales beneficios de la aplicación de la tecnología de servidores de aplicación son la centralización y la disminución de la complejidad en el desarrollo de aplicaciones. Si bien el término es aplicable a todas las plataformas de software, hoy en día el término servidor de aplicaciones se ha convertido en sinónimo de la plataforma J2EE de Sun Microsystems

Como consecuencia del éxito del lenguaje de programación Java, el término servidor de aplicaciones usualmente hace referencia a un servidor de aplicaciones J2EE. WebSphere (IBM), Oracle Application Server (Oracle Corporation) y WebLogic (BEA) están entre los servidores de aplicación J2EE privativos más conocidos. EAServer (Sybase Inc.) es también conocido por ofrecer soporte a otros lenguajes diferentes a Java, como PowerBuilder. El servidor de aplicaciones JOnAS, desarrollado por el consorcio ObjectWeb, fue el primer servidor de aplicaciones libre en lograr certificación oficial de compatibilidad con J2EE. JBoss es otro servidor de aplicaciones libre y muy popular en la actualidad. Mucha gente confunde a Tomcat (The Apache Software Foundation) con un servidor de aplicaciones, sin embargo es sólamente un contenedor de servlets [1].

J2EE provee estándares que le permiten a un servidor de aplicaciones servir como "contenedor" de los componentes que conforman dichas aplicaciones. Estos componentes, escritos en lenguaje Java, usualmente se conocen como Servlets, Java Server Pages (JSPs) y Enterprise JavaBeans (EJBs) y permiten implementar diferentes capas de la aplicación, como la interfaz de usuario, la lógica de negocio, la gestión de sesiones de usuario o el acceso a bases de datos remotas.

La portabilidad de Java también ha permitido que los servidores de aplicación J2EE se encuentren disponibles sobre una gran variedad de plataformas, como Unix, Microsoft Windows y GNU/Linux.

oop

La Programación Orientada a Objetos (POO u OOP según sus siglas en inglés) es un paradigma de programación que usa objetos y sus interacciones para diseñar aplicaciones y programas de computadora. Está basado en varias técnicas, incluyendo herencia, modularidad, polimorfismo, y encapsulamiento. Su uso se popularizó a principios de la década de 1990. Actualmente son muchos los lenguajes de programación que soportan la orientación a objetos.


Los objetos son entidades que combinan estado, comportamiento e identidad:

  • El estado está compuesto de datos, serán uno o vários atributos a los que se habrán asignado unos valores concretos (datos).
  • El comportamiento está definido por los procedimientos o métodos con que puede operar dicho objeto, es decir, qué operaciones se pueden realizar con él.
  • La identidad es una propiedad de un objeto que lo diferencia del resto, dicho con otras palabras, es su identificador (concepto análogo al de identificador de una variable o una constante).

La programación orientada a objetos expresa un programa como un conjunto de estos objetos, que colaboran entre ellos para realizar tareas. Esto permite hacer los programas y módulos más fáciles de escribir, mantener y reutilizar.

De esta forma, un objeto contiene toda la información que permite definirlo e identificarlo frente a otros objetos pertenecientes a otras clases e incluso frente a objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos. A su vez, los objetos disponen de mecanismos de interacción llamados métodos que favorecen la comunicación entre ellos. Esta comunicación favorece a su vez el cambio de estado en los propios objetos. Esta característica lleva a tratarlos como unidades indivisibles, en las que no se separan ni deben separarse el estado y el comportamiento.

Los métodos (comportamiento) y atributos (estado) están estrechamente relacionados por la propiedad de conjunto. Esta propiedad destaca que una clase requiere de métodos para poder tratar los atributos con los que cuenta. El programador debe pensar indistintamente en ambos conceptos, sin separar ni darle mayor importancia a ninguno de ellos, hacerlo podría producir el hábito erróneo de crear clases contenedoras de información por un lado y clases con métodos que manejen a las primeras por el otro. De esta manera se estaría realizando una programación estructurada camuflada en un lenguaje de programación orientado a objetos.

Esto difiere de la programación estructurada tradicional, en la que los datos y los procedimientos están separados y sin relación, ya que lo único que se busca es el procesamiento de unos datos de entrada para obtener otros de salida. La programación estructurada anima al programador a pensar sobre todo en términos de procedimientos o funciones, y en segundo lugar en las estructuras de datos que esos procedimientos manejan. En la programación estructurada sólo se escriben funciones que procesan datos. Los programadores que emplean éste nuevo paradigma, en cambio, primero definen objetos para luego enviarles mensajes solicitándoles que realicen sus métodos por sí mismos.

La programación orientada a objetos es una nueva forma de programar que trata de encontrar una solución a estos problemas. Introduce nuevos conceptos, que superan y amplían conceptos antiguos ya conocidos. Entre ellos destacan los siguientes:

  • Objeto: entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (métodos). Corresponden a los objetos reales del mundo que nos rodea, o a objetos internos del sistema (del programa). Es una instancia a una clase.---
  • Clase: definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La instanciación es la lectura de estas definiciones y la creación de un objeto a partir de ellas.
  • Método: algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena tras la recepción de un "mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un método puede producir un cambio en las propiedades del objeto, o la generación de un "evento" con un nuevo mensaje para otro objeto del sistema.
  • Evento: un suceso en el sistema (tal como una interacción del usuario con la máquina, o un mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente. También se puede definir como evento, a la reacción que puede desencadenar un objeto, es decir la acción que genera.
  • Mensaje: una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus métodos con ciertos parámetros asociados al evento que lo generó.
  • Propiedad o atributo: contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto y esto se define como sus características predeterminadas, y cuyo valor puede ser alterado por la ejecución de algún método.
  • Estado interno: es una propiedad invisible de los objetos, que puede ser únicamente accedida y alterada por un método del objeto, y que se utiliza para indicar distintas situaciones posibles para el objeto (o clase de objetos).
  • Componentes de un objeto:atributos, identidad, relaciones y métodos.
  • Representación de un objeto: un objeto se representa por medio de una tabla o entidad que esté compuesta por sus atributos y funciones correspondientes.

En comparación con un lenguaje imperativo, una "variable", no es más que un contenedor interno del atributo del objeto o de un estado interno, así como la "función" es un procedimiento interno del método del objeto.

Características de la POO [editar]

Hay un cierto desacuerdo sobre exactamente qué características de un método de programación o lenguaje le definen como "orientado a objetos", pero hay un consenso general en que las características siguientes son las más importantes (para más información, seguir los enlaces respectivos):

  • Abstracción: Cada objeto en el sistema sirve como modelo de un "agente" abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cómo se implementan estas características. Los procesos, las funciones o los métodos pueden también ser abstraídos y cuando lo están, una variedad de técnicas son requeridas para ampliar una abstracción.
  • Encapsulamiento: Significa reunir a todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstracción. Esto permite aumentar la cohesión de los componentes del sistema. Algunos autores confunden este concepto con el principio de ocultación, principalmente porque se suelen emplear conjuntamente.
  • Principio de ocultación: Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone una interfaz a otros objetos que especifica cómo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificación por quien no tenga derecho a acceder a ellas, solamente los propios métodos internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no pueden cambiar el estado interno de un objeto de maneras inesperadas, eliminando efectos secundarios e interacciones inesperadas. Algunos lenguajes relajan esto, permitiendo un acceso directo a los datos internos del objeto de una manera controlada y limitando el grado de abstracción. La aplicación entera se reduce a un agregado o rompecabezas de objetos.
  • Polimorfismo: comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizará el comportamiento correspondiente al objeto que se esté usando. O dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocación de un comportamiento en una referencia producirá el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en "tiempo de ejecución", esta última característica se llama asignación tardía o asignación dinámica. Algunos lenguajes proporcionan medios más estáticos (en "tiempo de compilación") de polimorfismo, tales como las plantillas y la sobrecarga de operadores de C++.
  • Herencia: las clases no están aisladas, sino que se relacionan entre sí, formando una jerarquía de clasificación. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos pueden compartir (y extender) su comportamiento sin tener que reimplementar su comportamiento. Esto suele hacerse habitualmente agrupando los objetos en clases y estas en árboles o enrejados que reflejan un comportamiento común. Cuando un objeto hereda de más de una clase se dice que hay herencia múltiple; esta característica no está soportada por algunos lenguajes (como Java

aop

Programación Orientada a Aspectos

La Programación Orientada a Aspectos (POA) es un paradigma de programación relativamente reciente cuya intención es permitir una adecuada modularización de las aplicaciones y posibilitar una mejor separación de conceptos. Gracias a la POA se pueden encapsular los diferentes conceptos que componen una aplicación en entidades bien definidas, eliminando las dependencias entre cada uno de los módulos. De esta forma se consigue razonar mejor sobre los conceptos, se elimina la dispersión del código y las implementaciones resultan más comprensibles, adaptables y reusables. Varias tecnologías con nombres diferentes se encaminan a la consecución de los mismos objetivos y así, el término POA es usado para referirse a varias tecnologías relacionadas como los métodos adaptivos, los filtros de composición, la programación orientada a sujetos o la separación multidimensional de competencias.

J2ee

Java Platform, Enterprise Edition o Java EE (anteriormente conocido como Java 2 Platform, Enterprise Edition o J2EE hasta la versión 1.4), es una plataforma de programación—parte de la Plataforma Java—para desarrollar y ejecutar software de aplicaciones en Lenguaje de programación Java con arquitectura de n niveles distribuida, basándose ampliamente en componentes de software modulares ejecutándose sobre un servidor de aplicaciones. La plataforma Java EE está definida por una especificación. Similar a otras especificaciones del Java Community Process, Java EE es también considerada informalmente como un estándar debido a que los suministradores deben cumplir ciertos requisitos de conformidad para declarar que sus productos son conformes a Java EE; no obstante sin un estándar de ISO o ECMA.

Java EE incluye varias especificaciones de API, tales como JDBC, RMI, e-mail, JMS, Servicios Web, XML, etc y define cómo coordinarlos. Java EE también configura algunas especificaciones únicas para Java EE para componentes. Estas incluyen Enterprise JavaBeans, servlets, portlets (siguiendo la especificación de Portlets Java), JavaServer Pages y varias tecnologías de servicios web. Esto permite al desarrollador crear una Aplicación de Empresa portable entre plataformas y escalable, a la vez que integrable con tecnologías anteriores. Otros beneficios añadidos son, por ejemplo, que el servidor de aplicaciones puede manejar transacciones, la seguridad, escalabilidad, concurrencia y gestión de los componentes desplegados, significando que los desarrolladores pueden concentrarse más en la lógica de negocio de los componentes en lugar de en tareas de mantenimiento de bajo nivel.

martes, 22 de enero de 2008

TestNG

TestNG es un framework para pruebas y testing que trabaja con Java y está basado en JUnit (para Java) y NUnit (para .NET), pero introduciendo nuevas funcionalidades que los hacen más poderosos y fáciles de usar, tales como:

  • Anotaciones JDK 5 (Annotations) (JDK 1.4 también es soportado con JavaDoc annotations).
  • Configuración flexible de pruebas.
  • Soporte para pruebas para data-driven testing (with @DataProvider).
  • Soporte de pasaje de parámetros.
  • Permite distribución de las pruebas en maquinas esclavas.
  • Modelo de ejecución poderoso (TestSuite nunca más).
  • Soportado por herramientas y plugins importantes y variados como: (Eclipse, IDEA, Maven, etc...).
  • Permite embeber BeanShell para una flexibilidad más amplia.
  • Funciones JDK por defecto de runtime y logging. (sin dependencias)
  • Métodos dependientes para pruebas sobre servidores de aplicación.

TestNG está diseñado para cubrir todas las categorías de las pruebas: unitarias, funcionales, end-to-end, integración, etc.