6.2 Hacer el deployment de una aplicación (J2EE+ WS) y ver los principales indicadores.

Un descriptor de despliegue (en inglés Deployment Descriptor) (DD) es un componente de aplicaciones J2EE que describe cómo se debe desplegar (o implantar) una aplicación web. Esto dirige una herramienta de despliegue (o publicación) para desplegar un módulo o aplicación con opciones de contenedor específicas y describe requisitos de configuración específicos que puede resolver un desplegador.

Las aplicaciones J2EE, XML se usan para la sintaxis del fichero descriptor de despliegue. Debe ser llamado web.xml, y debe ser colocado en un subdirectorio llamado WEB-INF, directamente debajo de la raíz de la aplicación web.

El término descriptor de despliegue también se usa como referencia general a un fichero de configuración para un artefacto que es desplegado en algún contenedor/motor (e.g. descriptor de despliegue de proceso para el BPEL-Engine ActiveBPEL).

 

Imagen 1. Descriptor de Despliegue 

IBM WebSphereApplication Server (WAS, servidor de aplicaciones WebSphere), un servidor de aplicaciones de software, es el producto estrella dentro de la familia WebSphere de IBM. WAS está construido usando estándares abiertos tales como J2EE, XML, y Servicios Web. Varios laboratorios de IBM alrededor del mundo participaron en la creación de los productos run-time WebSphere y las herramientas de desarrollo. Esto funciona con varios servidores web incluyendo Apache HTTP Server, Netscape Enterprise Server, Microsoft Internet Information Services (IIS), IBM HTTP Server para i5/OS, IBM HTTP Server para z/OS, y también IBM HTTP Server para el sistema operativo AIX/Linux/Microsoft Windows/Solaris.

El repositorio de configuración basado en bases de datos fue reemplazado con un repositorio de configuración basado en ficheros XML de replicación. Un servicio llamado el Gestor de Despliegue tenía la copia maestra de la configuración de celdas, y los nodos tenían los ficheros que necesitaran copiados desde este servidor maestro cuando quiera que cambiaran. V5 también incluyó una versión miniatura de MQ 5.3 llamado el servidor de Java MessageService (JMS) empotrado.

• Express Edition reemplaza a la edición Standard. Express ahora se convierte en el término que indica las ofertas orientadas a PyMEsdesde IBM, a través de todas sus marcas de software.
• Base
• Network Deployment (Despliegue de Red). Esta versión soporta el despliegue de una configuración en celdas con cluster y soporte a tolerancia de fallos J2EE. Ahora también incluye EdgeComponents, previamente conocido como Edge Server. Esto suministra un servidor proxy, balanceado de carga, y enrutamiento basado en contenidos
• Enterprise Edition. Esta versión añadió un motor de workflow, llamado el Coreógrafo de Procesos, la primera vez, pero elimina el estándar BPEL. También añadió el primer modelo de threading de aplicaciones completamente soportado llamado WebSphereAsynchronousBeans.
• WebSphereApplication Server para z/OS. Esta versión esencialmente es el mismo que el producto de Network Deployment excepto que está optimizado para tomar ventaja total de las características z/OS, tales como el Gestor de Carga de Trabajo(Workload), para impulsar las tecnologías clave que hacen al mainframe indispensable para cargas de trabajo seguras, importantes y escalables.

Versión 6 

• Esta versión fue publicada en diciembre de 2004. Es un servidor de aplicaciones que cumple J2EE 1.4.
• CommunityEdition (Gratuito, para recibir soporte bajo pago)
• Código basado en el proyecto Apache Gerónimo
• Express

Muchas extensiones del modelo de programación previamente encontradas en WebSphereApplication Server V5.0 Enterprise Edition fueron extraídas del enterprise hacia el Express y Base. Estas APIs incluyeron perfil de aplicación, beans de inicio, el planificador, y los beans asíncronos.

El motor JMS, ahora llamado "WebSpherePlatformMessaging," fue reescrito en Java al 100% y mejorada su funcionalidad. (Obviamente WebSphere MQ es todavía soportado como el proveedor JMS y es interoperable con WebSpherePlatformMessaging.)

• Base
• Network Deployment

El clustering fue reescrito para usar el gestor de alta disponibilidad. Esto gestiona todos los singletons en el entorno WebSphere y puede suministrar recuperación en caliente para esos singletons.

WebSphere fue modificado para que un sistema de ficheros compartido pudiera usarse para almacenar logs de transacciones y esto significa que cualquier miembro del cluster con ese sistema de ficheros compartido montado puede recuperar en caliente las transacciones XA dudosas sin software HA externo.

El rol del Gestor de Despliegue fue eliminado de todas las operaciones runtime de clustering. Esto es solo requerido para admin JMX centralizado y cambios en la configuración.

ObjetGrid

El ObjectGrid es la primera pieza del framework de cacheado distribuido de IBM. V6 de XD se entrega con soporte para cacheado de Objetos locales Java así como también cacheado peer to peer con invalidación/push de datos asíncronos. Esto está diseñado para instalar framework extensible de cliente para cachear objetos. Todos los aspectos del framework núcleo tienen puntos de plugin (para añadir plugin). Esto permite a los clientes añadir funciones así como también permite a IBM extenderlo en futuros niveles del producto. Esto está diseñado para ejecutarse independientemente del WebSphere. No significa que no se integra con WebSphere 6.0 XD, sí que lo hace. En cambio, esto también funcionará con las versiones viejas del servidor de aplicaciones, servidores tomcat, y servidores de aplicaciones competitivos. Esto es necesario para competir contra otros productos de cache distribuida del mercado. Actualmente solo requiere un nivel de JDK 1.4 de cualquier vendedor. La Versión 2 de ObjectGrid está actualmente bajo desarrollo para entrega en XD 6.0.1. Esto añadirá la función significativa al componente así como también un soporte a nivel JDK más amplio. La intención es permitir a los clientes construir grandes grids de JVMs en las cuales puedan conectar aplicaciones y almacenar objetos de varias calidades de servicio. La grid está siendo diseñada para escalar a 1000s de JVMs y mantener una gran cantidad de datos.