Integracin sin barreras

Cinco Errores Conceptuales y cmo evitarlos

15

Introduccin
Cuntos integrantes de su organizacin consideran las TIs no slo como un factor de cambio, sino tambin como una limitacin para el crecimiento en muchos casos? En el entorno de negocios de hoy en da en constante cambio y con clientes cada vez ms exigentes, las TIs estn consideradas como uno de los aspectos ms difciles de cambiar dentro de la organizacin. La alineacin estratgica de las TIs y el negocio es un factor clave para el xito. Las palabras clave son integracin, arquitectura orientada a servicios (SOA), arquitectura orientada por eventos (EDA) y Enterpise Service Bus (ESB). La integracin eficiente de las aplicaciones existentes permitir que su empresa se mueva hacia el futuro donde la TI realmente estimula el crecimiento y, por lo tanto, es el motor del negocio. Para lograrlo, el director de sistemas de informacin y el departamento de TI deben cambiar su enfoque de: ofrecer operaciones eficientes a crear nuevas oportunidades en mercados altamente competitivos. Existen barreras que impidan lograrlo? En Information Builders, creemos en los negocios sin barreras y, durante ms de 32 aos, hemos ayudado a nuestros clientes a romper las barreras que les impedan lograr sus objetivos de negocios. Nuestra visin es la de romper las barreras que se interponen en el camino del xito en los negocios ofreciendo soluciones para simplificar la integracin y proporcionar informacin fcil de usar a todos los usuarios internos y externos. En esta gua, trataremos los Cinco Errores Conceptuales de la Integracin y cmo evitarlos. Considrela una gua de supervivencia y le servir para prepararse en los negocios de cara al futuro Information Builders Marzo de 2007
15 3

A pesar de que se han hecho esfuerzos para asegurar la alta calidad y precisin de la informacin contenida en este documento, Information Builders/iWay Software no otorga ninguna garanta, ni expresa ni implcita, sobre Integracin sin barreras. Cinco Errores Conceptuales y cmo evitarlos ni su contenido, tal cual se proporciona En ningn caso, Information Builders/iWay Software, sus afiliados ni otros proveedores sern responsables de ningn dao directo, especial, ocasional ni consecuente (incluyendo, sin limitaciones, los daos por prdidas de beneficios comerciales, interrupcin del negocio, prdida de informacin comercial u otras prdidas econmicas) que se derive, directa o directamente, del uso (o imposibilidad de uso) del contenido de esta documentacin o de la confianza depositada por el usuario en l. Copyright 2007 Information Builders, Inc. Reservados todos los derechos. Todos los productos y nombres de productos mencionados en esta publicacin son marcas comerciales o marcas comerciales registradas de sus respectivas compaas

14 2

ndice
El contexto:  Integracin de aplicaciones frente a desarrollo de aplicaciones Error conceptual 1: La idea de que los servicios lo son todo Error conceptual 2:  No considerar que Enterprise Service BUS es en realidad un trmino errneo Error conceptual 3:  Demasiados protocolos de peticin / respuesta

El contexto: I ntegracin de aplicaciones frente a desarrollo de aplicaciones

5 9 Es importante entender la diferencia entre la integracin basada en SOA de aplicaciones ya existentes y la construccin de nuevas aplicaciones usando servicios.

13

Estado
Los mtodos de programacin tradicionales mantienen el estado. Por ejemplo, los objetos para examinar archivos generalmente se escriben usando varios mtodos que deben llamarse en la secuencia correcta: open abre el archivo, next itera el procesamiento en los registros y close cierra el archivo despus de que el programa lea todos los registros. Durante este proceso el objeto usa un cursor para recordar la posicin en la que se encuentra en el archivo. En otras palabras, el cursor mantiene el estado del objeto entre los mtodos open y close. SOA utiliza servicios no persistentes tanto para la integracin como para el desarrollo de aplicaciones. Cada solicitud de un servicio empieza de cero: no se mantiene memoria alguna de lo que ya se ha llevado a cabo. ste es un paradigma relativamente nuevo para el desarrollo de aplicaciones que requiere que los programadores piensen de forma diferente. Si quiere crear un servicio no persistente para, por ejemplo, examinar un archivo, su interfaz tendr que incluir el nombre del archivo que tiene que abrir, el nmero o clave del primer registro que debe devolver y el nmero de registros que se devolvern. Por otro lado, los servicios no persistentes se han utilizado para la integracin durante bastante tiempo, aunque no siempre con el mismo nombre. Las interfaces de intercambio electrnico de datos (EDI), por ejem-

22

Error conceptual 4:  No ver que BPEL no integra aplicaciones sino que realmente las crea 24 Error conceptual 5:  Pensar que la integracin de SOA es para programadores, no para analistas 29 Recomendaciones 30

14 4

15 5 5

