The challenge in writing this article is to get you, the reader, to invest some of your time and thought into understanding just what Platform Independent Computing (PIC) can mean in your day-to-day operations. Until you've actually seen one of your processes running as a Platform Independent application it can be difficult to fully grasp all the ways your work efficiency might be improved.

PIC transforms how you perform a given IT based process and how your people interact with that process. These changes are often not apparent until after you see the differences in action. In fact, it is not unusual to hear clients expressing surprise by the scope of the advantages well after testing begins or the system goes live. It is also dificult to express how much every-day users appreciate the advantages a properly written Platform Independent application imparts to them.

Is PIC right for every situation? No. Whether or not it is the best choice for your development project is a matter of weighing the benefits and liabilities PIC brings to the planned solution. Understanding those benefits and liabilities is where this article is targeted.

As a software designer my first and most important goal is to make sure my clients fully understand the advantages and disadvantages of each design decision at specification time. This is necessary in order for clients to fully participate in the design of their own software.

For clients who are ready to try web based, pan-platform applications, this article is a good first step on the way to the goal.

There are two sides to a Platform Independent Program:

1. An application which is capable of being run on many different server platforms.   

   - And -

2. A Browser-based User Interface (BUI) which the application provides.

If done well, a platform independent program lets anybody with access to a browser have access to all the features and functionality of the application...

d

To be Platform Independent, the application that runs on the server must be capable of being installed and run on many different platforms. The best way to accomplish this is through an interpreted P-Code language like Perl, or PHP. The most important thing to know about this is that despite how difficult this might sound, it is really very easy to do.

The other side of the PIC story is the User Interface. In order to allow users of many different platforms to interact with it, the application should provide output for display by any Internet browser. By providing a Browser-based User Interface (BUI) the application ensures that anybody with a system running a browser can interact with it.

Some Q&A

Are Web Services and related standards Platform Independent Computing?

No, in fact, one important purpose for web services standards is to provide a way for platform-locked applications to communicate with one another across the Web. Diagrammatically:

d

In this diagram

• You can not run OnlyRunsOnWin.exe on the Moon platform.

• You can not run WrittenForMoon.bin on the WindowPane platform.

If you try you will either crash the system or, more likely, the application will not load.

Also, each application's User Interface can only be accessed on the platform for which it is written or on compatible terminals connected to that system.

In this example SOAP is required precisely because these two applications can only run on otherwise isolated proprietary platforms.

Are Web based applications, such as banking, Platform Independent?

They can be. But sadly, they are often not.

Web applications are designed to run on the World Wide Web, an inherently Platform Independent medium. They can easily be Platform Independent but instead, many choose to insist on only Internet Explorer. Even more distressing, these applications will declare Internet Explorer running on the Macintosh off-limits as well.

Here developers have written something specifically for a Platform Independent medium (the Web), and have chosen to intentionally limit it to only a single browser running on a single platform. This is such a waste of available resources it almost causes physical pain. Think of Mexican oil drillers in the 1990s burning off natural gas so they could get to the oil.

What about enterprise web-based applications?

A web-based application need not be restricted to any single platform or framework, and should strive to be very Platform Independent. But many developers limit themselves to tools provided by a specific platform maker. This often limits the applications they write to only run on that one maker's systems.

As shown in the first section, there are two sides to Platform Independent applications. A User Interface that runs on a web browser, and an application that runs on a web server.

A good Browser-based User Interface should be accessible by users who run them from their Macintoshes, Windows machines, Linux machines, AS/400s, or mainframes. Ideally users should have their choice of any browser that is available to run on their respective platforms.

Likewise, good web-based server applications will run on any web-server platform, including Windows, OS/400, Sun, Linux, or Unix. Platform-locked shops may misunderstand this statement. This is not saying that an application should be separately developed for each and every platform mentioned. It is saying the same application; the same distribution, the same ZIP or TAR file should be installable on all of the above and more. This is not market-speak, it is actually quite easy to do using development languages like Perl or PHP.

Are client-side scripts, like JavaScript, PIC applications?

