Con la “explosión” del uso de los dispositivos móviles, los analistas dicen que este año será el del punto de inflexión: habrá más accesos a los servicios empresariales desde smartphones y tablets que desde ordenadores. Es el momento de revisar la situación de nuestra instalación y nuestras aplicaciones ¿Estamos preparados para proporcionar servicios a las aplicaciones móviles?

¿En qué situación estamos?

Y como casi siempre, el resultado de esta evaluación puede ser muy diferente. Nuestra situación será una de las siguientes:

1. No tenemos servicios SOA
2. Tenemos servicios pero no están preparados para movilidad
3. Podemos ofrecer servicios a los dispositivos móviles con una estrategia de multinalidad y multidispositivo definida

Dejando aparte el punto 3 que es la situación ideal, nos detendremos en el primer y segundo caso.

No tenemos servicios SOA: ¿Cómo es posible?

En el caso de que no tengamos servicios SOA, mal vamos. Creo que las únicas preguntas coherentes que podríamos hacernos en ese caso serían:

• ¿Por qué no?
• ¿A qué esperamos?
• ¿Cuando los tendremos?

La arquitectura SOA es necesaria si no queremos que nuestra informática se quede colapsadas el día menos pensando por falta de flexibilidad y capaz de evolucionar, convertida en un mastodonte caro de mantener y mucho más incapaz de proporcionar nuevas funcionalidades de negocio.

Tenemos servicios SOA, pero ¿sirven para los móviles?

Tenemos entonces el segundo caso, tenemos servicios SOA en la empresa, pero ¿están preparados para movilidad?. Para responder a esta pregunta, antes hagamos un breve repaso a las características que necesitan cumplir estos servicios para poder usarse en el ámbito de la movilidad.

Así pues, las aplicaciones móviles necesitan:

1. Servicios REST (Se pueden usar los mismos servicos para apps móviles que para aplicaciones web)
2. Ser accesibles de internet
3. Servicios compuestos de grano grueso
4. Mediaciones de canal
5. Modo offline por lo que se necesita un servicio de sincronización

¿Cómo adaptamos los servicios SOA de la empresa para su consumo desde los dispositivos móviles?

Como pieza fundamental para implementar todo esto, se necesita una mediación de canal ¿Qué es esto?. Una mediación es, si se quiere ver así, otro servicio que se interpone entre el dispositivo móvil y el servicio de negocio de la empresa. Al servicio de negocio acceden todo tipo de aplicaciones y canales como los B2B. Sin embargo, este servicio de negocio necesita adaptarse a lo que necesita una app móvil. Por ejemplo:

• Las pantallas de los móviles son mucho más sencillas que sus equivalentes en el desktop, por lo que el móvil necesita enviar muchos menos parámetros. Es en esta mediación donde se completan los parámetros que faltan (con parámetros por defecto o configurados de cierta manera).
• Es necesario reducir las comunicaciones entre el móvil y los sistemas de la empresa (dependemos de las redes de datos móviles que son más lentas y tienen menos disponibilidad). Por lo tanto, el grano de los servicios destinado a los móviles será seguramente más grueso que los servicios de negocio. En esta mediación se hará la integración de los servicios más básicos en un servicio compuesto de alto nivel.
• Es muy posible que la implementación de los servicios de negocio se base en SOAP. Sin embargo, en los móviles la implementación que puede tenerse como estándar de facto son los basados en REST. Esto es así por su mayor sencillez y sobre todo, por su mayor rendimiento. Hay que tener en cuenta que, al menos hasta ahora, los dispositivos móviles eran mucho menos potentes que los ordenadores de sobremesa, con mucha menor capacidad de proceso y de memoria. Por lo tanto, seguramente será necesario que esta mediación transforme el servicio SOAP en un servicio REST (y esto no será trivial).

Conclusión

Si no podemos proporcionar servicios a los dispositivos móviles con los que hacer aplicaciones estaremos en un gran aprieto. Nuestros usuarios usarán el canal móvil como su forma preferente de acceder a la empresa… así que asegurémonos que nuestros servicios SOA puedan ser consumidos desde este canal.

Y si no tenemos servicios SOA: apaga y vámonos.

Esta semana, he asistido al evento de IBM movilidad en Madrid. Aparte de conocer un par de productos de IBM que parecen francamente interesantes, hubo la habitual lluvia de cifras e informes de consultoras tipo Forrester o Gartner, diciendo algo que creo que ya no duda nadie:

Dentro de un tiempo (pueden ser meses o un par de años) la forma más usual de que un cliente interactue con la empressa no será la web de escritorio si no que será su móvil. Esto es así y es imparable.

En este contexto, me ha hago la siguiente reflexión: por muy sofisticada que sea una aplicación móvil, por norma general es una puerta de entrada a la funcionalidad que me aporta la empresa, al producto o servicio que me ofrece… y ¿como se hace eso? pues con servicios naturalmente.

Y es que ya sabemos que SOA tiene un problema de marketing. Por supuesto hay organizaciones (sobre todo en IT) que ven en este modo de diseñar aplicaciones la salvación del marasmo de funcionalidades y de conexiones punto a punto en el que están inmersos. Sin embargo, también las hay en que todavía no han percibido el verdadero valor que los principios de SOA les pueden aportar: desacoplamiento, contratos definidos, registro de servicios, eliminar las conexiones punto a punto, mayor flexibilidad, composición de servicios y un largo etc.

Es en este último caso en el que se necesita una prueba visible y tangible, algo que convenza a los más incrédulos que esto de SOA no es un invento de charlatanes vendedores de crecepelo… y en este punto, ¿qué nos encontramos?… las aplicaciones móviles.

Las mismas apps que llevan en su smartphone o tablet preferido, con un diseño tan bonito, pero que salvo algunas excepciones, no son nada si una capa importante de servicios de backend a los que acceder. ¿Cómo podríamos vender viajes o ropa desde una app móvil sin el servicio de comprobar stock o el de cobrar con tarjeta?

Así que al final va a resultar que los móviles van a forzar de verdad a seguir los principios de SOA. Al fin y al cabo los móviles están en internet y son cliente servidor. En esta ocasión no podemos recurrir al recurso fácil de conectar la pantalla con la base de datos. No nos queda más remedio que publicar servicios SOA (pueden ser SOAP o REST por supuesto), pero tienen que ser servicios SOA.

Conclusión:

Las aplicaciones móviles y los servicios SOA van de la mano. No podemos tener apps sin servicios, y dentro de poco no tendrá sentido tener servicios sin disponer también de apps móviles.

Aunque hay determinados supuestos que a veces nos parece que no van a ocurrir nunca… el día menos pensando, zas… van y ocurren.

Hemos tratado el desacoplamiento una y otra vez, diciendo que es uno de los principios básicos de SOA y también el que aboga por la transparencia de la localización física del servicio.

¿Y que pasa el día que trasladan las máquinas de un centro a otro? Pues pueden pasar dos cosas:

1. Seas la persona más feliz del mundo al poder ir haciendo los traspasos de forma gradual al tener los servicios y por tanto las aplicaciones desacopladas
2. Seas una persona con un problema muy, muy gordo

Si estás en el segundo caso, creo que será el momento de acordarte de los beneficios de SOA y de por qué no los aplicaste cuando estabas a tiempo. El famoso bing bang se va a quedar pequeño si lo comparamos con el “movimiento masivo” de aplicaciones que vas a tener que hacer para apagar las aplicaciones en un centro y arrancarlas en otro.

En conclusión, el principio de desacoplamiento y transparencia de la localización física de donde se ejecuta un servicio no es una cosa gratuita, ni siquiera una manía.

Además de mejorar el mantenimiento de las aplicaciones y la gran flexibilidad que ofrece a la hora de crear nuevas funcionalidades de negocio durante la vida normal de las aplicaciones, resultará de gran ayuda cuando cambiemos las máquinas de sitio ¿no te parece?.

A raíz de esta entrada me hago la siguiente reflexión: quizás hemos estado mucho tiempo poniendo de relieve los beneficios, creo que innegables que tiene SOA desde el punto de vista de la arquitectura técnica. Sin embargo, quizás hemos dejado un poco de lado lo que de verdad tiene que significar SOA, los beneficios que tiene para el negocio.

En el post al que me refiero se citan los siguientes:

1. Bajo acoplamiento
2. Transparencia en la localización de los servicios
3. Reutilización
4. Mejor “testeo” de los servicios
5. Desarrollo paralelo al poder independizar el desarrollo de las “pantalla” del de los servicios

Beneficios que creo que son innegables. Pero como tenemos un gran trabajo por hacer, y me refiero a convencer a la gente de negocio y a los que toman las decisiones del “gasto” en la T.I., creo que nunca se es bastante pesado en ponerlo de manifiesto.

Imperativos de negocio

El negocio nos pide lo siguiente:

1. Conectar los activos que ya tenemos
2. Extraer más valor de lo que ya tenemos
3. Extender y evolucionar lo que ya tenemos

Como vemos aquí, algunos de los principales requerimientos que se hacen a T.I. no es una tecnología revolucionaria. Simplemente y siendo prácticos, nos hacemos la siguiente reflexión:

hemos estado años pagando millones por unos sistemas informáticos y tenemos que rentabilizarlos. Tenemos que aprovechar lo que ya tenemos y sacarle más jugo si es posible. Además si tenemos en cuenta que hoy en día no tenemos mucho dinero que gastar  hay que extraer más valor de los activos que tenemos actualmente en la empresa.

¿Y como se consigue esto?

Pues en muchas ocasiones de una manera que obviamente es más fácil de decir que de hacer: conectando esos activos con otros.

Ya han pasado los tiempos de aplicaciones verticales, aplicaciones silo, diseñadas para no conectarse con nada y tener un fin meramente departamental o de nicho dentro de la empresa. Es necesario conectar las cosas para sacar más valor a lo que ya tenemos.

¿Y bien? ¿cual es la solución a estos requerimientos de negocio? La respuesta es fácil: SOA.

En conclusión

Así pues, no debemos tener reparos ni cortapisas en hablar a negocio (desde el área de T.I.) sobre SOA y los beneficios que conlleva (también por supuesto de sus riesgos).

Uno de los primeros conceptos que se aprenden cuando se estudia SOA es que no es lo mismo web services (SOAP) que SOA. SOA es un estilo de diseño de software dirigido a las necesidades de negocio, que sigue unos principios básicos. La mejor prueba de esto es que hay bastantes empresas que tienen decenas o quizás cientos de servicio web (con una implementación estándar de SOAP, WSDL, etc. etc.) y no es SOA en absoluto.

¿Por qué puede ser esto? lo más típico es que tienen una integración punto a punto. Es decir, aunque la comunicación se establezca mediante el servicio web, y por tanto en remoto, hay una relación directa entre el cliente y el consumidor. Por lo tanto, se establece un acoplamiento (si bien es cierto que mucho menor que con otras alternativas ya que es sólo en runtime) entre todos los consumidores y proveedores de los servicios. Imaginaros por ejemplo 100 clientes contra 300 endpoints. Potencialmente desde cada cliente se podría llamar a los 300 endpoints, y no solo, si hacemos un servicio compuesto, desde cada endpoint de los proveedores se podría llamar (potencialmete) a los otros 299. Es fácil de imaginarse la maraña de conexiones que se establecen y la pesadilla de su gestión. ¿que pasa si cambiamos un endpoint de sitio (de servidor)? ¿cuántos cambios deberíamos tener?
En definitiva, está claro que no por tener servicios web perfectamente estándar, se tenga SOA. Para ello es neceario algo más: como el desacoplamiento del punto a punto y que el cliente no sepa dónde se ejecuta el servicio.

También puede ocurrir al revés. Puedo tener SOA sin tener SOAP. El ejemplo más palmario es REST. REST es más ligero y por tanto más fácil de utilizar (aunque también es verdad que tiene menos funcionalidades que SOAP y WS-* relacionados).

Pero incluso no es necesario ir tan lejos como con REST. Se puede tener SOA con otras tecnologías y forma de comunicarse que en un principio no identificamos como SOA.

Por ejemplo, ¿puede un sistema que se basa en el intercambio y transformación de ficheros de texto considerarse como SOA? Pues aunque nos choque en un principio, en mi opinión sí, siempre y cuando cumpla con los principios de SOA por supuesto.

¿Cuáles serían estos principios aplicados a un sistema de este tipo? veamos dos de los más importantes brevemente:

Desacoplamiento: es necesario evitar la integración punto a punto. Por eso es necesario tener una capa intermedia entre el cliente y el servidor que actúe de intermediario y evite que el consumidor y el proveedor dialoguen directamente. En una arquitectura clásica esto se implementa mediante un ESB. Sin embargo, no hay que olvidar que un “bus” antes de nada es un patrón de diseño que persigue precisamente esto. Es posible implementar el patrón de diseño Bus sin un ESB.
Contrato bien definido: aunque estemos hablando de intercambiar ficheros, podemos tener una definición de interfaz o metadatos del tipo de fichero que estamos tratando. Por ejemplo, podría ser un fichero XML que describa los campos que contiene el fichero (de longitud fija, con separador de campos, etc. etc.)

