Diseño de las soluciones del WebSphere Process Server: Parte 1

Aspecto de las soluciones del WebSphere Process Server

Este artículo describe cómo diseñar soluciones basadas en service-oriented architecture (SOA) utilizando WebSphere Process Server y WebSphere Enterprise Service Bus. La Parte 1 de esta serie de artículos analiza de qué modo las técnicas de diseño cambian a medida que madura SOA.

Kim J. Clark, Consulting IT Specialist, IBM

Photo of Kim J. ClarkKim Clark es un IT Specialist del Reino Unido que trabaja en IBM Software Services for WebSphere (ISSW). Ha trabajado en la industria informática desde 1993 y fue jefe técnico de diversos proyectos desde las primeras implementaciones de WebSphere Process Server. Asimismo, escribe artículos y realiza presentaciones sobre diseño de SOA. Se graduó en Física en la Universidad de Londres.


Nivel de autor contribuyente en developerWorks

Brian M. Petrini, Senior IT Architect, IBM

Author photoBrian Petrini se desempeña como Integration Architect and Consultant en IBM Software Services for WebSphere (ISSW). Se especializa en WebSphere Process Server, WebSphere Enterprise Service Bus, WebSphere Adapters y WebSphere InterChange Server. Trabaja con implementaciones de productos de integración desde 1999 y publica artículos y realiza presentaciones sobre mejores prácticas. Es ingeniero en electricidad e informática.



28-07-2011

Introducción

Este artículo es el primero de una serie que analiza el modo de diseñar soluciones utilizando WebSphere Process Server (de aquí en adelande denominado Process Server) y WebSphere Enterprise Service Bus (WESB). Dicho artículo se centra en los diferentes usos de Process Server en las distintas etapas de madurez de una arquitectura orientada al servicio. Para ilustrar la vista de alto nivel de los diseños, utilizamos las nuevas vistas de soluciones en WebSphere Integration Developer.

El artículo forma parte de una serie que abarca los aspectos principales del diseño de las soluciones de Process Server. El contenido de los demás artículos de esta serie se detalla al final de este artículo.


¿Cómo cambia la "integración" a medida que la arquitectura se transforma en SOA?

La creación de una service-oriented architecture (SOA) nunca consta de un solo paso. Se trata de una maduración progresiva en la cual cada nivel de maduración se basa en el último. Algunas de las principales razones de que esto sea así son las siguientes:

  • Muy rara vez, si es que lo hace, usted crea una arquitectura desde cero, implementando una arquitectura idealizada en una implementación. La infraestructura, los paquetes, y las aplicaciones heredadas ya se encuentran instalados y usted los utiliza como punto de partida.
  • Ningún proyecto puede abarcar el costo y el tiempo necesarios para madurar una arquitectura significativamente. Éste requiere la vasta influencia de un programa a más largo plazo.
  • No todas las partes de la arquitectura de la aplicación se prestan al rigor que requiere una SOA bien administrada. Algunas partes pueden madurar más lentamente. En un determinado momento, la arquitectura consistirá de una mezcla del antiguo estilo arquitectónico con el nuevo .

Usted no crea una SOA, la desarrolla. Cada etapa de la evolución necesita tiempo para madurar y afirmarse.

¿Por qué es esto importante para Process Server? Bueno, muchos productos juegan su papel principal en la maduración de una SOAS. Process Server no es común en este sentido porque aloja una gran variedad de capacidades que son importantes en muchas etapas del desarrollo. Para comprender cómo utilizar Process Server de manera eficaz, usted necesita entender cuales son las partes del producto y cuál es el modo de uso adecuado para cada nivel de madurez.

A continuación, analizaremos un mecanismo estandar para medir el nivel de madurez actual y cuál es el esperado de una empresa, y luego analizaremos cómo utilizar Process Server en cada nivel.


El Service Integration Maturity Model

El Service Integration Maturity Model (SIMM), presentado en el gráfico 1, constituye una forma aceptada de representar las etapas a través de las cuales la arquitectura y la empresa en general se mueven progresivamente hacia una SOA.

Gráfico 1. Representación esquemática de SIMM
Gráfico 1. Representación esquemática de SIMM

