Oracle SOA-Direct Binding vs. SOAP sobre HTTP
javaHispanoEn la mayoría de las soluciones software, ya sean desarrollos a medida o uso de productos específicos, llega un momento en el que nos tenemos que enfrentar a la difícil fase de optimización de la solución para poder obtener un mejor rendimiento. Entre las distintas acciones que podemos aplicar encontraríamos, desde optimizaciones de los algoritmos utilizados hasta acciones que dependen del producto sobre el que está desplegada nuestra solución software. Por ejemplo, si utilizamos productos Oracle, podríamos deshabilitar el audit level en los procesos BPEL o evitar un uso excesivo de XPath mediante variables en el bus.
¿Pero qué pasa con las comunicaciones? En las arquitecturas SOA no sólo afectan al rendimiento la calidad de los algoritmos utilizados sino que también las comunicaciones pueden repercutir en los tiempos de respuesta. Es ese tiempo el que muchas veces por desconocimiento o descuido se deja de lado al llevar a cabo las optimizaciones. Por este motivo, si trabajamos con productos Oracle, es necesario tener en cuenta la alternativa de utilizar SOA-Direct Binding en lugar de utilizar SOAP sobre HTTP como otra opción bastante interesante a la hora de aplicar optimizaciones de rendimiento a nivel de comunicaciones.
Por este motivo y ya que no hay mucha información ni comparativas que ayuden a tomar la decisión de si utilizar Oracle SOA-Direct Binding o SOAP sobre HTTP, en la siguiente reseña podemos encontrar una comparativa de rendimiento de ambas tecnologías.
Nota: noticia enviada por Elías Grande
Reader Comments (3)
Interesante artículo,
Al solo efecto de generar debate.
En lo personal, y más allá de que herramienta o tecnología emplees (WS, RES, RMI, EJB, CORBA, MQ, etc., etc., etc., etc. ) es más un problema de diseño que otra cosa.
Y la razón por la que argumento esto, es que en un par de ocasiones, tratando de conversar con otras personas, sobre algún problema para modelar un caso de negocio como una estructura de servicios. La única respuesta que he obtenido de parte de mis interlocutores, es lo fantástico y sencillo que les resulta crear un WS con la herramienta A o con la herramienta B.
Ahora, temas de integridad transaccional, reducción en el número de llamadas, el no acarreo de datos entre llamadas a distintos servicios, el no tener el caso de negocio distribuido entre varios servicios concatenados (y el riesgo que implica el no completar la secuencia de servicios por parte de la capa cliente), y no exponer las "tripas" de tu negocio / aplicación como WS.
De eso, cero respuesta u opinión.
Un saludo.
Creo qe aún se piensa que SOA son solo los WebService y que es la mejor tecnología y muchos no saben que simplemente se encapsulan la peticion y respuesta de una conexión HTTP.
Las personas que piensan eso están en un total error y simplemente no saben, están enfocadas a trabajas y desarrollar sin saber lo que hacen. Lastimosamente, es un error pensar que SOA está enfocado a la tecnología ..., totalmente erróneo. SOA está enfocado al negocio y es agnóstica a la tecnología y vendors. El problema está en los conceptos mucho se confunden el pensar que es lo mismo: Web Service, Servicios, SOAP, REST, Componentes, Aplicaciones ..., la mayoría habla de estos como lo mismo cuando sus definiciones son diferentes. Esto es un problema porque en si si no saben las definiciones, principios, objetivos estratégicos hacen un mal diseño y trabajan incorrectamente una Arquitectura como tal.