BUENAS PRÁCTICAS Y LECCIONES APRENDIDAS EN OSB

Para la implantación de un proyecto SOA es importante considerar el manejo de un ESB que controle la comunicación entre los servicios entre otros puntos importantes. Por otro lado, el contar con dicha capa de virtualización los clientes no podrán consumir directamente los servicios expuestos por los proveedores, proporcionando agilidad en las transformaciones, orquestaciones, desacoplamiento entre servicios expuestos y/o los servicios consumidores. Así mismo, los beneficios a considerar por utilizar OSB son:

- La mediación.
- La transformación.
- El redirecionamiento.
- La eliminación de conexiones punto a punto.
- Virtualización.
- Orquestamiento.
- Balanceo entre servicios.
- Aseguramiento de Servicios.
- Desacoplamiento entre clientes y proveedores.

Para el cumplimiento de esto ORACLE, ofrece su propio ESB denominado OSB (Oracle Service Bus), con la finalidad de cubrir dichos puntos importantes. Así mismo, con relación a los desarrollos en esta herramienta, se debe tener claro que el OSB deberá ser el intermediario de los servicios, convirtiéndose  en la columna vertebral de integración empresarial, debiendo ofrecer un altísimo desempeño en el bus, para cumplir esta meta se debe de considerar algunos puntos conocidos como buenas prácticas y/o lecciones aprendidas en base a la experiencia en muchos proyectos de similar calibre. Estos son:

A. ¿QUE SE DEBE CONSIDERAR EN OSB?:

• Se debe de considerar que el OSB debe tener altísimo desempeño, monitoreo, soporte a legacy, disponibilidad 24x7, siendo considerado como única plataforma base de la infraestructura SOA. 
  
• Se debe utilizar XmlObject y XmlCursor en Java Callout , ya que con esto se puede manejar toda la potencia de las bibliotecas Java, para cubrir necesidades de procesamiento de mensajes.
  
• Se debe de generar automáticamente los WSDL (topDown). Lo mismo puede decirse acerca de las transformaciones de XQuery.
  
• Se debe de reutilizar en los WSDL  los  XSD de manera externa en un servidor SOA-MDS, esto para fomentar la reutilización de estos.
  
• Se debe redefinir la URL del servicio virtual expuesto por el OSB, esto debido a que la URL generada es muy extensa. Esta desde ser redefinida desde el Transport del Proxy Service respectivamente.
  
• Se debe establecer por cada  Proxy Service y Business Service un tiempo de espera (TimeOut).
  
• Se debe de incentivar el uso de Split-Join para reducir la latencia. Esto debido a que las ejecuciones en paralelo se utilizan para reducir la latencia cuando se consume altos recursos del sistema. Se debe analizar que si un conjunto de actividades no tienen dependencia (unos de otras), estas pueden ser ejecutadas en paralelo.
  
• Se debe de usar un Dynamic Routing para dinámicamente invocar un diferente Business Service.
  
• Se debe de usar un HTTP Transport  de un Proxy Service para aceptar llamadas RESTful. Mapear métodos HTTP (GET/PUT/POST/DELETE) para la operación SOAP, usando un nodo: Branch Conditional.
  
• Se debe de usar el transporte JEJB en ambos extremos de OSB, para desacoplar los EJB consumers de los EJB  providers.
  
  
  
• Se debe de usar un  Conditional Branch o un Routing Table en lugar de una sola acción de Routing.
  
• Se debe usar un Result Caching para almacenar en memoria la información del OSB.
  
• Se debe usar un adaptador JCA para integrar los sistemas Legacy a través de adaptadores proporcionados por la SOA Suite, tales como, DB, File, FTP adapters y EJB, JMS, File y FTP Transport.
  
• Se debe considerar el control de Exception (fault) y logging en todos los servicios.
  
• Se debe de manejar la  auditoría para el rastreo de los servicios. Un complexType que contenga tiempo de respuesta, codResp, DetaResp, nombUsuario, nomApplicacion, ipAplicacion. Se debe  registrar eficientemente dicha información por ejemplo con log4j  de manera asíncrona a un archivo. 
  
  
• Se debe configurar siempre el controlador de errores a nivel de servicio. Cualquier tipo de error existente en el Pipeline debe ser controlado por medio de los nodos que brinda el OSB. Esto se puede aplicar  en las 4 áreas diferentes en el OSB: Pipeline, Proxy Service, Route Node, Stage Node. Esto para que no exista una respuesta de error estándar (como un error de SOAP que puede auto generar con el TopDown).
  
