Arquitectura Orientada a Servicios

En esencia se requiere que tus sistemas / subsistemas / módulos ofrezcan un servicio (web) y queden aislados de otros sistemas.

Por ejemplo, si tienes un sistema donde están las ventas, y otro donde esta el inventario, en vez de tener una base de datos compartida donde un sistema registra las ventas y quita del inventario y otro sistema registra nuevos productos, lo que se tiene es dos sistemas que se comunican con llamadas web y cada uno es responsable de afectar su propia base de datos. El sistema / modulo de ventas puede ni siquiera tener que afectar el inventario.

Esto se puede usar con webservices usando WSDL ( web service description language ) que es un estándar para describir el modulo y sus funciones con XML. O lo puedes hacer con un esquema REST/JSON, no necesariamente tiene que ser WSDL.

El ESB sirve para desacoplar nodos, y que en vez de que se llamen unos a otros directamente ( ventas llamando directamente a inventario ) llamen el ESB que a su vez los redirecciona al lugar correcto ( ventas -> esb -> inventario ) . Es m'as bien para administración de la infraestructura y dependiendo del tamaño de el sistema/módulos en la empresa se puede prescindir de el.

Los sistemas legados / heredados pues son los que ya están ahí y tienen que seguir corriendo en lo que se migran a nuevos. Generalmente se les hace modificaciones adaptaciones para poder exponerlos como servicios.

LDAP, generalmente se utiliza para tener la administración de usuarios en una empresa ( quizá con active directory de MS ) y de ahi definir grupos y perfiles. En esto del SOA te sirve para saber quien puede hacer que.

Orquestacion de servicios es un termino ocupado para definir como un servicio interactúa con otro sin pelearse.

De nuevo SOA en su termino mas simple es tener tus módulos expuestos como servicios ( piensa por ejemplo en el API de búsqueda de Google o en el API de twitter, ellos exponen como servicios sus productos sin que tengas que acceder a su base de datos por ejemplo )

Lo puedes hacer tan sencillo como un API con REST/JSON y un servidor web, o hay vendors que te "venden" SOA empaquetadito y a precios bastante elevados que incluyen todos esos modulos y muchos mas. Dependiendo del tamanio de la empresa puede o no servir esto.

Por ejemplo, para una empresa con 8 - 10 módulos donde haya varias versiones, desarrollos ( hay un proyecto en almacén mientras el sistema de customer support se esta migrando a blabalba ) y varios ambientes ( QA, desarrollo, producción, staging, etc. ) un ESB puede super simplificar el la administración al saber que versión esta apuntando a donde.

En otros escenarios esto podría no necesitarse ( ejemplo, no hay nada que "orquestar" )

Gracias OscarRyz por tu pronta respuesta, ya me quedaron mas claro algunos conceptos. Oye, sobre tu experiencia y conocimiento, ¿que stack de tecnologias podrias recomendarme para cumplir con el proposito?

Estaba pensando usar Apache CXF + Spring para los WS usando SOAP, pero aun tengo duda sobre otros temas como la seguridad, la escabilidad, rendimiento, etc.

Saludos

Pues depende de la organización; hay quienes quieren / prefieren / pueden tener un proveedor como IBM / Oracle y hay quienes prefieren hacerlo todo en casa.

Se puede hacer algo tan sencillo como Spring sobre Tomcat usando un REST API con JSON o algún otro formato y quedarse alejado de todo aquello que parezca XML y los WS-etc's