Compartir a través de

¿BizTalk Server 2006 o WF? Elección de la herramienta de flujo de trabajo adecuada para el proyecto

  • Artículo

Kent Brown

twentysix Nueva York (www.26ny.com)

Noviembre de 2007

Revisión de febrero de 2008

Se aplica a:

   Microsoft BizTalk Server 2006

   Windows Workflow Foundation

Resumen: Este artículo proporcionará instrucciones para elegir entre Microsoft BizTalk Server 2006 y Windows Workflow Foundation en una variedad de escenarios de flujo de trabajo de integración empresarial y aplicación. (16 páginas impresas)

Contenido

Introducción

Proceso para elegir la herramienta de flujo de trabajo adecuada

Escenarios comunes de flujo de trabajo

Todo está en el host

Recomendaciones de Workflow-Technology

Future-Proofing

Conclusión

Adenda

Reconocimientos

Más información

Introducción

El flujo de trabajo es generalizado en los procesos empresariales cotidianos, por lo que una necesidad común es encontrar herramientas de programación que admitan directamente la creación de soluciones de flujo de trabajo. Microsoft BizTalk Server 2006 y Windows Workflow Foundation (WF) son las dos herramientas principales de Microsoft para programar soluciones de flujo de trabajo. Sin embargo, debido a la aparente superposición entre ellos, muchos arquitectos y desarrolladores tienen dificultades para decidir qué tecnología de flujo de trabajo tiene sentido para sus propósitos.

Esto es especialmente cierto dado que WF se ha identificado claramente como la tecnología de flujo de trabajo preferida en el futuro, mientras que BizTalk Server 2006 sigue siendo el producto de servidor Premium para la integración empresarial. Hasta que la orquestación de BizTalk Server sea totalmente compatible con WF, los arquitectos y desarrolladores tienen que elegir cuidadosamente en qué tecnología invertir.

Uno de los desafíos de elegir la tecnología adecuada para implementar el flujo de trabajo es que el flujo de trabajo puede significar muchas cosas, entre ellas:

  • Flujo de pantallas de interfaz de usuario con las que un usuario interactúa para completar una tarea.
  • Flujo de lógica de negocios dentro de una aplicación o servicio.
  • Interacción de varios seres humanos para completar un proceso de negocio.
  • Coordinación de varios intercambios de mensajes entre sistemas para procesar una transacción empresarial.
  • Coordinación de los pasos para extraer, transformar y cargar datos (ETL) en una base de datos.

Aunque el espectro de escenarios de flujo de trabajo es amplio, resulta útil agruparlos en cuatro categorías generales: flujo de trabajo humano, flujo de trabajo de aplicación, flujo de trabajo de integración empresarialy flujo de trabajo de integración de datos.

De las cuatro categorías principales de flujo de trabajo, Flujo de trabajo de aplicación y Flujo de trabajo de integración empresarial son las dos áreas en las que las personas encuentran más difícil elegir una tecnología. Los escenarios flujo de trabajo humano e integración de datos son bastante sencillos, desde una perspectiva de selección de herramientas. El flujo de trabajo humano requiere una interfaz de usuario y suele centrarse en documentos, por lo que Microsoft Office SharePoint Server 2007 es la plataforma recomendada para crear soluciones de flujo de trabajo humano. Microsoft SQL Server Integration Services (SSIS) es la herramienta recomendada para escenarios de integración de datos.

En este artículo se proporcionan instrucciones para elegir entre BizTalk Server 2006 y WF en escenarios de flujo de trabajo de aplicación y flujo de trabajo de integración empresarial.

Motor de orquestación de BizTalk Server

El motor de orquestación de BizTalk Server siempre ha sido una de las características atractivas de BizTalk Server. Cuando se introdujo, fue la mejor herramienta que estaba disponible en Microsoft para realizar la programación centrada en el flujo de trabajo. La orquestación de BizTalk Server proporciona un entorno de programación visual para desarrollar componentes para controlar flujos de mensajes complejos y multistep para completar una transacción empresarial determinada.

Los artefactos de código de orquestación de BizTalk Server se asemejan mucho al diagrama de flujo o a los diagramas de actividad del lenguaje de modelado unificado (UML) que un analista de negocios podría generar para documentar un proceso de negocio. Estos artefactos se pueden compilar y ejecutar en el entorno de ejecución del motor de orquestación, que proporciona servicios como transacciones de larga duración y compensación, durabilidad, tolerancia a errores y recuperación ante desastres, que son cruciales para la creación de sistemas que automatizan transacciones empresariales críticas.

Una base de flujo de trabajo para el futuro

Aunque hay distintas categorías de escenarios de flujo de trabajo, hay suficiente en común entre los escenarios, desde una perspectiva de programación, para que valga la pena intentar establecer un marco común para el desarrollo de flujos de trabajo. El motor de orquestación de BizTalk Server es eficaz, pero nunca se diseñó para usarse fuera de BizTalk Server; por lo tanto, no es posible reasignar la orquestación de BizTalk Server de forma eficaz para las otras categorías de flujo de trabajo.

