“Deep Integration” is a waste of time
It’s 2009, right? As an industry we’ve cast off heavyweight solutions and processes in favor of lightweight software and Agility. Now we create RESTful APIs as part of this push for more meaningful software development. Web applications communicate with each other via RESTful APIs these days. YouTube, Yahoo!, Twitter, Facebook, Google Apps, Digg, everyone has a RESTful API. Integrating two applications has never been easier. Punch a hole in the firewall for a known host on the other side, give their developers an API key and let them get to work. Couldn’t be easier, could it? This is why you’ll never believe what I heard last week.
I was told, quite authoritatively, a better way of integrating with an application is to give the other application developers your messaging system and have them integrate with that. Not just the message broker but the entire end-to-end message system, producers and consumers included. I panicked when I heard this because I knew this guy was serious. He wanted to build an application like this?!
Deep Integration
The messaging platform needs some kind of web server to handle the RESTful calls coming from the client application. It needs a message broker, ActiveMQ, RabbitMQ, WebSphereMQ, take your pick. It needs some way of consuming messages produced by the web/application server. It needs at least one dedicated server to run it.
Hardening an appliance for use on a customer site is significantly more time consuming and expensive than running that platform in-house. The appliance has to “just work” for the customer. The customer also has access to the provider database. Notice how the message consumer communicates with that provider database through both corporate firewalls. The provider database is exposed and the customer has a box with the credentials on their premises.
The push for this “deep integration” with the customer was so that their developers wouldn’t have to learn how to make RESTful API calls. Instead they would learn how to administer the provider platform (keeping the database credentials safe, of course), learn the Ruby/Java/C#/C++ API to put messages on the queue and learn the RESTful API anyway because that’s the easiest way to interact with the message platform.
I can’t help but wonder why the customer needs to be bothered with the provider message platform. The provider isn’t in the business of providing a message platform. The provider only needs to provide the services the customer is buying. Pushing some messaging platform on them doesn’t help them get their job done. It’s a waste of time, effort and money. Giving them the messaging platform and saying, “here, you administer it” shows laziness and ignorance in the provider. What could possibly be gained from making the customer use the messaging platform? It makes the provider’s tech guys feel good because they worked on what seems like a big, important project.
RESTful Integration
Most of the time this works just fine. Keep your message platforms to yourself.
I think whoever told you that just can’t tell the difference between a public API -exposed to systems outside your ecosystem- and integration strategies that make sense inside a company’s walls.
As more people come from the Enterprisey(tm) world to the world ‘wild’ web I think that this unfortunate comment will be quite popular.
cheers
Thanks for the comment Phillip. I agree that Enterprisey thinking will slow down web projects. Those of us familiar with both web and enterprise projects will have to stay vigilant to keep projects on the right path in the technical sense and for deliverables.
Thanks again!