En conclusión:
Por lo tanto, creo que de la misma manera que se está popularizando el concepto de noSQL en relación a los gestores de persistencia. Ojo, que no significa NO SQL, si no Not Only SQL. Es decir, tener en cuenta que en determinadas ocasiones es mejor un repositorio no relacional (como el usado por Amazon, Google, Facebook, etc.) que uno relacional (como Oracle o DB2).
Pues bien, creo que tendríamos que pensar en el noSOAP, es decir, not only SOAP. Hay ocasiones en que por la naturaleza y casuística del problema es mejor implementar SOA (por supuesto) pero no con SOAP, si no con otras aproximaciones (y no me refiero solo a REST).

De los creadores de “¿Se puede tener BPM sin SOA? va a ser que no” ahora llega “¿y Cloud sin SOA? también va a ser que no”…

Dejando aparte el chiste fácil de antes, en el post anterior de este blog hablábamos de que no tiene mucho sentido tener un BPM sin SOA, pues bien, creo que igualmente no tiene mucho sentido pretender subir a la nube sin no tener un diseño orientado a servicios. ¿Por qué digo esto? veamos…

¿Es muy diferente “pensar en SOA” que “pensar en Cloud”? Yo creo que no si nos fijamos en los principios de SOA (ver esta entrada en el blog):

Desacoplamiento

Es uno de sus principios principales: ser agnóstico respecto a la tecnología que hay por debajo, a la topología, el ciclo de vida del servicio y de la organización que lo implementa.

En el Cloud, se tiene el mismo objetivo respecto a la operativa y la gestión de recursos. Da la posibilidad de obtener recursos para el usuario independientemente de su localización y de la tecnología sobre la que se implementa.

Por otra parte, los programas que se ejecutan en la nube puede ser implementados con tecnologías SOA, los servicios ofrecidos desde la nube pueden ser compuestos con otros (de la nube pública o híbrida) para proporcionar aplicaciones compuestas.

Encapsulación

La encapsulación es importante para SOA pero crítica para cloud. Si en la nube se crean dependencias sobre la localización de los recursos, no es posible la virtualización y la elasticidad respecto a los recursos.

Distribuible

Los recursos son independientes respecto a su localización física. Incluso hay nubes, como las de google con el gmail, que pueden cambiar la localización de tu buzón dependiendo de la hora del día (incluso de la temperatura que haga en  en la ciudad donde está situado el centro de datos).

Claramente definido

Aunque salvando las distancias, los recursos ofrecidos por la red están claramente definidos y medidos: ¡son los que aparecerán en la factura a pagar!

Intercambiables

Los recursos no dependen de la implementación física, por lo que son fácilmente sustituibles por otros, de hecho son “virtuales”.

Compartibles

Es la esencia misma de la nube y su multi-tenancy, o sea, la capacidad de la nube para dar servicios a varios usuarios con los mismos recursos.

En conclusión:

En mi opinión, no se puede tener SOA sin diseño orientado a servicios (SOA). ¿Estás de acuerdo?

El acercamiento a SOA de una empresa puede venir por varios caminos… uno es simplemente que se necesita una solución a la maraña de aplicaciones silo que se comunican entre sí de manera improvisada y que impide la evolución de la TI de la empresa para dar respuesta a los requisitos de negocio…

Otros sin embargo, vienen a SOA a través de la gestión de procesos, del BPM. Digamos que los procesos de negocio, la automatización de los mismos o la reingeniería o mejora continua de los ya existentes en la empresa tiene mejor “venta” de cara al departamento de negocio.

Lo que no hay duda, o al menos eso espero, es que SOA y BPM se complementan. Tan es así, que los vendedores de productos Middleware, como Oracle, ya dan por supuesta una arquitectura orientada a servicios como paso previo a implementar BPM en la empresa.

¿Por qué BPM?

En un entorno para el negocio enormemente cambiante debido a la cada vez más fuerte competencia en un mundo globalizado, clientes cada vez más exigentes, cambios normativos y legales, etc., la velocidad para poner una aplicación en el mercado llega a ser crítica (el famoso time to market).

Por otra parte, en ocasiones, las empresas no tienen sus procesos de negocio correctamente definidos, por lo que no pueden ser gestionados ni optimizados correctamente. No se tienen métricas del negocio en tiempo real que proporcione información a los analistas de negocio para poder tomar decisiones casi inmediatamente.

