2009-04-23 11 views
5

Supongamos que tengo una gran infraestructura de middleware que media las solicitudes entre varios componentes comerciales (aplicaciones del cliente, red, pagos, etc.). La pila de middleware es responsable de la orquestación, el enrutamiento, la transformación y otras cosas (similar al libro de Patrones de integración empresarial de Gregor Hohpe).¿Se requieren aplicaciones de middleware para hacer lógica de negocios?

Mi pregunta es: ¿es un buen diseño poner lógica de negocio en el middleware?

Digamos que mi aplicación A solicita algunos datos del cliente del middleware. Pero para obtener estos datos, debo proporcionar ID de cliente y algún otro otro parámetro. La aplicación solicitante debe realizar la recuperación de este parámetro o el middleware responsable de "facilitar" y proporcionar una interfaz que recibe ID de cliente y obtiene internamente el otro parámetro?

Me doy cuenta de que esta no es una pregunta simple (debido a la definición de lógica comercial), pero me preguntaba si es un enfoque general o algunas pautas.

Respuesta

2

Este es el patrón de "Aplicación compuesta"; el corazón de una arquitectura orientada a servicios. Eso es lo que los vendedores de ESB están vendiendo: una forma de poner lógica de negocios adicional en algún lugar que crea una aplicación compuesta a partir de aplicaciones existentes.

Esto no es simple porque su aplicación compuesta no es solo enrutamiento. Es una nueva transacción compuesta adecuada en capas sobre el enrutamiento.

Sugerencia. Mira obtener un buen ESB antes de ir mucho más allá. Esto rápidamente se sale de control y es útil tener algo de apoyo adicional. Incluso si no compra algo como Sun JCAPS o Open ESB, se alegrará de haber aprendido lo que hace y cómo organizan aplicaciones compuestas complejas.

+0

La parte difícil es la responsabilidad: quién debe ser responsable de qué. Creo que esto es esencialmente un problema cultural. Por cierto, mi pregunta era puramente hipotética, el proyecto en el que estoy ya está casi terminado y estamos utilizando un buen producto de middleware. –

+1

La parte difícil se llama "gobernanza" e incluye la responsabilidad, así como el control de cambios y las normas técnicas. No es "cultural", es más que eso, y por lo general es muy difícil. –

0

La aplicación de middleware debería hacerlo. El sistema A no debe tener idea de que el otro parámetro existe, y ciertamente no tendrá idea de cómo obtenerlo.

1

Orquestación, Enrutamiento y Transformación.

Usted no hace ninguna de estas cosas por razones técnicas, al azar, o simplemente por diversión, usted hace esto porque tiene algún requisito empresarial, por lo que hay lógica de negocios involucrada.

Lo único que falta para un sistema de negocios completo es el cálculo y la generación de informes (¡supongamos que ya tiene la seguridad en su lugar!).

A excepción de las redes de muy bajo nivel, problemas de sistema operativo y almacenamiento, casi todo lo que comprende un sistema informático está ahí porque el negocio/gobierno/usuarios finales quiere que esté allí.

La elección de 'Business Logic' como terminología era muy pobre y ha dado lugar a interminables distorsiones de diseño y arquitectura.

Lo que la mayoría de los buenos diseñadores/arquitectos quieren decir por lógica de negocios es el cálculo y el análisis.

Si "% s/Business Logic/Calculation/g" la mayoría de los edictos arquitectónicos tienen más sentido.

4

Además del enrutamiento, la transformación y la orquestación, el rendimiento debe tenerse en cuenta al cargar middleware con requisitos funcionales. Middlware debería tomar una fracción de toda la vida de la transacción de extremo a extremo. Esto solo se puede lograr concentrándose en las funcionalidades básicas del middleware, en lugar de tratar de complementar las funcionalidades del sistema host.

Cuestiones relacionadas