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" .

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.

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;
}
}

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.

repositorio

http://code.google.com/p/java-zakaria

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.