Geeks With Blogs
John Conwell: aka Turbo Research in the visual exploration of data
 

I'd like to a few minutes to rant here about something for a moment.  I read something in the MSDN newsgroups a few days ago that kind of set me off.  It was a fairly simple and innocent question.  Someone asked if they should turn an existing class library into a web service.  What's the harm in asking such a question?  In fact, its often asked so what's the big deal, right?  Its the fact that this type of question is asked so often which is the problem.

 

My issue is that ever since .Net came out, Microsoft has been bombarding us with "The Glory of Web Services".  Interestingly even though a lot of this was aimed at programmers, Microsoft was especially targeting its management level audience.  Most of my coding buddies recognized Microsoft's hype for what it was.  We remembered the days of "The Glory of Component Services", and before that "The Glory of MTS" (and don’t forget DCOM…that was fun).  It was the same speech, regurgitated and changed a little bit for a new transfer protocol and data format.  No more applications!  Now you just have a bunch of components that just fit magically together to create usable, scalable services.  What could be better?  Easy deployment?  Oh my god, pinch me, I must be dreaming.  We've all seen that, tried it, and figured out that its not that easy, isn't that fast, and isn't the silver bullet Microsoft claimed it was.

 

So we added it to our list of tools to use when the specific need arose.  And just when I started to notice that I wasn’t being pounded on the head web services propaganda every time I read a white paper or technical article, a new term come onto the horizon.  "Service Oriented Architecture"  What is this?  Something new and exciting?  Something grand that will save the project?  A new silver bullet?  Hmm…lets see here…its…just…oh, web services.  Crap.

 

Now, I'm not claiming that SOA and web services were invented by Microsoft.  Actually the push seemed to start big in the Java world for SOA, and I guess Microsoft figured it better jump on the band wagon and get with the picture, so its started hyping it as well.  And then what do you know, but all that media hype had to eventually sink into the pointy haired project managers, and they started insisting on turning all business logic and data logic (everything that wasn’t the bare bones UI) into web services.  Apparently, according to Microsoft, this was going to cut development time and costs, cut deployment time and costs, scale better, be more maintainable, be more stable, more secure, and more extensible.  What else could you ask for?  And Microsoft wouldn’t push something that’s inefficient, right? (acho-databinding…excuse me)  Next thing you knew, it seemed like everything NEEDED to be a web service.  I have several consultant friends who jumped on this bandwagon (as a consultant, you go where the money is right?) and have done dozens of projects where web services were used as the binding glue between the UI, business layer, data layer and the database.  I even know of one ASP.Net project where the client UI layer was nothing but a big xml interpretation engine that built pages based on XML passed to it from a web service.  It just interpreted the xml to build its UI dynamically, and then passed all response info back into the web services to handle the response.  Web services handled everything else.  Amazing!  I know of several Fortune 100 companies who have implemented extensive systems where all logic is a mass collection of web services.  All done in C#, Windows OS and SQL Server.

 

Again, what's so wrong with this?  Well, what is a web service's greatest benefit?  What is the reason you might want to use this tool?  Its platform independent.  It can take data from platform A and fairly seamlessly give it to platform B.  It can do so synchronously or asynchronously.  It can communicate through firewalls via http/s.  Ok, for this list of requirements it is truly a wonderful tool.  I've worked on several web service projects communicating between Windows and AS/400 and Unix.  I've also worked on projects where I needed to call a secure service that resided outside the corporate network. Again, web services fit this bill very well.

 

But in the Windows world, why would you want to use a web service to communicate between two Windows servers, inside the same network?  You have several options for this, almost all of which are faster and more efficient that serializing objects to XML, then passing XML over http to get de-serialized back to an object and then used (and then back again).  The only reason I can come up with is that its easier and faster to develop.  I've heard the argument that remoting is so complicated to understand.  Pick up a book and read for 2 hours and suddenly its not complicated at all.  I don’t get it.  And the kinds of companies that are moving to SOA type architectures are mostly large corporations, building enterprise scale applications, to be used by hundreds to thousands of users.  Are you gona tell me that xml and http is gona scale to that level with a performance level that’s acceptable?

 

And here is my biggest complaint.  Why does everyone want to distribute all their objects?  This is crazy.  Again, we go back in history and we've been told to distribute all our objects with each new technological breakthrough; CORBA, DCOM, MTS, COM+, Web Services, Remoting.  We are always being told to distribute our objects.  This is crazy talk!  Put the logic where it needs to be.  If a class library doesn't need to be distributed, then DON’T distribute it! 

 

One of my favorite authors, Martin Fowler, said in his book "Patterns of Enterprise Application Architecture", that the number one rule of distributed objects is don’t distribute them if they don’t need to be distributed. 

 

The last argument that I've heard for distributed objects has been ease of deployment and updates.  You know, on paper distributed objects do seem like they would have an advantage.  But I've been designing and writing large enterprise applications for 10 years now.  I've written applications that make heavy use of distributed objects and those that only use one or two (based on the application requirement needs).  And by far, the easiest to support from an admin perspective is one where there are few to no distributed objects.  There are less points of failure, its less complex. Its just easier.

 

So don't believe the hype, or at don’t blindly follow the SOA and the "we must distribute EVERYTING" chanting you hear coming from Redmond.  Design the application to its specifications.  Distributed objects are just one tool in your tool box.  If it doesn’t need to be distributed, than just don’t do it.  If it does, the just distribute the pieces that make sense.  I mean if we listened to all the evangelism coming from Microsoft, everything would be a web service, and we'd use SOAP sterilization, XML, DataSets, data binding, reflection, and every application would be a web app.  All the wonderful things that make applications fast and scale really, really well.

Posted on Tuesday, August 30, 2005 6:51 AM Ramblings | Back to top


Comments on this post: A tirade against SOA and Distributed Objects

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © John Conwell | Powered by: GeeksWithBlogs.net