DEFINICIÓN DE ESTRUCTURA DE DIRECTORIOS EN OSB 12c

El manejo de los estándares en todo tipo de proyectos es importante, ya que permite definir un mismo modo de trabajo (un estándar), con relación a todo el equipo de desarrollo. Estos estándares pueden ser aplicados a prácticamente todo, desde fuentes, documentación etc.

A nivel de Oracle Service Bus (OSB), esto también es recomendable que se aplique, para la creación de los proyecto OSB relacionados los Servicios Virtuales: (Exposiciones, Virtualizaciones, etc). En esta oportunidad mostraré una forma de cómo estandarizar la Estructura de Directorios del proyecto OSB propiamente, con relación al manejo de un proyecto mediano/grande a nivel departamental. Dicha estructura de directorios debe ser capaz de soportar ser lo más ordenado y reutilizable posible, pensando en la gran cantidad de Servicios Virtuales que manejará internamente, así mismo como facilitar la segmentación y mantenimiento de estos.

La Estructura de Directorios propuesta, para este tipo de proyectos OSB de mediano/grande envergadura, así como la extensión de los archivos manejados por directorios, son las que se muestran en imagen:

Cada Estructura de Directorios tiene una finalidad con relación a lo que manejará en su interior. Esta estructura está bien detallada:

El contenido de los archivos deberán tener así como una ubicación fija (directorio), una nomenclatura estándar con relación al nombre del proyecto/servicio/operación manejado. La propuesta es la siguiente:

Finalmente, como se visualizaría dicha Estructura de Directorios estándar propuesta, a nivel de la herramienta sería de la siguiente forma: (Los nombres de empresa, servicios, etc, son subjetivos)

Así mismo, desde la consola OSB el agrupamiento departamental de los proyectos/servicios de tipo OSB, deberían visualizarse de la siguiente manera:

Espero que este post haya sido de gran importancia para eliminar duda alguna existente anteriormente, sobre la definición para el manejo de una correcta Estructura de Directorios en OSB.

CATCHING & LOAD BALANCING EN OSB

En post anteriores he explicado sobre la importancia del manejo del Cache en las aplicaciones y servicios por medio del framework Ehcache. En esta oportunidad daré detalles de cómo manejar dos temas muy importantes que son el Catching, así mismo como el Balanceo de Carga a nivel de Oracle Service Bus 12c.

Este artículo se ha creado para ayudar a aquellos que quieren poner en marcha el almacenamiento en caché por medio de OSB, ya que en él se describe cómo utilizar esta funcionalidad por medio de un ejemplo de cómo el cache maneja dicho almacenamiento y como distribuir la carga existente por medio del balanceo de carga, para mejorar el rendimiento por medio del caché y la configuración de equilibrio de carga en OSB. Así mismo,  OSB proporciona una funcionalidad que viene ya integrada, que es el soporte de caché por medio de Oracle Coherence, que brinda muchas estrategias de almacenamiento en caché, a continuación se procederá con la explicación.

Antes que nada, es necesario para el dummy preparado crear un Web Service con JaxWS, para ejecutarlo a modo local sin necesidad de desplegarlo en un servidor. Este Web Service expondrá dos servicios con diferente puerto simulando dos server distintos:

• http://localhost:8098/ServidorWS_JAXWS_Generado/UsuarioDAOImpl?wsdl
• http://localhost:8099/ServidorWS_JAXWS_Generado/UsuarioDAOImpl?wsdl

Luego, en la operación: sumar, hemos ingresado una línea para aplicar un delay de 10 segundos en la respuesta de dicho servicio, esto para probar posteriormente la eficacia del cache configurado.

Finalmente, crearemos en el OSB un Servicio Virtual de dicho servicio, en base al .wsdl (TopDown) ya expuesto. La URL de este servicio virtual será: 

• http://localhost:7101/Operaciones_SB/Pipeline/OperacionesWS?wsdl

I. CATCHING:

Para el manejo del Caching en OSB, realizaremos la configuración en el: BusinessService (Operaciones_BS) previamenete ya creado. Luego, vamos a la opción: Performance y habilitamos el check: Enable Result Caching. Después, configuramos en: Expiration Time, a nivel de: Días, Hora, Minutos y Segundos, que se requiere que el Cache almacene la información para posteriormente refrescar con la nueva info. Esto se debe configurar en base a la información que proporcione el negocio en escenarios donde la información NO variará, esto para agilizar la respuesta y evitar consultas a BD y/o servicios por gusto.