WF, que se publica en Microsoft .NET Framework 3.0, presenta un modelo de programación visual centrado en el flujo de trabajo en .NET Framework diseñado para ser lo suficientemente general y extensible como para usarse en todos los escenarios relacionados con el flujo de trabajo en la plataforma Windows en el futuro. El equipo que produjo WF pudo tomar los mejores conceptos del motor de orquestación de BizTalk Server, tener en cuenta los requisitos para el dominio más amplio de escenarios de flujo de trabajo y diseñar un marco lo suficientemente flexible como para admitirlos todos.

Como evidencia de la flexibilidad de WF, Microsoft Office SharePoint Server 2007 lo usa para implementar soluciones de flujo de trabajo humano. La intención es que los proveedores de BPM de terceros también compilen sus soluciones sobre WF, en lugar de crear sus propios motores de flujo de trabajo propietarios; varios proveedores ya lo han hecho. Los desarrolladores individuales también pueden usar WF para implementar el flujo de trabajo de aplicaciones personalizado en aplicaciones de .NET Framework. El plan también es para una versión futura de BizTalk Server para implementar el motor de orquestación en WF para implementar soluciones de flujo de trabajo de integración empresarial.

Figura 1. Usar la herramienta de flujo de trabajo adecuada: BizTalk Server 2006 frente a WF

Proceso para elegir la herramienta de flujo de trabajo adecuada

Nuestro método para proporcionar instrucciones para ayudarle a decidir qué herramienta de flujo de trabajo se ajusta al proyecto será delimitar los escenarios de flujo de trabajo más comunes, de modo que pueda determinar el escenario o la combinación de escenarios que mejor se adapten a su proyecto. A continuación, proporcionaremos instrucciones específicas para cada escenario en cuanto a qué herramienta (BizTalk Server 2006 o WF) es la mejor opción y por qué. Además, usaremos el modelo de optimización de infraestructura de plataforma de aplicaciones (APIO), un modelo para clasificar la madurez de las funcionalidades de desarrollo y plataforma de aplicaciones de una organización, para proporcionar instrucciones específicas de la organización en los escenarios en los que cualquiera de las herramientas se puede usar de forma eficaz. Por último, veremos el plan de desarrollo de BizTalk Server 2006 y WF, para que pueda tomar las mejores decisiones para probar en el futuro las aplicaciones que está compilando hoy mismo.

Escenarios comunes de flujo de trabajo

Incluso después de limitar nuestro ámbito a las categorías application and Enterprise Integration de flujo de trabajo, todavía hay una amplia gama de escenarios de flujo de trabajo que se deben tener en cuenta. Como se muestra en la figura 2, en un lado del espectro se muestran escenarios en los que WF es claramente la elección correcta. Un ejemplo de esto es la funcionalidad de flujo de trabajo dentro de un producto de proveedor de software independiente (ISV), donde los costos de licencia y la complejidad de la implementación de BizTalk Server 2006 serían prohibitivos. En este escenario, como ISV, usted está en el negocio de hacer software comercial, y el esfuerzo de programación adicional que se requiere para hospedar la libre de regalías de WF es una inversión razonable.

Figura 2. Integración y continuidad del flujo de trabajo

En el otro lado del espectro se encuentran soluciones de integración empresarial que se crean dentro de un departamento de TI corporativo, donde claramente BizTalk Server 2006 es la opción correcta. En este escenario, quiere centrarse en la producción de valor empresarial, en lugar de invertir en la construcción de la "fontanería" para que la solución sea escalable, confiable y manejable; por lo tanto, el costo de licencia de BizTalk Server 2006 vale la pena, debido a lo que proporciona.

