330 likes | 490 Views
Messaging Patterns. An alternative approach to modeling with ESB’s. Jimmy P @ pjimmy mail@thejimmyp.com http:// www.blog.thejimmyp.com. Outline. Some Context Some Problems Intro to Messaging Systems Some Solutions And The Focus Some Patterns. Platform. Temporal. Spatial. Afferent.
E N D
Messaging Patterns An alternative approach to modeling with ESB’s Jimmy P @pjimmy mail@thejimmyp.com http://www.blog.thejimmyp.com
Outline • Some Context • Some Problems • Intro to Messaging Systems • Some Solutions • And The Focus • Some Patterns
Platform Temporal Spatial Afferent Efferent It’s mainly about coupling
Platform Temporal Spatial Afferent Efferent AKA interoperability Most RPC and other common messaging technologies are platform dependent in painful places
Platform Temporal Spatial Afferent Efferent When A calls B synchronously B’s processing time affects A A B A Calls B A Blocks While B Processes B Processes B Returns
Platform Temporal Spatial Afferent Efferent Where are the components physically? Is there multiple instances, and where are they? How do I decide which of multiple logically identical components I should send my message to? What happens if the only physical instance I know of is down?
Platform Temporal Spatial Afferent Efferent Afferent - What do I take a dependency on? Efferent - What takes a dependency on me?
When Servers Crash DB App Tx [HTTP] $$ Order Call 1 of 3 Call 2 of 3 Critical Windows Patch Rollback Where’s the order!?
When Databases Are Down DB App Tx Exception Down Write to log [HTTP] $$ Order Call 1 of 3 Where’s the order!?
When Deadlocks Happen DB App Tx Exception A B Write to log [HTTP] $$ Order Call 1 of 3 Call 2 of 3 Deadlock Where’s the order!?
Data Loss Using Web Services A B C D $$ Order Not Rolled back [HTTP] Invoke DB WS Rollback Deadlock
Bus vs. Brokervs. RPC Broker .NET WCF Service JAVA WEB Service External JSON Service SalesForce SVC A SVC B SVC C SAP BUS BUS BUS Service A Service C Service B Service D Service E Service C Service F
What makes up a messaging system • Messages travel between queues • Queues are persistent stores located on the machine the service is deployed to • Queues can persist messages to non volatile storage in case of faults • Adding and removing messages from queues can be transactional • Queues provide us with our asynchronous behavior
Platform Temporal Spatial Afferent Efferent XML for message format & XSD for message schema Communication protocol and addressing is a problem
Platform Temporal Spatial Afferent Efferent Asynchronous messaging
Platform Temporal Spatial Afferent Efferent Create logically autonomous services Address services logically not physically
Platform Temporal Spatial Afferent Efferent Use the message schema to create a level of indirection between services so there is no direct dependency Schema A Schema B Service A Service B Communications Infrastructure
Messages are transactions Tx Q Receive App DB $$ Order Call 1 of 3 Call 2 of 3 Rollback Rollback The order is back in the queue
Web Services with Messaging The message won’t be sent if there’s a failure A B C D $$ Order Msg [HTTP] Invoke DB Messaging Gateway WS
So messaging is the silver bullet ;)Let’s look at some patterns
Return Address Pattern • Provides a place to specify a physical address per message, allowing of logical addressing per message type • Now EndpointA can do other work while waiting for it’s response
Load Balancing with Return Address • EndpointA can specify an endpoint under less load to process the response if it has that information
Correlated Request/Response • An extension of Return Address • Allows services to maintain state
Multiple Responses with Correlated Request/Response • User may not know or care about ALL of the responses
Multiple Handlers with Correlated Request/Response • Ultimate in SRP
Publish/Subscribe • Allows us to add Events to our modeling arsenal • By subscribing to message types from a logical address we are only coupled to schema • This allows us to trivially increase parallelism as required
Modeling Business with Messaging Systems • Simpler more Robust systems
Resources and Thanks • http://www.nservicebus.com/ • service-orientated-architecture@yahoogroups.com • nservicebus@yahoogroups.com • dddcqrs+noreply@googlegroups.com • If you are really keen watch this space http://www.udidahan.com/training/ a truly life changing course • And many thanks to Udi for letting me steal his pretty animated slides and a diagram here and there. Made me look better than I deserved and saved me heaps of work