No, but they can be part of it. A client-side script should have no way to alter data on the local machine's disk. For this reason client-side scripts are generally only employed by Platform Independent application's to enhance their user interface.

Client-side code can be used by a web based application for such things as keeping running totals, disabling parts of a form that are not needed, verifying that form fields are formatted correctly, performing simple conversions on form fields, etc...

Knowing some of the background and understanding some of the facts about Platform Independent Computing does not necessarily impart what it means to use it in day-to-day business. Most of the advantages do not sound sexy or cutting edge. Some advantages are not so easy to see ahead of time. There are also some disadvantages, but those often sound worse in theory than they are in practice.

Disadvantages: real

• Disadvantage: PIC is a force-multiplier... sometimes

  An application that nobody used as a spreadsheet or database program may not be helped by turning it into a Platform Independent application. On the other hand some applications may have gone unused because they lacked the functionality that the web provides. For example, if there's an application that people complain about using because it makes them send lots of email attachments, that's likely going to be a good candidate for "webification".

• Disadvantage: Users of poorly designed Platform Independent applications may experience un-welcome delays when using the browser interface

  A Platform Independent application runs over an internet link, which may be dial-up and may exhibit non-instantaneous responses. A Platform Independent application must be specifically designed to minimize the inconvenience that these response delays present to users. If a developer simply transfers a desktop application's User Interface verbatim, users will find the delays unacceptable.

  If you are a developer, you need to master the art of producing user interfaces that are specifically designed to capitalize on the advantages and avoid the disadvantages of browser interfaces.

  If you are a manager commissioning a project, you must find developers who are familiar with these issues. This is not something you want developers to learn by trial and error while designing your application. If you leave users frustrated and disgusted with your application, you will have a long hard road back to user acceptance.

• Disadvantage: Security will be different

  Most security breaches, whether at your office or at your web site, are inside jobs. Some are not. Just as people can break into your office to steal information and resources, they can also break into your web site to steal information and resources.

  The difference right now is that if somebody breaks into your office you can ask your local police to pursue the perpetrators. If they're caught there's a local prosecutor who will then act on your behalf to insure the perpetrators are punished.

  No such infrastructure currently exists on the Internet. How do you deal with it?

  1. Use a reputable web hosting service to act as your police force.
     -
     Hosting is one of the few things that is almost always better left to outsourcing. They can concentrate many servers into a single building. This gives them economies of scale to implement ultra secure access to the facilities, a full-time security officer, and many other things that make it more difficult for bad people to break in. Is it impervious? No, nothing is, but you will be more difficult to break into than others.

  2. Let security specialists deal with the very high-risk data.
     -
     The best way to avoid liability associated with collecting and keeping high-risk data like credit card information is to not collect or keep it. Third-party credit card transaction processors allow you to hand off control to them just before credit card information is requested. Control is handed back to you immediately following the authorization. You never see card numbers, so you avoid having to concern yourself with the much higher security infrastructure associated with handling them.

  3. Specify that regular backups are performed automatically.
     -
     This will allow your data and applications to be quickly restored if it becomes corrupted for any reason (vandals being only one). You might also want to specify this feature as part of CSV imports and exports which can be useful for more than just backups.

  4. Specify that the application allow you to perform data backups and restores manually from its browser based user interface.
     -
     This will cost extra to implement, but for some may be worth the effort. Automatic backups will require that you contact someone else and ask them to restore your data for you. Manual backups and restores mean you can do it the moment you decide to. The deciding question is: How important are minutes to the application in question. If little damage is done by waiting a day or two for the system, then manual backup and restore facilities are probably overkill and not required.

• Disadvantage: Applications may cost a little more to develop

  At least at first, until in-house expertise increases, there will be a cost premium for development of truly platform independent information systems. This should change generally as more developers break away from the tools and educational materials provided by vendors with a vested interest in platform locked applications.

  In the general sense, the advantages of developing platform independent applications will far outweigh their extra cost. This should be analyzed on a case by case bases though, if only to demonstrate to overseers and stakeholders just how much better the higher cost option is.

Disadvantage: myth

