This post originated from an RSS feed registered with Agile Buzz
by Jared Richardson.
Original Post: The abuse of SOA and Web Services
Feed Title: Jared's Weblog
Feed URL: http://www.jaredrichardson.net/blog/index.rss
Feed Description: Jared's weblog.
The web site was created after the launch of the book "Ship It!" and discusses issues from Continuous Integration to web hosting providers.
Over the last two weekends I've been at conferences in St. Louis and Boston. (I've got to get another hobby!) At both locations I was involved with the Birds of a Feather session for architecture.
I found it very interesting that in both cities, SOA and it's usage was discussed. Teams using SOA technologies (like Web Services for instance) to pass larger data sets are finding SOA works very well.
Other teams that are wrapping very small bits of data in a Web Service are finding them to be cumbersome, ugly, and useless.
The problem is the same abuse of EJB that occurred a few years ago. People took a technology that's designed to handle large, coarse-grained chunks of data (something like getCustomer) and using it for fine-grained data queries (like getFirstName). The technology wasn't designed for setters and getters, it was designed for documents or datasets.
People who abused EJBs thought they weren't very useful either. :)
The trend was very pronounced. Everyone implementing SOAs with fine-grained access thought SOA was a buzzword compliant boondoggle mandated by clueless management. Everyone using coarse-grained SOAs access loved the technology and saw it filling a real need. During both discussions light bulbs went off all over the room. People saw what they were doing right or wrong.
It came down to the concept of what Mark Richards called an application interface versus and enterprise interface. Fine grained access should be available in a light-weight way from within an application. You don't move that to RMI, Corba, or a web service. However, when you have an enterprise interface, it gets shared via Corba or Web Services, and because of that scope and cost, you only share the bigger document requests through those interfaces.
This is just an observation on what I find to be an interesting trend. I think it's significant because Boston and St. Louis are in completely different parts of the country and (primarily) host different types of industry. Yet, they're already bumping into the same issues.
The principal here is to learn the new technology or tool, but don't use it just because you can. Don't use it if you don't understand it. Most of the technology we use falls into the category of YAGNI. You Aren't Going to Need It. New technologies are still good to learn so that you understand when they are appropriate to use, but abusing a new technology just so you can use it tends to cause more problems than it solves.
Previous Topic
