When learning about new products, I often find myself trying to understand what problem the product is trying to solve and often without much success. It is crucial for vendors to express this clearly, yet it's not so easy. We sometimes get lost talking the jargon, the features, etc. and forget about the fundamental question. What is this product good for?
So I remind myself not to loose track of where we (iFountain) have started. RapidOSS is a direct result of number of problems we have run into repeatedly in the field. It's our attempt to have a repeatable solution to common problems that are typically solved as ad-hoc custom projects or by forcing product to perform “unnatural acts”.
So in this series of posts. I'll discuss the problems we have encountered in the field. The problems we are trying to solve with RapidOSS.
Problem: The client is broken
When deploying an application that will be used by many people, the typical options have been fat clients and html based web applications. Both options have pluses and minuses.
Fat clients (aka client/server architecture) provide a richer UI, more functionality, but the client needs to be installed on every PC, therefore overhead is very high. About 10 years ago, I remember Unicenter TNG client install taking over an hour. There were patches, and patch groups, etc. that had to be installed in a specific order. Considering that management tools are implemented to increase productivity, needless to say, a solution that generates so much overhead is not ideal for in many cases.
Html based web applications have the advantage to be deployed quickly. There is only one copy of the application, hence it is easy to maintain and the overhead is minimal. The problem with html based applications is that the UI is limited, and not suitable to represent all types of information. Regardless, html applications are quite popular and good enough in many cases.
People have been trying to compensate for the shortcoming of both of these options in number of ways. In a past life, we had used Citrix (Windows Terminal Services) to give people access to the Unicenter console, rather than installing on each PC. It was not “supported” but it worked most of the time.
On the web applications side, the typical solution to resolve the usability issues has been the use of java applets in the browser. Java applets do provide a richer UI and solve the distribution problem to a degree, yet they introduce other problems:
-
Not all browsers have a JVM and applications often require specific versions of JVM which creates compatibility problems, therefore support overhead.
-
Use of java applets often mean just moving the client piece of a client server application to the browser rather than re-architecting the application. The client server applications do not work well over the web with high latency connections (when client and server are connected via WAN). As a result usability suffers significantly despite availability of a rich UI.
-
Java applets also can be very large, several megabytes in size, causing long startup times.
-
It is very difficult (if possible) to integrate the user interfaces of two java applets even though they may be running in the same browser
To address the problems stated above, a new set of technologies loosely named as Rich Internet Applications, RIAs have emerged. These technologies use the capabilities of the browser (javascript and/or flash) to create rich user interfaces. The browser typically receives the data as XML/JSON from the server, the data is processed within the browser and represented using UI components, etc. The user interfaces provided by RIA technologies may not be as rich as the native desktop applications (at least not yet) however they are getting closer by the day. Usability is much better than html based applications yet they are almost as easily distributable as the html based web applications.
RapidOSS takes advantage of the recent advancements in RIA technologies, to provide a light web based user interface that can be used in any browser, eliminating JVM version conflicts, large initial downloads etc. and providing a richer interface than html based applications at the same time.
The user interface does not have to refresh to update the data. It polls the data in the background, and updates the UI as the data is updated. It provides menus to allow in-context actions, etc.
RapidOSS client uses standard web services API to interact with the server, which allows us to decouple the server and the client, giving us more flexibility in development of the client.
In the next post, I'll talk about the challenge to segment data and so that users can only see the data they should be able to see.