La mayoría de los proyectos se encuentran entre estos dos extremos del espectro. A continuación se muestran algunos escenarios comunes en los que los requisitos dictan una solución de flujo de trabajo:

  • controlador de páginas de interfaz de usuario: un requisito común en aplicaciones complejas es aplicar la navegación de pantalla de la interfaz de usuario según las reglas de negocios del caso de uso específico que se está implementando. El ejemplo más sencillo es un asistente que guía al usuario a través de un conjunto de pantallas prescrito para realizar una tarea. A menudo, es un gráfico más complejo de posibilidades de navegación en pantalla que se basan en las acciones del usuario y el estado de los datos.
    El patrón Model-view-controller (MVC) es la técnica clásica para extraer esta lógica de navegación fuera de los propios formularios, de modo que sean más sencillos y reutilizables en distintos casos de uso. El controlador en el patrón MVC es realmente un flujo de trabajo o una máquina de estado; por lo tanto, es natural buscar una herramienta de flujo de trabajo en la implementación de estos tipos de aplicaciones.
  • lógica de negocios de larga duración: cuando se requieren muchos pasos para completar una transacción empresarial, es posible que el usuario tenga que detenerse en medio del proceso o esperar acciones de otros usuarios o sistemas antes de continuar. La capacidad de pausar temporalmente (o "hibernar") un proceso y, a continuación, reiniciarlo, en función de eventos externos, es fundamental para la idea del flujo de trabajo. Sin un motor de flujo de trabajo, los desarrolladores se ven obligados a diseñar y codificar manualmente los mecanismos para almacenar el estado de un proceso incompleto y recordar ese estado cuando el proceso continúa. Con un motor de flujo de trabajo bien diseñado, esta funcionalidad se admite de forma nativa sin trabajo adicional para los desarrolladores.
  • flujo de proceso actualizable dinámicamente— Aunque parece posible en primer lugar codificar los procesos empresariales en pasos secuenciales bien definidos, los seres humanos a menudo deben modificar el flujo intermedio para tener en cuenta las situaciones reales. En un proceso de aprobación de gastos, el administrador del empleado que envió el informe de gastos podría ser el aprobador predeterminado. Sin embargo, el administrador podría decidir delegar la tarea a un secretario (por ejemplo, porque el gerente se dirige a jugar al golf) o escalar la aprobación a un superior (por ejemplo, porque el administrador no está seguro de la directiva para un gasto determinado). Permitir que el usuario actualice el flujo suele ser más sencillo que intentar anticipar cada permutación posible del flujo con antelación.
  • abstracción de reglas de lalógica de negocios: en este escenario, el objetivo es separar las reglas de negocios de otra lógica de negocios. Un buen ejemplo es las reglas de validación de formularios. En un programa de solicitud de hipoteca, el formulario solicitud de préstamo puede tener un conjunto de reglas de validación de campo antes de que el usuario pueda presionar el botón Enviar para enviar una solicitud de préstamo. Si el oficial de préstamos utiliza el mismo formulario para revisar y aprobar el préstamo, se requieren reglas de validación adicionales, ya que se encuentra en una fase diferente del proceso.
    La implementación de las reglas de validación por separado del formulario facilita la reutilización del formulario en diferentes escenarios y la aplicación de las reglas de validación adecuadas simplemente mediante la evaluación del conjunto adecuado de reglas para ese escenario.
  • agregador de servicios web: las aplicaciones a menudo deben agregar datos de varios servicios web diferentes. En muchas situaciones, la propia lógica de agregación puede extraerse de la aplicación y exponerse como servicio en su propio derecho que se puede reutilizar de otras aplicaciones. A menudo, estos servicios se denominan servicios web compuestos, y son un elemento importante de una arquitectura orientada a servicios maduro. El escenario del agregador de servicios web normalmente es sincrónico y de ejecución corta.
  • proceso de negocio de larga duración: el escenario de proceso de negocio de larga duración se usa en este artículo para designar procesos basados en servidor que integran varias aplicaciones juntas, mientras que lógica de negocios se usa para la lógica dentro de una sola aplicación. Los requisitos para estos procesos empresariales de larga duración basados en servidor para multithreading, comportamiento asincrónico, persistencia del estado del proceso, correlación de mensajes a instancias de proceso, escalabilidad, confiabilidad, integridad transaccional, etc., son mucho más altas que para la lógica de negocios dentro de una aplicación.
  • proceso de negocio a negocio (B2B): el escenario de proceso B2B es esencialmente el mismo que el escenario de proceso de negocio de larga duración, excepto que el primero está entre organizaciones además de aplicaciones internas. Los requisitos de seguridad, por lo tanto, son primordiales. Además, tiene aún menos control sobre el formato de datos y el protocolo de transporte específicos, ya que estos podrían ser dictados por su socio comercial; por lo tanto, necesita la capacidad de admitir una amplia gama de formatos y protocolos y admitir la configuración de los intercambios específicos para un gran número de asociados.
  • abstracción de reglas del proceso de negocio: de forma similar a la abstracción de reglas del escenario de lógica de negocios, este escenario se aplica cuando desea separar las reglas de negocio del código principal en el escenario proceso de negocio de larga duración y el escenario de proceso B2B. Este escenario requiere un mayor nivel de rendimiento y escalabilidad. Además, es probable que requiera herramientas para permitir que los no programadores vean y editen las reglas.
  • repositorio de reglas empresariales: en este escenario, el objetivo es crear un repositorio central de reglas compartidas que se pueda invocar desde todas las aplicaciones de la empresa. Esto proporciona coherencia en todas las aplicaciones de una organización para aplicar reglas de negocio importantes. De forma similar a la abstracción de reglas del escenario de proceso de negocio, este escenario requiere alta escalabilidad y herramientas para permitir que los no programadores vean y editen las reglas. Además, este escenario requiere que el repositorio de reglas sea capaz de existir como su propia entidad en la empresa, con su propio mecanismo de hospedaje independiente del motor de flujo de trabajo y con componentes o API para ejecutar las reglas de varias aplicaciones.
  • Enterprise Service Bus (ESB)/Message Broker: muchas organizaciones quieren una infraestructura de comunicación estandarizada para todos los servicios. Las dos topologías más comunes para esta infraestructura son ESB y Message Broker. La mensajería de publicación o suscripción y el enrutamiento base de temas son características habituales de esta infraestructura.

Modelo de optimización de infraestructura de plataforma de aplicaciones

En algunos de los escenarios de flujo de trabajo, BizTalk Server 2006 y WF cumplen satisfactoriamente los requisitos técnicos. Para estos escenarios, la elección correcta de la tecnología de flujo de trabajo requiere que la solución coincida con las necesidades de la organización específica. Con el fin de realizar recomendaciones que se aplican a su organización determinada, usaremos el modelo de optimización de infraestructura de plataforma de aplicaciones (APIO), como se muestra en la figura 3.

Figura 3. Modelo de optimización de infraestructura de plataforma de aplicaciones (APIO)

El modelo de APIO es una técnica para generar perfiles de madurez de una organización con respecto a su infraestructura de aplicaciones, arquitectura y prácticas de desarrollo. El objetivo de este modelo es proporcionar a las organizaciones un plan de desarrollo para optimizar su agilidad al proporcionar soluciones de TI para satisfacer las necesidades de la empresa.