Es importante comprender en qué lugar de esta escala se encuentra la organización, y a qué parte de la escala está apuntando la misma antes de decidir qué iniciativas, y por lo tanto qué software, usted necesitará implementar para influir en el cambio.

Continuemos para ver qué forma toma todo esto en las soluciones de Process Server.

Para terminar el tema de SIMM, este artículo se centra en una pequeña parte de SIMM - las capas de arquitectura y aplicaciones - y específicamente los aspectos del middleware de integración. SIMM tiene un alcance mucho más amplio. si desea tener una visión más completa, consulte la sección Recursos que se encuentra al final de este artículo.


¿Cuándo entran en juego Process Server y WESB en el modelo de la madurez?

Ahora que tiene conocimiento sobre los niveles graduales de la madurez, consideremos las capacidades básicas de Process Server y de qué forma estas se relacionan al modelo SIMM. La Figura 1 señala los diferentes tipos de soluciones que se utilizan en los distintos niveles de la madurez

Figura 1. Diferentes tipos de soluciones
Tipo de soluciónDescripciónRelación con SIMMComponentes de Process Server relacionados
Bajo nivel de conectividad Trasportes nativos, formatos de datos, APIs Nivel 2
  • Adaptadores
  • Enlaces de Exportación/Importación
  • Controladores de datos
Integración basada en concentrador Resistencia, consumibilidad y granularidad mejorada. Concentrador y radio. Nivel 3 Componentes de flujo de mediación
Exposición del servicio Protocolos estandarizados, formatos de datos, contratos del servicio, y directivas Nivel 4
  • Enlaces de exportación/importación
  • Registro del servicios
  • Gateway de servicios
Servicios compuestos y automatización de procesos empresariales Orquestación y coreografía de servicios maduros Nivel 5 Business Process Choreographer (BPC) - por ejemplo, el motor Business Process Execution Language (BPEL) en Process Server.
Flujo de trabajo y soluciones basadas en tareas Distribución de trabajo a través de tareas Varios, ver en detalle más adelante. Tareas humanas y BPC

Repasemos los niveles de madurez y analicemos cada una de las soluciones en detalle.


¿Qué forma toman los diferentes niveles de madurez en las soluciones de Process Server?

En las siguientes secciones se analiza la forma que podrían tomar las soluciones de Process Server al tratar de lograr los objetivos de cada nivel de madurez.

Bajo nivel de conectividad - Nivel SIMM 2

Estas soluciones proporcionan conectividad a los sistemas back end directamente utilizando un código o una configuración adicional a través de sus transportes nativos, APIs, y formatos de datos. Las organizaciones comienzan a desarrollar esta capacidad en el nivel SIMM 2. En primer lugar, ingresan el código de conectividad en sus aplicaciones back end y luego utilizan los adaptadores empaquetados. Por lo general, este área de la tecnología es bien comprendida en la actualidad: posee una combinación de APIs suministrada por sistemas empaquetados, adaptadores productizados para plataformas de back end comunes, y controladores de datos para formatos de datos establecidos, como por ejemplo un bloc de notas COBOL.

Figura 2. Conectividad punto a punto
Conectividad punto a punto

Sin embargo, toda la comunicación es punto a punto como puede observarse en la Figura 2. A medida que se incorporan más solicitantes y proveedores, cada vez es necesario ingresar más código de conectividad, lo cual se torna rápidamente insostenible.

Integración basada en concentrador (básica) - Nivel inferior SIMM 3

El uso más sencillo posible de Process Server o WESB consiste en un concentrador que conecta a los solicitantes con los proveedores cuando no es posible que estos tengan una tecnología común de conectividad. La presencia de un concentrador marca el inicio del nivel SIMM 3.

Este uso puede implementarse exclusivamente en WESB dado que incluye sólo un componente de flujo de mediación y WebSphere Adapters, como se puede observar en la Figura 3. En este nivel de madurez, usted por lo general encuentra adaptadores de cada lado, ya que se supone que ni los solicitantes ni los proveedores pueden realizar la conectividad de manera implícita con los estándares comunes. Esto significa que la solución depende de estos solicitante y proveedor específicos, y que la reutilización requiere como mínimo adaptadores y mapas adicionales.

