The Conversation
“We just converted the last of our client/server applications to thin-client!” exclaimed a friend of mine at a local Fortune 500 company. “Why?” I asked. “What do you mean why? We changed our architecture to n-tier with application servers and browser interfaces.” To which I could only ask, “Why?”
I could see that I was irritating him, but I thought I’d let him hang for a minute. This was a technically adept, well-paid engineer. He commented, “We went to n-tier because we could reduce our deployment costs. All the applications are now delivered to the clients without requiring p.c. administrators to install them! We can also deliver applications to our business partners over the Internet.”
“Those are all great things. You must be proud. Did you give up anything to accomplish this feat?” I asked. “No, I don’t think so – what do you mean?” he asked. “Well did you increase your server side costs? Did you deliver the application with the same robust user interface that you had in the client/server world? If I remember correctly, the client/server version used to connect to a bar-code reader on the pc, was that hard to do in HTML?”
Now he was aggravated. I had just pointed out three things that were worse in the new system that he preferred not to talk about. Conversations similar to this one are popping up in virtually every Fortune 500 I.T. shop. Why did we compromise on so many items? The answer is simple; the immediate advantages of the browser out-weighed any other solution that was presented at that point in time.
The Browser
The web browser was designed to enable a simple method for linking information across physical locations and rendering structured documents. These goals were met with overwhelming success. The browser was so successful that people began thinking of it as the sole method of sending and receiving information. Even other traditional applications like email were redesigned for this new model. It was apparent that the software designer could kluge just about any piece of software to work in this paradigm. As time went on, the software community began to realize that stuffing every application into the same architectural model would not adequately serve the needs of the user or the engineer. The intentions behind the web browser were noble. No one could have predicted that an entire generation of developers would have attempted to transition all of their programming needs to this new model. Had they, the browser would surely have a different design.
Before the browser we had some pretty powerful features: robust user interfaces, access to local peripherals, client-side computing and storage, etc. Plenty of sophisticated features were traded for the promise of ubiquitous graphical rendering. Well, today we have ubiquitous rendering but none of the other features that developers consistently need at the client. We have tried to remedy this issue but met with limited success. The Java applet failed to achieve significant success due to the limited support in the Microsoft Internet Explorer browser, while the ActiveX control remained ridden with security issues.
Clean Sheet of Paper
Developers are now re-thinking the role of the browser. What would client-side computing look like if you had a clean sheet of paper? Should it be the primary mechanism for delivering fat client side code? Should it always be a client and never a server? The answer to these vatic questions are leading many to believe that the client may be ready to undergo yet another major transformation. No one is suggesting that we do away with the browser, rather that we use it for what it was originally intended to do, rendering structured documents with hyperlinks.
The new goal is to balance a few simple concepts:
· I need continued access to my thin-client applications and web sites. Anything that I had in a browser I want to continue to have!
· Sometimes I work offline and I should be able to keep working when I’m not connected to the network.
· I need to communicate and collaborate with co-workers and business associates, often in real-time.
· I don’t want complicated installs nor does my I.T. department want to roll out new applications.
· Some personal information I’d like to keep on my computer rather than at a remote server.
Client Side Platforms
Five years ago I.T. shops were against adding anymore to the client than was absolutely needed. Today, as CPU performance is skyrocketing and disk and memory prices plummeting, there is a less emphasis on the hardware restrictions and a renewed interest in delivering more robust applications to the user. Also, software developer are tired of cursing HTML, trying to make it do things that it was never meant to do.
Returning many of the basic features that we had before browsers is the goal of the next generation of client side platforms. The CSP is really not a new concept. The CSP is merely a combination of those technical features that software developers need when writing client-side systems, while stressing strong (yet loose) integration between those components.
(more coming soon...)
No comments:
Post a Comment