El modelo de APIO usa los cuatro perfiles siguientes de madurez de una organización:

  • Básico: las organizaciones tratan el software como un costo. Tienen aplicaciones en gran medida siloadas con poca integración o reutilización. Las aplicaciones que sí tienen pueden estar en una variedad de plataformas. No tienen estándares coherentes para las técnicas de infraestructura o desarrollo; no tienen una visión arquitectónica coherente.
  • estandarizado: las organizaciones siguen tratando el software como un costo, pero han tomado medidas para mejorar la eficiencia. Tienen una visión arquitectónica e intentan considerar las oportunidades de reutilización. Han empezado a integrar algunas aplicaciones, pero son principalmente integraciones de punto a punto.
  • Advanced: las organizaciones tratan el software como un habilitador empresarial. Tienen arquitectos dedicados y una visión arquitectónica clara. Tienen muchos servicios y logran un alto nivel de reutilización. Todos los procesos empresariales principales se automatizan y supervisan. Usan una plataforma de integración centralizada empaquetada.
  • Dynamic: las organizaciones tratan el software como un recurso estratégico. Tienen un SOA muy maduro en visión e implementación. Tienen procesos claros para el control de versiones dinámicos y la reimplementación de servicios. Puede adaptarse rápidamente a los cambios de los requisitos empresariales y puede integrarse rápidamente con nuevos socios comerciales.

No es sólo donde estás, pero adónde vas

Algo implícito en el modelo de APIO es la noción de que cada organización aspiraría a avanzar hacia el perfil dinámico. En realidad, depende de la naturaleza del negocio y de la filosofía de la gestión con respecto a la tecnología. Es posible que algunas empresas estén completamente satisfechos para permanecer en el perfil Básico o Estandarizado.

Debe tener en cuenta el perfil actual, así como los objetivos a corto plazo y a largo plazo, con el objetivo a corto plazo como el más importante. Una organización en el perfil Básico, con el deseo de estar en el perfil dinámico finalmente, podría elegir sabiamente centrarse inicialmente en entrar en el perfil estandarizado; por lo tanto, sus decisiones tecnológicas deben ser principalmente coherentes con el perfil estandarizado.

En general, BizTalk Server 2006 va a ser una mejor opción para las organizaciones que son, o tienen un objetivo a corto plazo, en el perfil avanzado o dinámico. Una organización del perfil básico relativamente satisfecho en este perfil podría no tener la motivación estratégica para adoptar BizTalk Server 2006 ni las funcionalidades para aprovecharlo de forma eficaz; por lo tanto, es probable que no quieran realizar la inversión. Sin embargo, si una organización del perfil básico ha tomado una decisión de avanzar hacia el perfil avanzado de forma agresiva, la adopción de BizTalk Server 2006 podría ser un paso estratégico en esa dirección.

El punto de introducir el modelo de APIO en la discusión es que tener una buena idea de los perfiles de APIO actuales y dirigidos de la organización ayudará a decidir entre WF y BizTalk Server 2006, cuando el escenario técnico podría ser bien compatible con cualquiera de las tecnologías. Dos organizaciones diferentes podrían tomar diferentes opciones, cada una de las cuales toma la opción adecuada para su perfil organizativo.

Todo está en el host

Uno de los aspectos más importantes que se deben tener en cuenta al elegir entre BizTalk Server 2006 y WF es los requisitos de hospedaje de los flujos de trabajo. A diferencia de BizTalk Server 2006, WF no proporciona hospedaje "lista para usar"; Debe implementar un host que establezca el proceso de Windows e inicie el motor en tiempo de ejecución de flujo de trabajo en el que se ejecutarán los flujos de trabajo.

Para crear un marco que pueda admitir el espectro completo de escenarios de flujo de trabajo de forma realista, WF abstrae los comportamientos principales que proporciona un entorno como BizTalk Server 2006 para que varios hosts puedan proporcionar el comportamiento deseado específico para estos servicios.

Los servicios principales que proporciona un host de flujo de trabajo de WF son los siguientes:

  • servicio de programación: crea y administra los subprocesos que usa el motor en tiempo de ejecución para ejecutar instancias de flujo de trabajo.
  • servicio Commit Work Batch: administra las transacciones que usa el motor en tiempo de ejecución para las operaciones de base de datos.
  • servicio de persistencia: controla la persistencia de la instancia de flujo de trabajo cuando el motor en tiempo de ejecución lo dirige a hacerlo. Este servicio es opcional. Si no se proporciona, las instancias de flujo de trabajo no se conservarán y deben ejecutarse en memoria durante toda su duración.
  • servicio de seguimiento: permite registrar eventos de seguimiento dentro de los flujos de trabajo. Este servicio es opcional.

Qué se necesita para crear un host de flujo de trabajo

Según el escenario de flujo de trabajo y los servicios que debe proporcionar a los flujos de trabajo, la creación de un host wf podría ser trivial o prohibitiva. En los escenarios en los que el flujo de trabajo está dentro del contexto de una aplicación, el hospedaje de WF es bastante sencillo. La propia aplicación actúa como host de proceso y hay implementaciones estándar de los servicios principales que se pueden configurar con un esfuerzo mínimo.