Figura 3. Solución para un escenario básico de integración - un único componente de flujo de mediación
Solución para un escenario básico de integración - un único componente de flujo de mediación

Por cada solicitud realizada en la exportación de la izquierda, llega una sola solicitud a la importación y al proveedor de la derecha. La única tarea de Process Server aquí es proporcionar un bajo nivel de conectividad de manera que el solicitante pueda comunicarse con el proveedor. Los adaptadores están realizando la mayor parte del trabajo duro de integración.

Figura 4. Interior del componente de flujo de mediación de la Figura 3
Interior del componente de flujo de mediación de la Figura 3

El componente de flujo de mediación (Figura 4) realiza un mapeo entre el modelo de datos del solicitante y el del proveedor, y quizá realice además algunos registros a efectos de diagnóstico o de auditoría.

Nota: Si bien nosotros sólo estamos haciendo conectividad uno a uno, no podemos describir esto como "punto-a-punto"(por ejemplo, nivel SIMM 2). El hecho de que haya un concentrador presente no sugiere de ninguna manera que este sea un nivel SIMM 3 dado que ya hemos tenido algunas oportunidades para reutilizar la integración. El nivel 2 puro consiste en un código personalizado ya sea que se encuentre dentro o cerca de las aplicaciones del solicitante/ proveedor.

Integración basada en concentrador (avanzada) - Nivel Superior SIMM 3

La integración simple se torna rápidamente insuficiente. Es necesario aplicar patrones adicionales de integración a la conectividad de nivel bajo para lograr que la interfaz del sistema back end sea generalmente más resistente, consumible, y que tenga la granularidad adecuada para su reutilización.

La presencia de múltiples solicitantes o proveedores conectados a través de un concentrador forma un patrón arquitectónico concentrador y radio identificable (Figura 5), que es común en soluciones más avanzadas de nivel SIMM 3. Esto principalmente se realiza a través de flujos de mediación, aunque en algunos casos, pueden utilizarse los procesos de BPEL. Generalmente, los solicitantes y los proveedores se conectan por medio de adaptadores.

Figura 5. Solución concentrador y radio
Solución concentrador y radio

Resulta tentador pensar que si el protocolo utilizado para exponer a los solicitantes fuera un protocolo estandar, como por ejemplo HTTP/SOAP o HTTP/REST, habríamos pasado inmediatamente al nivel SIMM 4 suministrando un servicio expuesto aparentemente reutilizable. Veremos en la sección sobre exposición del servicio que esto no es tan sencillo.

Este diagrama de simple lectura (Figura 5) esconde algunas variantes. Veamos cada una por separado un momento:

  • Router: cada solicitante es ruteado a un proveedor específico por una solicitud realizada.
  • Traductor: varios solicitantes son configurados de manera que sus solicitudes sean ruteadas a proveedores particulares por cada solicitud.
  • Composición de bajo nivel: cada solicitante realiza una solicitud utilizando varios proveedores. Tenga en cuenta que esto es diferente de la composición de servicio que discutiremos más adelante. Aquí estamos creando soluciones de composición utilizando las interfaces tradicionales de bajo nivel de sistemas back end en lugar de servicios maduros.

Las combinaciones mencionadas también son posibles y comunes. Varios solicitantes pueden tener sus llamadas traducidas y luego ruteadas a diferentes componentes que realizan una composición de bajo nivel adecuada para completar la interacción.

Piense de qué formas diferentes podría subdividirse la solución para cada uno de los casos antes mencionados. En primer lugar, veamos el router presentado en la Figura 6.

Figura 6. Solución del router básico
Solución del router básico

Tenemos más de un proveedor, y podemos utilizar un componente de flujo de mediación para elegir entre ellos. El flujo de mediación podría utilizar un filtro de mensajes para realizar, por ejemplo, un ruteo basado en el contenido o en el encabezado, como se observa en la Figura 7. Una vez que el proveedor ha sido seleccionado, se realiza una transformación específica de los datos para adaptarla al modelo de datos del proveedor.

Figura 7. Router Básico - primitivos de mediación dentro del componente de flujo de mediación de la Figura 6
Router Básico - primitivos de mediación dentro del componente de flujo de mediación de la Figura 6

