Oracle sigue planeando su ataque a SOA Quinta parte: la adquisición de Collaxa




Collaxa

A pesar de que se subestima la posición que ha adoptado Oracle Corporation (NASDAQ: ORCL) hacia la arquitectura orientada al servicio (SOA) y la gestión de los procesos del negocio (BPM), la adquisición que realizó de Collaxa pone en evidencia que Oracle los está tomando en cuenta para su estrategia de productos. Gracias a Collaxa, Oracle será capaz de proporcionar nuevas funciones de reportes que supervisarán el progreso de los procesos del negocio. Ahora puede ofrecer capacidades para el flujo de trabajo, herramientas de supervisión y soporte al funcionamiento para el lenguaje de ejecución de los procesos del negocio (BPEL). Estas circunstancias deben ayudar a eliminar la ambigüedad de los enfoques en SOA y BPM que tiene Oracle. Es posible que Collaxa tenga un efecto más profundo sobre ciertos productos Oracle, además de que puede darle la oportunidad para convertir a más usuarios.

Collaxa fue fundada en diciembre de 2000 por Edwin Khodabakchian, que formó parte del equipo de servidores de Netscape Communications y AOL. En un principio, el modelo del negocio de la empresa era similar al que buscaba WebLogic antes de ser adquirida por BEA. Su objetivo era básicamente crear el mercado para el servidor de aplicaciones Java. Del mismo modo, Collaxa vio la oportunidad para hacer algo similar con su producto Web Services Orchestration Server (WSOS) (que posteriormente llamó Collaxa BPEL Server y que ahora se conoce como Oracle BPEL Process Manager). Este producto pretendía ayudar a los desarrolladores de Java a trabajar en la integración de proyectos de gran escala, dándoles un método para orquestar por medio de coordinación, gestión y supervisión de los servicios web. Posteriormente, Collaxa estableció sociedades estrechas con todos los proveedores principales de servidores de aplicaciones J2EE, como BEA, IBM, Oracle y Sun, que utilizan WSOS para realizar la orquestación. También se asoció con Computer Associates (CA) para proporcionar su plataforma de gestión de infraestructura, Unicenter, con el soporte de la norma BPEL. Sin embargo, ahora que Oracle ha mordido el anzuelo y se ha apropiado del producto de Collaxa, sólo el tiempo dirá si estas sociedades continuarán.

Collaxa fue uno de los pioneros en la orquestación de servicios web gracias a su proceso de dos pasos para volver dichos servicios funcionales: publicar primero y orquestar después. En otras palabras, integrar estos servicios web publicados y coordinar los mensajes entre ellos para crear los procesos del negocio.

La orquestación consta de tres elementos principales:

  1. coordinación, que incluye comunicaciones asíncronas, manejo de eventos, protocolo para las transacciones del negocio (BTP), agrupamiento y capacidad de graduación

  2. gestión, que incluye administración, gestión de las cancelaciones y los cambios, excepción y suspensiones y control de las versiones

  3. supervisión de las actividades, que incluye reportes sobre el negocio, auditorías y no rechazos.

Sin embargo, la naturaleza libremente conectada de los componentes de los servicios web puede crear complejidades, como la necesidad de coordinar la mensajería asíncrona, que no ocurre en intervalos regulares o predefinidos. El término asíncrono se usa normalmente para describir comunicaciones en las que es posible transmitir los datos de forma intermitente y no en un flujo constante. Por ejemplo, una conversación telefónica es asíncrona porque ambas partes pueden hablar cuando quieran. De otro modo, si la comunicación fuera sincrónica, cada parte tendría que esperar un intervalo específico antes de hablar. La dificultad que presentan las comunicaciones asíncronas es que el receptor debe tener una forma para distinguir entre los datos válidos y el ruido. En las comunicaciones por computadora, esto se logra generalmente mediante un bit de salida y un bit de parada al principio y al final de cada porción de datos, respectivamente. Por ello, la comunicación asíncrona se conoce a veces como transmisión arrítmica.

Esta es la quinta de seis partes que conforman esta nota.

La primera parte trató el resumen del evento y el impacto en el mercado.

La segunda parte habló de la estrategia.

La tercera parte cubrió los cambios en la estrategia.

La cuarta parte examinó SOA y los servicios web.

La sexta parte hablará de las debilidades y dará recomendaciones a los usuarios.

Collaxa usa BPEL