Sin embargo, la sofisticación necesaria del host salta drásticamente cuando se entra en escenarios altamente escalables basados en servidor. En la tabla 1 se muestra una lista de lavandería de servicios host que podrían ser necesarios, la mayoría de los cuales se proporcionan en BizTalk Server 2006.

Tabla 1. Servicios de host

  • Configuración de escalabilidad horizontal
  • Equilibrio de carga
  • Conmutación por error
  • Regulación
  • Administración de subprocesos
  • Administración de memoria
  • Aislamiento del servicio
  • Configuración de excepciones
  • Administración de mensajes con errores
  • Seguimiento de mensajes
  • Archivado y purga
  • Identidad y suplantación
  • Modelo de implementación de varios entornos
  • Supervisión del estado
  • Seguimiento de uso y rendimiento
  • Administración del estado de proceso compuesto
  • Scripting
  • Recuperación ante desastres
  • Cumplimiento normativo
  • Administración de configuración

¿En qué negocio estás, de todos modos?

Si tiene la tarea de compilar una aplicación específica con plazos estrictos, probablemente no quiera que el equipo se distraiga teniendo que crear un host complejo cuando se deba centrar en implementar la lógica de negocios necesaria. En este caso, BizTalk Server 2006 merece la pena la inversión para comprar, en lugar de intentar compilar, un host de flujo de trabajo sólido. Si forma parte del equipo arquitectónico central de una gran corporación, puede optar por invertir en la creación de un host que podría usarse en toda la organización. Aun así, este esfuerzo no debe tomarse ligeramente.

Recomendaciones de Workflow-Technology

Para escenarios dentro de una aplicación: WF

Para todos los escenarios que se incluyen en una aplicación( incluido el controlador de páginas de la interfaz de usuario, la lógica de negocios de larga duración, el flujo de proceso actualizable dinámicamente, la composición del servicio web y la abstracción de reglas de la lógica de negocios), WF es la opción adecuada de tecnología de flujo de trabajo.

En la mayoría de los escenarios centrados en la aplicación, el patrón de uso requiere interacción sincrónica y de baja latencia entre la aplicación y el flujo de trabajo, que no es la intensidad de BizTalk Server 2006. BizTalk Server 2006 no sería una buena opción para estos escenarios, por motivos de rendimiento; Las orquestaciones de BizTalk Server se ejecutan en servidores de BizTalk Dedicados y la invocación desde una aplicación cliente requiere un recorrido de ida y vuelta a través de la red. Además, el diseño de BizTalk Server 2006 de conservar todos los mensajes en la base de datos messageBox para la durabilidad presenta una latencia adicional, lo que podría no ser aceptable en el contexto de una interfaz de usuario interactiva, si se debe llamar al flujo de trabajo de forma sincrónica.

WF es una mejor opción para estos escenarios; cumple los requisitos de flujo de trabajo y es más sencillo y barato que BizTalk Server 2006. Las funcionalidades de mensajería de BizTalk Server 2006, por ejemplo, la asignación y los adaptadores, no son necesarias en estos escenarios. Los requisitos para los servicios de hospedaje son modestos, por lo que el hospedaje del entorno de ejecución de WF dentro de la aplicación no requiere una cantidad prohibitiva de trabajo.

Para la mayoría de los escenarios de Business-Process: BizTalk Server 2006

Para la mayoría de los escenarios que implican procesos empresariales basados en servidor, BizTalk Server 2006 es la opción correcta. Estos incluyen el proceso B2B, la abstracción de reglas del proceso de negocio, el repositorio de reglas de empresa y enterprise Service Bus (ESB)/Message Broker.

Estos escenarios requieren una alta escalabilidad. Además, requieren la capacidad de ver los procesos en ejecución y detenerlos y reiniciarlos. Por último, requieren compatibilidad para escalar horizontalmente a varios servidores. En estos escenarios, se requieren las características avanzadas de hospedaje de BizTalk Server 2006 y vale la pena la inversión.

Básico Estandarizado Avanzado Dinámico

WF → BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

Figura 4. Escenario de proceso de negocio de larga duración

BizTalk Server 2006 suele ser la mejor plataforma para el escenario de procesos empresariales de larga duración. Estos procesos tienden a ser asincrónicos, de larga duración y con estado. Estos procesos suelen ser críticos para la organización; por lo tanto, requieren alta disponibilidad, visibilidad, seguridad y capacidad de administración. La topología de grupo o "granja" de BizTalk Server 2006 permite administrar una matriz de servidores para proporcionar escalabilidad y redundancia.

El mecanismo de persistencia de BizTalk Server 2006 para almacenar el estado del proceso tiene una seguridad sólida integrada para proteger la privacidad del estado persistente, lo que puede ser importante por motivos normativos. La supervisión de actividad empresarial (BAM) de BizTalk Server 2006 proporciona visibilidad de nivel empresarial adecuada a los procesos en ejecución de forma segura. Por último, estos escenarios suelen requerir compatibilidad con formatos de mensajes heterogéneos y protocolos de transporte, incluidos los sistemas heredados.

Por estas razones, BizTalk Server 2006 suele ser la mejor opción para las organizaciones que tienen como destino los perfiles estandarizados, avanzados y dinámicos. Estas organizaciones suelen considerar el escenario de proceso de negocio de larga duración para ser muy importante para la empresa y muy común dentro de la empresa; por lo tanto, compran BizTalk Server 2006 específicamente para establecer una plataforma estandarizada para ellos.