Ahora comparemos este con el traductor(Figura 8). Este administra solicitudes de dos fuentes diferentes y las traduce de manera que pueden llamar al mismo proveedor de back end.

Figura 8. Traductor básico
Traductor básico

Tenga en cuenta que hemos utilizado dos componentes de flujo de mediación diferentes para cada una de las dos rutas. Es posible hacer todo esto en un único componente de flujo de mediación. Dado que dos rutas de entrada distintas son por lo general diferentes en cuanto al carácter, es mejor mantenerlas por separado. De esta forma, pueden desarrollarse y mantenerse de forma independiente y sus responsabilidades están claras. Como podrá observar más adelante, si su interacción es más compleja, es posible que puedan tener sus propios módulos.

Es interesante combinar los estilos traductor y router (Figura 9). Recuerde que cada solicitante posee su propio modelo de datos, al igual que los proveedores. Desde el punto de vista simplista, por cada solicitante, se debe mapear el modelo de datos del solicitante a cada uno de los proveedores. Si hay muchos proveedores, será necesario crear un número creciente de manera exponencial de mapas -desastre similar al que tratamos de evitar en el nivel SIMM 2. No estamos aprovechando al máximo los beneficios de tener un concentrador central porque no hemos incorporado un modelo de datos central ni canónico.

Figura 9. Solución combinada traductor/router (ver la Figura 9 ampliada)
Solución combinada traductor/router (ver la Figura 9 ampliada)

En el ejemplo anterior, los componentes de flujo de entrada de mediación se traducen al modelo de datos canónico, luego el componente de flujo de mediación del router realiza traducciones reutilizables para cada uno de los modelos de datos de los proveedores. El modelo de datos canónico implica menos mapas que escribir, y además si el modelo de datos del solicitante o del proveedor cambiara, sólo se vería afectado el mapeo específico hacia o desde el modelo canónico.

Pasemos ahora a la composición (Figura 10). Usted necesita algo para reunir varias solicitudes con los sistemas back end.

Figura 10. Composición mediante un proceso BPEL (ver la Figura 10 ampliada)
Composición mediante un proceso BPEL (ver la Figura 10 ampliada)

Es posible realizar cierto nivel de agrupación de invocaciones en los proveedores utilizando un componente de flujo de mediación y uno o más primitivos de invocación de servicios, y en los casos simples, Estaa puede ser la solución correcta. Esta resulta razonable si la lógica a aplicar representa claramente la lógica de la integración, como por ejemplo el enriquecimiento de datos o la agrupación simple. El uso de mediaciones puede tener ventajas de performance si usted mantiene el formato XML de los datos y obtiene los beneficios de las transformaciones XSLT sin realizar el análisis sintáctico de los objetos. Sin embargo, aún cuando la composición presentara un nivel de complejidad muy bajo de repente puede resultar preferible recurrir a las capacidades de BPEL. Por ejemplo, si usted necesita una lógica condicional más compleja, un flujo cíclico, capacidades compensatorias, persistencia de estado, o interacción humana en proceso. En estos casos, utilice BPEL para la solución, especialmente si el proceso resulta de interés para la empresa desde el punto de vista de la supervisión.

Si se utiliza BPEL, es importante hacerlo para que BPEL controle los pasos de alto nivel, y no como parte de un lenguaje de codificación visual para realizar la lógica de bajo nivel. Esta es la razón por la cual hemos conservado los componentes de flujo de mediación al lado de los adaptadores en la Figura 10. Esto asegura que toda la lógica de integración posible sea extraída del proceso BPEL. Recuerde que uno de los beneficios de BPEL es su visualización, tanto al momento del desarrollo como de la ejecución. Si algo parece complicado al hacer esto en BPEL, entonces probablemente necesite sacar ese detalle afuera, hasta la mediación, o quizá hasta la aplicación del proveedor.

Es interesante ver si esta solución que utiliza BPEL es diferente de las soluciones que usan BPEL en el nivel SIMM 5, donde los servicios son más maduros. Una de las cuestiones principales es que las interfaces de los proveedores aquí no han madurado ni han sido expuestas correctamente, será mucho más complicado aplicar la lógica de integración. Dado que esta integración de bajo nivel es compleja, es probable que esta solución sea más costosa y su implementación lleve más tiempo que una solución equivalente de nivel 5. Esta es, por supuesto, la razón por la cual se desea madurar los servicios en la arquitectura en la etapa siguiente.