plo, utilizan mensajes unidireccionales que representan eventos de negocio que se han completado o que todava tienen que completarse. Aunque existen mecanismos internos para el mantenimiento del estado del negocio basados en mensajes enviados y recibidos, el mecanismo de envo y recepcin propiamente dicho no tiene estado. Por lo tanto, podemos afirmar con total confianza que la ausencia de estado (y, por lo tanto, la orientacin a los servicios) va bien con la integracin, aunque es algo completamente nuevo para el desarrollo de aplicaciones.

En el desarrollo de aplicaciones basadas en SOA, todos los servicios que llaman una funcin en particular se pueden ejecutar en un solo entorno de transacciones (como por ejemplo en un servidor de aplicaciones). Esto significa que todas las transacciones de compensacin y otras operaciones transaccionales, se pueden gestionar en el servidor de aplicaciones y que, se puede usar con seguridad, una llamada a un procedimiento para que un servicio realice un trabajo en nombre de otro. Sin embargo, en la integracin de aplicaciones basadas en SOA, el origen de un evento y el destino de un evento se ejecutan en transacciones diferentes. Si el origen quiere acceder al resultado de una operacin de destino, se debe producir otro evento. Es decir, la integracin de aplicaciones basadas en SOA est ms dirigida por eventos (o EDA) que por servicios. Una transaccin de negocio dar como resultado uno o varios eventos y cada uno de ellos se trata como una transaccin diferente.

Transacciones
Tanto, la integracin de aplicaciones basadas en SOA como el desarrollo de aplicaciones del mismo, utilizan servicios no persistentes, pero hay una gran diferencia entre ellas en lo que respecta a las transacciones. Las transacciones son una entidad de implementacin (una unidad lgica de trabajo) y una unidad de negocio (una unidad de negocio de trabajo). Una unidad lgica de trabajo (LUW) es un conjunto de operaciones del tipo todo o nada; ocurren todas o bien ninguna. Una unidad de negocio de trabajo (BUW) es el procesamiento de un evento de negocio que puede englobar varias LUW; en sistemas tradicionales de procesamiento de transacciones, por ejemplo, una pseudo conversacin CICS puede gestionar la invocacin de varias LUW hasta que el usuario haya completado la BUW. Las aplicaciones engloban transacciones, por lo tanto la integracin de aplicaciones est realmente ms orientada a las transacciones que a los servicios. En otras palabras, la integracin de aplicaciones basadas en SOA est ms limitada que el desarrollo de aplicaciones basadas en SOA.

Semntica
La integracin es semntica. En otras palabras, uno de los mayores desafos de la integracin es la transformacin del significado de un mensaje a medida que va desde el origen al destino. Si quiere integrar aplicaciones pero no puede, debido a que el origen no puede interactuar con el destino, considerar que la interaccin es un problema. Pero una vez que pueda interactuar (por ejemplo, usando los adaptadores de iWay), empezar a resolver el problema real que es la transformacin semntica.

Un espacio de nombres XML es una recomendacin del W3C que proporciona un mtodo simple para cualificar nombres de elementos y atributos usados en una instancia XML. Una instancia de XML puede contener nombres de elementos o atributos para varios vocabularios XML. Si a cada vocabulario se le da un espacio de nombres se puede resolver la ambigedad entre elementos o atributos con nombres idnticos. Todos los nombres de elementos dentro de un espacio de nombres deben ser exclusivos.
1

6 14

La integracin basada en SOA consiste, por lo tanto, en la transformacin de mensajes de origen en mensajes de destino, posiblemente con otro tipo de mensajes en el medio. Sin embargo, existe la suposicin en el desarrollo de aplicaciones basadas en SOA de que la interfaz del que realiza la llamada es la misma que la del servicio al que se llama. Por esta razn, los registros de servicio se generan para personas que crean nuevos servicios con el fin de orquestar los existentes. Esta suposicin no tiene sentido cuando el flujo de trabajo de orquestacin y los servicios que se orquestan provienen de diferentes aplicaciones. Tcnicamente, los espacios de nombres de la aplicacin de llamada y el servicio sern diferentes, por lo que ser necesaria su transformacin. Teniendo esto en cuenta, debe considerar los siguientes errores conceptuales.

Error conceptual 1: La idea de que los servicios lo son todo

Todo el mundo hace referencia a los servicios cuando se habla de SOA, pero en contadas ocasiones se mencionan los canales. Esto es desafortunado, porque la integracin depende tanto de los canales utilizados como los servicios a los que se llama. En la siguiente ilustracin se muestran varios servicios que se colocan en cualquier canal en una configuracin tradicional de agente/puerta de enlace.
Interactive Channels Channel Adapters Middleware Service adapters Services
Claims Sales Fin Corp Re Broker/GW WAP Portal Web Portal Voice Portal Forecourts

Non-Interactive
CC Portal

