Michael Rozlog

The rage, the hype, and the excitement over the past couple of months has been around RIA(s). You don’t know what an RIA is? Well, RIA stands for Rich Internet Application. RIA(s) add significant eye-candy via various methods to make a web application and its interaction appear to act more like a Windows application.

For those that have been reading my blogs for a while now, you know I’ve been starting to raise the issue of new web technologies being introduced to solve a problem that may be more hype than actual solid issues. If you read the post on “how small is small enough” then you know that some of these applications can be fairly large in size and depending on how they are written they can be extremely chatty. If you read the post on “how many layers is too many” then you know that we are putting extreme pressure on our IT departments to enable RIAs using a plethora of methods; from the simple “AJAX” methodology, to using different frameworks (Adobe AIR, Microsoft Silverlight, Mozilla’s Prism Technology) all in an effort to get rid of the Browser and again act more like a Windows application.

That is also the second time that I mentioned “act more like a Windows application” in 2 paragraphs. Why are we trying to act like a Windows application? Because, they own 92% of the market, Apple has 7.5%, and Linux has a dismal 0.61% of the market. For more on market share check out: http://marketshare.hitslink.com/report.aspx?qprid=8. Let’s face the facts, the only reasons why people want to do this are because it is new and it is cool. Or they have a belief that they need to be cross-platform or zero client side deployment and the only way to do that is web-enablement. But, as the numbers above clearly point out, that is really smoke and mirrors. I understand that management, or your team, may be saying you have to create applications this way and we all know how pressure works. Again, they may have people saying things like we have to move everything now to the web, but we should think more about that before we leap into the next major web application rewrite.

Now let it be said, I have no issues with any of the technologies being used, invented, or hoped for in the future. Those people, who know me, know that I have a background in CORBA, J2EE/JEE, Java, C++ and many other languages and platforms, but we need to be honest, all technologies have a place. For example, look at Java Enterprise Edition and Java in general. It is great on the server, but realistically the client side is a mess, no matter if you are talking rich-client (AWT, Swing, or SWT) or the exponentially growing list of platforms, frameworks, and best practices for building a web site with Java they all are attempts to try to be like a Microsoft Windows application. Again, I want to say I have no issues with Java, AIR, Silverlight, or any other technology. What I do have a problem with is the time we spend trying to solve the mythical cross-platform client concept when there really isn’t that many platforms being used by clients today. This could be the great Google(ization) or SalesForce.com(ization) of technology and interaction, and I do agree that Software as a Service (SAAS) has its place just like every other technology, approach, or best practice, but it is not the only solution for every problem.

When I was away from Borland/CodeGear for almost a year I was running Products and R&D for a startup and I had the great privilege of working with a developer from Apple. Let me say the person was beyond technically competent and brought with him the Apple philosophy; do it right, or don’t do it at all. Pick the technology that is going to give the best possible chance to succeed and impress the users. I still count this individual as a friend, but about 5 months into having him on the team, Apple called him back home and he left, but the single-minded approach of making great software using the best tool for the job had a problem-solving approach changing effect on how I now look at creating solutions. This laser focus on the solution is also hopefully evident in my prior research and post on Situational Applications on the Dr. Dobbs website, which is really where I began to preach the change in my approach. That is why I’ve been looking at the new technology and it is dawning on me that a better approach may be RIEA.

Rich Internet Enabled Applications (RIEA) is really built around the concept of using a standard Windows client that communicated using Internet technologies (Web Services, REST Web Services, TCP, SOAP and others). The ideas around AJAX are alive and well and the AJAX approach has the same pitfalls doing RIEA type solutions as it does in a standard Web application using an AJAX approach. Using products like Delphi, C++Builder or even Visual Basic or Java Swing (you know we have a new kick butt Swing designer in JBuilder 2008) and using internet communications to retrieve and update information on the server side is a valid approach. Even though I’m not as excited about Visual Basic! Heck, there are so many components already created, tested and available, that almost anybody can get things working very quickly using this approach.

I also know that some companies are worried about viruses and exploiting security holes in Windows applications, but I will submit as an argument, that anybody who has had a Browser Helper Object (BHO) in Internet Explorer and the same type of technology in Firefox that gets loaded from one of those great unscrupulous websites that install things without people understanding what they just installed… it can happen on any machine, in almost any technology. But, at least on Windows you know you have to keep your guard up. Technologies like BHO(s) are used to attach to the web browser to capture and export information back to the server, which can then be used for many different purposes. The point that I’m trying to make is that security is a risk no matter what platform or approach you use… Rich Applications, Web Applications, and RIAs, it does not matter. If you have valuable information, most likely there is a person or persons willing to steal or compromise a system or systems to get to that information.

What about software updates? I’ve seen some really slick Application update software lately. In some standard RIA applications when a change is made a lot of new software has to be loaded on to the client on the next run. If it is programmed correctly to use caching properly, it will hopefully only have to do this once. Plus with an RIEA approach, the client side functionality that end-users expect like client-side caching of data, off-line access, and additional client-side horse power to add value to the application. Sorry, did I just make a commercial or present the value-add items from the early-middle 80s PC revolution when power to the people meant that software like Lotus 123 could go to the people and not have to wait on IT to bless me with an application? I thought we fought this battle of the green screen or dumb terminal years ago. But like any technology there is a pendulum that swings from centralized processing to decentralized processing. I’m trying to push the best of both worlds with the RIEA approach.

With an RIEA approach, education of the facts back to your team, your management, and your users will be a constant challenge. The grass is always greener on the other side of the fence and the next silver bullet will solve any issues we are having today, just wait a few days, months or years. However, if you have ever had a customer complain about the Web interface/paradigm and wish they had a “real” application like the old days, maybe you can make their day and reintroduce them back to the RIEA approach.

An interesting example is web search. Most are done with Browsers connecting to the web and returning results. Again, let me state, I have no issues with this approach. However, when you start looking at desktop search interfaces things start to change. Google still uses the browser interface, but other companies like the Halfone client for desktop search adds significant features and functionality to the simple text input. The same can be said about Copernic desktop search and their full windows (that is the one I use) has a good amount of additional settings and features that you just don’t get with the standard browser interface. This again is only one simple example. Think of media players, like Apple’s iTunes, Real player or many others, they all use web services and web protocols to enhance the software functionality in a full Windows client.

RIEA is again just another approach, and it is not perfect for every job, but for the vast majority of applications that are getting built on the web today, RIEA makes more sense than the hoops, strategies, and overhead we are putting our end-users, IT departments, and management through to get to the mythical cross-platform or zero “deployment” dreams that are so espoused.

In the end if your goal for creating a web application is to get away from Windows, ask yourself why? If all your users are using Windows why would you create a sub-par application just to put it inside the browser, or if you are using the new technologies to get away from the browser and into another layer of interface again ask the question why? If you come up with a good reason that makes a real business case or it will be far superior to what you can create in Windows then go for it, but if the business case is not there and the interface and the additional layers or structure is really unknown… then take a stand and create the best application possible that will make your company successful and your users happy and if it happens to be on Windows, then you know what, 92% of the rest of the world is using the exact same interface.

More to come…

Share This | Email this page to a friend