 |
|||||||||
|
|||||||||
|
|
Here's a quick exercise to see if you've been affected by the "Age of Web 2.0". Ask yourself the following hypothetical question:
Q: You need to create a desktop application that communicates with a back-end over the internet. The back-end is on a machine within your organization that you fully control. What architecture do you propose?
A: ?????
This is the heart of the problem. Today we are so completely besieged by Internet "applications", that this is no longer a simple answer. Remember back in the good old days of client/server applications when it was a pretty simple matter of deciding how you were going to frame your TCP/IP messages between the client and server and we were good. Sure, we had "chatty vs. chunky" arguments all the time, but a C/S app was a C/S app and we were damn happy walking uphill both ways in the snow, now get outta my yard!! *cough* but I digress...
So how do you answer the question? Well, take a look at your potential answers:
With many of these, it becomes balancing act where you have to weigh the ease of development and deployment against the "enterprisey" features. For example, I could literally expose an entire data model as a RESTful POX service complete with nested resources using Rails 1.2 in under 20 minutes...but I would have no active directory integration and no Windows authentication and might need some complicated bridge-y stuff if I want access to other code like .NET libraries.
A regular .asmx ASP.NET web service is pretty solid, and most client applications conform to the WS-I standards so it can be consumed by pretty much any library. The problem is lately there's been such a huge "down with SOAP!" movement (I'm one of the cheerleaders of said movement) that devs and architects often find themselves saying :
WSDL is so old-school. It's not Web 2.0-y enough.
True, but what's wrong with old-school if it works? The whole situation is confusing, and it get's more confusing when you add even more technology to the arsenal. What about WCF? WCF is this fantastically cool new technology from Microsoft that is supposed to allow us to create even more powerful services (Web or otherwise). Why would you use WCF instead of ASMX? Well, that's a huge freaking can of worms that is better addressed in other places. The point I want to make is that it's a decision that every service creator in a Microsoft-dominated shop needs to answer, and justifiably so. So if you go with WCF, do you go with self-hosted WCF which gives you more flexibility in the wire formats you can use and the objects you can serialize, or do you go with IIS which gives you some more solid foundations on which to build your service but you lose some wire format flexibility?
WCF services let you do callbacks so you can actually have a service push data back to your desktop application. Do you need true push functionality from your C/S app or are you fine with polling? These are also questions that need to be answered. If you want push, then you'll need to make your client act as a mini-server, which is a transition many of us have been through - but it brings up more questions.
So the question I have is this: given all of the new technology that allows clients to communicate with servers, have we really benefitted from the excess of solutions, or are we now stuck asking ourselves in hindsight, "Should I have had the steak or the lobster? If I ordered the steak, maybe I should've gotten the mushrooms... or maybe I could've had a small steak and just a lobster tail...."
In this current age of Web 2.0, social networking, and exposing everything under the sun as a web-based API, have we forgotten all of the lessons we learned in the old days of writing client/server applications? Are there so many possible ways to create C/S applications that we can't possibly have enough time to evaluate all of them for our particular applications, so we're going to have to settle for feeling a little bit of the "what if ..?"s after every C/S app we create now?
I'd love to hear your thoughts.
