1. Modelos de
Exposición:
A nivel de proxy los modelos de exposición pueden ser http,
https, REST, JMS, etc. Existe además la posibilidad de exposición Local.
1.1 Exposición Local vs
Http.
La elección de este modo de exposición dependerá de cómo el
proxy debe ser accedido por el cliente.
·
Si el proxy es accedido por otros proxies, sea
mediante callout, routing o publish, entonces el modelo de exposición a usar
debería ser local.
·
Si el proxy será accedido por clientes externos,
entonces la opción debería ser Http, JMS, etc.
·
El uso del transporte local es mucho más seguro
y eficiente.
Un escenario común
sería el siguiente:
Se expone un proxy http hacia el cliente externo, mientras
este proxy establece comunicación con otros proxies a través del transporte
local.
2. Modelos de invocación.
2.1 Service Callout vs
Routing.
Todos los Service Callout en OSB son llamadas
Request/Response bloqueantes, es decir, dejan bloqueado el thread del pipeline.
Toda llamada de enriquecimiento aunque sea JMS tendrá este comportamiento.
El enriquecimiento a través de SC no es un anti-patrón. Se
considera anti-patrón el uso de SC si no se usa un routing al final de flujo de
entrada.
Nota 1: Si se hace enriquecimiento con SC, el último servicio de
enriquecimiento o debe ser con un routing en el flujo de entrada.
2.2. Publish Action.
Es una acción no bloqueante en el OSB (el flujo continua sin
esperar respuesta) Fire and Forget. Se aplica sólo para llamadas a Business
Services. Si el publish hace una llamada a un Proxy Service esta será de tipo
bloqueante.
Nota 2: Usando QoS de “Exactly One” se puede forzar a que el
publish sea bloqueante y espere confirmación de que el mensaje fue recibido.
3. Semántica de XA (Transacción Global).
Se usa principalmente cuando se requiere hacer un flujo
completo (Ejemplo una reservación con múltiples servicios). Esto implica que
todos los componentes que participan en el flujo, si al menos uno es incapaz de
completar la transacción o “commit”, se envía una señal de “rollback” a todos
los componentes. Este es el mecanismo
idel para el manejo de integridad a nivel transaccional. El OSB por naturaleza
es un servicio “stateless”, lo que quiere decir que no mantiene los estados de
una transacción por defecto como si lo hace la SOA Suite con el BPEL.
Nota 3: Si no se está trabajando con un flujo transaccional dentro
del OSB, porque por ejemplo se emplea un mecanismo de integridad externo,
entonces ningún componente debiese ser XA.
4. Implementación de
flujos de Pipeline.
4.1. Validación de mensajes de entrada:
Se recomienda usar la validación de mensajes y cabeceras del
mensaje entrante para asegurar tenga formatos válidos, así como también la completitud y cardinalidad de campos.
4.2. Validación de mensajes de salida:
Un punto a tener en cuenta, es que el proceso de validación
de mensajes tiene un costo de procesamiento considerable, más aún si el payload
es de gran tamaño. Se recomienda usar la validación del mensaje de salida
cuando esta aporta valor a la lógica del negocio y no por razones meramente
técnicas.
4.3. Duplicación del contenido del body.
No se recomienda crear copias de la variable body a menos
que sea necesario, e intentar usar la variable body global en la medida que sea
posible.
4.4. Abuso en la creación de variables (assign).
Cada vez que se crea una variable en el pipeline, esta ocupa
un espacio en la memoria dentro de la instancia del pipeline en ejecución. Se
recomienda usar sólo las variables necesarias y que no tengan una vida corta.
4.5. Limpieza de variables en desuso.
Se deben eliminar las variables o colocarles un valor vacío
una vez haya perdido la utilidad dentro del flujo.
4.6. Consideraciones para mejorar el rendimiento en XQuery.
· A. Evitar el uso de la expresión ‘//’ en xpath.
Ejemplo:
Usar $body/order/data/customer/customerName
En vez de $body//customerName
· B. Indexar el Xpath cuando sea posible(ir
directamente al primer y único item).
Ejemplo:
$body/order[1]/data[1]/customer[1]/customerName[1]
· C. Extraer parte del XML que será usado en varias veces
a variables temporales en el caso de trabajar con grandes payloads.
Ejemplo:
let $summary := $body/order[1]/summary[1]
$summary/totalAmount, $summary/status, etc.
4.7. Insert, Replace actions vs assigns.
En caso de que se requiera realizar un insert o replace al
inicio o final de un XML, se recomienda hacerlo mediante un assign en vez de un
replace.
4.8. Uso de Split Joins para reducir latencia.
El uso de los Split Joins(Paralelismo) es especialmente útil
cuando se desea incrementar el performace.
·
Es importante destacar que el uso de Split Join
debe ser analizado cuidadosamente, ya que si un servicio es de alta demanda,
mientras mejora el throughput general del servicio, implica un impacto directo
en la CPU de la máquina.
·
Se recomienda como buena práctica el uso de
workmanagers a los servicios invocados invocados mediante Split Join con un min
y max thread constraint definido para evitar deadlocks y consumir todos los
recursos que pueden ser necesitados por otros servicios.
Ejemplo práctico:
Cuando el proxy contenga múltiples llamadas a Business
Services basados en EJB Transport, se recomienda usar Java Callouts.
El OSB hace un translation que podía ser bajo cuando la
llamada a este tipo de servicios es unitaria dentro del contexto del
procesamiento, pero cuando existen múltiples llamadas a EJB, se sugiere el uso
de Java Callouts para dichos efectos, ya que posee menor carga debido a la
omisión de la capa de translation del EJB TRansport.
5. Uso de IPs fijas para backends en los Business Services.
Se debe prohibir el uso de IPs fijas para comunicarse con
sistemas backend, siempre se deben usar alias definidos. Con esto se evita
modificar el fuente del servicio si un sistema backend cambia de localización.
6. Rastreo de mensajes (Message Tracing).
El uso de message tracing para Business Service, Proxy
Service, Pipelines permite al OS entregar información útil para la resolución
de problemas, bien sea a nivel de desarrollo o en ambientes productivos.
Existen diversas configuraciones que se pueden emplear para
determinar el nivel de trazas, tamaño, formato, etc.
7. Configuraciones de Business Services.
Se deben fijar Timeouts para la comunicación con los
sistemas backend.
Para los endpoints con protocolo http se debe deshabilitar
la opción “chunked streaming mode” a menos que el sistema destino soporte este
tipo de comunicación fragmentada.
Ejemplos de Timeouts por protocolo.
Protocolo
|
Timeout(segundos)
|
JCA
|
5
|
JMS
|
10
|
MQ
|
5
|
Socket
|
5
|
Http
|
10
|
Split Join
|
10
|
Regla:
Timeout
Consumidor > Timeout OSB > Timeout Backend
No hay comentarios:
Publicar un comentario