Message Driven Architecture in Grails

Editor's Notes

• #2: 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
• #4: 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
• #5: Live code: mda-gateway
• #6: Sometimes called a “Message Flow”
• #7: 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
• #8: 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”
• #9: 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*
• #10: 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
• #11: 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?
• #12: Sometimes called a “Message Flow”
• #13: 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?
• #14: Sometimes called a “Message Flow”
• #15: Sometimes called a “Message Flow”
• #16: 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