Collaxa atacó las complejidades de la comunicación mediante su capa de abstracción, en donde su solución interactúa con los sistemas de ejecución dispares a través de BPEL. Funciona encapsulando la orquestación requerida por las instalaciones para coordinar, administrar y supervisar los procesos del negocio orientados al servicio. Posteriormente, los desarrolladores entran en contacto con estas instalaciones mediante un componente parecido a JSP llamado ScenarioBean, que tiene base en normas de la industria como XML, SOAP, WSDL, Java Message Service, BTP y ebXML (XML para negocios electrónicos). Además de ScenarioBeans, que permitió que los desarrolladores de Java crearan varios servicios web e interacciones con los usuarios, WSOS de Collaxa presentó otros dos componentes primarios: 1) el servidor de orquestación y 2) la Web Service Orchestration Console de Collaxa para administrar los servicios. En palabras más simples, los servicios web permiten que las aplicaciones intercambien y reutilicen la información fácilmente. Sin embargo, las empresas pueden lograr su valor real únicamente cuando se orquestan (coordinan) en flujos o procesos del negocio de funcionamiento prolongado.

Aquí aparece BPEL. También conocido como BPEL4WS, es un lenguaje basado en XML que se usa para normalizar los procesos del negocio en un ambiente de cómputo distribuido o cuadriculado que permite que los distintos negocios interconecten sus aplicaciones y compartan sus datos. Proporciona un lenguaje de programación estándar que los negocios pueden usar para definir la forma en que combinarán los servicios web para completar sus tareas. Así, la especificación de coordinación de WS describe la forma en que interactuará cada servicio web dentro de la tarea. Mientras tanto, la norma de transacciones de WS determinará si se terminan todas las transacciones satisfactoriamente o si fracasarán como grupo. En la pila de protocolo de los servicios web, BPEL es una capa que está por encima de WSDL y que utiliza para especificar las acciones que deben realizarse en un proceso del negocio. Describe los servicios web que proporciona un proceso del negocio.

BPEL, que es independiente de la plataforma, se diseñó como una combinación de especificaciones patentadas del Web Services Flow Language (WSFL) de IBM y el XML business process language in BizTalk Server (XLANG) de Microsoft. Permite que las empresas mantengan una separación entre los protocolos internos del negocio y los protocolos de toda la empresa, permitiendo cambiar los procesos internos sin afectar el intercambio de datos entre empresas. Por ejemplo, un documento BPEL mantiene un registro de todos los procesos del negocio que están conectados a una transacción y se asegura de que los procesos se ejecuten en el orden correcto durante la automatización de los mensajes.

Como formato basado en las normas que transfiere procesos entre plataformas mientras se mantiene independiente de ellas, BPEL parece estarse convirtiendo en un elemento importante de la taxonomía de los servicios web y BPM. También recibe apoyo de BEA y SAP. Collaxa, que ha apoyado BPEL durante mucho tiempo, presume que estas dos importantes empresas sean usuarios de su motor.

Ahora los clientes pueden usar Oracle BPEL Process Manager para orquestar los procesos que se utilizan en infraestructura Java o .NET de Microsoft. El producto soporta las normas más recientes como BPEL 1.1 o XML 1.0, además de que los servicios web pueden permitir que los procesos integrados del negocio se transporten entre las plataformas sin importar la tecnología subyacente. Sin embargo, aunque Oracle es capaz de afirmar que su producto es el único servidor BPEL nativo del mercado, algunos competidores como BEA y webMethods tienen en el mercado varios productos que no son nativos nominales de BPEL. Estos productos permiten la importación y la exportación entre BPEL y sus propios formatos patentados mediante sociedades como la que tiene con The Middleware Company. A pesar de que tiene muchos partidarios, BPEL sigue siendo una de tantas normas emergentes en el área general de BPM. Existen otras como lenguaje de modelos de los procesos del negocio (BPML) o lenguaje de descripción de procesamiento SML (XPDL) e interfaz de coreografía de servicios web (WSCI), que tiene el respaldo de BEA, Intalio, SAP y Sun.

Retos

Esto nos lleva a la oferta de EAI y servidor de aplicaciones de Oracle, que hasta hace poco se volvió tan completa y abierta como los productos IBM WebSphere o SAP NetWeaver. Sin embargo, Oracle sigue incorporando cambios a su mantra de sistemas empresariales estándar que todo lo abarcan y que son tan simples como sea posible. Aunque no se ha dado por vencido y sigue luchando por ser la solución de un solo vendedor, hace poco modificó los consejos que da a los usuarios (consulte Oracle Makes a U-Turn at the 'All Things to All People' Exit) proporcionándoles interfaces de programación de aplicaciones (API), lenguajes de definición de datos y datos para ayudarlos con la integración.