Los servicios representan funcionalidad de negocio y slo se deben cambiar cuando cambia la funcionalidad de negocio fundamental. Sabemos que el requisito crear un pedido de compra ha cambiado con mucha menos frecuencia que la tecnologa que implementa la creacin de pedidos, por lo que las interfaces de servicio son ms estables que la tecnologa que las implementa.

15 9

Evidentemente, si cambia la implementacin de un servicio, es posible que el propietario del mismo tenga que cambiar la interfaz de servicio. Esto se debe llevar a cabo teniendo en cuenta la complejidad que conllevan estos cambios, que se puede compensar mediante la regla de tres flujos y dos transformaciones. Para obtener ms informacin sobre estos problemas, consulte el documento Las cinco reglas de oro de la integracin. El canal se compone de la interfaz tcnica por la que se invocan not solicitan los servicios, la representacin semntica del servicio y las relaciones que los servicios tienen entre s. Los canales son una represen tacin de TI de la organizacin del negocio. Por ejemplo, imaginemos un canal de empresa a empresa (B2B) que (1) acepta pedidos de compra electrnicos mediante el intercambio de datos electrnicos (EDI), (2) gestiona descuentos y las relaciones con el cliente a travs de servicios web y (3) enva pedidos, a travs de mensajera JMS, a otras partes de la organizacin encargadas de su cumplimiento. Este proceso electrnico es un reflejo directo de la forma en que la empresa se organiza alrededor de los pedidos y su cumplimiento. De nuevo, la forma en que una empresa procesa los pedidos de compra cambia con ms frecuencia que el hecho de que procesa los pedidos de compra. Como la integracin siempre implica a varias aplicaciones y a menudo ms de un dominio de negocio, la propiedad de los canales debe estar en un nivel distinto al de los servicios. Debe ser propiedad de un dominio de negocio, es decir, los debe pagar. Si se combinan estas ideas, podemos ver que los servicios son relativamente estables porque representan algo que la empresa debe hacer. Por otro lado, las implementaciones de servicio cambian con ms frecuencia debido a la tecnologa y los canales cambian incluso con mayor frecuencia porque cambian con las relaciones de negocios.

Para lograr la mxima agilidad, los servicios se deben crear de un modo que sea posible una re-configuracin sencilla a travs de los canales. Esto ofrece algo ms que una arquitectura orientada a servicios. Lo que realmente proporciona es una arquitectura orientada a dominios de negocios. Los canales solucionan el problema de las versiones. Con SOA, puede cambiar una implementacin de servicio. El propietario del servicio puede cambiar la semntica del mismo con la publicacin de un nuevo esquema2. Pueden intentar adaptarse a los distintos usuarios mediante la ejecucin de dos servicios (es decir, dos implementaciones diferentes de la misma funcin de negocios). Sin embargo, es mejor ejecutar el mismo servicio sobre dos canales: uno que utiliza la semntica anterior y otro que utiliza la nueva, segn se ilustra a continuacin.

Service Manager Application document

Application Service Version One

Domain Service Bus

Routing Transform Transform

Gateway Agreed document

Partner Version One

Channel

El diagrama anterior muestra la implementacin de un canal de una versin para un servicio. Posteriormente, el servicio cambia y un nuevo socio aprovecha el nuevo servicio. La gestin de versiones se lleva a cabo del modo mostrado a continuacin.

 n este contexto se habla de un esquema XML, tambin denominado XSD. El esquema XML contiene E un conjunto de reglas a las que se debe ajustar un documento XML para que se considere vlido segn dicho esquema

14 10

15 11

Service Manager Application document

Application Service Version Two

Domain Service Bus

Routing Transform Transform

Gateway Agreed document

Partner Version One Channel Partner Version Two

Error conceptual 2: No considerar que Enterprise Service BUS es en realidad un trmino errneo
La estructura de la empresa debe determinar el propietario de cada proceso de integracin. Por lo tanto, para gestionar la semntica de interfaz, cada dominio de negocios debe disponer de un hub semntico lgico (la implementacin fsica de estos hubs se puede efectuar de diversas formas). Por ejemplo, un importante banco mayorista tiene una operacin de nego ciacin de valores con un solo hub semntico, pero tambin dispone de una operacin de negociacin de deudas con cinco hubs semnticos (para hipotecas, derivados, divisas, deuda pblica y deuda privada). En trminos tcnicos, no necesitan seis hubs semnticos, de hecho, todas las transformaciones de dominio a dominio se podran, tericamente, llevar a cabo en un hub. Este fue el modelo utilizado originalmente en proyectos EAI (integracin de aplicaciones empresariales) basados en agente (lo que tambin explica por qu tantos usuarios han tenido problemas para diferenciar los ESB de los agentes de integracin).

Channel

Transform

Ahora la repercusin de la versin se produce en el service bus que gestiona el canal, no en el servicio. La aplicacin desconoce los usos que se realizan de sus servicios y tampoco sabe que otras aplicaciones invocan sus servicios mediante semntica diferente. El service bus acta como un hub de semntica local. Esto demuestra un punto importante sobre la finalidad de un service bus: transforma mensajes de un formato a otro. La transformacin es semntica, de una interfaz a otra. Por lo que, de hecho, un service buses un tipo de hub semntico.

