It’s time to re-adopt the client as a full-fledged member of standard software architecture. Ever since the days of the LAN the client has been out of vogue. It was semantically replaced by the browser, which is really a client in disguise but is disliked by companies that sell operating systems and so is not talked about as such. Because the companies that sell operating systems have played a prominent role in establishing architectures and programming practices for many years, the browser aka client seems to have been neglected. For example, the service oriented architectures which are all the rage right now are heavily biased towards servers and don’t do much for the browser. However, I think that’s all changing.

Standards for the People, By the People

This time around it’s not IBM or Microsoft or Sun debating programming practices and creating standards, it’s the people who are using them on a day to day basis to solve real-world problems. Buy-in from mega corporations is no longer needed. In fact, most of the solutions that are competing for acceptance started out as a hack to make something work, then graduated to standard or quasi-standard status as a result of other people noticing that they were a good idea and wanting to use them too. It’s a shift from the brainstorm->standardize->implement workflow that we had to deal with for so long to a brainstorm->implement ->standardize workflow that we’ve been seeing lately.

XML and SOAP, for example, were both thoroughly standardized and developed over many years to do what they do. However, there’s now a question as to whether they’re the right tools to do the jobs that need to be done. JSON and REST work just as well in many cases, and in many cases they’re much easier to use because they work more seamlessly with the new client, the browser. They also have a much lower barrier to entry because they’re a natural progression of the way Javascript and HTTP work, and so they’re being adopted by programmer after programmer who’s just trying to solve a problem and doesn’t really care what has Microsoft’s or IBM’s seal of approval. The technology community is doing a much better job than our government of being run by the people.

Programming Evolved

Punch cards were used for the 1890 U.S. census, Fortran was developed in 1954, and then aside from language improvements things stayed pretty much the same (procedural) until about 1985 when C++ and object oriented programming started to catch on. Things started getting interesting in 1993 when HTML was introduced and we suddenly had a common front end for applications regardless of who was using them or what client they were using. And if you think about it, there really haven’t been too many other radical changes in programming. Yes there have been some great improvements in languages, database technology has played a vital role in improving responsiveness and application functionality, but in the end everything is still pretty much shooting at the same target: make an application that runs on a computer, usually a server, run as fast and flawlessly as possible.

Networking Evolved

The other side of this coin, of course, is network technology. Network technology has historically had a direct impact on the way programming is done, and what it’s used for. It evolves on a separate path and it requires a different skill set, but the developments in networking technology create shockwaves that ripple through the programming community for years. And just as the ripples die down and people start getting used to programming in the new networking environment, networking technology advances and throws another curveball at programmers.

Think about the impact Ethernet had when it started to be adopted around 1974. It changed the requirements for programming—suddenly applications needed to be able to operate across a local area network. We called it client-server. Or the impact HTTP had when it was developed in 1992—it enabled HTML and the Internet, which turned into Web-based applications. Again, the developments of the networking world changed forever how the programmers had to do things.

An Awkward Moment

I think that right now we’re at a stage where the tools and accepted architectures do not fit the job that programmers have to do. We have three factors that are not going to change in the near future, and they all live on the client: HTML, the browser, and Javascript. Everything else is negotiable. It’s up to programmers to figure out how to deliver the best application they can using any back-end they want, as long as it works with those three front-end technologies. Programmers have done some really cool stuff on top of those three technologies, but things are still pretty awkward. You usually have some kind of Javascript library like Dojo or Prototype on the front-end, making HTTP posts to a remote server to send and receive data from the disconnected server. This requires a lot of manual labor to hook everything up, and very little in the way of a standardized way to do things on the front-end. And we have this thing called service-oriented architecture that tries to describe a way to build applications so they can be used by other applications.

The big problem, I think, is that the front-end is still very disconnected from the back-end. Because of SOA, people are still thinking very much in terms of sending and receiving messages rather than thinking about how to create a smooth and seamless application that exists both on the client and the server. I don’t know if it’s because of the fact that the Web was very disconnected in the early days, but most programmers still don’t think of the Web browser as a connected client. Technologies such as comet are starting to change that, but they’re still in their infancy and have a long way to go.