Sin embargo, WF podría ser una mejor opción para las organizaciones que se encuentran en el perfil de APIO básico. Por lo general, estas organizaciones no buscan invertir en la creación de una plataforma de aplicaciones estandarizada. En su lugar, buscan minimizar los costos y los costos de licencias y hardware de BizTalk Server 2006 podrían ser prohibitivos. La excepción a esta guía es cuando hay requisitos para una alta escalabilidad, supervisión y compatibilidad con una amplia variedad de formatos de mensajes y protocolos de transporte. En este caso, aunque la organización es renuente a invertir en su plataforma de aplicaciones, el costo de crear las características de hospedaje y mensajería desde cero probablemente superaría los costos de BizTalk Server 2006.

Básico Estandarizado Avanzado Dinámico

WF

WF → BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

Figura 5. Escenario del agregador de servicios web

Tanto las orquestaciones de BizTalk Server como los flujos de trabajo de WF tienen una gran compatibilidad con los servicios web que consumen externamente desde un flujo de trabajo y para exponer el flujo de trabajo como servicio web. Por lo tanto, para crear soluciones de agregador de servicios web, al igual que para las soluciones de procesos empresariales de larga duración, la elección viene determinada por el perfil de la organización y los requisitos de hospedaje.

Si el servicio web agregado solo es para agregar otros servicios web, la capacidad de BizTalk Server 2006 para admitir formatos de mensajes heterogéneos y protocolos de transporte agrega poco valor. Sin embargo, si el servicio también debe agregar datos de entornos heredados que no se exponen como servicios web, BizTalk Server 2006 agregaría valor.

Dado que el patrón de uso es rápido, las llamadas de solicitud y respuesta sincrónicas, la durabilidad del mensaje proporcionada por BizTalk Server 2006 normalmente no es importante. De hecho, la latencia introducida por la persistencia en el Cuadro de mensajes es realmente una responsabilidad. El valor principal que proporciona BizTalk Server 2006 para este escenario es la capacidad de administrar la implementación en muchos servidores y supervisar las instancias en ejecución. La funcionalidad bam de BizTalk Server 2006 también puede ser útil para supervisar que se cumplen los acuerdos de nivel de servicio (SLA).

Por estas razones, WF es una opción muy buena para implementar agregadores de servicios web, especialmente en las organizaciones de los perfiles básico y estandarizado. Un ejemplo en el que BizTalk Server 2006 puede ser ventajoso es uno en el que debe administrar un gran número de puntos de conexión para diferentes organizaciones cliente. La configuración puerto de recepción y ubicación de recepción de BizTalk Server 2006 controla específicamente esto. En este caso, los certificados también pueden ser importantes y la compatibilidad de BizTalk Server 2006 para configurar y administrar certificados y aplicarlos al cifrado o descifrado puede resultar útil.

Future-Proofing

Quiere asegurarse de que sus inversiones en costos de licencias de software, en el aprendizaje de una tecnología de flujo de trabajo y en la creación de componentes de flujo de trabajo específicos, le proporcionarán el valor más posible en el futuro. Además de elegir el flujo de trabajo adecuado para su escenario y organización específicos de flujo de trabajo, también debe tener en cuenta los mapas de carreteras del producto para BizTalk Server 2006 y WF. No hay una respuesta sencilla para esto. Los comentarios que siguen no hacen un fuerte argumento para elegir ninguna tecnología; en su lugar, son puntos de datos para ayudar en su decisión.

Lo que agrega BizTalk Server 2006 R2

BizTalk Server 2006 R2 agrega dos características que podrían afectar a su elección de plataforma de flujo de trabajo: los adaptadores de WCF y los interceptores de BAM para WCF y WF.

Adaptadores de WCF

Si su equipo ha adoptado Windows Communication Foundation (WCF) como tecnología estándar para implementar servicios en la creación de su SOA, el hecho de que BizTalk Server 2006 no tenía compatibilidad con WCF podría haber descalificado como plataforma para compilar y hospedar servicios web compuestos. Esto podría haberle empujado hacia WF, incluso si BizTalk Server 2006 era una excelente coincidencia para sus escenarios y perfil de APIO.

Afortunadamente, con la introducción de gran integración de WCF en BizTalk Server 2006 R2, esto ya no es una preocupación. BizTalk Server 2006 ahora tiene una sólida integración con WCF, y es una plataforma excelente para crear servicios compuestos fuera de servicios más granulares y exponer estos servicios compuestos como servicios WCF.

Interceptor de BAM para WF

La segunda característica relevante de BizTalk Server 2006 R2 es la introducción del interceptor de BAM para WF. Si la supervisión de la actividad empresarial es una característica importante de la solución, es posible que se haya insertado hacia el uso de BizTalk Server 2006, solo para aprovechar BAM, cuando WF era una mejor opción para su escenario. Con el interceptor de BAM para WF, puede elegir WF si es la tecnología de flujo de trabajo adecuada para el proyecto y seguir usando BAM como una solución de supervisión de actividades empresariales.