• Se debe considerar si un servicio de proxy tiene un WSDL con múltiples operaciones, generalmente se recomienda el uso de: operational branch, para manejar mensajes por separado para cada operación en vez de blogues: IF.
  
• Se debe considerar las acciones de actualización como: Delete, Insert, Replace, Rename, son más eficientes para correcciones pequeñas en un documento, que usando Asign con XQuery debido a que regenera todo el documento, sobre todo si el documento es grande.
• Se debe utilizar para transformaciones con XQuery el uso de XQuery mapper. Esto debido a puede ser más productivo (más rápido). Así mismo, una subRutina XQuery puede ser menos eficiente que acciones de transformación como: Rename, Delete, etc.
  
• Se debe de configurar los servicios en OSB en modo alta disponibilidad  (cluster), esto para que el procesamiento de carga sea compartido por cada server (físico / virtual) , así mismo para que el servicio pueda estar expuesto  y si uno URL no está disponible,  se pueda acceder de forma automática al otro server.
  
• Se debe en vez de tener un solo controlador de errores en todo el Pipeline, apoyarse en cada nodo Stage ya que en un diseño request/response Pipeline, se puede controlar los errores existentes en su interior por cada Stage.
  
• Se recomienda configurar el Throttling para la protección de los servicios OSB, con relación a los picos de sobrecarga. Throttling puede definir políticas de limitación de peticiones para un servicio de negocio dentro de OSB. Esto para evitar que se alcance la capacidad de un servicio web y se continúe aceptando conexiones.
  
• Se debe utilizar para la creación de DataSource de tipo Select (Operaciones Query), el los Driver que brinda Weblogic de tipo: non-XA. Esto con relación al futuro manejo del JCA que será autogenerado.
  
• Se recomienda el uso de expresiones FLOWR (acrónimo de: For, Let, Where, Oorder By, Return), en la creación de los XQuery.

B. ¿QUE SE DEBE EVITAR EN OSB?:

• No se debe  tratar de desarrollar toda una solución sólo en OSB. Ya que el OSB es un ESB y este NO debe ser usado para manejar lógica de negocio y ser utilizador exclusivamente para desarrollos ESB (Mediación, redireccionamiento, transformación).  Es muy común que en muchos proyectos se cometa este error (el desarrollo de la totalidad de su solución en OSB).
  
• No se debe diseñar flujos transaccionales StateFul dentro de OSB. Esto debido a que OSB es una herramienta de tipo StateLess, que no debe ser utilizada para manejar transacciones StateFul. Para este manejo transaccional StateFul se debe utilizar como solución BPEL o BPM en vez de OSB.
  
• No se debe usar OSB para ejecutar SQL ó llamados a Store Procedimientos complejos: Aunque OSB proporciona mecanismo para ejecutar estos dentro del ‘pipeline’, se debe restringir su manejo sólo para operaciones para recuperar datos (SELECT), nunca se debe de ejecutar para operaciones SQL de tipo CRUD (INSERT / UPDATE / DELETE) dentro del pipeline en OSB.
  
• No se debe usar Java CallOut para satisfacer necesidades de negocio. Esto debido a que las llamadas Java es la característica más abusado de OSB (y a veces se abusa de su manejo). Sea cual sea la lógica de negocio no debe ser manejada a través de OSB  (Java CallOut) para implementaciones de lógica de negocio compleja, dentro de  OSB pipeline. Puede ser utilizada para tareas utilitarias como transformaciones puntuales o para log. 
  
• No se debe desarrollar lógica de negocio compleja dentro de OSB pipeline: Teniendo en cuenta el hecho de que se puede cambiar fácilmente en Runtime desde la consola OSB. Oracle SOA Suite maneja lo que se conoce como OBR (Oracle Business Rule) para definir la lógica de negocio, así que por qué definir reglas de negocio en otro lugar (OSB). Se debe de definir reglas de negocio en OBR y exponerlas como servicio web, para posteriormente consumir dichas reglas de negocio en OSB (como WS) cuando sea requerido.
  
