This document discusses message driven architecture in Grails. It provides an overview of Spring Integration and describes how to build a message driven architecture skeleton as a messaging pipeline. It then gives examples of functions for room search and booking, illustrating them as message driven pipelines with different services as handlers. The document explains that message driven architecture is not always the same as distributed architecture and discusses reasons for adopting a message driven approach.
10. Message Driven Architecture in Grails
Function #1
Room Search
• Need to find hotels with rooms that don’t have
bookings for the date range requested
• RoomSearch
• Need to hand off available rooms to be priced
appropriately for the user
• RatingEngine
• Need to store the rate that we have have
generated for the user, to recall during booking
11. Message Driven Architecture in Grails
FUNCTION #1 – ROOM SEARCH
Gateway Service
Interface
Room Search
Provides:
List<Room>
RatingEngine
Provides:
List<PublishedRoom>
Message Channel
PublishedRoomServic
e
DB
12. Message Driven Architecture in Grails
Function #2
Booking
• Need to retrieved the room and the stored rate
• Need to validate room is still available
• RoomSearch
• Re-rate the room to ensure no major
discrepancy
• RatingEngine
• Create the booking
13. Message Driven Architecture in Grails
FUNCTION #2 – BOOKING
PublishedRoomServic
e
Gateway Service
Interface
Provides:
PublishedRoom
RatingEngine
Provides:
PublishedRoom
Booking Service
Message Channel
Notify
Hotel
MetricsService
Pass-Thru:
Booking
EmailService
Provides:
Booking
DB
14. Message Driven Architecture in Grails
PIPELINE WITH WORKFLOW GROUPS
Message Channel
AppPipeline
Room Search
Provides:
List<Room>
Message Router
RatingEngine
SearchRequest Handler
PublishedRoomService
Message Channel
Provides:
List<Publishe
dRoom>
BookingRequest Handler
DB
Message Channel
PublishedRoomService
Provides:
PublishedRoom
RatingEngine
Provides:
PublishedRoom
Booking Service
Notify
Hotel
MetricsService
Pass-Thru:
Booking
EmailService
Provides:
Booking
DB
Web development backed by a powerful messaging pipelineAn approach to architecture where messaging is a core conceptSpecifically going to talk about using Spring Integration as our Messaging framework within a Grails application
Swiss Army Knife of messagingImplementation of the Enterprise Integration PatternsEIP talks about how we can effectively implement messaging, and outlines patterns for doing thatMore than just messaging abstraction, there’s a full tool setContinental benefits of having a Spring container
Live code: mda-gateway
Sometimes called a “Message Flow”
Tirade about developer lack of flexibilityHate the argument that system is defined by its limitationsWrote a blog post about this ideaUsing it as a crutch because we weren’t liberal enough with the “limitations” is irresponsibleI always try to find ways to build applications that will be flexibleThis is good for agile since we don’t have that six-to-eighteen month requirements gathering periodIf a stakeholder didn’t get their thoughts in, shame on them!As developers we like agile, we want to be flexiblehate it when the business community wants to do the sameWant business community to come to us with fully formulated ideasComplain and get angry when requirements dramatically changeThat’s really one-sided of usNeed to build applications that are flexible to changing requirementsLet the business community discover requirements as we’re implementing them
Sometimes maybe we get scared into thinking of splitting our app up and deploying brokers for the different piecesMDA is about extensibility and flexibility in your implementationStrictly speaking, MDA can be entirely in-memory within the appCan give you head-room to fit into a distributed architecture in the future“Forward thinking”
I’ve talked about this idea of “Write it Once, Write it Right”By that, I don’t mean that you were able to foresee Need to approach application design in a different kind of wayStart at a very high level and think about what your application is and what it does. - Consider a contrived example of a banking system - *change slide*
Think about the system at a very high level, in very broad termsWe can start to define some of the “functions” of the applicationThings that we know that we’ll need to satisfyIn Grails, our invocation point into these functions will be through a controller actionEach of the individual “functions” of the application can be thought of as a workflowSome “subsystem” of the application that handles a specific functionNo limit on how many workflows the application can accommodateFunctionally, workflows are discrete subsystems that can stand on their ownGreat for reusability (modularity)Design the application with messaging as a core tenant of the application architectureEach of the workflows will have their own, isolated messaging pipeline that the core will interface withInteraction with the workflows is managed through a centralized configurationOnly ever need to interact with one serviceGreat for testing, because we can focus on testing the domain logic and not the already-tested framework
Start to hone-in on the actual implementation stepsThe more granular and fine-tuned we get with the workflowsThe more we can think about the workflows being encapsulatedDefining a contract with the workflowLike the workflows themselves, each of the steps of the workflow can be sustained on its ownDiscrete, reusable unitsFollows a somewhat “functional” style of programmingIn a more traditional application, we might create a service classWould lead to programmatic coupling of the stepsChain of Responsibility libraries (commons-chain) don’t necessarily lend themselves to centralized managementEasier to start violating SRPWhat do we hope to get out of a Message Driven Architecture?
Sometimes called a “Message Flow”
Start to hone-in on the actual implementation stepsThe more granular and fine-tuned we get with the workflowsThe more we can think about the workflows being encapsulatedDefining a contract with the workflowLike the workflows themselves, each of the steps of the workflow can be sustained on its ownDiscrete, reusable unitsFollows a somewhat “functional” style of programmingIn a more traditional application, we might create a service classWould lead to programmatic coupling of the stepsChain of Responsibility libraries (commons-chain) don’t necessarily lend themselves to centralized managementEasier to start violating SRPWhat do we hope to get out of a Message Driven Architecture?
Sometimes called a “Message Flow”
Sometimes called a “Message Flow”
Ties back to Agile philosophy, where we discover and adapt the requirements and iterate rapidly on over an idea and base implementationComponent pieces of an application can be broken down to workflowsWorkflows can be built modularlySpring Integration gives us centralized management of those workflows through configuration"Premiere Level of Encapsulation”Individual parts of the workflow can be replaced through configurationQuickly and easily adapt to evolving requirements and feature requestsIsolated workflow steps can be discretely unit-testedMuch more useful code coverage - Developing application in workflows adds relevance to the implementation - Easier to see the "big picture" - Workflows & Workflow Steps are entirely reusable - Autowire candidates in Spring - Usable for batch too - Messaging "plays nicely" with other applications