Nota: Hemos analizado la madurez del servicio, y aún así apenas hemos mencionado el término servicio. Esto es importante y completamente adrede. Hay mucho trabajo previo por realizar si se desea mejorar la integración y también la comprensión de las principales funciones reutilizables de la empresa antes de comenzar a hablar sobre la exposición de los servicios.

Exposición del servicio - nivel SIMM 4

Cuando una SOA alcanza el nivel SIMM 4, surgen varias empresas y funciones técnicas claves como candidatos para la reutilización. En primer lugar, pueden ser reutilizables dentro del departamento de IT, pero algunas tienen mayor posibilidad en el nivel de la empresa, o incluso en Internet. El nivel SIMM 4 se trata del modo en el cual se reciben los servicios (el cual se encuentra fuera del alcance de este artículo - ver Service-oriented modeling and architecture), y desde el punto de vista técnico, la forma en la cual se expone el servicio, tema principal de esta sección. Al hablar de la exposición del servicio, nos referimos a las interfaces que utilizan protocolos, formatos de datos, contratos de servicios, y políticas estándares para permitir una amplia reutilización a través de diversas aplicaciones del consumidor.

Entonces, ¿cuál es el gran desafío que representa la exposición de un servicio para su reutilización? Hemos mencionado ya que la elección de un protocolo estándar interoperable, como por ejemplo SOAP/HTTP o REST/HTTP, es solamente una parte de lo que implica "exponer" un servicio. ¿Qué más se puede hacer?

Para exponer un servicio de manera útil, éste debe ser al menos: valioso, sólido, confiable, rendidor, útil, supervisable, mantenible y seguro. Analizaremos estas cualidades mucho más en detalle en otros artículos. Por ahora, usted necesita reconocer que la mayoría de las interfaces anteriores a esta etapa fueron desarrolladas para un fin y un solicitante específicos, y por lo tanto presentamos sólo una pequeña selección de las cualidades antes nombradas. Estas responden a cualidades necesarias para una solución específica en lugar de considerar todos los posibles consumidores de un servicio. La estandarización de estas cualidades es fundamental para la exposición del servicio, y por lo tanto para el nivel SIMM 4.

Veamos brevemente cómo y dónde pueden diseñarse estas capacidades en una solución.

Figura 11. Exposición de los servicios
Exposición de los servicios

Cuatro cosas han cambiado a medida que progresamos desde la arquitectura del concentrador y radio previos hasta la exposición del servicio, tres de las cuales pueden observarse en la comparación de la figura anterior con la Figura 11.

  1. Exposición estandarizada: Los solicitantes ya no necesitan un conector para hablar al concentrador, ya que han convenido protocolos y transportes interoperables estándares, como SOAP/HTTP o REST/HTTP.
  2. Administración de solicitudes estandarizadas: Hemos dedicado una parte del concentrador, denominada ESB Gateway, la cual realiza las capacidades de virtualización orientada al aspecto, la seguridad, la visibilidad, y la administración del tráfico necesarias para la exposición madura de servicios.
  3. Registro del servicio: Se ha incorporado un registro del servicio porque usted necesita el servicio de publicación de manera que los solicitantes puedan encontrar dicho servicio. La línea de puntos representa el registro que se usó inicialmente se utilizó al momento del desarrollo y no de la ejecución.
  4. Integración específica de la operación para mejorar la consumibilidad: El cuarto cambio no se puede ver en la Figura 11 porque se trata de un cambio en la tarea del concentrador, pero el concentrador ya se encontraba allí. La parte del concentrador que no es "ESB Gateway" estaba realizando la lógica de integración más profunda y específica de la operación, y todavía lo sigue haciendo. Mientras que antes sólo se realizaba la lógica mínima requerida por los solicitantesconocidos, ahora se realiza cualquier lógica razonable que hace que este servicio sea más consumible para cualquier solicitante. Esto podría incluir la granularidad del control de errores, la administración de solicitudes duplicadas, la administración de los reintentos, los tiempos de inactividad programados, las sutilezas de la conexión compartida, y mucho más. Estos son los mismos patrones de integración que utilizamos en el nivel SIMM 3. La cuestión es que usted está atendiendo a más consumidores, por lo tanto tiene más requisitos, y por consiguiente hay más trabajo de integración por realizar.