Banco

Banco minorista

Banco mayorista

Gestin de activos

Acciones

Deuda

Hipoteca

Derivados

Divisas

Deuda pblica

Deuda privada

Los dominios con hubs semnticos se representan mediante puntos blancos.

14 12

15 13

Deuda tiene hubs para instrumentos concretos porque es el modo en que el banco est organizado y la forma en que se gasta el dinero. Debido a que los presupuestos determinan el modo de expansin de la infraestructura, es muy poco probable que alguna empresa llegue a implementar un solo hub semntico. No se espera que un arquitecto explique el motivo de tantos dominios de negocios, eso corresponde al director del banco mayorista, pero s debe explicar cmo los hubs semnticos pueden ayudar a la interaccin de estos dominios. As, mientras implementan el agente de divisas en este banco, el director cambia de idea y decide la siguiente arquitectura:

que las actividades administrativas representan un banco de transacciones. Por lo tanto, una arquitectura de TI razonable debe separar la implementacin de estos servicios de la forma en que estn organizados (sus canales). Existe un motivo tcnico por el que resulta difcil contar con un solo hub semntico y tambin de por qu es difcil tener un service bus para empresas, ya que los buses actan como hubs semnticos. Est relacionado con la forma en que los agentes de mensajes se alinean(intercambian mensajes). Si se coloca (PUT) un mensaje en un hub, una aplicacin en otro hub lo debe obtener (GET). Para que esto suceda, los dos hubs semnticos (en realidad agentes de mensajes) se deben alinear. La mayora de los sistemas de mensajes pueden hacerlo. Por ejemplo, Sonic MQ, WebLogic JMS y WebSphere MQ tienen protocolos para alinearse con sistemas de mensajes del mismo tipo. Sin embargo, no existe un protocolo estndar para la alineacin entre sistemas de mensajes diferentes.

Banco

Banco minorista

Banco mayorista

Gestin de activos Servicios de valores

Acciones

Deuda

Message Broker
Deuda privada Application PUT Proxy Queue Federation Protocol

Message Broker
GET

Hipoteca

Derivados

Divisas

Deuda pblica

Queue

Application

Estructura del banco despus de la reorganizacin.

El banco ha separado las actividades administrativas de las dos divisiones que estn organizadas por instrumento. Es posible imaginar que los derivados constituyen un dominio independiente si se agrupan los derivados de acciones y los de deuda. Tambin es posible imaginar la separacin de las actividades de ventanilla de las de contratacin de deuda y acciones, del mismo modo que la formacin de servicios de valores se puede separar de las actividades administrativas. Esto podra formar parte de una estrategia para crear un banco de ventas independiente del banco de producto orientado a instrumentos, del mismo modo
14

Para establecer comunicacin desde un hub semntico/agente de mensajes con otro debe haber un protocolo de alineacin entre los sistemas de mensajes. No obstante, los protocolos son propietarios. Esto no provoca problemas cuando los agentes de mensajes son del mismo tipo. Pero no se pueden alinear diferentes tipos de agente (como BEA y Sonic), lo que supone una barrera.

15

Si un dominio elige WebLogic JMS, otro Sonic MQ y un tercero Tibco Rendezvous, no habr ningn protocolo que les permita alinearse. Adems, ninguno de estos sistemas de mensajes utiliza servicios web de forma nativa para la alineacin . Esto significa que es necesario crear un puente entre los sistemas de mensajes en cualquier entorno complejo real para integrar a los integradores, por as decirlo. Incluso si se suprime esta barrera (AMQP3 intenta solucionar el problema), todava sera mejor evitar la idea de un Enterprise Service Bus. El trmino empresa supone un solo tipo de service bus para cada parte de la compaa. Pero, como sabemos que la infraestructura sigue al dinero, sera mejor, idea que los arquitectos y gente de negocios crearan hubs semnticos para dominios. Cambiar de un sistema de mensajes monoltico o de punto a punto a un sistema de mensajes con agentes, slo es cuestin de tiempo y dinero. El mantenimiento del dominio resulta caro con el sistema de mensajes punto a punto debido a la necesidad de efectuar pruebas de regresin de un extremo a otro siempre que hay un cambio. El hub resuelve el problema de la prueba de regresin, tal como se muestra a continuacin.

Service Transform

Transform Service Application

Service Transform

Transform Service Application

Transform Application

Transform Service Application

Transform Service Application Service Transform Transform Service

Integracin punto a punto: un cambio en una interfaz puede afectar a todas las dems aplicaciones. Al final, esto resulta muy caro de mantener.

El protocolo avanzado de colas de mensajes (AMQP) es un protocolo de capa de aplicaciones para  mensajes, diseado para permitir la adaptacin de las implementaciones de mensajes en el mismo modo que SMTP para el correo electrnico.

