WebSphere BPM y Lotus Webform Server
Visión general de HTML y la interacción de formularios
Siempre que una tarea humana sea incluida en un BPEL de larga duración, se necesita tomar una decisión con respecto a la tecnología que se utilizará en la prestación de esta tarea. El conjunto de WebSphere BPM brinda algunas opciones en la tecnología de user interface (UI): JSF, HTML simple y ahora una integración fuertemente acoplada a Lotus Forms.
Cada una de estas interfaces de usuarios puede ser integrada a Business Space y ser utilizada desde su interior pero la inclusión de Lotus Forms requiere que los usuarios implementen una nueva infraestructura que les dé soporte a los productos para implementar y ver estos formularios
En anteriores versiones de Lotus Forms los usuarios necesitaban instalar la aplicación de un cliente (Lotus Viewer) en cada una de las máquinas de los usuarios finales. Esto restringía a los usuarios a una cantidad limitada de plataformas desde las cuales se podía interactuar con Human Tasks – aquéllas soportadas por Lotus Viewer – y, sobre todo, a un conjunto de máquinas en las que se había instalado el visor.
Lotus Webform Server es una tecnología diseñada para eliminar esas restricciones y permitirles a los usuarios ver e interactuar con Lotus Forms desde un navegador.
En la aplicación SalesPromotion reside un proceso empresarial simple (BPEL) que contiene una única Human Task.
Figura 1. StorePromotions BPEL
La Human Task 'Approve Request' ya ha tenido un formulario creado para ella y esto se puede ver haciendo clic en el nombre Human Task en la sección de detalles. Se le mostrarán las configuraciones actuales para esta tarea. En este caso, la figura 1 muestra que una interfaz de usuario de Lotus Forms ha sido seleccionada.
Figura 2. Configuración de Human Task
Cuando 'Generate Human Task Interface' se selecciona desde el menú de contexto del módulo y el formulario es generado para 'Approve Request', un archivo 'xfdl' (Extensible Forms Description Language) será generado y ubicado en la carpeta del módulo. Cuando sea desplegado, el archivo de formularios (xfdl) será almacenado en la carpeta de WebContent (o el proyecto seleccionado de la Web).
Figure 3. Archivo NewPromotionForm xfdl en los recursos físicos
Este archivo, NewPromotion.xfdl, almacena todos los formularios de requisitos – en el caso de una aplicación de formularios múltiples – y estos formularios serán enviados a Webform Server. La tarea de Webform Servers, en este punto, es convertir el 'formulario' en HTML y devolverlo a Business Space para mostrarlo. Si usted tiene instalado Lotus Forms Designer, al abrir NewPromotionForm, éste le permitirá editar y adaptar el formulario.
Despliegue de Lotus Webform Server
Hay efectivamente dos opciones para desplegar Lotus Webform Server (WFS) para su uso con una topología de Business Process Management.
Local Deployment instala Webform Server en una celda de BPM existente. En este escenario, debido a la ubicación de la instalación de la aplicación proxy bSpaceWebformEnabler, es más fácil realizar la instalación en el mismo nodo físico que el cluster que contenga la aplicación Business Space.
Tabla 1. Reference Cluster Type para la ubicación de Webform Server
| Tipo de cluster | Ubicación |
|---|---|
| Mensajería remota/Soporte remoto (Oro) | Miembros del cluster de soporte |
| Mensajería remota (Plata) | Aplicación/Cluster de soporte |
| Cluster único (Bronce) | Cluster único disponible |
Aunque éste sea el tipo de instalación más sencillo, como no debe volver a ubicar la aplicación proxy, puede ser inapropiado debido a la carga creada en los nodos. Para los sistemas de alta performance sería más prudente instalar Webform Server en su propia celda, en nodos separados. A este tipo de instalación se lo denomina despliegue Distribuido.
Despligue local – en la misma celda
Figura 4. Despliegue Local en un cluster Remoto de Soporte de Mensajería Remota
Despliegue Distribuido – celda remota
Figura 5. Distributed Webform Server Cluster con el HTTP Server
En los dos tipos de despliegue se puede crear un único Webform Server o un cluster de servidores.
Con un solo servidor, usted corre el riesgo de crear tanto un cuello de botella como un único punto de falla para sus aplicaciones. Sin Webform Server, ningún formulario de Human Task será presentado y aunque esto no afectaría el motor de BPC en sí mismo, evitaría efectivamente que los usuarios interactúen con los procesos. Agrupar los Webform Servers reducirá en forma efectiva el potencial cuello de botella y eliminará el único punto de falla.
Para crear el cluster de Webform Server, la aplicación de Translator Server necesita ser instalada en una máquina utilizando el procedimiento de instalación estándar, ya sea mediante el despliegue de la aplicación y el Application Server suministrado, o desplegando la aplicación Translator Server en un Application Server desplegado.
El Application Server que aloja la aplicación Translator Server debe estar federado en Webform Cell.
En el segundo nodo, el que debe ser un nodo del Application Server ya federado en Webform Cell, los binarios del Webform Server deberían estar instalados. La aplicación del Translator Server no debería ser desplegada en el Application Server en este momento, como se puede ver en la Figura 4. Esto se logrará con la creación del cluster.
Figura 6. Deplegar el Translator Server
Para agrupar los servidores desde la consola de admin seleccione Servers > Clusters > WebSphere Application Server Cluster y cree un nuevo cluster, como se muestra en la figura 7.
Figura 7. Crear un cluster del Webform Server
Ingrese el nombre del cluster y deje las configuraciones por omisión. En la siguiente pantalla, en la figura 8, seleccione create the member using an existing application server as a template y seleccione el Translator Server que se creó originalmente.
Esta opción tendrá un Application Server existente como base para otros nodos en el cluster. Cualquiera de las aplicaciones y/o de los recursos configurados en el Application Server existente será creado en el cluster y en consecuencia será transferido a los nuevos miembros del cluster cuando estos sean agregados.
Figure 8. Crear un formulario de cluster desde un servidor existente
En la pantalla Add Member, figura 9, seleccione el segundo Application Server que no tenga la aplicación del Translator Server desplegada en él y haga clic en Next. Esto creará un nuevo miembro de cluster, y transferirá las aplicaciones y los recursos desplegados del Application Server existente al nuevo miembro.
Figura 9. Miembros adicionales
Usted ahora tiene un cluster de dos Application Servers, cada uno con un TranslatorServer desplegado desde el cual los formularios pueden ser presentados.
El servlet bSpaceWebFormEnabler es el proxy a través del cual Business Space se comunicará con Lotus WebForm Server. Se trata de una aplicación simple que debe ser desplegada en el lugar en el que se instalen los binarios del WebForm Server a medida que se requiera el acceso a estas bibliotecas.
Existen dos puntos de configuración para permitirle a Business Space interactuar con WFS:
- Configurar la ubicación de bSpaceWebformEnabler
- Configurar bSpaceWebformEnabler para indicar la ubicación de WebForm Server
La URL por omisión definida para bSpaceWebformEnabler utiliza el nombre de host 'localhost', por lo tanto si WFS está instalado en forma local al miembro del cluster en el que se instale bSpacewebformEnabler, entonces ningún cambio será necesario.
Para cambiar el valor, seleccione Resource Environment Provider > Mashup EndPoints > Custom Properties, y altere la entrada {com.ibm.bspace}bspaceWebformProxyRootId.url, como lo indica la figura 10.
Figura 10. Modificar la URL raíz Proxy
Si el bSpaceWebformEnabler es instalado en un servidor que no sea Webform Server, el parámetro servlet bSpaceWebformEnabler, 'translatorLocation', necesita ser alterado para reflejar esto, como se puede observar en la figura 11. Tenga en cuenta que el puerto normalmente no debería ser diferente al valor por omisión 8085.
Figura 11. Configuración del facilitador de Webform Proxy
En la configuración para translatorLocation, una única URL es configurada. Esto significa que incluso si un cluster es configurado para la aplicación TranslatorServer, el servlet proxy accederá únicamente a uno de ellos, lo que quiere decir que no tenemos una funcionalidad real de High Availability (HA) en la operación.
Para mejorar esta situación, un servidor HTTP o un IBM Proxy Server debería ser configurado y colocado frente al cluster. La URL en 'translatorLocation' debería entonces ser configurada para indicarle a este servidor un puerto asociado.
Un Proxy Server será el más fácil de configurar, ya que está incorporado al Application Server. A diferencia de un servidor HTTP, el Proxy Server posee una lista de aplicaciones dinámicas que no requieren ningún plug-in para ser generados y distribuidos manualmente.
El patrón de instalación utilizado para WebForm Server depende de los requisitos del proyecto y de la disponibilidad de los recursos necesarios.
Un entorno distribuido, por el cual Lotus Webform Server es remoto, ofrece la mejor demarcación de las preocupaciones, y permite crear programas de mantenimiento por separado.
Las instalaciones locales, en las que WebForm Server es instalado en forma local al WPS Cluster, pueden tener un efecto perjudicial sobre el cluster de WPS con una carga adicional que se coloca en los servidores. Una instalación local también significa que WebForm Server se vería afectado cuando el mantenimiento se realice en el Application Server.
Si High Availability es un requisito, entonces un cluster de WebForm Servers debería ser desplegado y un HTTP Server o un IBM Proxy Server debería ser configurado para permitir el equilibrio de la carga a través de los miembros de los clusters.
Aprender
- En SOA and web
services area on
developerWorks, obtenga los recursos necesarios para mejorar sus aptitudes.
- Manténgase actualizado con developerWorks technical events
and webcasts que se centran en una variedad de productos de IBM y en los temas correspondientes a la
industria de IT.
- Asista a free developerWorks Live!
briefing para ponerse rápidamente al tanto de los productos y de las herramientas de IBM así
como también de las tendencias de la industria de IT.
- Siga developerWorks on
Twitter.
- Observe developerWorks on-demand demos
que van desde la instalación de los productos y la demostración de las configuraciones para principiantes hasta
la funcionalidad avanzada para desarrolladores experimentados.
Obtener los productos y tecnologías
-
Evaluate IBM products del modo que
más le convenga: baje el producto de prueba, pruebe un producto en línea,
utilice un producto en un entorno en nube, o dedíquele unas pocas horas a SOA Sandbox conocer cómo
implementar Service Oriented Architecture en forma eficiente.
Comentar
- Involúcrese con la My developerWorks community.
Conéctese con otros usuarios de developerWorks mientras explora los blogs, foros, grupos y wikis
impulsados por los desarrolladores.