However, there is no longer any good reason to keep the client disconnected from the server in terms of software architecture. Broadband penetration is now 75% of active Internet users in the U.S., and much higher in countries that are not as backwards as we are. For some reason, programming techniques have not yet adapted to this fact. And what’s more, everyone is on their way to becoming an always-on node on the Internet network. One third of Blackberry owners are not using their phones for business. The iPhone from Apple (if it gets to keep its name) is a tiny OS X computer with Internet connectivity. In places where Wi-fi hotspots aren’t present, Wi-Max will be soon. In other words, we can no longer get around the fact that the client is once again part of the architecture equation, and our programming practices need to support that fact.

Network-Oriented Architecture

I think the solution to this lies in approaching the problem from a different direction. Instead of thinking about the most effective way to send and receive messages between the browser and the server, we need to start thinking about how to make the client a seamless extension of the server. Just as you don’t need to know assembly code to write a computer program, you shouldn’t need to know about transports, encoding, and services to write Internet applications. If the network is the operating system, as I believe it is now, we need to refine the concepts a little further to bring programming practices up to speed with the network.

I haven’t seen any satisfactory approaches to this yet—everything we have right feels like a stopgap solution to me. Service oriented API’s are usable by clients, sometimes, but it requires heavy coding by hand to do it. If you’ve ever tried to call a SOAP service from a browser you know how painful and ugly it is. Most service-oriented API's are built for use by other servers, not by browsers. AJAX applications are hooked up to heavily customized back-ends that are built specifically to serve that application. There’s nothing elegant, easy, or re-usable about any of these solutions.

To me it seems that the goal of a true network-oriented architecture that considers the client an equally important member of the equation should at least include the following:

A security model that allows the server to definitively identify the client, and ideally identify clients running on OTHER servers as well. There is no easy way to authenticate and authorize Web clients right now, and no technological reason why it can’t be done. This is going to be key once always-on personal nodes such as iPhones start to become widely adopted, and very closely tied to online identity.

The ability to use server resources such as objects on the client. For example, I should be able to create an object on the client that exists on the server and call its methods in the browser.

The ability to maintain synchronized state between objects living on the server and the client. If I update and save something on the client, the server should be updated automatically. I shouldn’t have to manually make a call to anything. Conversely, if another client or something on the server updates and saves a resource all clients that are using that resource should be automatically notified and updated as well.

A way for resources on the client to use resources on other servers. I can’t see any reason why clients shouldn’t be able to use resources that live on more than one server. It is, after all, the World Wide WEB.

A way for server-side resources to represent themselves visually on the client. If server-side resources can extend to the client, there’s no good reason why the server objects shouldn’t be able to take care of displaying themselves on the client as well. It’s one less thing to do in code, and something that I don’t even recall being done in the OLD client-server environment.

This is really just scratching the surface of what a true network-oriented architecture should be capable of.  The fact is that we've been focused so much on trying to provide a rich user experience on the browser that we've neglected to build a firm foundation for programming in the new environment.  Once the training wheels come off I think we can expect entirely new types of applications to be built around this technology.

Just Around the Corner?

I started implementing something similar to this a few months back, and it was a very enlightening experience. It changed the way I thought about a few different technologies. For example, I was on the fence about the XML vs. JSON debate until I tried sending stateless objects back and forth from the client. JSON is beautiful for this, but you have to jump thru hoops to do it with XML. I didn’t much care about REST vs. SOAP either, until I tried to call a SOAP service from the browser. What I realized is that some of the technologies that work great on the server just do not translate well to the client. That makes all the difference in the world if you don’t want the client to be disconnected from the server. Certain technology was developed with use by only servers in mind—and it shows.

I think programming will arrive at this type of architecture sooner or later, it’s just a matter of time. It’s the difference between holding your application together with duct tape and having a nice, consistent library to work with that works no matter where your code is running. The discussions that are currently being held about to challenge established ways of doing things in favor of simpler and home-grown solutions show that there is a paradigm shift happening, both in the way that we think about programming and the way that changes are adopted. We’re starting to adopt the client as part of the software architecture again. And perhaps more exciting, we’re starting to adopt new changes in programming on our own, apart from the influence of companies that are trying to sell us a particular architecture because it benefits them. It’s the free market at it’s best, and I can’t wait to see the end product.