• No se debe utilizar la consola OSB para el desarrollo. Anteriormente en OSB no había existía el apoyo de IDEs, pero actualmente el desarrollo directamente desde la consola OSB es considerado reliquia. Actualmente, soluciones como OEPE  permiten crear proyectos OSB y componentes de manera local, que puede ser fácilmente controlados. Así mismo, se debe tener en cuenta que desarrollos OSB por medio de OEPE tiene muchas ventajas sobre la consola OSB como Xquery editor, split-join, etc.
  
• No se debe utilizar WS Policy para el control de  Seguridad en OSB. Para implementar la seguridad alrededor de Servicio OSB utiliza OWSM (Oracle Web Service Manager), esto debido a que las políticas en Weblogic no están actualizadas.
  
• No se debe desarrollar los flujos de mensajes completos en un solo Stage dentro de un Pipeline. Esta es una mala práctica muy común, el manejar  todo en un solo Stage así como definir los nombres sin mucho significado. Se debe manejar cada parte que tenga acciones relevantes (agrupando), con nombres de Stage explicando claramente lo que hacen.
  
• No se debe procesar archivos de gran tamaño a través de OSB. Ya que OSB no es para trabajo pesados, para estos casos se debe utilizar ODI (Oracle Data Integrator), que es una herramienta especializada para el procesamiento de archivos de gran tamaño.
  
• No se debe manejar comodines en expresiones de tipo XPath. Se debe evitar el uso de caracteres comodines con:      * u operadores recursivos de ruta como: "//" con  XPath. Esto debido a que su manejo causa impacto en el rendimiento significativo. Se debe evitar lo más que pueda.
  
• No se debe crear un Proxy Service es de tipo: Any SOAP, Messaging type services o Any XML ya que OSB tiene problemas al autogenerar WSDL eficaces para este tipo de servicios, es preferible seleccionar los tipos SOAP desde .WSDL ó XML desde .WSDL, esto para favorecer los estandarizado con el TopDown (todos lo objetos definidos dentro de la interface): element, message, portType, etc. Así mismo, posteriormente apoyarse con el nodo: Operationa Branch para automáticamente reconocer cada operación existente.
  
• No se debe abusar en las comunicaciones de datos, enviando parámetros en XML (como Texto). Estas se deben de minimizar ya que el Marshalling / Unmarshalling de mensajes, es de las acciones más costosas en OSB.
  
• No se debe abusar del manejo de Proxies EJBs (EJB Transport). Esto permiten la transformación de: XML a Java, pero son caros tanto para el mantenimiento como para el rendimiento. Si es necesaria la interacción  con el mundo Java, verificar si es que no se pueda realizar simplemente usando un Java Callout. EJB Transport está diseñado para ofrecer un débil acoplamiento orientados a la interface por medio de un WSDL autogenerado. Este binding tiene un costo de trasformación que es aceptable cuando el EJB representa un servicio reutilizable. Así mismo, un Java Callout puede ser una mejor solución para acceder a un EJB, y obtener un más bajo acoplamiento.
  
• No se debe  crear de muchas variables de contexto OSB, que se utilicen una sola vez dentro de algún XQuery. En si la creación de variables se debe de realizar con el objetivo de la reutilización en varias partes del OSB.
  
• No es recomendable el manejo de XLST en proyectos en OSB. Si analizamos XSLT es para XQuery como JavaScript es para Java y en actualmente no existe una equivalencia en versiones con relación al motor de transformaciones de xsl existente en OSB con el actual generando por ello muchos errores. Debido a ello de preferencia para todo tipo de transformaciones en OSB es mejor considerar trabajarse con XQuery. 
  
• No se debe de crear componentes JCA para consumir Store Procedure que manejen ORACLE Types, esto debido a que el OSB  como herramienta autogenera unos ORACLE Package como Wrappers que contienen todo el parseo de equivalencias. Esto genera problemas con las áreas de QA, ya que por su estructura es muy complicada su prueba como Script (PL/SQL) y traerá problemas al momento del pase. Es preferible referenciar a Store Procedure que manejen parámetros de tipos nativos.

Esperemos que estas recomendaciones sean consideradas y aplicadas de la mejor manera, para que mejoren el rendimiento de estos en sus proyectos de tipo OSB.