14 16

15 17

A continuacin se ofrece un ejemplo, tomado de un cliente real, de algunas de las interfaces con Cuentas por cobrar (hay ms de 120 interfaces en total).
JETS Gen. Ledger (US/CROC/ EMEA) 96.1, 98.1 Airmiles (Casablanca) (CROC) 96.2 GNA Global New Accts 97.2 FAS/AV (US/CROC/ EMEA) 96.1 CIM MarketingMassMemo/ BT (US/CROC) 97.2

Centrax 96.1

ARGRM 97.2

Call Inter active 96.1

ENLIST 97.2

Balboa Insur Provider

CAS&AA (US/ CROC/EMEA) 95.1, 98.1 CARP (US/ CROC/EMEA) 97.2, 98.1 CRS (US/ CROC/EMEA) 97.2, 98.1

WFIS (US/CROC/ EMEA) 97.2 CC90s (US/CROC/ EMEA) 97.1 CMHDB Marketing (EMEA) 98.1 Credit MIS Table Unload (US/CROC/ EMEA) 96.2 ABS 97.2 Deloitte and Touche/ E&Y 97.2 Centurion ACAPS 97.2 Fraud Scanners 97.1 MFE Mktg Front End 95.2 Data Warehouse 97.2

Operations (New Accts)

Authorizations

E/P Rewards & Reports

E/P Cycling

Non-Monetary

Disputes

ACE (EMEA) 98.1 SECRETS 97.2

Fraud

A/R
Operations (GRMS, Ltrwrtg, Securitization) Issue/Reisue E/P Repo Fed Factory

Statementing

STARS 97.2 DELUXE/ Harland (Chkbk Vendor-US) 97.2 VA (EMEA) 98.1 AECB Centurion Inclearing 97.2 GNAT (US/ CROC/EMEA) 97.1, 98.1

Operations (Collections)

Costumer Service

Inter-Centre Utility (EMEA) 98.1 GRMS (US/CROC/ EMEA) 97.1, 98.1 FDR (US) 95.1 PCO Plastic Production (EMEA) 98.1 EMEA Card Handling (EMEA) 98.1 AECB/ AET-FS 97.2 CPS Customer Profile System (US/CROC/ EMEA) 97.1, 98.1 FINCAP (EMEA) 98.1 FINCAP (US/CROC) 95.1, 97.2 SEIMS 97.2 VRU (USCROC/ EMEA) 96.1, 98.1

SDP 97.2 AEGIS 97.2 Express-Net 97.2

SCS (CAD) 97.1

Legend: Batch Interface

Real-time Interface

Both Batch & Real -time Interface

Third Party

Interfaces de un cliente con Cuentas por cobrar.

14 18

15 19

Este banco en concreto necesit 9 meses para realizar pruebas de regresin por un cambio que se haba llevado a cabo en tan slo diez minutos. La solucin radica en rehacer las interfaces para crear un hub semntico del siguiente modo:

Ahora los cambios slo se tienen que probar con el hub semntico en vez de ir de un extremo a todos los dems. Las dos transformaciones son fundamentales y proporcionan un acoplamiento flexible mediante la reconciliacin de las diferencias semnticas (consulte el documento Las cinco reglas de oro de la integracin para obtener ms detalles sobre la regla de tres flujos y dos transformaciones). Observe que el service bus (hub semntico) parece estar centralizado, pero esto slo se debe a que es propiedad del dominio de negocios. El service bus debe interactuar con numerosos hubs semnticos por toda la empresa, del mismo modo que un directivo interacta con otros directivos de la empresa. Los fabricantes seguirn comercializando software con la etiqueta Enterprise Service Bus porque es lo que piden los usuarios. Pero sorprendentemente, un ESB slo puede tener xito si se suprime este tipo de barrera, para no tener que usar el software en toda la empresa.

Service

Transform Transform

Service Application

Service

Transform

Transform

Service Application

Routing Transform Transform Application

Service Application

Transform

Service Application

Service

Transform

Transform

Service

Uso de un hub semntico para reemplazar al sistema de mensajes punto a punto.

14 20

15 21

Error conceptual 3: Demasiados protocolos de peticin / respuesta

