2011-12-18 23 views
6

He estado trabajando con Spring por un tiempo para darme cuenta de que no todas las solicitudes entrantes que recibo en mi aplicación están basadas en HTTP. Algunas solicitudes están basadas en correo electrónico y necesitan respuestas basadas en correo electrónico, otras están basadas en un socket (recibir notificaciones cuando un valor cambia en mi tienda NOSQL). Todos ellos, aunque usan más o menos la misma infraestructura de MVC.Desacoplamiento Controlador de MVC de Spring de HTTPServlet

Por lo tanto, pensé que tal vez la modificación de la aplicación para eliminar el acoplamiento entre los controladores y la infraestructura HTTP ayudaría.

El despachador ya no debe llamar directamente a los métodos del controlador, sino extraer los parámetros de solicitud y usarlos para crear un mensaje abstracto (o evento), que luego coloca en un bus de mensajes. Por otro lado, cada controlador suscribirá sus acciones (instancias de la clase Action - una implementación del patrón Command) para diferentes eventos.

Como soy bastante nuevo en Spring Integration, JMS y otras cosas por el estilo, no tengo idea de qué tecnología de mensajería elegir. Además, estoy bastante seguro de que una arquitectura como esta ya se ha desarrollado. Quizás, quizás ni siquiera esté en el camino correcto.

Acepto todo tipo de sugerencias sobre cómo proceder.

Respuesta

5

Tiene razón en que la solución de mensajes con un poco de ayuda de algunos patrones de integración es el camino "correcto" a seguir.

¿Está diciendo que los correos electrónicos y alguna base de datos NoSQL ya están llegando a su controlador? Esto significa que hay una capa de traducción entre estos sistemas y sus controladores. Con Spring integration usaría Mail-Receiving Channel Adapter para procesar correos electrónicos entrantes y TCP and UDP Support para notificaciones NoSQL. Los controladores Spring MVC aún se pueden usar para solicitudes web "verdaderas", accediendo debajo del canal de mensajes.

Cada adaptador de canal tendría un conjunto único de transformers para traducir el adaptador específico message en formato canónico. Al final, los mensajes de cada punto final serían routed con el mismo message channel.

De hecho, su ejemplo es perfecto para una solución tipo ESB. También puedes ver Mule ESB, que es aún más maduro y poderoso.

Cuestiones relacionadas