BAM es una característica de BizTalk Server 2006 que proporciona un marco para capturar eventos y datos de orquestaciones y flujos de mensajes de BizTalk Server, y presentar esos datos en un portal para proporcionar al usuario empresarial visibilidad de un extremo a otro en el proceso de negocio. Un aspecto eficaz de la forma en que BAM funciona para aplicaciones de BizTalk Server 2006 es que la supervisión de BAM se puede configurar (o "instrumentar") después de implementar una aplicación de BizTalk Server 2006, sin necesidad de modificaciones en los artefactos de código de BizTalk Server 2006.

BAM está diseñado como una solución de supervisión de actividades empresariales de toda la empresa; por lo tanto, es posible que las aplicaciones que no sean de BizTalk Server 2006 alimenten eventos y datos en BAM. Sin embargo, las API para hacerlo requieren bastante código para escribirse en las aplicaciones externas. El interceptor WF de BAM en BizTalk Server 2006 R2 proporciona la capacidad de instrumentar flujos de trabajo de WF para BAM de forma más sencilla y sin necesidad de modificaciones de código. Mediante el uso de interceptores de BAM, puede realizar un seguimiento de los procesos empresariales sin volver a compilar la solución WF o WCF; la integración se realiza a través de un archivo de configuración.

Extensiones de BizTalk Server 2006 para el SDK de WF

Las extensiones de BizTalk Server 2006 para el SDK de WF se anunciaron y demostraban en TechEd 2007. Este SDK proporciona un mecanismo sencillo para hospedar flujos de trabajo de WF en BizTalk Server 2006. Esta herramienta está pensada para su uso por parte de los desarrolladores de .NET que crean flujos de trabajo de WF hoy en día y buscan una manera fácil de lograr un hospedaje sólido y escalable de esos flujos de trabajo.

El SDK proporciona dos actividades wf personalizadas (una actividad btsReceive y una actividad btsSend) que se pueden usar dentro de un flujo de trabajo de WF para recibir y enviar mensajes a través de BizTalk Server 2006. Como desarrollador, se define wcF dataContracts para los mensajes entrantes y salientes, y un ServiceContract para definir el patrón de intercambio de mensajes. Dentro del flujo de trabajo de WF, las actividades btsReceive y btsSend están configuradas para usar el ServiceContract definido, como se muestra en la figura 6.

Figura 6. actividades btsReceive y btsSend para su uso en ServiceContract definido

Una vez completado y compilado el flujo de trabajo de WF, haga clic con el botón derecho en el proyecto de flujo de trabajo y seleccione Generar de orquestación para generar automáticamente una orquestación contenedora (vea la figura 7) que iniciará el flujo de trabajo de WF y enrutará los mensajes de BizTalk Server 2006 hacia y desde él.

La orquestación de contenedor generada automáticamente contiene esquemas para los mensajes definidos en el ServiceContract. También contiene las formas y el código de orquestación de BizTalk Server para recibir un mensaje de BizTalk Server 2006, crear e iniciar la instancia de flujo de trabajo, pasar mensajes entrantes a la instancia de flujo de trabajo, recibir los mensajes salientes y reenviarlos al motor de mensajería de BizTalk Server 2006. Para completar el hospedaje del flujo de trabajo de WF, solo tiene que compilar e implementar la orquestación del contenedor y enlazarla mediante el mecanismo normal de BizTalk Server 2006.

Figura 7. Generación automática de una orquestación contenedora

Además de aprovechar el sólido mecanismo de hospedaje escalable de BizTalk Server 2006 para flujos de trabajo de WF, las extensiones de BizTalk Server 2006 para EL SDK de WF le permiten aprovechar la infraestructura de mensajería de BizTalk Server 2006. Por lo tanto, puede aprovechar los muchos adaptadores disponibles para obtener mensajes dentro y fuera de BizTalk Server 2006, así como el procesamiento de canalizaciones, incluidas las funcionalidades de asignación.

Tan eficaz como es, las extensiones de BizTalk Server 2006 para el SDK de WF deben usarse como herramienta para permitir que los desarrolladores de WF implementen sus flujos de trabajo encima de BizTalk Server 2006, no como reemplazo de orquestaciones en escenarios en los que hemos identificado BizTalk Server 2006 como herramienta adecuada. Hay algunas formas wf que no funcionan cuando se encapsulan en una orquestación. Esto se debe a que hospedar los flujos de trabajo de WF dentro de BizTalk Server 2006 mediante el uso de las extensiones de BizTalk Server 2006 para el SDK de WF no proporcionará el mismo comportamiento de hospedaje que las orquestaciones nativas. El SDK tiene una lista de preguntas más frecuentes (incluida en la Guía de inicio rápido) que describe estas diferencias.

Conclusión

BizTalk Server 2006 y Windows Workflow Foundation son las herramientas principales de Microsoft para implementar soluciones de flujo de trabajo en las categorías Application and Enterprise Integration Workflow. Para elegir cuál es el adecuado para el proyecto, primero debe identificar cuál de los escenarios de flujo de trabajo que tiene como destino.

A continuación, use la tabla de la figura 8 para ver la tecnología de flujo de trabajo recomendada para su escenario. Para el flujo de trabajo dentro de una aplicación, se recomienda WF. Para la mayoría de los escenarios de negocio basados en servidor y B2B, se recomienda BizTalk Server 2006.

Figura 8. Tecnologías de flujo de trabajo específicas del escenario

