|Home • Patterns • Ramblings • Articles • Talks • Download • Links • Books • Contact|
No Escape From Integration
January 5, 2004
|DDD - Diagram Driven Design|
|What Does It Mean to Use Messaging?|
|A Chapter a Day...|
|Clouds and Integration Patterns at JavaOne|
|My First Google Wave Robot|
|Into the Clouds on New Acid|
|Design Patterns: More than meets the eye|
|Reflecting on Enterprise Integration Patterns|
|Google Gears Live From Japan|
|Double-Dipping: OOPSLA and Colorado Software Summit|
|Enterprise Mashup Summit|
|Facebook Developer Garage|
|Mashups Tools Market|
|Mashups == EAI 2.0?|
I had never thought about having guest appearances on my ramblings, but this e-mail response from my friend Hyon made me laugh hard enough that I think it would be a waste not to share it with the community:
Okay, so I"ve read the first chapter of the book... and sorrowfully and sympathetically (and somewhat gleefully by the evil twin side of me that needs others to share in my pain and misery) appreciated all the integration challenges that the poor Mom-n-Pop's Widgets & Gadgets R Us were faced with.
So what's the moral of the story? Simplify your life? Go find a deserted island somwhere, build a shack for shelter and grow vegetables and go fishing for food? That is... until you realize you need fresh water and you can only get it from Waters R Us in the mainland... so you build a pipe to transfer the water from the Waters R Us in the mainland to your island, a basic point-to-point integration... but then realize that you have different channels that can request water (kitchen faucets, ice maker, bathroom shower, bathroom sink, bathroom toilet, etc, etc) and each channel only wants to have to pay for the water it consumes so your point-to-point pipe branches out into parallel processing branches to each water requester source, turning it into a publish (the Waters R Us) and subscribe (the different water requesting channels) model with a control bus connecting to a management console so we can monitor how many times water is requested (and received) for measuring quality customer satisfaction purposes and in what amounts are actually consumed by each water requesting channel. Then the water requesting channels decide it requires different water format, the kitchen faucet water requesting channel needs clear water format while the bathroom toilet decides it needs blue water with bleach format and the shower head wants pale creamy peachy water format to match the complexion of its end user so you place a water translator at each water requesting channels to apply the correct water transformation. And with so many people fleeing to their deserted islands and requiring water, the Waters R Us is having problems keeping enough inventory of water to fulfill all their water requests so you must now query their inventory system to ensure there is water in its inventory before allowing the water request order to continue... and the bathroom sink has become delinquent in its payments and been ignoring the harsh 'Pay NOW or you will be CUT OFF' letters (which is handled through a different integration pipe that we won't get into here)... so now you must check inventory to make sure there is enough water in Waters R Us inventory system to fulfill the water request and make sure the water requesting channel has good credit standing so you build a publish-subscribe channel to send out parallel async request to the credit system and to the inventory system to make sure all's OK with the world, build an aggregator to aggregate the responses and a content based router to determine whether to send the water request to the Waters R Us for fullfillment or to send the water request to the 'water request fallout' system for future manual intervention. Then with all this overabundance of activity and increase in demand and single source of supply and increase in water request fallout, you decide to build a process manager to help with management of all your water requests, so the water request messages can be stored/persisted and track the progress of your water requests and etc, etc. And then finally... realizing that you have no idea what the hell you are doing anymore and have perhaps applied the wrong tools to perform the required task and life has just gotten a bit too complicated and can't afford the high consulting fees charged by Water Consulting... so you leave the deserted island and buy a ticket to the Mars Settlement Colony to simplify your life...
Hyon Kyong Na
MORE RAMBLINGS SUBSCRIBE TO GREGOR'S RAMBLINGS
Gregor is a software architect with Google. He is a frequent speaker on asynchronous messaging and service-oriented architectures and co-authored Enterprise Integration Patterns (Addison-Wesley). His mission is to make integration and distributed system development easier by harvesting common patterns and best practices from many different technologies.
|© 2010 • All rights reserved.|