Veamos cómo implementar esto en una solución de Process Server.

Figura 12. Diagrama de soluciones para las interfaces expuestas a través del gateway de servicios (ver la Figura 12 ampliada)
Diagrama de soluciones para las interfaces expuestas a través del gateway de servicios (ver la Figura 12 ampliada)

¿Qué cambios se observan en la Figura 12? Cada parte de la solución es diferente internamente, por lo tanto analicemos la figura en detalle de izquierda a derecha.

  • Protocolo/transporte estándar para la exposición: hemos elegido un modo estandarizado de realizar el llamado del servicio. En este caso, ServiceExport1 es una exportación de servicio web. La mayoría de los sistemas modernos pueden llamar a servicios web, y WSDL es una manera reconocida de compartir la definición, ya sea en un registro, o directamente. El servicio es fácil de buscar y llamar.
  • Administración estandarizada de solicitudes: Hemos incorporado un componente de flujo de mediación especial denominado gateway de servicios.
  • Este es similar al flujo de mediación normal, pero permite definir la lógica de integración que será utilizada en todas las solicitudes, más allá del hecho de que puede tratarse de operaciones diferentes. Esto facilita la realización de las capacidades "orientadas al aspecto" que usted necesita para que los servicios se comporten adecuadamente como parte de una SOA gobernada. Este componente es responsable de:
    • Exponer el servicio de manera segura (encriptación, administración de identidades, autorización, etc.)
    • Hacerlo visible (registro, auditoría, control, etc.)
    • Hacerlo sostenible (virtualizado, versionado, configurable, etc.)
    • Administrar el tráfico (regulación, equilibrio de carga, ruteo, etc.)

La Parte 2 de esta serie de artículos le mostrará más detalles sobre la forma en la cual se logran estas capacidades orientadas al aspecto.

  • La integración específica de la operación para mejorar la consumibilidad: Existen componentes de flujo de mediación específicos para cada operación con los proveedores back end. En estos, usted implementa la lógica de integración específica de la operación necesaria para resolver las diferencias entre las características de los proveedores y aquellas del servicio expuesto deseado.

Nota: Es complicado llegar a un acuerdo sobre las definiciones del propósito y los límites de un ESB. Un ESB es un concepto arquitectónico, y por lo tanto no existe de manera independiente dentro de ningún componente concreto en el diagrama presentado en la Figura 12. Una capacidad concreta es el componente gateway de servicios, el cual es muy importante para el patrón ESB. La puerta de enlace del servicio permite exponer los servicios empresariales maduros de una forma estandarizada y gobernada. Es uno de los principales factores que extiende y diferencia la exposición del servicio (nivel SIMM 4) de la integración más tradicional, como concentrador y radio (nivel SIMM 3).

Servicios compuestos y automatización del proceso empresarial- nivel SIMM 5

De la etapa anterior, pasamos ahora a algunos de los servicios completamente maduros y consumibles (Figura 13). El próximo paso lógico es ver dónde estos son utilizados en los patrones comunes de sus procesos diarios. Al hacerlo, usted tiene la oportunidad de unirlos para formar nuevos servicios compuestos que orquesten o coreografíen los servicios de niveles más bajos. Esto además mejora la madurez del SOA, suministrando servicios más eficaces a los consumidores.

Figura 13. Soluciones basadas en servicios compuestos
Soluciones basadas en servicios compuestos

Desde el punto de vista simplista, por ahora, dividiremos los servicios básicos en los tipos:

  • Un servicio compuesto básico no es más que el conjunto de solicitudes de servicio utilizadas comúnmente para formar una única solicitud de servicio. Todas las solicitudes de servicio son probablemente sincrónicas y se completan dentro de un período de tiempo razonable (por ejemplo, segundos o menos). Estas por lo general son implementadas por medio de un proceso BPEL de corta ejecución.
  • Algunos servicios compuestos son creados inevitablemente para administrar los procesos que abarcan un período de tiempo mucho más largo que quizá lleve días o incluso semanas. Es probable en estos casos que la visibilidad de la ubicación dentro de los pasos de la solicitud sea importante para la empresa. Estos son, conocidos más claramente bajo la etiqueta de Procesos empresariales. Y por lo general son implementados en los procesos BPEL que se están ejecutando, y pueden involucrar interacción humana en la forma de Human Tasks en el proceso.