Para este escenario del dummy, configuraremos solo la parte de los segundos (20 segundos), para que se refresque dicho cache en ese tiempo.

Desplegamos el Servicio Virtual dummy e iniciamos la consola de pruebas, tal como se muestra en imagen.

Verificamos que al ser ejecutado el Servicio Virtual, demora exactamente 10 segundos en mostrar la respuesta (ANTES de aplicar la configuración del cache).

Posteriormente, a la configuración del Cache, el tiempo de 10 segundos para la respuesta del Servicio Virtual, será aplicado solo la primera vez que se ejecute. Ya que a la siguiente vez automáticamente se activará el Cache configurado e iniciará el conteo de tiempo de 20 segundos configurado. Esto efecto se puede apreciar desde la consola misma de pruebas, ya que la primera vez demorará y luego de ello, uno puede ejecutar varias veces y la respuesta demorará menos de un segundo en responder, ya que se obtendrá del Cache respectivamente, durante el delay configurado.

II. LOAD BALANCING:

Para el manejo del Load Balancing en OSB, realizaremos la configuración en el: BusinessService (Operaciones_BS) previamente ya creado. Luego, vamos a la opción: Transport y seleccionamos el Algoritmo que más nos acomode (en este caso: round-robin). Luego, agregamos la segunda URL que al inicio del post definimos (con diferente puerto) a la lista y finalmente, el máximo número de reintentos posibles y el intervalo entre cada uno de estos.

Finalmente, volvemos a desplegar el Servicio Virtual en la consola OSB y validamos el efecto ya con todo el Balanceo de Carga configurado.

Esperemos que el post haya sido de su agrada y lo puedan aplicar de la mejor manera en sus proyectos OSB. Para los interesados en descargar las fuentes (Eclipse & OSB) lo pueden hacer aquí:

http://www.mediafire.com/download/76562h6mo37731o/Dummy_Caching_%26_LoadBalancing.zip

(XSD) INCLUDE vs (XSD) IMPORT

Tanto en los proyectos SOA donde existe la necesidad de orientar la arquitectura a nivel de servicios, como en las exposiciones de sistemas Legacy y Virtualizaciones de Servicios por medio de OSB, en todos estos proyectos nace la necesidad de desarrollar servicios de tipo Web Service. Ahora, durante el diseño de dichos Web Service lo primero que se requiere hacer son los contratos de servicio (.wsdl), ahora nace aquí el problema ¿cómo los diseño?..., por medio de una IDE o manualmente, en mi caso yo recomendaría inicialmente apoyarse en una IDE como JDeveloper o Eclipse que manejan editores que facilitan de algún modo su creación, posteriormente cuando ya tengan práctica y como yo acostumbro hacer, por rapidez y conocimiento, es definir una plantilla base y desde ultraEdit aplicar replace a los nombres estándar de: wsdl:definitions, Namespace, xsd:element, wsdl:message, wsdl:binding, wsdl:service, wsdl:port, soap:address, wsdl:part, wsdl:operation. Así mismo, la edición del modelo de negocio dentro: wsdl:types.

Jústamente, aquí es la idea de este post, ya que es recomendable NO embeber el modelo por medio de los: wsdl:types, dentro de las interfaces: .wsdl. Aquí se genera la gran duda de muchos profesionales que es: ¿Cómo lo manejo con Include o con Import?, ¿Cual es la diferencia de ambos?, y que así nomás no se encuentra su explicación. La diferencia es la siguiente:

xsd:include: 

Se debe usar cuando se requiere manejar los datos de un .xsd con un mismo Namespace.

xsd:import:  
Se debe usar cuando se requiere manejar los datos de un .xsd con un diferente Namespace. 

Esto quiere decir que la gran diferencia entre ambos en a nivel de como uno diseñe su contrato de servicio, específicamente a como segmentará .wsdl y .xsd's con relación a sus Namespace.

Procederé a explicar mejor por medio de un dummy de un diseño que he creado para su mejor entendimiento, este consiste en un .wsdl y tres modelos .xsd:

ObtenerTecnologia.wsdl, este es el contrato de servicio el cual se ha diseñado para que NO se alterado y/o modificado posteriormente. Maneja un Namespace definido como: http://pe.com.eai.dummySOA/bean/obtenerTecnologiaWS, y segmenta su modelo de negocio de manera externa a el, por medio de un xsd.include ya que manejará el mismo Namespace: 

[xsd:include schemaLocation="./ObtenerTecnologia.xsd" /]

ObtenerTecnologia.xsd, es el modelo principal y base del contrato, este se ha diseñado para manejar un mismo contrato que dicho contrato: http://pe.com.eai.dummySOA/bean/obtenerTecnologiaWS. Así mismo, desde el se referenciará a los demás modelos .xsd que se han creado:

- Persona.xsd: la referencia con relación a este modelo, será por medio de xsd.include: [xsd:include schemaLocation="./Persona.xsd" /], ya que dicho .xsd SI manejará el mismo Namespace:  http://pe.com.eai.dummySOA/bean/obtenerTecnologiaWS

- Auditoria.xsd: la referencia con relación a este modelo, será por medio de xsd.import: [xsd:import namespace="http://pe.com.eai.dummySOA/bean/auditoria" schemaLocation="./Auditoria.xsd" /], ya que dicho .xsd NO manejará el mismo Namespace (ya que este modelo será REUTILIZABLE entre diferentes proyectos). El NameSpace que manejará será: http://pe.com.eai.dummySOA/bean/auditoria

Persona.xsd, es el modelo donde será definido los campos embebidos en los objetos: simpleType, complexType, relacionados directamente al negocio que el servicio implementado utilizará.

Auditoria.xsd, es el modelo donde será definido los campos de auditoría especificamente, embebidos en los objetos: simpleType, complexType, que serán REUTILIZADO en diferentes proyectos (modelos).  

Finalmente, con esto se completa la explicación del post. Para los interesados en el diseño explicado, pulsar aquí:
http://www.mediafire.com/download/l152h524h6l2rrb/xsd.include++VS++xsd.import.zip

PROCESOS PARALELOS CON 'SPLIT-JOIN'

Los procesos paralelos son muy importantes en todo flujo de tareas, así mismo en 'Oracle Service Bus 12c' (desde ahora OSB) este tratamiento también es utilizado en la mediación, debido a que es una buena práctica, ya que son mucho más ágiles y rápidos que los procesos secuenciales comúnmente usados.

OSB ofrece el manejo de este tipo de procesos por medio de su colección nodos, pero lastimosamente este manejo en paralelo no es muy utilizado comúnmente en los diferentes proyectos. OSB brinda lo que se conoce como Split-Join (Para los procesos PARALELOS) y Pipeline (Para los proceso SECUENCIALES). Así mismo, Split-Join proviene de un patrón que es SPLITTER este patrón consiste en dividir los mensajes grandes en muchos mensajes más pequeños y ser manejados todos estos en paralelo y por medio de JOIN, se vuelven a unir. Es importante mencionar que para el tratamiento en paralelo se debe antes que nada verificar que las tareas que se irán a poder en paralelo NO tengan dependencia alguna entre ellas.