• Myth: Platform Independent applications make it difficult to get at your company's data.

  Data stored on server applications is generally much more accessible than data kept in proprietary desktop applications. If you've tried to export transaction records from desktop accounting programs like Quick Books, for example, you've learned that it can't be done. Quick Books will only let you export minor lists, such as customer names or vendor names.

  In contrast, server applications will usually let you download all your database tables as CSV or XML files right from a browser based administration page. Once you've downloaded CSV file, you are free to view, present, and analyze your data with your favorite desktop spreadsheet or database program. And you don't need to be at the office to do it.

Advantages you would expect:

• Advantage: You have anywhere, any-time access to your applications and data

  This may seem obvious, but please take a moment to consider the ramifications. You are in a hotel room and have some time for paperwork, or have a hot prospect on the phone. You are at your sister-in-law's barbecue and need to check the status of something at the office (yes, you can access a well written web application through her AOL account). You are sick, at home, in your jammies, with only your hot-toddy and your Macintosh. ...No problem, none, just do it.

• Advantage: Your applications will be real-time

  When somebody adds a change to, say, the customer support system the change is available to anybody who views it, immediately. It doesn't matter if they're in the next office or the next hemisphere. It doesn't matter if you're on a PC and they're on a Mac. You can see the change take place while you're on the phone with them. No waiting to get the email with the spreadsheet attachment. The change doesn't have to be imported, cut, or pasted. It is where it belongs from the instant it is entered.

Advantages you may not expect:

• Advantage: You wont have to guess which technologies will "win"

  You can bow out of the hype wars. When you have developed your company's institutional processes and applications as truly platform-independent, web based software, you don't have to worry about which of the many "Next Big Things" will be around in five years. You can step off that treadmill and concentrate on what's best for your company today.

  Whatever happens in the arena of vendor supported and licensed "standards", "paradigms", and "frameworks" your applications will continue to run, and your users will continue to have access to them. When any of these vendors succeed in producing a real (if self perpetuated) need, you can add the capabiltities to your platform independent applications at that time.

• Advantage: Your company's institutional know-how will be kept in applications that run on any platform

  Five years from now, some pimply faced geek in a suit may decide he's going to make a name for himself by increasing server licensing fees five-fold. If that happens, you can just move your server applications elsewhere. You can choose Sun, or Linux, or OS/400, or, heck, QnX if you'd like. If done right, your Platform Independent applications will run just fine on any of those platforms, likely without modification. And your users, using their browsers, will never know there was a change.

• Advantage: Users and support staff wont need to install a thing on their computers in order to run your applications

  This is perhaps the most commonly overlooked advantages of platform independent computing.

  After installing and testing a new platform independent application, users will invariably ask for the installation and setup files. Perhaps by force of habit, support people will also generally ask what they will need to include in the distribution package for people to begin using the program.

  It is always fun to tell them: if they have a browser, they've already installed the distribution package. Just give them their passwords and the starting URL.

• That's true for updates too

  What if you've just designed, coded, and tested a major upgrade of the purchasing and requisition app? Do you need to copy a bunch of disks containing the new distribution and write step-by-step installation instructions? Nope, just install it on the web-server. Yup, it's just that easy. Don't forget to backup your old data first though. If you want, you can do that from home the night before, during commercial breaks.

There is no widely accepted definition for the term Platform Independent Computing or even Web Application. Specifying that your next software project be "platform-independent" may not be enough to ensure you end up with a platform independent application as we have described here.

I will soon release the first article in our How To^specify series entitled Specifying Platform Independent Web Applications. Please watch this section for a link to that article when it is ready (when copyright registration is completed).

This article is © Copyright, Creativyst, Inc. 2003 - 2006 ALL RIGHTS RESERVED.

Links to this article are always welcome.

However, you may not copy, modify, or distribute this work without first obtaining express written permission from Creativyst, Inc. Production and distribution of derivative products, such as displaying this content along with directly related content in a common browser view are expressly forbidden!

Those wishing to obtain permission to distribute copies of this article or derivatives in any form should contact Creativyst.

Permissions printed over any code, DTD, or schema files are supported as our permission statement for those constructs.