Arquitectura de estilo SOA en ColdFusion?

Question

El backend del sistema interno de la empresa se está complicando y me gustaría explorar la idea de hacer una arquitectura de estilo SOA en lugar de un sistema monolítico pesado. ¿Dónde debo comenzar?

Soy nuevo en SOA. ¿Significa ... instancias de CF individuales, y se comunican entre sí a través de llamadas de servicios web remotos? ¿Cómo lidiar con cosas como ... el manejo de errores y la interrupción del servidor? ¿Un ESB sería beneficioso para la arquitectura si cada parte de ella estuviera en ColdFusion?

¿Qué hay de la capa DB? ¿Deberían compartir una gran base de datos o deberían almacenar las cosas a su manera?

Gracias

Answer 1

Primero, ¿qué estás tratando de lograr? SOA es útil para sistemas que necesitan cambiar con relativa facilidad y ser accesibles para un nuevo programador. Por otro lado, tiende a tener una compensación de rendimiento porque termina segregando la persistencia, de modo que su interacción ocurre en el servidor de aplicaciones en lugar de en la base de datos. Por lo general, esta compensación de rendimiento no es un problema, pero si está trabajando en un sistema transaccional de alto rendimiento, es posible que deba comprometerse colocando algunos algoritmos en la base de datos y que estos violen el desglose de sus servicios.

Así que si quieres los pros y no está particularmente preocupado por los contras, comience por leer algunos libros aplicables sobre el tema:

• Martin Fowler Patterns of Enterprise Application Architecture - en particular, prestar atención al patrón Service Layer
• Domain Driven Design Quickly una versión condensada de la gran cantidad (innecesariamente IMO) libro más largo del mismo nombre menos "rápidamente", que le ayuda a pensar sobre cómo definir los servicios y la jerarquía de objetos debajo de cada uno.

Lo que se quiere es tendencia hacia un diseño con objetos de servicio de alto nivel cuyas relaciones son gestionados a través de dependency injection través de un recipiente service locator. En el caso de ColdFusion ColdSpring es un ejemplo. Esto luego permite object mocking para que pueda probar la unidad fácilmente. Por ejemplo, si los servicios viven en otros servidores, entonces tienen objetos de servicio localmente que son proxies que se pasarán como dependencias. Para probar estos proxies se burlan de modo que no tengan que hablar con el servidor remoto.

En cuanto a la gestión de errores y las interrupciones del servidor. Supongo que está preocupado principalmente por tratar problemas fuera del control del servidor local. Esta es otra razón para usar un objeto proxy de servicio. Haga que este objeto sea responsable de manejar los tiempos de espera, los valores de respuesta erróneos y similares, efectivamente un anti corruption layer.

En cuanto al intercambio de bases de datos, construiría las relaciones de mi tabla para reflejar mis relaciones de objeto de servicio. Entonces, si las tablas en cuestión tienen datos que solo se relacionan a través de los servicios, no aplicaré ninguna restricción de clave externa. Entonces, si bien podrían estar en la misma base de datos, no importa. Esto le permite mover esos servicios y tablas de bases de datos en otro lugar con relativamente pocos cambios en el código.

Answer 2

He oído el término SOA utiliza para describir una gran cantidad de montajes de imagen así que no estoy seguro de si hay una respuesta "correcta", pero el concepto básico es la capa de servicio. El gran beneficio es que la respuesta a su última pregunta sobre la capa DB es: todo lo anterior. Una vez que la lógica para manejar el almacenamiento/persistencia se aísla en la capa de servicio y las aplicaciones simplemente llaman a esta capa, es mucho más fácil mover ciertos datos a otros servidores o consolidarlos en uno cuando sea necesario. Incluso puede terminar con algunos servicios simplemente llamando a otros servicios que a menudo se conoce como service facade.

Para un ejemplo de "vida real". Supongamos que tiene una base de datos de clientes de algún tipo donde almacena nombres, direcciones, correos electrónicos, etc. Usted expone esto como un servicio web donde puede obtener fragmentos de información sobre una persona. En algún punto, creces este sistema de elaboración casera y decides licenciar un sistema completo de CRM. Como ha aislado todas las transacciones relacionadas con el cliente en un servicio web, solo necesita actualizar ese servicio para obtener información del software CRM en lugar de su base de datos. Aquí es realmente donde las arquitecturas de servicios realmente brillan.

En cuanto al manejo de errores, si sus aplicaciones y servicios están todos escritos en CF, usted tendría registro y manejo de errores en ambas (o todas) las capas. Obviamente, una interrupción del servidor en un servidor de servicio va a ser bastante grave, ya que afectará a todo lo anterior. Usamos un monitor que envía correos electrónicos a la mesa de servicio si se agota el tiempo o comienza a ir hacia el sur. En las aplicaciones del cliente, la clave que encontré es establecer un tiempo de espera razonable para las llamadas al servicio web. Nunca he visto utilizar un ESB, pero supongo que le daría otra capa de abstracción para administrar las llamadas reales. Esto puede ayudar con los tiempos de espera y similares, pero realmente no puedo decirlo.