WebSphere Application Server: Visión general e inicio rápido

Obtenga información sobre el modelo de programación, información de alto nivel del producto para poder iniciarse rápidamente.

El modelo de programación para aplicaciones desplegadas en este producto tiene los aspectos siguientes:
  • Especificaciones Java™ y otros estándares abiertos para desarrollar aplicaciones
  • Extensiones del modelo de programación de WebSphere para mejorar la funcionalidad de las aplicaciones
  • Contenedores y servicios en el servidor de aplicaciones, utilizados por las aplicaciones desplegadas, que a veces se pueden ampliar

En el diagrama se muestra una instalación del servidor de aplicaciones. Aquí se describen las partes que pertenecen al modelo de programación. Otras partes incluyen la arquitectura del producto, independientemente de los diversos tipos de aplicaciones descritos por el modelo de programación. Consulte Visión general del producto.

Entorno de servicio de aplicaciones

Componentes de aplicación Java EE

El producto da soporte a componentes de aplicaciones que cumplan con las especificaciones de Java EE (Java Platform, Enterprise Edition.
Aplicaciones web ejecutadas en el contenedor web

El contenedor web es la parte del servidor de aplicaciones en el cual se ejecutan los componentes de aplicación web. Las aplicaciones web constan de uno o varios servlets relacionados, tecnología JavaServer Pages (archivos JSP) y archivos HTML (Hyper Text Markup Language) que puede gestionar como una unidad. Combinadas, realizan funciones de lógica empresarial.

El contenedor web procesa servlets, archivos JSP y otros tipos de inclusiones del lado de servidor. Cada ejecución de servidor de aplicaciones tiene un contenedor web lógico, que se puede modificar, pero no crear o eliminar. Cada contenedor web proporciona lo siguiente.
Cadenas de transporte del contenedor Web
Las solicitudes se dirigen al contenedor web utilizando la cadena de transporte de entrada de contenedor web. La cadena consta de un canal de entrada TCP que proporciona la conexión a la red, un canal de entrada HTTP que atiende las solicitudes HTTP y un canal de contenedor web a través del cual se envían las solicitudes de servlets y archivos JSP al contenedor web para su proceso.
Procesamiento de servlet
Al manejar los servlets, el contenedor web crea un objeto de solicitud y un objeto de respuesta y, a continuación, invoca el método de servicio de servlet. El contenedor web invoca al método de destrucción del servlet cuando es apropiado y descarga el servlet, después del cual la JVM realiza la recogida de basura.

Los servlets pueden realizar tareas tales como dar soporte el contenido de páginas web dinámicas, proporcionar acceso a la base de datos, dar servicio a varios clientes a la vez y filtrar datos.

Los archivos JSP permiten la separación de código HTML de la lógica empresarial en páginas web. Las extensiones IBM® de la especificación JSP facilitan a los autores de HTML añadir la potencia de la tecnología Java a las páginas web, sin necesidad de ser expertos en programación Java.

HTML y otros procesos de contenido estático
Las solicitudes de HTML y de otro contenido estático que se dirigen al contenedor web las atiende la cadena de entrada de contenedor web. Sin embargo, en la mayoría de los casos, la utilización de un servidor web externo y un plug-in de servidor web como frontal para el contenedor web resulta más apropiada para un entorno de producción.
Gestión de sesiones
Se proporciona soporte para la interfaz javax.servlet.http.HttpSession tal como se describe en la especificación de interfaz de programación de aplicaciones (API) de Servlet.

Una sesión HTTP es una serie de solicitudes a un servlet, que se originan en el mismo usuario en el mismo navegador. Las sesiones permiten a las aplicaciones que se ejecutan en un contenedor web realizar un seguimiento de usuarios individuales. Por ejemplo, muchas aplicaciones web permiten que los usuarios recopilen datos de forma dinámica a medida que se mueven por el sitio, según una serie de selecciones realizadas en las páginas que visitan. Dónde irá el usuario o qué mostrará el sitio a continuación dependerá de qué haya elegido el usuario previamente en el sitio. Para mantener estos datos, la aplicación los almacena en una "sesión".

Aplicaciones SIP y el contenedor

Las aplicaciones SIP son programas Java que utilizan como mínimo un servlet SIP (Session Initiation Protocol). SIP se utiliza para establecer, modificar y terminar sesiones IP multimedia, incluyendo la telefonía, la presencia y la mensajería instantánea de IP.

Aplicaciones de portlet y el contenedor

Las aplicaciones de portlet son servlets Java especiales reutilizables que aparecen como regiones definidas en páginas de portal. Los portlets proporcionan acceso a muchas aplicaciones, servicios y contenido web diferentes.

Las aplicaciones EJB se ejecutan en el contenedor EJB

El contenedor EJB proporciona todos los servicios de ejecución necesarios para desplegar y gestionar enterprise beans. Es un proceso de servidor que maneja solicitudes para beans de sesión y de entidad.

Los enterprise beans son componentes Java que implementan normalmente la lógica empresarial de las aplicaciones Java EE, así como el acceso a los datos. Los enterprise beans, empaquetados en módulos EJB, instalados en un servidor de aplicaciones no se comunican directamente con el servidor. En lugar de ello, el contenedor EJB es una interfaz entre los componentes EJB y el servidor de aplicaciones. Juntos, el contenedor y el servidor proporcionan el entorno de ejecución de enterprise bean.

El contenedor proporciona muchos servicios de bajo nivel, incluido el soporte de hebras y transacciones. Desde el punto de vista de la administración, el contenedor maneja el acceso a datos de los beans contenidos. Un solo contenedor puede albergar más de un archivo JAR (Java Archive) EJB.

Aplicaciones cliente y otros tipos de cliente

En un entorno de cliente-servidor, los clientes se comunican con las aplicaciones que se ejecutan en el servidor. Las aplicaciones cliente o los clientes de aplicaciones generalmente hacen referencia a los clientes que se implementan de acuerdo con un determinado conjunto de especificaciones Java y se ejecutan en el contenedor de cliente de un servidor de aplicaciones compatible con Java EE. Otros clientes del entorno de WebSphere Application Server son los clientes implementados como aplicaciones web (clientes web), los clientes de los programas de los servicios web (clientes de servicios web) y los clientes administrativos de sistemas de productos (clientes administrativos).
Aplicaciones cliente y el contenedor
El contenedor cliente se instala por separado del servidor de aplicaciones en la máquina cliente. Permite al cliente ejecutar aplicaciones en un entorno Java EE compatible con EJB. En el diagrama muestra un cliente Java que se ejecuta en el contenedor de cliente.

Este producto proporciona una Herramienta launchClient útil para iniciar el cliente de aplicación, junto con la ejecución de contenedor de cliente.

En función del origen de la información técnica, las aplicaciones cliente se denominan a veces clientes de aplicaciones. En esta documentación, los dos términos son sinónimos.

Clientes web, también conocidos como clientes de navegador web
En el diagrama se muestra un cliente de navegador web, que se puede denominar simplemente cliente web, que realiza una solicitud al contenedor web del servidor de aplicaciones. Un cliente web o un cliente de navegador web se ejecuta en un navegador web y normalmente es una aplicación web.
Clientes de servicios web
No obstante, los clientes de servicios web son otro tipo de cliente que puede existir en el entorno de servicio de aplicaciones. El diagrama no describe un cliente de servicios web. La información de servicios web incluye información sobre este tipo de cliente.
Clientes administrativos
El diagrama muestra dos clases de clientes administrativos: un cliente de scripts y la consola administrativa que es la interfaz gráfica de usuario (GUI) para administrar este producto. Ambos acceden a partes de la infraestructura de administración de sistemas. En el sentido de que son básicamente iguales para cualquier clase de aplicaciones que esté desplegando en el servidor, los clientes administrativos forman parte de la arquitectura del producto. Sin embargo, estos clientes se describen como parte del modelo de programación de forma completa, puesto que muchos de ellos son programas que el usuario crea.

Consulte Utilización de los clientes administrativos.

Servicios Web

Servicios Web
En el diagrama se muestra el motor de servicios web, que forma parte del soporte de servicios web en la ejecución del servidor de aplicaciones. Los servicios web son aplicaciones autónomas y modulares que se pueden describir, publicar, localizar e invocar a través de una red. Implementan una arquitectura orientada a servicios (SOA), que soporta la conexión o el compartimiento de recursos y datos de un modo flexible y estandarizado. Los servicios se describen y se organizan para dar soporte al descubrimiento y la reutilización dinámica y automática.

El producto actúa como proveedor de servicios web y como solicitante. Como proveedor, contiene los servicios web que se publican para uso de los clientes. Como solicitante, contiene aplicaciones que invocan servicios web de otras ubicaciones. El diagrama muestra el motor de servicios web en esta capacidad, que contacta con un proveedor de servicios web o pasarela.

Recursos de acceso a datos, mensajería y Java EE

Recursos de acceso a datos
La gestión de conexiones para acceder a sistemas EIS (Enterprise Information System) en el servidor de aplicaciones se basa en la especificación JCA (Java EE Connector Architecture). El diagrama muestra los servicios JCA que ayudan a una aplicación a acceder a una base de datos en la que la aplicación recupera y mantiene datos.

La conexión entre la aplicación de empresa y el EIS se realiza a mediante el uso de adaptadores de recursos proporcionados por EIS, que se conectan al servidor de aplicaciones. La arquitectura especifica la gestión de conexiones, la gestión de transacciones y los contratos de seguridad entre el servidor de aplicaciones y EIS.

El Gestor de conexiones (no mostrado) en el servidor de aplicaciones sondea y gestiona las conexiones. Puede gestionar las conexiones que se obtienen mediante los adaptadores de recursos definidos por la especificación JCA y los orígenes de datos definidos por la especificación de extensiones JDBC 2.0.

Los recursos JDBC (orígenes de datos y proveedores de JDBC) son un tipo de recurso Java EE que utilizan las aplicaciones para acceder a los datos. Aunque el acceso a datos es un tema más amplio que el de los recursos JDBC, normalmente en esta información, para simplificar, se agrupa el acceso a datos bajo la cabecera de recursos Java EE.

Los adaptadores de recursos JCA son otro tipo de recurso Java EE utilizado por las aplicaciones. JCA define la arquitectura estándar para conectar la plataforma Java EE con EIS heterogéneos. Imagine un ERP, el proceso de transacciones de host, sistemas de bases de datos y aplicaciones de legado no escritos en el lenguaje de programación Java.

El adaptador de recursos JCA es un controlador de software a nivel de sistema proporcionado por los proveedores de EIS y proveedores de otras empresas. Proporciona la conectividad entre clientes o servidores de aplicaciones Java EE y un EIS. Para utilizar un adaptador de recursos, instale el código de adaptador de recursos y cree configuraciones que utilicen dicho adaptador. El producto proporciona un adaptador de recursos relacional predefinido para que lo utilice.

Recursos de mensajería y motores de mensajería
El soporte de JMS permite que las aplicaciones intercambien mensajes de forma asíncrona con otros clientes JMS utilizando destinos JMS (colas o temas). Las aplicaciones pueden utilizar beans controladores por mensajes para recuperar automáticamente mensajes de destinos JMS y puntos finales JCA sin sondear explícitamente mensajes.

Para las solicitudes de entrada que no son JMS, los beans controlados por mensajes utilizan un adaptador de recursos JCA (Java EE Connector Architecture) 1.5 escrito con ese fin. Para la mensajería JMS, los beans controlados por mensaje pueden utilizar un proveedor de mensajería basado en JCA, por ejemplo el proveedor de mensajería predeterminado que forma parte del producto.

El motor de mensajería soporta los siguientes tipos de proveedores de mensajes.
Proveedor de mensajería predeterminado (bus de integración de servicios)
El proveedor de mensajería predeterminado utiliza el bus de integración de servicio para el transporte. El proveedor de mensajería predeterminado proporciona funciones de punto a punto así como funciones de publicación y suscripción. En este proveedor, puede definir fábricas de conexiones JMS y destinos que corresponden destinos de bus de integración de servicios.
Proveedor de IBM MQ
Puede utilizar IBM MQ como proveedor JMS externo. El servidor de aplicaciones proporciona las clases de cliente JMS y la interfaz de administración, mientras que IBM MQ proporciona el sistema de mensajería basado en colas.
Proveedor genérico de JMS
Puede utilizar otro proveedor de mensajería a condición de que éste implemente el componente ASF de la especificación de JMS 1.0.2. Los recursos JMS para este proveedor no se pueden configurar utilizando la consola administrativa.
transition: La versión 6 sustituye el concepto de servidor JMS de la versión 5 por un motor de mensajería incorporado en el servidor de aplicaciones, ofreciendo las diversas clases de proveedores mencionados anteriormente. El proveedor de mensajería de la Versión 5 se ofrece para configurar recursos a fin de utilizarlos con la mensajería incorporada de la Versión 5. También puede utilizar el proveedor de mensajería predeterminado de la versión 5 con un bus de integración de servicios.

EJB 2.1 introduce una especificación de activación para conectar los beans controlados por mensaje con los destinos. Por compatibilidad con la Versión 5, podrá seguir configurando beans controlados por mensaje JMS (EJB 2.0) en un puerto de escucha. Para esos beans controlados por mensaje, el servicio de escucha de mensajes proporciona un gestor de escuchas que controla y supervisa una o varias escuchas JMS, cada uno de los cuales supervisa un destino de JMS en nombre de un bean controlado por mensaje desplegado.

Bus de integración de servicios

El bus de integración de servicios proporciona una infraestructura de comunicaciones unificada para aplicaciones orientadas a servicios y de mensajería. El bus de integración de servicios es un proveedor JMS que proporciona transporte de mensajes fiable y utiliza la lógica de intermediario para adaptar el flujo de mensajes de forma inteligente en la red. Da soporte a la conexión de solicitantes y proveedores de servicios web. Las posibilidades se integran totalmente en la arquitectura de producto, incluyendo los subsistemas de seguridad, administración de sistema, supervisión y determinación de problemas.

Normalmente el bus de integración de servicios se denomina simplemente bus. Cuando se utiliza para albergar aplicaciones JMS, normalmente se denomina bus de mensajería. Consta de las siguientes partes (no mostradas en este nivel de detalle del diagrama).
Miembros del bus
Servidores de aplicaciones añadidos al bus.
Motor de mensajería
Componente que gestiona recursos de bus. Proporciona un punto de conexión para que los clientes produzcan mensajes o del que los clientes consuman mensajes.
Destinos
Lugar en el bus en el que las aplicaciones se conectan para intercambiar mensajes. Los destinos pueden representar puntos finales de servicios web, colas de punto a punto de mensajería o temas de publicación y suscripción de mensajería. Los destinos se crean en un bus y se albergan en un motor de mensajería.
Almacén de mensajes
Cada motor de mensajería utiliza un conjunto de tablas de un almacén de datos soportado (por ejemplo una base de datos JDBC) para mantener información como mensajes, información de suscripciones y estados de transacciones.
A través de la habilitación de servicios web del bus de integración de servicios, puede:
  • Hacer que un servicio interno que ya está disponible en un destino de servicio esté disponible como servicio web.
  • Hacer que un servicio web externo esté disponible en un destino de servicio.
  • Utilizar la pasarela de servicios web para correlacionar un servicio existente, un servicio interno o un servicio web externo, con un nuevo servicio web que parece proporcionado por la pasarela.
Los recursos de simultaneidad, de correo electrónico, de URL y otros recursos Java EE
Las aplicaciones desplegadas en un servidor de aplicaciones que se ajusta a J2EE utilizan las siguientes clases de recursos Java EE.
  • Recursos JDBC y otra tecnología de acceso a datos (descrito en este documento)
  • Adaptadores de recursos JCA (descritos anteriormente)
  • Recursos JMS y otro soporte de mensajería (descrito anteriormente)
  • Los recursos de simultaneidad para someter o planificar tareas para que se ejecuten en paralelo, para crear hebras que hereden el contexto de Java EE y para transferir el contexto de Java EE a la invocación de interfaces como, por ejemplo, la devolución de llamada asíncrona
  • Soporte JavaMail, para que las aplicaciones envíen correo de Internet

    Las API JavaMail proporcionan una infraestructura independiente de la plataforma y del protocolo para crear aplicaciones cliente de correo basadas en Java. Las API necesitan que los proveedores de servicio, que se conocen como proveedores de protocolo, interactúen con los servidores de correo que se ejecutan en los protocolos apropiados.

    Un proveedor de correo encapsula una colección de proveedores de protocolo, incluido SMTP (Simple Mail Transfer Protocol) para enviar correo, POP (Post Office Protocol) para recibir correo e IMAP (Internet Message Access Protocol) como otra opción para recibir correo. Para utilizar otro protocolo, debe instalar el proveedor de servicio apropiado para el protocolo.

    JavaMail no sólo necesita proveedores de servicio sino también JAF (JavaBeans Activation Framework - Infraestructura de activación de JavaBeans), como infraestructura subyacente para manejar tipos de datos complejos que no son texto normal, por ejemplo MIME ( Multipurpose Internet Mail Extensions), páginas URL y adjuntos de archivo.

  • URL, para describir ubicaciones lógicas

    Los proveedores de URL implementan la funcionalidad para un protocolo de URL determinado, por ejemplo HTTP, permitiendo las comunicaciones entre la aplicación y un recurso de URL servido por un protocolo determinado. Se incluye un proveedor de URL predeterminado para que lo utilice cualquier recurso de URL con protocolos basados en la especificación de Java SE (Java Platform, Standard Edition), por ejemplo HTTP, FTP o Archivo. También puede conectar sus propios proveedores de URL que implementen protocolos adicionales.

  • Entradas del entorno de recursos, para correlacionar nombres lógicos con nombres físicos

    El entorno java:comp/env proporciona un solo mecanismo mediante el cual se pueden buscar los objetos de espacio de nombres JNDI y los objetos de entorno de aplicaciones local. El producto proporciona muchas entradas de entorno local de forma predeterminada.

    La especificación Java EE también proporciona un mecanismo para definir entradas de entorno de cliente definiendo entradas en el descriptor de despliegue estándar de una aplicación. La especificación Java EE utiliza los métodos siguientes para separar la definición de la entrada de entorno de recurso de la aplicación.
    • Necesidad de que el servidor de aplicaciones proporcione un mecanismo para definir objetos administrativos independientes que encapsulan una entrada de entorno de recurso. Se puede acceder a los objetos administrativos utilizando JNDI en el espacio de nombres local del servidor de aplicaciones (java:comp/env).
    • Especificación del nombre de búsqueda de JNDI del objeto administrativo y tipo de objeto devuelto esperado. Esta especificación se proporciona en la entrada de entorno de recurso mencionada en el descriptor de despliegue.
    El producto soporta la utilización de las entradas de entorno de recurso con los siguientes conceptos administrativos.
    • Una entrada de entorno de recurso define el destino de enlace (nombre JNDI), la clase de fábrica y el tipo de objeto de retorno (a través del enlace a un referenciable) de la entrada de entorno de recurso.
    • Un referenciable define el nombre de clase de la fábrica que devuelve instancias de objeto implementando una interfaz Java.
    • Un proveedor de entorno de recurso agrupa el referenciable, las entradas de entorno de recurso y las propiedades personalizadas necesarias.

Seguridad

Modelo de programación e infraestructura de seguridad
El producto ofrece una infraestructura de seguridad y mecanismos para proteger los recursos de administración y los recursos Java EE confidenciales, así como para dar respuesta a los requisitos de seguridad de empresa de extremo a extremo para la autenticación, el control de acceso a los recursos, la integridad de los datos, la confidencialidad, la privacidad y la interoperatividad segura.

La infraestructura y los mecanismos de seguridad protegen los recursos Java EE (Java Platform, Enterprise Edition) y los recursos administrativos, respondiendo a los requisitos de seguridad de la empresa. A su vez, la infraestructura de seguridad de este producto funciona con la infraestructura de seguridad existente de la infraestructura de cálculo de empresa de varios niveles. Basado en una arquitectura abierta, este producto proporciona muchos puntos de plug-in para integrarse con componentes de software de empresa para proporcionar seguridad de extremo a extremo.

La infraestructura de seguridad incluye un modelo de programación y elementos de la arquitectura de producto que son independientes del tipo de aplicación.

Servicios adicionales para las aplicaciones

Nombres y directorios
Cada servidor de aplicaciones proporciona un servicio de nombres que, a su vez, proporciona un espacio de nombres JNDI (Java Naming and Directory Interface). El servicio se utiliza para registrar los recursos alojados en el servidor de aplicaciones. La implementación de JNDI se crea encima de un servicio de nombres CORBA (Common Object Request Broker Architecture) (CosNaming).

JNDI proporciona el acceso del cliente a los nombres y presenta el modelo de programación que utilizan los desarrolladores de aplicaciones. CosNaming proporciona la implementación del servidor y es donde se almacena realmente el espacio de nombres. JNDI proporciona básicamente una envoltura de cliente del espacio de nombres almacenado en CosNaming, e interactúa con el servidor CosNaming en nombre del cliente.

Los clientes del servidor de aplicaciones utilizan la arquitectura de nombres para obtener referencias a objetos relacionados con las aplicaciones. Los objetos se enlazan en una estructura principalmente jerárquica denominada el espacio de nombres. Está formada por un conjunto de enlaces de nombres, cada uno de los cuales es un nombre relativo al contexto específico y el objeto enlazado con ese nombre. Se puede acceder al espacio de nombres y manipularlo utilizando un servidor de nombres.

Este producto proporciona las siguientes características de nombres y directorios:
  • Espacio de nombres distribuido, para aumentar la escalabilidad
  • Particiones transitorias y persistentes, para el enlace en varios ámbitos
  • Estructura federada de espacios de nombres entre varios servidores
  • Enlaces configurados para definir enlaces enlazados por el sistema al iniciar el servidor
  • Soporte de URL de objetos INS (Servicio de nombres interoperativo) de CORBA

Tenga en cuenta que con la adición del gestor de miembros virtuales para proporcionar soporte de repositorio federado para la seguridad de producto, ahora el producto ofrece posibilidades de gestión de identidad más amplias y sofisticadas que nunca anteriormente, especialmente en combinación con otros producto de WebSphere y Tivoli.

ORB (Object Request Broker)
El producto utiliza un ORB para gestionar la interacción entre las aplicaciones cliente y las aplicaciones servidor, así como entre los componentes del producto. Un ORB utiliza IIOP para permitir a los clientes realizar solicitudes y recibir solicitudes de los servidores de un entorno distribuido de red.

El ORB proporciona una infraestructura a los clientes para localizar objetos de la red e invocar operaciones en estos objetos, como si los objetos remotos estuvieran ubicados en el mismo proceso de ejecución que el cliente, lo que supone una mayor transparencia de ubicación.

Aunque no se muestra en el diagrama, un lugar en el que el ORB entra en juego es el punto donde el contenedor de cliente está en contacto con el contenedor de EJB en nombre de un cliente Java.

Transacciones
El servicio de transacciones forma parte del servidor de aplicaciones. El producto proporciona posibilidades de realizar transacciones avanzadas para ayudar a los desarrolladores de aplicaciones a evitar la codificación personalizada. Proporciona soporte para los numerosos retos relacionados con la integración de los activos de software existentes en un entorno Java EE. Estas medidas incluyen ActivitySessions.

Las aplicaciones que se estén ejecutando en el servidor pueden utilizar transacciones para coordinar varias actualizaciones en recursos como una unidad de trabajo de modo que, todas o ninguna de las actualizaciones pasan a ser permanentes. Las aplicaciones o el contenedor en el que éstas se despliegan inician y detienen las transacciones.

El servidor de aplicaciones es un gestor de transacciones que permite coordinar los gestores de recursos y participa en las transacciones globales distribuidas con otros gestores de transacciones compatibles.

El servidor se puede configurar para que interactúe con bases de datos, colas JMS y conectores JCA mediante el soporte de transacciones locales cuando el soporte de transacciones distribuidas no sea necesario.

El modo en que las aplicaciones utilizan las transacciones depende del tipo de aplicación, por ejemplo:
  • Un bean de sesión puede gestionar las transacciones él mismo o delegar la gestión de las transacciones al contenedor.
  • Los beans de entidad utilizan transacciones gestionadas por contenedor.
  • Los componentes web, por ejemplo servlets, utilizan transacciones gestionadas por bean.
El producto maneja las transacciones con los componentes siguientes.
  • Un gestor de transacciones soporta la obtención de recursos XAResources recuperables y asegura que cada recurso se dirija a un resultado coherente, ya sea al final de una transacción o después de una anomalía y reinicio del servidor de aplicaciones.
  • El contenedor gestiona la obtención de XAResources en nombre de las aplicaciones desplegadas cuando realiza actualizaciones en gestores de recursos transaccionales por ejemplo bases de datos. De modo opcional, el contenedor puede controlar la demarcación de transacciones para aplicaciones EJB que tienen enterprise beans configurados para transacciones gestionadas por contenedor.
  • Una API maneja servlets y enterprise beans gestionados por bean, permitiendo componentes de aplicación de este tipo controlen la demarcación de sus propias transacciones.

Extensiones WebSphere

Las extensiones de modelo de programación de WebSphere son las ventajas del modelo de programación que se obtienen al adquirir este producto. Representan la tecnología líder que aumenta el rendimiento y las posibilidades de las aplicaciones, para que la programación y el despliegue sean más rápidos y productivos.

Además, las aplicaciones pueden utilizar la infraestructura de extensión de Eclipse. Las aplicaciones son ampliables en cuanto se define un punto de extensión y se proporciona el código de proceso de extensión para el área extensible de la aplicación. También puede conectar una aplicación a otra aplicación extensible definiendo una extensión que se ajuste a los requisitos de punto de extensión de destino. El punto de extensión puede buscar la extensión recién añadida dinámicamente y la nueva función se integra perfectamente en la aplicación existente. Funciona en módulos Java EE (Java Platform, Enterprise Edition) cruzados. El registro de extensión de aplicación utiliza el formato de descriptor de plug-in de Eclipse e interfaces de programación de aplicaciones (API) como mecanismo de extensión estándar para las aplicaciones WebSphere. Los desarrolladores que crean módulos de aplicaciones de WebSphere pueden utilizar las extensiones de WebSphere Application Server para implementar herramientas de Eclipse y para proporcionar módulos de plug-in para contribuir con la funcionalidad, por ejemplo acciones, tareas, elementos de menú y enlaces en puntos de extensión predefinidos de la aplicación WebSphere. Para obtener más información sobre esta característica, consulte Registro de extensión de aplicaciones.

Las diversas extensiones de modelo de programación de WebSphere y los servicios de aplicación correspondientes que las soportan en la ejecución del servidor de aplicaciones se pueden dividir en tres grupos: las extensiones del modelo de objeto de empresa, las extensiones del modelo de proceso empresarial y las extensiones para producir aplicaciones de próxima generación.

Extensiones pertenecientes al modelo de objeto de empresa

Las extensiones del modelo de objeto de empresa trabajan con objetos de empresa como, por ejemplo, las aplicaciones EJB (enterprise bean).
Perfilado de aplicaciones
El perfilado de aplicaciones es una extensión WebSphere que permite definir estrategias para controlar de forma dinámica la simultaneidad, la búsqueda previa y la lectura hacia adelante.

El perfilado de aplicaciones y el intento de acceso proporcionan un método flexible para ajustar con precisión el rendimiento de las aplicaciones de los enterprise beans sin afectar al código fuente. Distintos enterprise beans e incluso métodos distintos de un enterprise bean pueden tener su propio intento de acceso a recursos. La creación de perfiles de componentes a partir del intento de acceso aumenta el rendimiento en la ejecución del servidor de aplicaciones.

Consulta dinámica
La consulta dinámica es una extensión de programación de WebSphere que ofrece una flexibilidad de aplicaciones sin precedentes. Permite crear y someter de forma dinámica las consultas que seleccionan, ordenan, unen y realizan cálculos en los datos de aplicación en tiempo de ejecución. El servicio de consulta dinámica ofrece la posibilidad de pasar y procesar consultas de lenguaje de consulta EJB en tiempo de ejecución, eliminando la necesidad de codificar las consultas necesarias en descriptores de despliegue durante el desarrollo de las aplicaciones.

La consulta dinámica mejora los enterprise beans al permitir que el cliente ejecute consultas personalizadas en componentes EJB durante el tiempo de ejecución. Hasta ahora, las búsquedas de EJB y las correlaciones de campos se implementaban durante el desarrollo y necesitaban un reensamblaje o un desarrollo adicional para poder modificarlas.

Memoria caché dinámica
El servicio de memoria caché dinámica aumenta el rendimiento al colocar en memoria caché la salida de servlets, mandatos y archivos JSP. Este servicio del servidor de aplicaciones intercepta llamadas a objetos que se pueden almacenar en memoria caché y, o bien, almacena la salida del objeto en la memoria caché dinámica o bien presta servicio al contenido del objeto desde la memoria caché dinámica.

Como las aplicaciones Java EE tienen proporciones elevadas de lectura-escritura y pueden tolerar grados de latencia pequeños en la simultaneidad de los datos, la memoria caché dinámica permite aumentar considerablemente el tiempo de respuesta, el rendimiento y la escalabilidad del servidor.

Entre las características se encuentran la réplica de memoria caché entre clústeres, la descarga de disco de memoria caché, el almacenamiento en memoria caché de Edge Side Include, y el almacenamiento en memoria caché externa (la capacidad de controlar las memorias caché fuera del servidor de aplicaciones, por ejemplo, del servidor web).

Extensiones pertenecientes al modelo de proceso de empresa

Las extensiones del modelo de proceso de empresa proporcionan procesos, funcionalidad de flujo de trabajo y servicios para el servidor de aplicaciones. Utilícelas conjuntamente con las posibilidades de integración de empresa.
Sesiones de actividad
Las sesiones de actividad son una extensión de WebSphere que permite reducir la complejidad que supone trabajar con las reglas de confirmación y las limitaciones asociadas con los recursos de confirmación de una fase.

Las sesiones de actividad ofrecen la posibilidad de ampliar el ámbito de varias transacciones locales y agruparlas. Esto permite confirmarlas basándose en los criterios de despliegue o mediante una lógica explícita de programa.

Servicios Web
Los servicios web son aplicaciones autónomas y modulares que se pueden describir, publicar, localizar e invocar a través de una red. Implementan una arquitectura orientada a servicios (SOA), que soporta la conexión o la compartición de recursos y datos de un modo muy flexible y estandarizado. Los servicios se describen y se organizan para dar soporte al descubrimiento y la reutilización dinámica y automática.

Extensiones para crear aplicaciones de próxima generación

Las extensiones de próxima generación se pueden utilizar en aplicaciones que necesiten las extensiones específicas. Estas permiten un desarrollo de próxima generación al aprovechar las últimas innovaciones basadas en los estándares actuales de Java EE. De esta forma, se obtiene un mayor control que antes sobre el desarrollo, la ejecución y el rendimiento de las aplicaciones.
Beans asíncronos
Los beans asíncronos están en desuso y se sustituyen por Concurrency Utilities para Java EE.

Los beans asíncronos ofrecen mejoras de rendimiento para aquellas tareas que utilizan una gran cantidad de recursos, al permitir que se ejecuten tareas individuales como tareas múltiples. También se pueden utilizar las funciones de planificación asíncrona para procesar peticiones de proceso paralelo en "modalidad por lotes" en el tiempo designado. El producto da soporte completo a la invocación y la ejecución asíncrona de hebras y componentes del servidor de aplicaciones. El servidor de aplicaciones proporciona un contexto de ejecución y de seguridad para los componentes, convirtiéndolos en parte integral de la aplicación.

Beans de arranque
Los beans de arranque permiten la ejecución automática de la lógica empresarial cuando se inicia o se detiene el servidor de aplicaciones. Por ejemplo, se pueden utilizar para rellenar previamente las memorias caché específicas de la aplicación, para inicializar las agrupaciones de conexiones a nivel de aplicación o para realizar otros procedimientos de inicialización y terminación específicos de la aplicación.
Agrupaciones de objetos
Las agrupaciones de objetos proporcionan un medio más eficaz de aumentar el rendimiento de las aplicaciones en tiempo de ejecución, al permitir reutilizar varias instancias de los objetos. Esta reutilización reduce la carga adicional asociada con la creación de instancias, la inicialización y la recogida de basura de los objetos. La creación de una agrupación de objetos permite a una aplicación obtener una instancia de un objeto Java y devolverla a la agrupación cuando haya terminado de utilizarla.
Internacionalización
El servicio de internacionalización es una extensión de WebSphere para aumentar la productividad del desarrollador. Permite reconocer automáticamente el huso horario y la información de ubicación del cliente que realiza la llamada, para que la aplicación pueda actuar según corresponda. Esta tecnología le permite proporcionar a los usuarios de cualquier parte del mundo la información correcta de fecha y hora, la moneda y el idioma adecuados y los formatos correctos de fecha y decimales.
Planificador
El servicio de planificador es una extensión de programación de WebSphere responsable de iniciar acciones en intervalos u horas específicas. Permite minimizar los costes de IT y aumentar la velocidad y la capacidad de respuesta de las aplicaciones, al maximizar la utilización de los recursos existentes. El servicio de planificador ofrece la posibilidad de procesar las cargas de trabajo utilizando proceso paralelo, establecer transacciones específicas como de máxima prioridad y planificar las tareas menos dependientes del tiempo para que se procesen durante las horas de menos tráfico.
Áreas de trabajo
Las áreas de trabajo son una extensión de WebSphere para aumentar la productividad del desarrollador. Las áreas de trabajo proporcionan posibilidades muy parecida a las de las "variables globales". Proporcionan una solución para pasar y propagar información contextual entre componentes de aplicación.

Las áreas de trabajo permiten el compartimiento eficaz de información en una aplicación distribuida. Por ejemplo, es posible que desee añadir información de perfil mientras cada cliente entra en la aplicación. Al colocar esta información en un área de trabajo, estará disponible en toda la aplicación, lo que eliminará la necesidad de codificar una solución o leer y escribir información en una base de datos.


Icon that indicates the type of topic Reference topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=welc6productov
File name: welc6productov.html