En el caso del proceso de negocio de larga duración y los escenarios del agregador de servicios web, cualquiera de las tecnologías se puede aplicar de forma afectiva. En estos escenarios, debe evaluar el perfil de APIO de destino actual y a corto plazo de la organización. Las organizaciones que están en o avanzan hacia los perfiles avanzados o dinámicos deben usar BizTalk Server 2006 para estos escenarios. Las organizaciones de los perfiles básico y estándar pueden usar WF de forma eficaz para estos escenarios.

Por último, debe tener en cuenta las fechas de lanzamiento y la duración deseada de la solución, en relación con el mapa de ruta del producto para BizTalk Server 2006 y WF. Con este marco y las instrucciones de este artículo, debería poder elegir el flujo de trabajo adecuado para el proyecto.

Adenda

Disipación de conceptos erróneos sobre BizTalk Server 2006 frente a WF

A continuación se muestran algunos conceptos erróneos comunes sobre WF y BizTalk Server 2006, y los argumentos aclaradores que usamos para disiparlos:

  • WF es el reemplazo de BizTalk Server 2006.No. Dado que WF es la oferta "más reciente y mejor" de Microsoft para los flujos de trabajo de programación, muchos que no están familiarizados con BizTalk Server 2006 inicialmente asumen que se ha quedado obsoleto con el lanzamiento de WF. La respuesta sencilla para corregir esta impresión es que WF es un marco de desarrollo de bajo nivel para crear todo tipo de flujos de trabajo, mientras que BizTalk Server 2006 es un producto de servidor completo con características avanzadas para una categoría específica de escenarios de flujo de trabajo: Enterprise Integration. (Vea la figura 1).
    WF solo proporciona un pequeño subconjunto de esta funcionalidad: Flujo de trabajo y reglas de negocio. Aunque WF puede ser una solución más sencilla y rentable para escenarios que no requieren todas las demás características que proporciona BizTalk Server 2006, de ninguna manera suplanta BizTalk Server 2006 para los principales escenarios de integración empresarial que BizTalk Server 2006 se diseñó para admitir.
  • BizTalk Server va a desaparecer.No. Una idea errónea similar es la impresión de que, dado que WF se publicó como herramienta de flujo de trabajo del futuro, y BizTalk Server aún no se ha reescrito para usar WF, Microsoft ya no está invirtiendo en BizTalk Server y finalmente lo reemplazará por un nuevo producto basado en WF. Esto no es sólo el caso; BizTalk Server ha sido un producto muy exitoso, y el área de integración empresarial que tiene como destino sigue siendo un área que Microsoft se compromete a admitir.
  • Tiene que elegir BizTalk Server 2006 en .NET Framework.No. puede resultar tentador para los desarrolladores de .NET que no están familiarizados con BizTalk Server 2006 para elegir WF sobre BizTalk Server 2006, solo sobre la base de que prefieren ir a .NET "puro". Sin embargo, esto no es realmente un criterio útil; BizTalk Server 2006 se basa en .NET Framework.
    De hecho, BizTalk Server 2006 representa más de 2 millones de líneas de código .NET que se pueden aplicar a la solución, lo que le ahorra tiempo, problemas y costo de desarrollar su funcionalidad desde cero. Además, la programación de BizTalk Server 2006 se realiza dentro de Microsoft Visual Studio .NET y los componentes se compilan e implementan como ensamblados de .NET. Además, los proyectos más significativos de BizTalk Server 2006 combinan componentes de BizTalk Server 2006 con componentes personalizados de .NET; Por lo tanto, el desarrollo de BizTalk Server 2006 debe considerarse desarrollo especializado de .NET, en lugar de algo que sea externo o diferente.
    La pregunta real es si las características de BizTalk Server 2006 proporcionan un valor suficiente para su escenario de flujo de trabajo concreto para justificar los costos de licencia. No quieres usar un mazo para colgar fotos; tampoco quieres usar el martillo de un carpintero para aplastar rocas grandes.
  • Gana la mayoría de las características.una mala elección. Podríamos colocar una matriz de características que compare las características granulares de WF con las de BizTalk Server 2006. Sin embargo, esta comparación no sería muy útil; BizTalk Server 2006 tiene un gran número de características destinadas específicamente al espacio de integración empresarial. Si no es el escenario de destino, las comparaciones de características no tendrán sentido. BizTalk Server 2006 probablemente ganaría, en términos del número de casillas de características; Sin embargo, se trata de una comparación entre manzanas y naranjas, si esas características no están relacionadas con el escenario de flujo de trabajo que tiene como destino.

Reconocimientos

Me gustaría agradecer a Paul Andrew y Kris Horrocks, y a todos los que revisaron este artículo.

Más información

Acerca del autor

Kent Brown es el director y arquitecto sénior de Enterprise Integration Practice en veintisix Nueva York, un socio de consultoría de Microsoft Gold Certified en Nueva York. Se ha entusiasmado con BizTalk Server desde su inicio en 2000, y ha desempeñado un papel evangelizador en torno al producto durante los últimos siete años. Kent es miembro del equipo técnico técnico virtual de Microsoft BizTalk, así como de un MVP para desarrolladores de sistemas conectados de Microsoft. Es el fundador y líder del grupo de usuarios de sistemas conectados de Nueva York (http://www.NYCCSUG.org).