CSF vs BizTalk ¿Compiten? ¿Aliados?
Cada vez que voy a un cliente o hablo con un compañero sobre CSF siempre salta la misma pregunta ¿Cual es exactamente la diferencia entre CSF y BizTalk Server?
Pues bien, este será el tema de mi primer post :)
BizTalk Server es el producto de Microsoft muy eficaz cuando es necesario integrar aplicaciones ya existentes basadas en plataformas heterogéneas, es decir no es un requesito que las aplicaciones a integrar expongan sus operaciones como servicios Web. BizTalk Server dispone de los llamados adaptadores para gestionar las tareas relacionadas con la comunicación o transporte de mensajes.
Por otra parte CSF es un marco de trabajo (o Framework) que posibilita una colaboración efectiva entre servicios Web. Su objetivo es conseguir integraciones rápidas entre servicios Web reduciendo las dependencias entre ellos, además permite combinar los servicios Web existentes de forma sencilla para componer nuevos servicios.
Para incluir un servicio Web como participante de una sesión de colaboración de CSF solo es necesario que adhieren a los cuatro principios de la orientación a servicios:
- Fronteras son explícitas
- Servicios son autónomos
- Se comparten solo esquemas de datos (XSD) y contratos, no clases
- Compatibilidad de los servicios determinada por las políticas
Desde el punto de vista de estandarés los servicios Web tienen que cumplir las recomendaciones establecidas por la WS-I (Web Services Interoperability Organization). Para que os hagais una idea CSF en su versión 3.0 ha sido implementada en su totalidad sobre WSE 3.0 (WS-*).
Un mensaje que me gustaría que quedase claro es que "CSF y BizTalk son complementarios".
CSF separa la colaboración (proporciona un lugar de encuentro para que los servicios Web puedan interactuar) y la orquestación (lógica de aplicación, transacción y gestión de estado). BizTalk Server normalmente es necesario en un escenario donde se quieren integrar con flujos de negocio estáticos y sistemas predefinidos. Por cierto, los servicios orquestados de BizTalk pueden ser participantes en el entorno de colaboración de CSF si son publicados como servicios Web. En cambio, CSF proporciona valor al cliente cuando hay eventos no solicitados, cuando hay que descubrir dinámicamente los participantes de una sesión de colaboración,o se necesita el desarrollo de un servicio Web basado en servicios Web existentes en el entorno de colaboración de CSF (Composición de servicios)
El componente de sesión de CSF es arquitectónicamente una formalización de un contexto dinámico de la capa de colaboración. Esto significa que se separan los elementos de “Orquestación” de los elementos de “Colaboración” (relación entre los servicios y las políticas asociadas definidas como contexto). Esta separación es muy útil para los siguientes propósitos:
- La sesión (contexto de colaboración) es como un contenedor donde las diferentes partes que necesitan comunicarse son colocadas en el mismo camino como salas de reuniones donde:
- Las políticas determinan que se puede decir y que no
- Una agenda (orquestación) determina como la reunión va a ser dirigida
- Una reunión no tiene tener una agenda obligatoriamente, e incluso podría contener varias agendas
La información asociada al contenedor esta recogida en el contexto, pudiéndose aplicar políticas a nivel de contexto. Un servicio puede compórtese en una forma en un contexto y de otra en otro contexto diferente.
Las consideraciones relativas a la comunicación (como la sincronía, asincronía, permisión de WS-*, conversaciones seguras, mensajería de confianza o no, etc.) y a la seguridad (por ejemplo: encriptación, firmas digitales, WS-Security Tokens, etc.) son gestionadas por la sesión. Si alguna de estas consideraciones cambia, la sesión automáticamente se ajusta para gestionarlo sin necesidad de parar o modificar la orquestación.
- Con la sesión se pueden tener cero o varias orquestaciones para trabajar con una actividad en el mismo contexto
- Los participantes de una sesión pueden ser cambiados en cualquier momento, de este modo accediendo a un aspecto dinámico no posible solamente con Biztalk Server. Véase los siguientes escenarios:
- En el caso de los lectores de RFID donde con frecuencia es difícil disponer de una orquestación que se anticipe a una lectura RFID
- Donde los dispositivos móviles pueden o no estar conectados a la red en cualquier momento
En todos estos casos, es difícil modelar eventos no solicitados desde participantes transitorios utilizando una construcción del tipo XLANG. BizTalk Server y la mayoría de plataformas de EAI están diseñadas para integraciones app-to-app y por lo tanto excelente modelando un entorno "bien entendido y bien comportado".