| If you're asking whether you can get to the intranet through America Online (AOL), you've missed one of the most important paradigm shifts in recent history. Intranets aren't new technology; they simply redeploy internal applications using traditional Internet tools. The way your data is managed hasn't changed. Nor has the custom application-deployment process been simplified. Instead, building an intranet simply redistributes the work and creates a new model for end-user interaction.
Rethink the Process
Throughout history,
inventions have enabled us to look at small aspects of life in different ways. Humans have applied these innovations to virtually everything they know. Although the new solution may not be the most efficient, it's usually more cost-effective and requires less work than the previous one. Gradually, the process becomes optimized.
Groupware applications are such an example. Currently, we are at the "inefficient, but easy-to-deploy" phase. Initially, software vendors had a proprietary stranglehold on the groupware market, not because they had the best technology or the most interoperability but because they had the best tool for the job. Int
ranets are starting to change the groupware market into a standards-based free-for-all. But, to remain competitive, vendors will add proprietary extensions at an alarming pace. Look at the Microsoft-Netscape battle of the browsers.
In the long run, the intranet solution can't continue to work strictly with the Internet's standard protocols. To get the extensive function
ality of a package like Notes, you have to have proprietary means. Issues, such as data replication, are not standardized anywhere--and you shouldn't plan on seeing standards here any time soon.
In the simplest terms, an intranet puts a Web front end on every bit of data that your company has made available to the desktop. In the past, access to data stores from the desktop meant custom application development using client tools from your favorite database vendor. Now, application development happens on the intranet (Web) server, requiring a new perspective on software development and a different set of tools.
In the case of intranet development, the tools are no longer developed for every desktop, be they Microsoft Windows, Apple Macintosh, Unix or any other desktop systems. Data-access tools are implemented on the server and can be accessed through methods such as Common Gateway Interface (CGI). Support and implementation have moved from every individual machine to a centrally located server.
Something New
Since it is possible to access every data source from the Web client, companies are doing just that. This reminds me of a favorite expression, "Funny how everything looks like a nail when you have a hammer." Companies are trying to deploy Web interfaces regardless of the data source or formatting--employee information, product inventories, internal inventories, technical-support data--you name it. But with some experience and experimentation, not everything will look like a nail.
With a little innovation, data transaction becomes a two-way street. In addition to displaying data, browsers can post data to the server using for
ms. So, complete database front ends can be created with forms interaction. However, the basic development tools don't provide the same convenience of canned solutions as the traditional database development tools, meaning most of the hard work is left to the implementer and C++ code.
Not Everything Is Perfect
Although the intranet may sound
like the s
olution to everyone's problems, not every solution is best-of-breed. Think of the poor server's task! Suddenly, all data processing is the Web server's responsibility. And, though they have come a long way, CGIs are not the best answer. In the case of PERL and other scripting languages, you will take a huge hit in performance because PERL is interpreted, which means it runs slowly. In addition, there is time and memory required to start up and tear down the interpreter every time a script runs.
Some of these problems can be solved by using the Web servers' application programming interfaces (APIs). But, this requires actual programming (meaning C or C++) and a lot of in-depth knowledge of the operating system, as well as the Web server software's APIs. Development time can be longer than writing a simple script. But, if your server load is going to be high, applications that hook into the APIs will scale much better.
Don't forget the wasteful model that we have created at this point. We need to put more
computing back on the desktop, without re-creating the cross-platform hurdles we've relegated to history.
Enter Java
In the case of client/server computing, Java may the best solution for most situations, but it will cost performance and development time. Unfortunately, most people don't understand the Java concept from the start. They think it simply means cool animations in their Web browser, when in fact, Java is a fully contained programming language, very much like C++.
The most interesting aspect of Java i
s what's called an applet. Applets are pseudo-compiled programs that run in an interpreted mode. With Java-applet interpreters cropping up in Netscape on every platform, architecture-neutral code is attainable. Some software developers, such as Corel Corp., have announced that they will be porting all their apps to the Java development environment. Imagine how much closer they'll be to deploying productivity apps on the Net and intranet.
In addition to providing cross-platform code,
Java applets are run on the local machine, pushing the load off the server and onto the client. However, as mentioned, be forewarned that Java applet interpretation currently is very slow. Just-In-Time (JIT) compilers will start to ease that pain by converting the applets to more architecture-specific code on the fly, though most of the early JIT incarnations, such as the one in Netscape Navigator 3.0, are only marginally faster.
Intranets, like every technology before them, are striving for the speed, flexibility, scalability and manageability network administrators demand. Yet, intranets still are in their infancy and, like any new implementation, they will have a fairly serious shakedown shortly. There are some rapid development, turnkey solutions that will get you the basic access to data. If you're into the traditional methods or have some very proprietary data sources, you may want to try your hand at custom programming using PERL, C++ or Java.
Database access tools will mature and Java interpret
ers will be more optimized. Also, the same visual development tools will be available for Web development that are available for custom application development. It's a brave new world and the intranet won't go away. All we need do is teach the Web browser and we may have a universal data access tool.
Robert J. Kohlhepp can be reached at rkohlhepp@nwc.com.
|