Más allá del tipo de solución, esta se verá similar a la de la Figura 14.

Figura 14. Módulo basado en el proceso o en la composición
Módulo basado en el proceso o en la composición

Hay más para decir sobre los diferentes tipos de soluciones de procesos. De hecho, lo haremos en los artículos que publicaremos más adelante sobre los tipos de implementaciones de procesos.

Veamos una solución más avanzada de Process Server que incluye algunas operaciones que son expuestas de forma adecuada a través de una gateway de servicios y que son, de por si, llamados compuestos a los sistemas back end.

Figura 15. Diagrama de la solución que incluye operaciones expuestas de servicio compuesto (ver Figura 15 ampliada)
Diagrama de la solución que incluye operaciones expuestas de servicio compuesto (ver Figura 15 ampliada)

En la Figura 15, usted puede observar que las dos operaciones de servicio separadas son expuestas a través de una gateway de servicios. El gateway realiza todas las capacidades orientadas al aspecto mencionadas más arriba para exponer las operaciones del servicio, luego rutea las solicitudes, según la operación llamada, a módulos separados. Estos módulos basados en procesos realizan los servicios compuestos, coreografiando múltiples llamadas a múltiples sistemas potencialmente back end utilizando BPEL. Como podrá apreciar, las importaciones a la derecha de los módulos del procesos ya no son adaptadores, ya que estamos llamando a servicios maduros, probablemente relacionados con servicios web. También podrá notar la ausencia de componentes de flujo de mediación en los módulos del proceso. Este no es el motivo por el cual no se puede tenerlos en el mismo módulo. A partir de WebSphere Process Server v6.2, es posible tener procesos y componentes de flujo de mediación en el mismo módulo. La razón de esto es, de nuevo, que asumimos que usted está coreografiando servicios maduros y no hay, por lo tanto, necesidad de ninguna lógica de integración compleja. Contamos con un mapa de interfaz simple con mapas de objetos empresariales subyacentes para traducir entre el modelo de datos utilizado en el proceso, y el modelo de datos de los servicios que estamos coreografiando.

Por lo tanto, lo ideal es que sólo se coreografíen servicios maduros para evitar que la lógica de integración desordene o restrinja los procesos empresariales. De esta forma se obtienen beneficios más significativos del proceso de automatización, y es por esto que lo mejor utilizar en el nivel SIMM 5 los servicios maduros de nivel 4. Tenga en cuenta que rara vez las interacciones requeridas para un proceso son servicios maduros y muy expuestos cuando simplemente se alcanza este nivel de madurez. Por lo tanto, es común ver que los procesos realicen una combinación de solicitudes a servicios maduros e interfaces tradicionales. Es necesario asegurarse de que estas interfaces tradicionales se desacoplen correctamente del proceso empresarial para mejorar el mantenimiento y la reutilización.

Flujo de trabajo y soluciones basadas en tareas

El flujo de trabajo es una categoría especial en lo que respecta a la madurez de integración de los servicios ya que no se vincula de forma innata a la integración. El flujo de trabajo hace referencia a los sistemas que permiten una distribución eficaz del trabajo entre equipos de personas dividiendo el trabajo en tareas, y automatizando la distribución y el progreso de dichas tareas (Figura 16).

Figura 16. Solución de sólo tareas - sin requisitos de integración
Solución de sólo tareas - sin requisitos de integración

Esto parece no corresponder al SIMM. En primer lugar, no requiere necesariamente una integración directa con sistemas de back end, ya que la tarea del usuario podría consistir en realizar una llamada telefónica o un trámite administrativo. Los sistemas back end por lo general se utilizan para algunas de las tareas, pero el sistema de flujo de trabajo no necesariamente debe integrarse a estos back end. El usuario puede pasar de su escritorio a una terminal mainframe para realizar la tarea, y luego volver al escritorio. Algunos productos, como IBM MQ Workflow y los que le siguen, han sobrevivido como sistemas independientes durante décadas, cuando las compañías todavía se encontraban en el nivel SIMM 1, y han alcanzado un alto nivel de sofisticación de manera simultánea a los conceptos arquitectónicos, como por ejemplo SOA.