En esta oportunidad mostraré como crear dicho Split-Join, con el objetivo de exponer dos servicios virtuales: DatosClienteService.wsdl y DeudaClienteService.wsdl, por medio de un SOAP-UI MockServices, dichos servicios simularan los posibles servicios creados en BPEL. Estos servicios serán virtualizado por medio de OSB y con los mismo .wsdls se generarán nuevas URLs propias del OSB. Estos Servicios Virtualizados son parte del proyecto: ExternalService (estos dos serán los servicios que se utilizarán en el posterior proceso en paralelo). Luego, se ha creado un proyecto: InternalService, en el cual se expondrá el servicio compuesto de tipo: Split-Join, que procesará los mensajes de cada Servicio Virtual (por medio de los: BusinessService's), y posteriormente integrará los mensajes de ambas respuestas en una sola respuesta final.

Los detalles de los recursos trabajados son:


Servicio Virtual #1:
http://localhost:7101/ExternalService/ClienteService/Pipelines/DatosClienteWS?wsdl

SOAP-UI (Mock#1):
DatosClienteService => DatosClienteService.wsdl 
http://localhost:8090/mockDatosClienteService?wsdl



Servicio Virtual #2:
http://localhost:7101/ExternalService/ClienteService/Pipelines/DeudaClienteWS?wsdl

SOAP-UI (Mock#2):        
DeudaClienteService => DeudaClienteService.wsdl   
http://localhost:8091/mockDeudaClienteService?wsdl   

Servicio Principal (Split-Join):
http://localhost:7101/InternalService/ClienteService/SplitJoin/InfoClienteWS?wsdl

Tal como se mencionó anteriormente, primero se debe de construir el proyecto base llamado: ExternalService, que contendrá los servicios que se procesarán en paralelo (BusinessServices):
 

Dentro de cada Pipeline, se debe redireccionar por medio de un nodo: route, del: Servicio Virtual, al servicio expuesto por los SOAP-UI MockServices:

Dentro del proyecto: InternalService, se debe de crear dos procesos: un Pipeline y un Split-Join. El proceso: Pipeline servirá solo para redireccionar el ProxyService creado (TopDown en base al: InfoClienteService.wsdl), al proceso: Split-Join. Dentro de este se manejará el proceso en paralelo respectivamente:

Dentro del proceso: Split-Join se diseñará todo el proceso en Paralelo requerido:

Las 'Variables Locales' almacenan el resultado los mapeos respectivos por medio de los nodos: Assign, así como por medio de los nodos: Invoke Service, se puede consumir los Servicios Virtuales respectivamente.

Finalmente, por medio de un nodo: Assign se integran todos los mensajes resultantes del consumo de los dos Servicios Virtuales, para luego ser integrados en un solo mensaje por medio de: XQuery.

Es importante recordar que para los mapeos en OSB 12c, la estructura de los XQuery, varía con relación a la estructura de creación de los XQuery (Tanto del editor como de código generado) con relación a la versión 11g, esto quiere decir que no se podrán reutilizar los XQuery que ya se tengan, pero no es complicada de interpretarlo.

 

Así mismo, tener en cuenta que NO todo el mapping se podrá realizar desde el editor, ya al igual que se hacía en la version 11g, para el tema de las listas se tendrá que hacer el mapping manualmente tal como se muestra en el ejemplo con dos FOR para la obtención de los atributos de la list de respuesta:

Considerar la creación de los XQuery como arma principal para todo trabajo de transformación a nivel de OSB, prefieriendo su uso antes al de XLST por tenas de rendimiento. Así mismo, evitar el uso de XQuery incrustado dentro del los nodos: Assign, por temas de mantenimiento.  

Esperemos que con el post se hayan cubierto todas las dudas con relación al manejo de Split-Join y puedan a partir de ahora aplicarlos en sus proyectos. Para los interesados se pueden descargar las fuentes del post desde aquí: http://www.mediafire.com/download/44dzwabl2ibo452/OracleServiceBusApp_SplitJoin.zip

 

APLICACIÓN DE SEGURIDAD EN OSB 12c

Debido a la constante necesidad para la comunicación entre servicios existentes en diferentes inventarios de servicios (externos), es importante conocer que el OSB al ser el bus de comunicación entre ellos soporta como una de sus características, el manejo de la seguridad entre estos. Esta será aplicada de modo que sólo los usuarios válidos pueden invocar. Por esta razón, en esta oportunidad mostraré cómo aplicar seguridad a los servicios virtuales desarrollados en OSB.

El dummy que mostraré consiste en una virtualización de un servicio (ya previamente creado), que por medio de la capa OSB, se accede al servicio compuesto principal (SOAPUI MockService).

Con fines del tema principal del tutorial que es la seguridad en sí, procederé a aplicar y mostrar los pasos a seguir para poder realizar dicha protección en OSB 12c.

Antes que nada resumiré los puntos principales a configurar para la seguridad:

• CREAR EL USUARIO DE ACCESO.
• APLICAR POLITICA DE SEGURIDAD (2 FORMAS).

I. CREAR EL USUARIO DE ACCESO:

Como primer paso, es necesario crear los usuarios que puedan ser invocados por las aplicaciones consumidoras (Muchas organizaciones manejan sus usuarios en el directorio LDAP, pero la configuración de amarre no es parte de este tutorial). Este usuario será creado desde la consola Weblogic de la siguiente manera:

Desde el árbol de la consola de Weblogic (http://localhost:7101/console) acceder a: MyDomain/Dominios de Seguridad y seleccionar: myrealm:

Seleccionar la pestaña: Usuarios y Grupos y seleccionar el botón: Nuevo:

Ingresar los datos para la autenticación del usuario al que se le brindará el acceso entre: servicio & OSB:

Luego de registro se debe poder visualizarse de la siguiente manera en la tabla de usuarios:

II. APLICAR POLÍTICAS DE SEGURIDAD:

Como herramienta el OSB está completamente integrado con: Oracle Webservices Administrador (OWSM), que ofrece gran cantidad de las políticas de seguridad que se pueden utilizar para asegurar los servicios virtuales.

Entre las políticas una de las más resaltantes es denominada: oracle/wss_username_token_service_policy, para la protección por medio de un: user/password definir y creado en el paso anterior. Esta es la que se utilizará en la demostración:

Para la aplicación de las políticas de seguridad se mostrarán dos formas:


A.    DESDE LA FUENTE OSB:

Esta forma consiste en la aplicación de la política desde la misma fuente del proyecto OSB (específicamente desde el: Proxy Service): 

Desde las fuentes (proyecto OSB), ingresar al proxy del servicio virtual que se desea enmascarar y proteger. Luego, seleccionar: Policies, dar check en: From OWSM Policy Store.

Agregar desde: Security, la política requerida, en nuestro caso será: oracle/wss_username_token_service_policy y pulsar el botón: OK.

Verificar que la política se haya agregado correctamente:

 
 
Una vez terminado esto ya se puede desplegar el servicio virtual.


A.    DESDE LA CONSOLA OSB:

Esta forma consiste en la aplicación de la política desde la misma consola OSB: http://localhost:7101/sbconsole, ya que como se mencionó posee conexión directa con OWSM. Ingresar a la consola y seleccionar el proyecto OSB desplegado. Luego, dar check en: De Almacén de Políticas OWSM:

Asociar la política requerida, en nuestro caso será: oracle/wss_username_token_service_policy:

Ingresar la descripción de la política deseada y pulsar: Activar:

Verificar que la política se haya agregado correctamente. Luego, pulsar el botón: Guardar y luego: Activar:

Una vez terminado esto ya se puede probar el servicio virtual. IMPORTANTE, esta configuración de este modo estará activa siempre y cuando no se despliegue de nuevo el servicio (Se tendrá que aplicar luego de cada despliegue).

III. PRUEBA DEL SERVICIO VIRTUAL:

Una vez terminado las configuraciones ya sea de cualquiera de las dos formas anteriormente mencionadas, validaremos la URL expuesta en el navegador donde se verificará los tags de las políticas que se han agregado:

Las pruebas realizadas se pueden realizar tanto desde SOAPUI como desde el tester de la consola OSB. Una vez configura y expuesto el servicio, si se desea probar sin ingresar los tags de policy adicionales en la cabecera o ingresándolos incorrectamente el: user/password, se mostrará el error siguiente:

Agregando el contenido correcto de los tags en la parte del header con relación a las políticas, el servicio deberá responder correctamente:

   [soapenv:Header]
    [wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"]
       [wsse:UsernameToken]
          [wsse:Username]USUARIO[/wsse:Username]
          [wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText"]PASSWORD[/wsse:Password]
       [/wsse:UsernameToken]
      [/wsse:Security]
   [/soapenv:Header]

Así mismo, se puede realizar la misma prueba en la consola OSB, desde el Proxy Service respectivamente:

Luego, de ingresar el bloque de policy en el header al igual que se hizo desde SOAPUI, el resultado de las pruebas sería el siguiente:

Con esto se termina el post, esperando que lo puedan aplicar en sus proyectos OSB.

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.

STATELESS vs STATEFUL

Muchas dudas existen sobre la diferencia entre: 'StateLess' y 'StateFul', con relación al control del estado. A continuación una diferencia resaltante para entender el concepto: 

• StateLess: Significa que NO se controla la memoria del pasado (ya procesada). Cada transacción se realiza como si se está haciendo por primera vez. Ejemplo:

public int agregar( int numero ){
           return (numero + 1);
}

• StateFul: Significa que SI se controla la memoria del pasado (ya procesada). Cada transacción anterior se recuerda y puede afectar a la transacción actual. Ejemplo:

private int numero = 0;

public int agregar(){
           numero ++;
           return numero ;
}

Así mismo, es importante tener concimiento que como conceptos a nivel de herramientas Oracle SOA son considerados:

- BPEL: (StateFul)
- OSB: (StateLess)