Hasta hace poco, los usuarios tenían que comprar las tres capas de los productos Oracle —Oracle Database, Oracle Application Server y Oracle E-Business Suite—, ya que la empresa quería impulsar su visión de una solución del negocio completa y en colaboración. Sin embargo, resulta intrigante cómo Oracle tuvo que dividir algunas de sus funcionalidades entre estas tres capas, mientras que otros proveedores las mantuvieron reunidas en el nivel de las aplicaciones. Aún con la presencia de SAP NetWeaver y IBM WebSphere, únicamente Oracle y Microsoft tienen las tres plataformas en donde se puede extender la funcionalidad. No existe nadie más en el mercado que pueda hacerlo. Por ello, es posible que muchos prospectos no acepten la visión de Oracle por miedo al cierre y las obligaciones tecnológicas que vienen con la compra de estos tres componentes. También es evidente que Oracle dispersó las capacidades de forma intencional en estos niveles para hacer que aquellos clientes que de verdad quieren una solución completa compren las tres capas. El resultado es que la empresa sacó del panorama las bases de datos SQLServer de Microsoft y DB2 de IBM, y los servidores de aplicaciones de WebSphere de IBM o WebLogic de BEA, respectivamente. Sin embargo, actualmente Oracle Application Server no necesita de Oracle Database, y vice versa, y Oracle E-Business Suite no requiere de Oracle Application Server, ya que más de las dos terceras partes de Oracle E-Business Suite funciona en Java y J2EE. Esto debe ayudar a calmar los miedos de cierre que tienen los posibles usuarios.

Sin embargo, es probable que Oracle siga enfocándose en exponer los procesos dentro de sus aplicaciones y en integrar sus herramientas de desarrollo para maximizar el potencial de Oracle BPEL Process Manager y asegurar más a los usuarios. Pero Oracle también debe ofrecer herramientas de diseño y desarrollo más avanzadas que automaticen la abreviación de BPEL Process Manager, Oracle JDeveloper y los modelos tradicionales, como el lenguaje de modelos unificado (UML). Aunque las adquisiciones que Oracle ha realizado recientemente deben ayudarle a lograrlo, debe realizar un trabajo importante para reunir todos estos productos. La principal debilidad de la plataforma sigue siendo su complejidad, aunque no debe atribuirse nada más a Oracle. El tiempo dirá cómo se adapta Oracle BPEL Process Manager a las aplicaciones actuales de planificación de los recursos de la empresa (ERP), gestión de las relaciones con los clientes (CRM) o gestión de la cadena de suministro (SCM) de Oracle, que tienen que recibir certificación para Oracle Database 10g, aunque Oracle E-Business Suite 11i.10 ya esté funcionando en vivo en Oracle Application Server 10g.

Es por eso que las grandes empresas querrán considerar otras soluciones que probablemente sean más completas. Es posible que acudan a los vendedores de BPM, SOA o servicios web que mencionamos, para crear, administrar y orquestar procesos complejos de alto volumen que incluyan personas, datos estructurados, contenido sin estructurar y manejo de las excepciones. Si Oracle malgasta la oportunidad que le presenta Collaxa para persuadir a más talleres que no le pertenecen, es muy probable que siga su desdichada búsqueda del “toque mágico” que diferenciará sus ofertas de productos (consulte Stalled Oracle Fumbling For A Jump-Start Kit). Desafortunadamente para las aplicaciones de Oracle, aunque los intentos han estado enfocados en la dirección adecuada, han sido pasos demasiado pequeños y algunos hasta repetidos. Sin embargo, a partir de junio de 2004, son más de 22,600 los usuarios que utilizan Oracle Application Server fuera de Oracle E-Business Suite —sin contar los 7,100 clientes de Oracle E-Business Suite que usan Oracle Application Server. Estos números demuestran que al menos Oracle Application Server va más allá de los talleres de Oracle.

La idea de construir a partir de la automatización de los procesos del negocio hacia otros procesos más sofisticados que van en dirección externa sería atractiva si el motivo final de Oracle no fuera terminar con todos los sistemas empresariales que funcionan actualmente en su base de datos para reemplazarlos con Oracle E-Business Suite. Aunque Oracle puede representar una propuesta convincente para los sitios “no urbanizados” (¿cuántos de ellos existen todavía?), muchas empresas mantienen su posición escéptica cuando se enfrentan a las complejidades de la integración con varios sistemas empresariales legados y con las más recientes mejores aplicaciones de ERP extendido proporcionadas por terceros.

Con esto concluye la quinta de seis partes que conforman esta nota.

La primera parte trató el resumen del evento y el impacto en el mercado.

La segunda parte habló de la estrategia.

La tercera parte cubrió los cambios en la estrategia.

La cuarta parte examinó SOA y los servicios web.

La sexta parte hablará de las debilidades y dará recomendaciones a los usuarios.

 
comments powered by Disqus