Sin embargo, esta evolución hacia las arquitecturas orientadas a los servicios generó nuevas posibilidades para el flujo de trabajo, y muchas empresas comenzaron a aplicar la automatización de procesos de forma gradual, permitiendo así que algunas tareas sean tareas del "sistema" (servicios) en lugar de tareas "humanas". En otras palabras, es posible considerar al flujo de trabajo como un proceso que hace una determinada cantidad de solicitudes de servicios, que son realizados por una combinación de personas y sistemas de back end. Al principio, la mayoría de estas tareas son realizadas por personas, pero, con el tiempo, algunas de estas personas son reemplazadas por llamadas a servicios y, finalmente se trata de un proceso completamente automatizado. En la figura 17 se compara un proceso basado en una tarea realizada completamente por personas con otro que se encuentra completamente automatizado salvo raras excepciones.

Figura 17. Solución de sólo tareas - sin requisitos de integración (ver Figura 17 ampliada)
Solución de sólo tareas - sin requisitos de integración (ver Figura 17 ampliada)

Process Server permite intercalar tareas humanas dentro y fuera de los procesos BPEL, motivo por el cual, por lo general no es posible automatizar todos los pasos de un proceso en un solo día. Sin embargo, no limite el uso de tareas humanas a estos pasos ocasionales de los procesos basados en la integración, y no ignore el conocimiento acumulado durante años en los sistemas de flujo de trabajo. También es necesario reconocer que muchos procesos están dirigidos fundamentalmente a la gente, y continuarán así durante algún tiempo más.

Process Server ofrece muchas formas de crear procesos basados en tareas humanas. Estos procesos se analizarán en detalle en un artículo sobre tipos de implementaciones de los procesos que publicaremos más adelante .


Conclusión

En este artículo se analizó la forma en la cual pueden presentarse las soluciones típicas de alto nivel para problemas de proceso e integración que generalmente se resuelven utilizando WebSphere Process Server y WebSphere Enterprise Service Bus.

En esta serie de artículos, analizaremos en detalle la forma en la cual se presentan las soluciones de integración y proceso. Describiremos además cómo capturar y traducir las características de las soluciones principales, y cómo traducirlas a los patrones del diseño. En cada artículo, se presentará una nueva característica clave del producto incorporada al mismo recientemente. A continuación presentamos el resumen del contenido de los próximos artículos:

  • Aspecto de las soluciones en WebSphere Process Server (este artículo) describe el uso de las vistas de soluciones para conocer los diseños desde un alto nivel.
  • Características de integración, patrones y el Bus de Servicios Empresariales presentará el nuevo patrón delgateway de servicios .
  • Tipos de implementaciones de los procesos analizará las capacidades crecientes de las soluciones basadas en procesos y tareas, como por ejemplo el flujo colaborativo.
  • Aumento de la flexibilidad de las soluciones a través del control de las versiones y del dinamismo probablemente analizará las opciones existentes y nuevas para el control de versiones del proceso y de los módulos y las opciones para flexibilizar los procesos.
  • Uso de patrones en las soluciones analizará cómo utilizar JET2 para aumentar la productividad y mejorar la estabilidad.

Agradecimientos

Las conclusiones de este artículo son producto de discusiones con otras personas sobre temas de diseño, experiencias en proyectos, y también de conversaciones que hemos mantenido con gente involucrada en la creación del producto. Agradecemos al menos a las siguientes personas: Andy Garratt, Bobby Woolf, Eric Herness, Geoff Hambrick, Greg Flurry, Helen M Wylie, Jonathan Adams, Joseph (Lin) Sharpe, Rob Phippen, Stephen Cocks, Paul Verschueren, Werner Fuehrich, y en realidad, a muchos más.

Recursos

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=WebSphere, Lotus
ArticleID=469566
ArticleTitle=Diseño de las soluciones del WebSphere Process Server: Parte 1
publish-date=07282011