Message Driven Architecture in Grails
•Download as PPTX, PDF•
0 likes•1,152 views
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.
Recommended
More Related Content
What's hot
What's hot (14)
Viewers also liked
Viewers also liked (13)
Similar to Message Driven Architecture in Grails
Similar to Message Driven Architecture in Grails (20)
More from Daniel Woods
More from Daniel Woods (14)
Recently uploaded
Recently uploaded (20)
Message Driven Architecture in Grails
- 1. London, Dec 2013 Message Driven Architecture in Grails Daniel Woods
- 2. Message Driven Architecture in Grails About Me @danveloper /danveloper #editor danielpwoods@gmail.com
- 3. Message Driven Architecture in Grails QUICK OVERVIEW: SPRING INTEGRATION
- 4. Message Driven Architecture in Grails GATEWAY gateway.request(obj) Gateway Service Interface Message Channel Somewhere
- 5. Message Driven Architecture in Grails HANDLER CHAIN Gateway Service Interface Message Channel Handler Handler Handler Handler
- 6. Message Driven Architecture in Grails APPROACH TO MESSAGE DRIVEN ARCHITECTURE IN GRAILS
- 7. Message Driven Architecture in Grails MESSAGE DRIVEN ARCHITECTURE IS NOT ALWAYS THE SAME THING AS DISTRIBUTED ARCHITECTURE
- 8. Message Driven Architecture in Grails - BUILD THE SKELETON OF THE APPLICATION AS A MESSAGING PIPELINE
- 9. Message Driven Architecture in Grails Function #1 Room Search Function #2 Booking
- 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
- 15. Message Driven Architecture in Grails WHY GO MESSAGE DRIVEN?
- 16. Message Driven Architecture in Grails THANK YOU
Editor's Notes
- 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