Gestione las dependencias de procesos y servicios en un entorno SOA.
Antecedentes ¿Sabe de qué servicios depende un proceso BPEL? Si se utilizan diferentes versiones de un proceso BPEL, las dependencias entre los dos pueden volverse rápidamente más complejas. La complejidad de la gestión de dependencias aumenta si tenemos en cuenta los servicios Enterprise Service Bus (ESB) invocados por el proceso BPEL. La complejidad hace que la implementación y las pruebas requieran mucho tiempo, sean difíciles y propensas a errores.
A menudo terminamos usando la herramienta de modelado de Microsoft Visio para diagramar manualmente las dependencias y luchar para actualizar las dependencias después de cada cambio en el proceso. Este es un obstáculo importante para la agilidad de las infraestructuras de arquitectura orientada a servicios (SOA), que están diseñadas para permitir cambios ágiles en los procesos de negocio.
En esta nota técnica, aprenderá cómo mejorar con éxito su proceso de compilación e implementar la generación automática de gráficos de dependencia de procesos.
Nuestro desafío es implementar un proyecto de demostración de Oracle SOA Suite para un cliente que contenga muchos procesos BPEL y haga referencia a muchos subprocesos BPEL y servicios ESB. Terminamos usando una docena de procesos BPEL y servicios ESB (que se definieron como servicios públicos y se compartieron en el registro de servicios), así como otros procesos BPEL y servicios ESB propietarios.
Primero, decidimos crear una implementación basada en Ant para todos los servicios del proyecto, implementar los procesos BPEL (incluidos los casos de prueba que los ejecutan) en diferentes entornos (pruebas, integración, producción) y también implementar los servicios ESB en los Ant-basados en estos entornos. Descarga gratuita de libros electrónicos sobre informática.
Requisitos Después de completar el primer lanzamiento del proyecto, tenemos algunos requisitos:
,
Cuando cambia un proceso BPEL o un servicio ESB, no queremos implementar todos los servicios del proyecto. Por lo tanto, debemos pasar de una implementación centrada en proyectos a un enfoque de implementación centrado en servicios públicos.
Al implementar un proceso BPEL, todos los subprocesos dependientes (propietarios) y los servicios ESB también se implementan automáticamente.
Para evitar sobrescribir una versión específica de un proceso, implemente esa versión del proceso solo si aún no está implementada en el servidor. La sobrescritura hará que se pierda toda la información del flujo de la instancia.
Se debe crear automáticamente un gráfico visual de todas las dependencias de procesos y servicios durante la implementación sin necesidad de mantener esta información por separado. La visualización debería verse así.
Preguntas abiertas En respuesta a estos nuevos requisitos, hicimos las siguientes preguntas y proporcionamos las siguientes respuestas:
Pregunta: ¿Dónde se almacena la información de las dependencias de procesos y servicios? ¿Necesita agregar más información para crear un gráfico de dependencia completo?
Respuesta: Todos los servicios llamados por el proceso BPEL se almacenan en el archivo bpel.xml marcado con partnerLinkBinding. El proceso BPEL llamado y la información de la versión también están codificados en la URL. Por ejemplo: descarga gratuita de libros electrónicos para computadora
<nombre de propiedad="wsdlRuntimeLocation">
${domain_url}/CustomerAccount_BES/1.3/CustomerAccount_BES?wsdl
</propiedad>
La versión actual del proceso BPEL que se implementará se puede encontrar en el archivo build.properties. Para el mantenimiento de la versión del proceso BPEL, solo necesitamos cambiar la propiedad rev en el archivo build.properties.
Para diferenciar entre procesos BPEL públicos y privados, el enlace del socio del cliente dentro del archivo bpel.xml proporciona un nuevo atributo "tipo" con un valor de "público" o "privado", como se muestra aquí:
<partnerLinkBinding nombre="cliente">
<property name="wsdlLocation">CuentaCliente_BES.wsdl</property>
<nombre de propiedad="tipo">público</propiedad>
</partnerLinkBinding>
Pregunta: ¿Existe alguna herramienta o marco que pueda generar dinámicamente gráficos de dependencia?
Respuesta: Sí, Graphviz ( www.graphviz.org ), una herramienta de código abierto, puede generar gráficos a partir de archivos de entrada en formato de texto.
Pregunta: ¿Cuáles son las opciones para hacer referencia a otros procesos BPEL?
Respuesta: Las opciones son:
Hacer referencia a la versión predeterminada Hacer referencia a una versión específica Hacer referencia a una clave de servicio UDDI (con o sin información de versión codificada)
Pregunta: ¿Cómo se pueden implementar todos estos nuevos requisitos de implementación?
Respuesta: Estos nuevos requisitos de implementación se logran mejor mediante tareas Ant personalizadas.
Con las preguntas iniciales respondidas satisfactoriamente, comencemos creando una tarea Ant personalizada. El archivo bpel.xml se analiza en la tarea Ant. Para todas las etiquetas partnersLinkBindings encontradas, el análisis del archivo bpel.xml correspondiente comenzará de forma recursiva. Además del análisis, el valor actual de la propiedad de versión ("ref") se extrae del archivo build.properties de cada proyecto BPEL encontrado. Uno de los desafíos del análisis recursivo es omitir las dependencias cíclicas.
Nuestro nuevo atributo "tipo" y el análisis recursivo en el archivo bpel.xml implementan todas nuestras necesidades de implementación con el servicio en mente.
Aún mejor, usamos Graphviz para resolver el problema de la generación automática de gráficos de dependencia. Para lograr esto, fusionaremos todas las dependencias obtenidas del análisis recursivo de bpel.xml en un único archivo XML como se muestra a continuación. Descarga gratuita de libros electrónicos sobre informática.
<?xml versión="1.0" codificación="UTF-8"?>
<BPELmaleta>
<BPELProcess id="Resource_BAS_SetForAccount" src=" http://www.oracle.com/technology/tech/soa/soa-suite-best-practices/Resource_BAS_SetForAccount.bpel ">
<socioEnlacesEnlaces>
<partnerLinkBinding nombre="cliente">
<nombre de propiedad="wsdlLocation">Resource_BAS_SetForAccount.wsdl</property>
<nombre de propiedad="tipo">público</propiedad>
<nombre de propiedad="versión">1.2</propiedad>
</partnerLinkBinding>
<partnerLinkBinding nombre="RemoveFromAccount">
<nombre de propiedad="wsdlLocation">Resource_BAS_RemoveFromAccount.wsdl</property>
<nombre de propiedad="versión">1.5</propiedad>
</partnerLinkBinding>
...
</partnerLinkBindings>
</BPELProceso>
<BPELProcess id="Resource_BAS_RemoveFromAccount" src=" http://www.oracle.com/technology/tech/soa/soa-suite-best-practices/Resource_BAS_RemoveFromAccount.bpel ">
<socioEnlacesEnlaces>
<partnerLinkBinding nombre="cliente">
<nombre de propiedad="wsdlLocation">Resource_BAS_RemoveFromAccount.wsdl</property>
<nombre de propiedad="tipo">público</propiedad>
<nombre de propiedad="versión">1.5</propiedad>
</partnerLinkBinding>
<partnerLinkBinding name="Comprobar disponibilidad">
<nombre de propiedad="wsdlLocation">Resource_BES_CheckAvailability.wsdl</property>
<nombre de propiedad="versión">1.1</propiedad>
</partnerLinkBinding>
...
</partnerLinkBindings>
</BPELProceso>
<BPELProcess id="Resource_BES_CheckAvailability" src=" http://www.oracle.com/technology/tech/soa/soa-suite-best-practices/Resource_BES_CheckAvailability.bpel ">
<socioEnlacesEnlaces>
<partnerLinkBinding nombre="cliente">
<nombre de propiedad="wsdlLocation">Resource_BES_CheckAvailability.wsdl</property>
<nombre de propiedad="tipo">público</propiedad>
<nombre de propiedad="versión">1.1</propiedad>
</partnerLinkBinding>
...
</partnerLinkBindings>
</BPELProceso>
...
</BPELMaleta>
Utilice XSLT para convertir los archivos XML combinados a un formato de destino (.dot), que se puede utilizar como entrada al generador Graphviz para generar una imagen PNG, como se muestra a continuación:
estructuras de dígrafo {
nodo [forma=registro,fontname="Arial",fontsize="10"];
borde [fontname="Arial",fontsize="8"];
rangodir=LR;
etiquetajust=l;
"Resource_BAS_SetForAccount_1_2" [forma=record,label="{Resource_BAS_SetForAccount}|{1.2|público}",
fillcolor=amarilloverde,estilo=relleno];
"Resource_BAS_RemoveFromAccount_1_5" [shape=record,label="{Resource_BAS_RemoveFromAccount}|{1.5|public}",
fillcolor=amarilloverde,estilo=relleno];
"Resource_BES_CheckAvailability_1_1" [shape=record,label="{Resource_BES_CheckAvailability}|{1.1|public}",
fillcolor=amarilloverde,estilo=relleno];
"Resource_BAS_SetForAccount_1_2" -> "Resource_BAS_RemoveFromAccount_1_5" [decorar=true,label=""];
"Resource_BAS_RemoveFromAccount_1_5" -> "Resource_BES_CheckAvailability_1_1" [decorar=true,label=""];
}
El gráfico de dependencia generado por el archivo DOT anterior se ve así:
El nombre, la versión y el tipo del servicio se muestran en el cuadro. El color del cuadro indica el tipo de servicio. En este diagrama tenemos tres servicios públicos (verdes). El diagrama al principio de este artículo también muestra el servicio ESB (blanco) y el servicio BPEL (naranja).
Después de generar el diagrama ideal para cada proceso BPEL público, debemos implementar la implementación automática de los procesos relevantes. Para esta implementación centrada en servicios, utilizamos la lista de procesos que generamos anteriormente. Se llama al destino de implementación estándar para cada proceso de la lista. Para evitar sobrescribir versiones de procesos existentes en el servidor, solo se llama al destino de implementación si no hay una versión actual del proceso en el servidor.
Puede determinar si una versión de proceso específica está disponible abriendo una conexión HTTP a la URL WSDL del proceso y luego verificando el código de estado devuelto (¿estado HTTP 200? Implementado, estado HTTP 404? Aún no implementado). Descarga gratuita de libros electrónicos sobre informática.
El resultado de nuestra tarea Ant personalizada (que contiene análisis recursivo), generación de imágenes PNG e implementación centrada en servicios se ve así:
...
[mkdir] Directorio creado: /MyProject/Resource_BAS_SetForAccount/doc
[bpeltask] ** INICIANDO DeployWithDependencesTask **
[bpeltarea] Resource_BAS_SetForAccount-1.2
[bpeltask] ** PARÁMETRO **
[bpeltask] nombre de archivo de punto: doc/bpel-recursiv-all.dot
[bpeltask] dotfilenamepublic: doc/bpel-recursiv-public.dot
[bpeltask] implementar objetivo: implementar
[bpeltask] implementación: verdadero
[bpeltask] sobrescritura: falso
[bpeltask] stoponalreadydeployed: falso
[bpeltask] ** RESOLUCIÓN RECURSIVA DE TODOS LOS ARCHIVOS bpel.xml **
[bpeltask] [Resource_BAS_SetForAccount-1.2]
[bpeltask] [Resource_BAS_SetForAccount-1.2, Resource_BAS_RemoveFromAccount-1.5]
[bpeltask] [Resource_BAS_SetForAccount-1.2, Resource_BAS_RemoveFromAccount-1.5, Resource_BES_CheckAvailability-1.1]
[bpeltask] ** ESCRITURA DEL ARCHIVO bpel.xml CENTRAL **
[bpeltask] ** TRANSFORMACIÓN DE ARCHIVO PUNTO **
[bpeltask] ** IMPLEMENTACIÓN DEL SERVICIO **
[bpeltask] ================================================= ===========================
[bpeltask] SERVICIO YA IMPLEMENTADO (HTTP/1.1 200 OK) 'Resource_BES_CheckAvailability' en la versión '1.1' http://localhost:8888/orabpel/default/Resource_BES_CheckAvailability/1.1/ Resource_BES_CheckAvailability?wsdl
[bpeltask] ================================================= ===========================
[bpeltask] ================================================= ===========================
[bpeltask] SERVICIO YA IMPLEMENTADO (HTTP/1.1 200 OK) 'Resource_BAS_RemoveFromAccount' en la versión '1.5' http://localhost:8888/orabpel/default/Resource_BAS_RemoveFromAccount/1.5/ Resource_BAS_RemoveFromAccount?wsdl
[bpeltask] ================================================= ===========================
[bpeltask] ================================================= ===========================
[bpeltask] SERVICIO AÚN NO IMPLEMENTADO (HTTP/1.1 404 no encontrado) http://localhost:8888/orabpel/default/Resource_BAS_SetForAccount/1.2/ Resource_BAS_SetForAccount?wsdl
[bpeltask] INICIO DE LA IMPLEMENTACIÓN DEL SERVICIO de Resource_BAS_SetForAccount en la versión 1.2
[bpeltask] ================================================= ===========================
...
Conclusión La implementación centrada en servicios que genera automáticamente gráficos de dependencia satisface todas nuestras necesidades de transparencia de la infraestructura SOA. Debido a que la implementación se basa completamente en Ant, también podemos usarlo para nuestros trabajos de compilación de producción y nocturnos de Luntbuild (entorno de compilación continua).
Para respaldar la gobernanza SOA de nuestros clientes, expondremos nuestro proceso público y su documentación, junto con el gráfico de dependencia resultante, en la wiki del cliente, como se muestra aquí:
Las páginas wiki se generan dinámicamente cuando una búsqueda en el registro de servicios recupera la versión de un servicio público actualmente registrado. Las figuras en la página wiki proporcionan enlaces al repositorio de fuentes (Subversion), que contiene figuras en tamaño real de la documentación y versiones registradas de nuestros servicios públicos. Haga clic en la miniatura para recuperar el archivo correspondiente de Subversion a través de WebDAV