Si a ello unimos que las aplicaciones tradicionales son poco flexibles y casi siempre limitadas al ámbito de un área concreta de la organización, tenemos la foto completa de una situación a la que se puede poner remedio con la combinación de dos conceptos muy complementarios: BPM y SOA

BPM es una metodología empresarial para la gestión de procesos mediante su automatización (mediante herramientas informáticas). Su objetivo es modelar, integrar, monitorizar y optimizar los procesos de negocio de la organización. De tal manera que obliga a las empresas a pensar en el proceso como elemento central.

¿Por qué SOA?

Por otra parte, SOA permite la implementación de nuevos procesos de negocio y la modificación de los actuales en menos tiempo y con menos coste, ayudando a rentabilizar la inversión ya hecha en software al integrar aplicaciones cerradas, antiguas y otros servicios de otras áreas de negocio (u otras organizaciones).

Al hacer corresponder un servicio SOA con un concepto de negocio, minimiza la “brecha” entre las áreas de negocio y T.I., pudiendo de esta manera hablar un lenguaje común.

Está claro que BPM y SOA se complementan y no se debería acometer una sin la otra. Con la aplicación de los dos, la organización puede adaptarse rápidamente al mercado obteniendo una ventaja competitiva.

¿Por qué SOA y BPM?

A mi modo de ver, y al de casi todos los expertos que he leído, BPM es la mejor aplicación para SOA (“killer application”):

1. SOA es la infraestructura que necesita BPM
2. SOA sin BPM sólo permite diseñar y construir un conjunto de servicios
3. BPM sin SOA requeriría un desarrollo de código ad-hoc para cada integración con otros sistemas
4. Juntos “orquestan a las personas y los servicios en un proceso de negocio”

Conclusión

No sé cual será vuestra opinión, pero yo no concibo tener BPM sin asentarse sobre una base de servicios con SOA. ¿Estáis de acuerdo?

Según la muy exigente normativa DSI PSS (Estándar de Seguridad de Datos para la Industria de Tarjeta de Pago), para que una empresa pueda almacenar o incluso únicamente procesar tarjetas de crédito, incluso sin guardarla en ningún momento, tiene que cumplir una serie de requisitos bastante difíciles de implementar.

Una de las más importantes, y la que más consecuencias tiene es que todos los sistemas que estén en la misma red que el que procesa la petición de la tarjeta tienen que cumplir con la misma normativa. Es decir, si en la misma red que la aplicación de pago con tarjeta, tenemos otras 100 aplicaciones (con sus correspondientes middleware y base datos).

Es fácil de imaginar que es lo que pasaría en la informática de una empresa si una aplicación de negocio, digamos que tradicional, tiene que integrar los pagos con tarjeta. Como esta aplicación seguramente estaría muy acoplada con el resto de aplicaciones de la empresa, no encontraríamos con la clásica bola de espagueti con decenas o cientos de llamadas entre ellas que nos daría como resultado que toda las aplicaciones de la empresa deben cumplir con la normativa que comentan al principio. Fácilmente, esto podría representar un proyecto de muchos meses, años siendo realistas, con un coste difícil de justificar (si no imposible) ante negocio.

¿Donde nos puede ayudar SOA con esto?. La respuesta es bastante inmediata: siguiendo los principios de desacoplamiento e independencia de la localización física del servicio podemos reducir la complejidad y coste de forma muy, pero que muy, significativa.

Desacoplamiento:

Mediante este principio, como ya sabemos, las aplicaciones o más bien los servicios están muy débilmente acoplados con los otros servicios que forman la solución de negocio. El único acoplamiento que existe es el contrato entre los mismos.

Independencia de la localización física del servicio:

Un servicio debe ser independiente de la localización física donde se ejecute. Por eso, el consumidor de ese servicio no debe saber dónde está el servicio a la hora de invocarlo. Es por eso que existe la figura del registro de servicios, un índice al que el consumidor acude para localizar el endpoint (dirección física del servicio) donde tiene que invocar.

Sumando estas dos cosas, podemos integrar fácilmente la funcionalidad de pago con tarjeta, con arreglo a esta exigente normativa con el mínimo esfuerzo y coste posible.

Por un lado, si es necesario, el servicio de pago con tarjet, se puede desplegar (él sólo incluso) en una red diferente a el resto de servicios de la empresa.

Por otro lado, los clientes sólo tienen que invocar al servicio de pago (y ni siquiera sabrán donde está)

Conclusión

Como vemos, si tenemos en cuenta mínimamente los principios sobre los que se asienta SOA, la solución aquí expuesta es poco más que una obviedad. Sin embargo, como he dicho en post anteriores, en la mayoría de las veces, para el éxito de SOA, debemos tener en cuenta dos puntos relativamente sencillos:

1. Con los principios más sencillos, aplicándolos con criterio, tenemos la solución a muchos de los problemas que se nos pueden plantear (ver la regla del 20%).
2. La mayor dificultad que tiene SOA es la de convencer a la gente. Me temo que indicar esta solución por parte del arquitecto SOA es bastante más sencillo que lograr que esto se implemente en la realidad (y no me estoy refiriendo a problemas técnicos).

Cuando nos enfrentamos por primera vez a los principios de SOA, una de las impresiones que nos podemos formar es que el desacoplamiento es enemigo de la integración. A fin de cuentas, el desacoplamiento aboga por la separación de los módulos o servicios de negocio y la mínima dependencia con el resto de activos de nuestra empresa.
Por su parte, la integración busca la sinergia, la asociación o combinación con otros elementos software para formar un nuevo activo software compuesto por otros más simples para dar más valor a la empresa (lo que conocemos como servicio compuesto).
Así pues, parece que el desacoplamiento y la integración son dos términos puestos… pues nada más lejos de la realidad.
Tal como yo lo veo, el desacoplamiento es el primer paso para lograr una verdadera integración según los principios de SOA.
Por ejemplo, en una aplicación silo que se comunica con el resto de la empresa gracias a mil y una triquiñuelas improvisadas: ficheros, FTP, tablas, colas, etc. Y digo improvisadas porque cuando se diseñó la aplicación no se pensó siquiera en que en un futuro no podría seguir estando aislada del mundo y que tendría que colaborar con el resto de aplicaciones de la empresa.
Pues bien, cuando tenemos una aplicación de este tipo, lo primero sería partirla en trozos funcionales (módulos software). ¿Cómo se hace esto? esa es la pregunta del millón…

Al menos no deberíamos perder de vista aquella frase que nos repetían una y mil veces en la universidad: un módulo software debe tener la máxima cohesión interna y el mínimo acoplamieno externo. ¿Qué significa esto y cómo se traduce en la práctica?

Cohesión es la característica de que algo es homogéneo y es muy igual entre sí (al menos esa es la definición intuitiva que a mí se me ocurre). Así que lo primero que tenemos que ver en un módulo para ver que realmente merece ese nombre es lo que hace. Por una elemental separación de cometidos (separation of concerns) un módulo no puede, por ejemplo, ocuparse de las cuentas corrientes de un banco y de los clientes… ¿por qué? porque no tienen nada que ver uno con otro, no tendría ninguna cohesión.

Otra forma practica es ver las llamadas que se hacen desde los diferentes elementos del módulo y a dónde las hacen. Si resulta que un elemento de un módulo hace más llamadas fuera del módulo que hacia dentro del módulo mismo debemos sospechar. ¿Tiene sentido que un elemento de un módulo, si tiene cohesión, se relacione más con el resto del mundo que con sus “compañeros” de módulo? pues no.

Pues bien, una vez que hemos descompuesto un programa en sus módulos de software, es el momento de integrarlo. Pero esta vez, de manera correcta, siguiendo los principios de SOA y su desacoplamiento.

¿Cómo se hace esto? Creo que con unas pocas reglas básicas, si se siguen con disciplina, podemos salir del paso de la mayoría de los casos que se nos presenten:
1.- Los backends no se llaman entre sí. Se entiende backend, el módulo o módulos donde se ejecuta la lógica de negocio de la compañía, lo que se llama también el “core” de la empresa
2.- Un backend, por no llamar, no llama a nadie fuera del mismo backend.
3.- Dos módulos, incluso en el mismo backend, no se llaman directamente. Son llamados por un tercero que coordina u orquesta las llamadas entre sí.

En conclusión, antes de realizar la integración de un sistema ya existente, el primer paso para ello es el desacoplamiento.

A lo largo de este tipo de existencia del blog (ya van más de tres años), ha habido algunas personas que me han pedido consejo para elegir un tema para su proyecto fin de carrera o para su tesis doctoral. Por supuesto, creo que en el ámbito de SOA hay muchos temas interesantes que dan de sí como para dedicarles un estudio y desarrollo intenso como son estos casos. Así que creo interesante dedicar una entrara a esto precisamente: recomendar temas para investigar y aportar a la estado del arte de SOA.

Si estás en esa situación y lo que quieres es un tema para tu tesis, creo que en SOA tienes para dar y tomar.