Cada cinco o seis aos, los expertos de TI aclaman algn nuevo protocolo RPC (llamada a procedimiento remoto) como la solucin a prcticamente cualquier problema de integracin. DCE, CORBA y los servicios web constituyen ejemplos recientes. Pero estas afirmaciones estn destinadas a ser falsas. Dichos protocolos pueden solucionar problemas de interoperabilidad, pero no solucionan los problemas de integracin. El motivo reside en la relacin entre interoperabilidad e integracin. Imagine un atleta que va al servicio antes de correr la maratn y accidentalmente se queda encerrado. Su problema inmediato es salir del servicio y no podr correr la maratn hasta que salga. Pero su objetivo real es la maratn. Del mismo modo, la ausencia de interoperabilidad impedir que las personas se integren, pero el problema real es conocer a fondo la semntica de cada dominio de negocio. Los protocolos RPC, incluidos los servicios web, tienden a afrontar el problema de la interoperabilidad mediante un acoplamiento rgido entre extremos, pero esto interfiere en la integracin de acoplamiento flexible. Resulta algo sorprendente cuando se considera la documentacin de los servicios web. Los servicios web de tipo RPC parecen ser mucho ms comunes que otros usos, con integracin basada en RPC entre la aplicacin cliente y los servicios sin estado a los que se llama. Evidentemente, esto se logra mejor con una RPC, pero no es lo mismo que la integracin de aplicaciones. Parece razonable llamar aplicacin a una interfaz, pero cuando los arquitectos disean una interfaz para llamar servicios, realmente se ocupan de jerarquizar aplicaciones,
14 22

no de integrarlas. La jerarquizacin de aplicaciones se presenta en el nivel tcnico o de aplicaciones, mientras que la integracin de aplicaciones tiene que construir servicios de nivel de negocio a partir de servicios de nivel de aplicacin. Se ha reconocido esta limitacin: cuando los servicios web de Microsoft no podan llamar a los servicios web de IBM, se cre la organizacin WS-I (interoperabilidad de servicios web) y la versin 1.0 de su perfil bsico indica que no se debe utilizar el modo RPC. En su lugar, en la medida en que sea posible, se debe utilizar el estilo4 documento/ literal de los servicios web. stos utilizan mensajes en vez de RPC para comunicarse. Hay quien denomina a estos servicios tcnicos sin estado procesos y a los eventos de negocios sin estado procedimientos. Este hecho se ilustra a continuacin.

User Interface Tier

Dialog Procedure User Interface

Business Tier
Business Processes Business Functions

Service Procedure

Integration Interface

 n estilo de vinculacin WSDL (lenguaje de descripcin de servicios web) puede ser RPC o un docuU mento. El uso puede ser codificado o literal

23 15

En este diagrama de flujo, el procedimiento de servicio desempea una funcin similar al procedimiento de dilogo en la interfaz de usuario. No obstante, la interfaz de dilogo se sincroniza (RPC), mientras que la interfaz de integracin es asncrona (mensajes). Se sigue utilizando RPC entre el procedimiento de servicio y los procesos de negocios, pero no entre una aplicacin y otra. Se trata de una diferencia sutil pero crucial. En resumen, los servicios en una SOA deben estar dirigidos principalmente por eventos; slo cuando sea absolutamente necesario deben estar dirigidos por protocolos de peticin/respuesta RPC.

Cmo es una integracin de ese tipo? Si los servicios a los que se llama no se ejecutan en el mismo servidor de aplicaciones que BPEL, el cdigo XML de BPEL (la semntica del propietario del motor BPEL) debe transformarse al menos en el cdigo XML de los servicios (la semntica del propietario del servicio). Esto requiere un cambio de espacio de nombres y probablemente tambin mucho ms. Otro problema con BPEL es la escalabilidad (un problema especfico y fundamental para la orquestacin en general). Este problema presenta dos dimensiones: rendimiento y complejidad.

Error conceptual 4: No ver que BPEL no integra aplicaciones sino que realmente las crea
Algunos argumentos de BPEL (lenguaje de ejecucin de procesos de negocios) parecen convincentes. En vez de crear nuevos servicios partiendo de cero, los usuarios pueden arrastrar y colocar servicios existentes en una paleta BPEL, ejecutar unas pruebas y realizar la implementacin. As se puede realizar una demostracin sensacional. No obstante, las cosas son ms complejas de lo que parecen. En primer lugar, los procesos basados en BPEL deben estar acoplados de forma flexible con los servicios que orquestan. Por ejemplo, si hay veinte procesos de negocios basados en BPEL que llaman a getCustomerInfo, no es de desear tener que cambiarlos todos porque alguien de marketing ha decidido que su servicio se debe cambiar. Esto significa que tiene que integrar BPEL y los servicios antes de orquestarlos. Y va completamente en contra de la secuencia normal de los eventos: no se utiliza BPEL para integrar aplicaciones, se integran aplicaciones para usar BPEL (en Cinco reglas de oro se ofrecen ms detalles al respecto).

e/mensaje

Agentes de mensajes

Slo por invitacin

No importa

Dispositivos de mensajes

Mensajes/segundo

Los ejes vertical y horizontal representan el valor de un mensaje y la tasa de mensajes, respectivamente. Esto genera cuatro cuadrantes en los que se puede encontrar una aplicacin: Tasa baja de mensajes, valor bajo. No hay muchos motivos para preocuparse demasiado sobre cmo se implementan.
25 15

14 24

Tasa alta de mensajes, valor alto. Estas aplicaciones probablemente ya son software intermedio de tercera generacin, y el software intermedio nuevo es slo por invitacin. Tasa baja de mensajes, valor alto. Estas aplicaciones son candidatas para agentes de mensajes tpicos, donde el coste del agente es asequible debido al valor del mensaje. Tasa alta de mensajes, valor bajo. Estas aplicaciones son candidatas para dispositivos, donde el coste del sistema de agentes es proporcional al valor de la transaccin. La experiencia demuestra que los agentes EAI tpicos son muy caros para esta clase de aplicaciones. En la actualidad, la mayora de las aplicaciones de orquestacin se encuentran en el cuadrante no importa. Para que una aplicacin de esta ndole salga de la parte inferior del cuadrante izquierdo, tiene que ascender a tasas de mensajes altas o a la gestin de transacciones de alto valor, tal como se ilustra a continuacin.

Consideremos el valor alto en primer lugar. Normalmente, cuando se plantea la orquestacin por primera vez, lo ms atractivo es la simplicidad de la ruta de la felicidad, el aspecto que presenta el proceso cuando todo va bien. Resulta adecuado para transacciones de valor bajo, pero no para las de valor alto. A medida que aumenta el valor, es necesario preocuparse ms de lo que hay que hacer si algo sale mal. Para cada actividad hay que se ocuparse de la lgica de prueba y error. Esto complica el flujo. Si utiliza eventos de negocios amplios no tiene que preocuparse de los detalles de implementacin de los servicios, pero s de lo que debe hacer si falla el servicio o no est disponible. En un flujo sin estado, cuando algo falla puede anular la transaccin emisora y generar un error para el mensaje. En un flujo BPEL tiene que hacer lo mismo y a continuacin deshacer las acciones anteriores, lo que los especialistas en integracin denominan compensacin. De hecho significa que cada servicio que dirija debe disponer de una interfaz adicional para la compensacin. Las actividades orientadas a personas tambin deben permitir que se produzca la compensacin despus del procesamiento nocturno. Esto requiere una tercera interfaz. Para la orquestacin de transacciones de valor alto, las interfaces de servicio necesitan su propia compensacin interna. ste, evidentemente, todava no es el caso en la tecnologa actual. La ampliacin en la otra dimensin requiere aumentar la tasa de mensajes. Los motores de orquestacin tienen un problema de rendimiento inherente. Un motor BPEL tiene ms trabajo que un monitor de transacciones, que inspecciona los encabezados de los mensajes y distribuye mensajes a programas con conjuntos simples de reglas. Primero, tiene que buscar los conjuntos de correlacin de cada mensaje entrante (igual que las reglas en un monitor de transacciones). Hasta el momento, no hay diferencias. Pero luego tiene que analizar el contenido del mensaje y buscar el valor de los conjuntos de correlacin: BPEL no puede distribuir a partir de encabezados de mensaje. Y lo que es peor, el motor de BPEL tiene que
27 15

e/mensaje

Agentes de mensajes

Slo por invitacin

Barrera de complejidad
No importa Dispositivos de mensajes

BPM Barrera de distribucin

14 26

Mensajes/segundo

utilizar estos valores para explorar la base de datos de instancias en busca de instancias de flujos de trabajo en los que el mensaje complete una actividad. Esto resulta mucho ms complicado que un monitor de transacciones que realice la distribucin y supone una gran barrera. Algunas estimaciones consideran que esta va es 1.000 veces ms lenta. Y hay pruebas. Las aplicaciones de aprovisionamiento para servicios pblicos han utilizado el flujo de trabajo durante algn tiempo y en cualquier momento dado tienen una gran cantidad de flujos pendientes (hasta medio milln). Se ha informado de que una aplicacin de ese tipo, en Francia, necesita un complejo de procesadores UNIX de 72 vas para ofrecer un rendimiento aceptable. Con la tecnologa de hoy en da, es muy difcil que BPEL salga del cuadrante no importa.

Error conceptual 5: Pensar que la integracin de SOA es para programadores, no para analistas
En una nota de prensa de COBOL a finales de los aos sesenta, el pionero de la informtica Grace Hopper manifest: Ahora los programadores pueden escribir los programas en ingls. En un sentido compartimos su punto de vista: los programadores son ms productivos cuando trabajan con interfaces intuitivas. Por otro lado, desde nuestra posicin de ventaja histrica, podemos ver que la mayora de los programas en COBOL apenas se parecen al ingls. Hay un buen motivo para ello: un lenguaje de programacin es fundamentalmente distinto del ingls hablado. Esto se aplica aunque el lenguaje de programacin est camuflado por diagramas de flujo. Todos los metadatos de los servicios web son fsicos. Si crea un servicio web a partir de un sistema SAP, obtendr elementos con abreviaturas ininteligibles de definiciones en alemn. Si crea un servicio web a partir de una base de datos, obtendr elementos de datos que corresponden a nombres incomprensibles que ha asignado el programador a las columnas de los esquemas de base de datos. Los metadatos lgicos eliminan todas las cuestiones especficas de implementacin de los metadatos, como los tipos de datos fsicos y las restricciones de implementacin. Se trata del tipo de metadatos que puede manejar un analista. Los metadatos conceptuales constituyen un trmino de negocios que no est relacionado con las mejores prcticas para la implementacin, como la normalizacin o la optimizacin de rendimiento. Lamentablemente, los usuarios de negocios que escriben flujos de proceso para crear servicios deben utilizar metadatos conceptuales . Y ms lamentable todava es que no haya apenas capacidad para que

14 28

29 15

los servicios web se representen en metadatos conceptuales en la tecnologa de hoy en da. Ni tampoco existe la esperanza de que esta situacin vaya a cambiar en un futuro prximo. Esto significa que la creacin de procesos basados en BPEL es una tarea de programadores, aunque el lenguaje de programacin est oculto.

Despus, los procesos por lotes. Los procesos por lotes actan en colecciones de datos entrantes (colecciones de eventos) y, por lo tanto, proporcionan una oportunidad natural de dividir las colecciones en eventos individuales.  Finalmente, las orquestaciones. Como los eventos y los servicios se tienen que crear en un modo de acoplamiento flexible para poder implementar las orquestaciones, debe pasar bastante tiempo para obtener un retorno de la inversin en los proyectos que requieran orquestacin. Pero una vez que los eventos y los servicios se han creado para ayudar en la integracin de silla giratoria y los procesos por lotes, se pueden evaluar correctamente las orquestaciones que se puedan crear de forma rentable mediante el uso de los anteriores.  Siempre tener en cuenta la compensacin. Cuando se crea una interfaz de servicio para fines de orquestacin, hay que tener en cuenta la compensacin, tanto inmediata como despus del procesamiento nocturno. Adems, como probablemente se querr que todos los servicios sean reutilizables, hay que plantearse cmo se compensaran incluso si el proyecto inicial no requiriera compensacin.

Recomendaciones
Ahora que hemos aclarado los errores conceptuales, podemos extraer algunas conclusiones sobre la integracin basada en SOA y cmo suprimir algunas de las posibles barreras. A continuacin se ofrecen algunas recomendaciones sobre cmo se puede enfocar SOA en la actualidad:  Primero integrar, despus orquestar. Cree los flujos de proceso sin estado que describan el tratamiento de un evento de negocios (proceso dirigido por eventos, no basado en RPC) y despus determine cmo se deben propagar los eventos de un entorno a otro.  Primero la integracin de silla giratoria. Con la expresin oportunidad a corto plazo se hace referencia a un sistema que desencadena un evento distinto en otro. El nombre silla giratoria deriva de la imagen de un empleado sentado en una silla que crea un evento en un sistema (por ejemplo, purchaseOrderAccepted) y, a continuacin, gira la silla hacia otro monitor e introduce los mismos datos de evento en dicho sistema. La integracin de silla giratoria crear resultados inmediatamente y si se realiza pensando en reutilizar eventos y servicios de negocios, tambin proporciona los eventos iniciales que impulsan todava ms los procesos de negocios.

Ms informacin
Para obtener ms informacin sobre cmo Information Builders ayuda a las empresas lderes a integrar sus negocios, visite www.informationbuilders.es o llame al +34 91 710 22 92

14 30

15 31

Acerca de Information Builders Information Builders, una empresa innovadora del sector durante ms de 32 aos, ha ayudado con xito a ms de 12.000 clientes a aumentar la visibilidad de sus negocios, lo que permite que los usuarios de todos los niveles tomen decisiones contando con la informacin necesaria. Information Builders ofrece inteligencia de negocios (WebFOCUS) y soluciones de integracin (iWay Software) que proporcionan informacin procesable extrayndola de datos operativos y financieros. El conjunto de programas WebFOCUS, que se compone de soluciones exhaustivas de inteligencia de negocios para la empresa e informes web en tiempo real, cumple las necesidades de informes de la toda empresa, desde analistas pasando por usuarios avanzados y hasta implementaciones ms extensas para cientos de miles de usuarios. iWay Software acelera la integracin de negocios al ofrecer soluciones de integracin y de base SOA. Los clientes obtienen el retorno de la inversin a corto plazo mediante el uso de iWay para reducir la programacin a medida y solucionar los problemas rpidamente, a la vez que van creando progresivamente una arquitectura gil que admite proyectos a largo plazo. La tecnologa galardonada de Information Builders ha proporcionado software de calidad y servicios excelentes a ms de 12.000 clientes, incluida la mayora de las empresas del listado Fortune 100 y agencias gubernamentales federales de EE.UU. Con sede en la ciudad de Nueva York y 90 oficinas en todo el mundo, la empresa da empleo a 1.600 personas y tiene ms de 350 socios de negocios.

14