by Bill Schongar
Are intranets just a bunch of hype? Corporate networks for sharing resources between departments and across locations aren't anything new; local area networks (LANs) and wide area networks (WANs) have been in mainstream use for well over 10 years. The infrastructure and the technology used to turn a LAN into this amorphous thing called an "intranet" isn't anything new and spiffy either, because the basic communications protocol used to power an intranet, in the form of TCP/IP, has been around for quite a while as well. So what's so brand spankin' new that it needs all the publicity? The feeling of "new" comes from the way the network is being used.
If you think about a basic file-sharing network, you have a server (or any multiple of one that suits your needs) and a bunch of files resident on a drive. That's all you get. If you need the latest copy of the company financials, you have to make sure you get access to accounting's drive, figure out where the file is, figure out what its filename is, and then make sure that you have something to read that file format. What, you don't have XYZ accounting software? Back to square one. E-mail the folks in accounting and ask for a hard copy. What a welcome to the age of technology. To the end user there is no interrelation of data, no reasonably clear method of general organization (unless you count being able to decipher DOS-style 8.3 format filenames as an efficient method of organization), and no leeway for incompatible data formats. What you need is an intranet.
The relationship between, and organization of, pieces of information is just as important as being able to view the information in the first place. Intranets are built on organization and interrelation, because they're designed as a way to share information, not just files. When you look for the corporate financials, you might expect to find a link to performance by month or by quarter, maybe by department or product. These in turn may have other factors involved in their creation, and you should be able to track them all down with just a quick click of the mouse. When you want to submit a request, you shouldn't have to track down a paper copy of a form and then get it checked, processed, and tossed into the mysterious depths of getting approval. You should be able to go to an easy-to-find location, find the form you need, fill it out online, have error-checking done for you, receive confirmation that you submitted it, and be done with it. That's not too unreasonable, is it?
In short, an intranet is all about getting the most bang for your information buck. This is where ActiveX and VBScript make the difference. You can add powerful functionality and flexibility to your intranet without breaking a sweat. Users can update data in its native format, not worrying about conversion to some static chunk of HTML or a graphic. Want a spreadsheet? No problem. Want a multimedia slide show? You got it.
Want client-side processing, self-updating distributed applications, complete design flexibility, and some free time? You can have it all, and we'll show you how. In this chapter we'll focus on elements of ActiveX and VBScript that power your intranet to new levels, including
Client-Side Processing
Distributed Applications
Native Data Formats
Return on Investment
Whether you already have an intranet, or are trying to justify the expenses associated with creating or improving one, this chapter will show you how ActiveX will kick your site into high gear, at a price point you can live with and with functionality you won't be able to live without.
1Mbps, 10Mbps, 100Mbps.... Let's face it, the network is never fast enough. No matter how fast you improve your network, something will come out that sucks up all the speed you have available, and then some. The more users you add to that lightning-fast server, the more all that speed seems like just another flash in the pan. The only way you can ever get a server to reach its true potential is to offload the menial tasks onto some other machine. Well, how about the users who are accessing the network? They have connected computers that could take on responsibility for their tasks, don't they?
Client-side processing is an increasingly important aspect of client/server computing. At first, it was enough that the two computers could talk to one another, and the server could be the processing powerhouse. That's akin to calling Julia Child and asking her to cook you dinner- if you have access to all the instructions and materials, why can't you do it yourself? Sure, an expert can probably do something faster and better, but if dozens of people call up with the same request over and over again, it's not going to be faster to wait for the expert than it would be to do the work yourself. Client-side processing gives the server a break, because it means you can download everything you need to do a job, and the server only has to process a fraction of what you really need, for tasks that require shared resources that your machine can't handle by itself.
ActiveX and VBScript are true client-side enabling technologies. You don't run embedded VBScript the way that you run a CGI program, where you call to the server, it thinks about it, it responds, and you repeat the cycle until you get what you want. VBScript is downloaded and run in your memory space, on your processor, with no network bandwidth taken up for paltry data operations like validating forms output. Do you really want to take up even a fraction of available server resources telling someone he forgot to enter an extension on his phone number, or a departmental billing number?
It's exactly these kinds of basic but necessary operations that VBScript and ActiveX can provide instant benefit in. Let's take the example of client-side forms validation in a little more detail, starting with the traditional method. First, the server has to download the form, which in and of itself is pretty static. Next, the user has to enter data. Any validation of that data has to initiate a connection to the server, the server has to start a process to evaluate the data, establish a connection to respond, and the end user has to receive it. Now, if this is a form that's accessed by one or two people twice a day, that's not very significant. If, on the other hand, this is one of a thousand such forms that on average get hit hundreds of times an hour, the processing savings for the server are significant, and the total performance benefit for users is extremely high. After all, what's faster-negotiating a conversation with a network server or communicating with a program resident in memory on your local machine?
Proceeding to the next level of client-side processing, you encounter distributed applications. More than just a script here and there, fully distributed applications provide the end user with all the files he needs to run a full-fledged application. Typical network installation of applications designed to be distributed is either localization of the programs' executables and support files on a drive that everyone runs them from, or asking users to go to that drive and download all those files locally. "Activated" applications can be fully functioning combinations of ActiveX and VBScript components working together, where it's downloaded once, automatically, and automatically updated to the latest version when it needs to be, by just a visit to a specific page.
What kinds of distributed applications are possible, and logical, for the corporate intranet environment? Here are just a few:
Order Processing
Training Materials
Inventory Controls
Data Warehousing Clients
Scheduling Applications
The point of distributed applications is one you're already familiar with-keeping efficiency maximized. Fully distributed applications put the majority of the processing load on the client, rather than the server. This shouldn't be equated to isolation from the server. Far from it! Distributed applications don't need to be completely stand-alone applications, in that they would need to download a database file or similar shared resources, but the majority of the action taken on those resources should be done without the server's intervention. Record locking, error-checking-all these things should be done before the connection to the server kicks in.
Database functions are traditionally processor-intensive. Everyone needs them, for anything from orders and inventory control to holding employee information. The benefit of placing database operations in a distributed environment is that while the data exchange operations may take up a significant portion of the server's time, formatting the results is taken care of "offline," without tying up the server resources. As an example, let's consider a CGI program performing database operations.
First, there's the client side. A simple form or alternate interface provides data entry. No error-checking, no real interaction, just type and click. When the user submits the form, data is sent to the server where the server needs to start a process to handle the CGI program, barring the use of in-process server extensions for handling the request. The CGI program then decodes the URL-encoded information and generates something that functions as the calling convention for the database. Next, something needs to initiate a connection to the database, execute the data query, store the results, process the results, process output to match those results to the displayable needs of the client, encode the output, and send it back to the client. The client then loads the new HTML page and displays the static results. It works, and it's definitely a useful function, but there are a couple extra steps there.
With a VBScript and ActiveX solution, the client side takes care of all formatting and error-checking. Pass back a stream of database information, and let the client deal with it. Forgot an entry? Don't ever let the connection to the database open until everything is ready to go. Need more efficiency? Communicate directly with the database or its own special server, and bypass the need for an HTTP server as a middleman. It's not a matter of any less work being done, but rather the location and the efficiency of the work that makes the difference.
Even better, think of what you can do with the results. CGI returns
come back as a standard text stream, with the possibility of some
images and other content. ActiveX and VBScript could handle a
streamed pile of data and fill dynamic listboxes or other UI features
so that you can modify what you get, and send it back. Tried modifying
a typical HTML page as the end user lately? Good luck. Taking
tables of data, listboxes, and even images, you could modify them
and then stream them back to the database. One-stop shopping for
your database needs.
| TIP |
Open database connectivity (ODBC) over the Internet is a growing field. Companies have announced drivers and utilities that allow direct database connections through built-in drivers so that the database server is also the TCP/IP server for database requests. Large database vendors including Oracle, Sybase, and Informix are heavily involved in making all of this a reality, and you can expect to see ActiveX playing a big part in their strategy and in the strategies of people riding their coattails. If you're interested in a direct Internet-capable driver for your database, check with your database vendor to see what they have available. The results may surprise you. |
There's more possibility for functionality in ActiveX and VBScript combinations than you can easily shake a big stick at. The list of ActiveX controls grows by dozens a day, and that's a bare minimum. OLE and extension controls (like VBXs) have been made by thousands of individual software companies for C and Visual Basic, and the opening of a whole new marketplace has inspired them to new levels of productivity. Chances are quite good that no matter what type of ActiveX control you need, you can either find it already, find something close, or find the instructions to build it yourself. There are certain areas of functionality, however, that transcend specific controls, and fall into general categories of use to the intranet frame of mind. Let's look at a few.
Have a lot of people creating material, but not a great way to convert it into HTML or some other arbitrary format? ActiveX is about to become your best friend. The whole concept behind OCX (and thus ActiveX) controls is to provide a generic container to which additional functionality can be added. The most obvious use of a generic container is to toss in different forms of content.
As an example, someone in your department has created a PowerPoint presentation. Now you'd like to share that with the rest of the company. You can either start taking screen captures and converting to HTML and JPEGs or GIFs, or you can take the easy and more functional way out. Not a tough decision. Microsoft came out with an ActiveX-enabled PowerPoint player, which allows you to embed the ActiveX player object in the HTML code, and reference a filename for the presentation itself. Suddenly, everyone who uses PowerPoint can place his or her presentations up for general use, with no conversion, no mess, no fuss!
The same holds true with other information types. Previously, the network involved hunting down the file you wanted, then hunting down the utility you need to open the document with. Now information is menued and organized, with logical text and links allowing information managers and employees in general to devise navigation that will lead people to relevant information without the hunt-and-peck of a flat file system.
New functions are just an .OCX file away. Because ActiveX is an open software component environment, any new capabilities that you need can be built in quickly, efficiently, and painlessly. Each new function is capable of cooperation with existing components as well, so that a database program doesn't have to be a reporting software, and a slide show presenter doesn't have to understand HTML. Everything plugs together to form a seamless whole.
You don't have to think of everything. How are people supposed
to sell you ideas and products if you've thought of, and implemented,
everything you could possibly ever need? The number of developers
out there who are creating ActiveX components is staggering. Pick
up a copy of any magazine dedicated to Visual Basic, flip to the
advertisements in the back, and you'll get some idea of what kind
of industry already exists for add-on components. Because VBXs
(the add-ons for Visual Basic) aren't too far away from ActiveX
controls, the vast majority of these developers will be moving
in that direction just as soon as they smell the money. And the
smell is getting stronger by the day.
| NOTE |
Using ActiveX functions on your intranet may be initially limited by the platforms that comprise your network. ActiveX on UNIX, for example, wouldn't have been the best option in the first few months after ActiveX's release. At the time of this writing, in fact, going to UNIX was not even a possibility, though it was being hyped heavily as a future development. Macintosh was the first scheduled platform besides the native Windows implementations, and even that hadn't come to fruition by October. Rest assured, though, that Microsoft realizes that they'll lose a significant chunk of potential revenue if they only cater to Windows, and they'll do everything in their capabilities to make sure platforms aren't a problem. |
"But what do we get back, financially?" It's a question heard all the time in companies big and small. Look at what you get so far-less wear and tear on the server, less maintenance, better performance, more functionality, and more expandability. Do these add up to big savings? You'd better believe it. And all of these contribute to two other significant improvements-employee efficiency and company image. Let's look at all of the fiscally friendly components.
We're not talking about cleaning the hard drive, or replacing monitors. Maintaining a corporate information system is all about keeping information up-to-date and accessible under any conditions. Fault-tolerant, mission-critical access is the kind of talk that people in high places like to hear. Maybe it's because they've been reading "Dilbert" and picked up some buzzwords, or maybe it's because they actually need those things; the jury's still out on that. Regardless of the real or perceived need, maintaining an information system comprised of data in a non-native format is time-consuming. Finding out about, getting hold of, converting, error-checking, and approving data before it goes anywhere is taking two steps forward and one step back every time you move. By allowing departments to leave documents in their native format, and using in-place document embedding through ActiveX controls or plain old OLE, responsibility for content can be narrowed down to two things: the accuracy of the original data, and the relocation of the data to the shared area. So, if there's a typo on line 3005 of this year's budget, let accounting fix it. If the new product schematic is missing a power cord, let R&D figure out where to put it and then have them modify the schematic. Isn't delegated responsibility great?
Reduced maintenance equals reduced costs, plain and simple. Less time lost from other revenue-generating projects, less time spent moaning and whining about not being able to get things converted properly, and fewer mistakes due to the conversion or modification by someone outside the originating department.
MIS Nightmare #23. You research, plan, design, recommend, specify, and purchase a state-of-the-art system that meets all your needs, only to have those needs completely change a week after you put everything together, and none of the vendor's partners ever come through on their original promises to develop what you need for the system you bought. While good planning can reduce the real instances of this nightmare, the underlying problem of technological obsolescence is anything but easily solvable through traditional methods. Scalability is what's needed, but it's often hard to scale a software solution because vendors change, new technology emerges, and everyone always wants what he or she read about that's currently not even in beta form yet. And, oh yes, it all has to work together with his or her existing stuff seamlessly.
ActiveX components give you the ability to say "No problem." What you're really building around when relying on ActiveX is a scalable software component architecture, like a modular server. Every time a new need arises, you've got plug-and-play expansibility by adding new components, and you know that each ActiveX component can communicate with the others easily and efficiently. You can even write custom code to integrate disparate elements in your own unique way, if you need to. This means that one department's need to have terminal emulation in a Web browser (shudder) and another department's need to integrate a proprietary legacy database format can both be accommodated, and even that some outside development company may already have done it for you with a component you can purchase.
When Microsoft decides to make a standard, and puts as much marketing power behind it as they have with ActiveX, you can be sure that it's not going to disappear in the near future. Before you bring up the inevitable subject of Microsoft's original failed foray into UNIX (called Xenix, for those of you who have forgotten that unfortunate incident), remember that ActiveX comes at a time and in a form that lots of people, especially Windows-centric developers, want very badly. They want to be able to make their applications Internet-ready with the addition of a file or two. They want to add other people's functions to their software without pain and frustration. And they want it right now. ActiveX delivers on all of those things and promises to deliver compatibility with Java as well.
That's what it comes down to, though, isn't it? Whose standard is going to become the one to follow, and which technologies are going to become tagalongs? Java made a splash the size of a tsunami when it first came out, and the rush continues. Why? Its goal in life is cross-platform compatibility and portability. This makes it a good choice for network computers and companies with diverse system types and the desire to program in a language slightly less cumbersome than C++, while still maintaining an object-oriented approach. Microsoft, however, is intent on making sure that if they can't conquer Java, they'll embrace it with ActiveX.
The first sign of this was the ActiveX scripting extensions that Microsoft built into Internet Explorer. Not just support for VBScript, their own scripting language, but support for JavaScript as well. In the same manner, scripting languages can communicate with ActiveX objects, and ActiveX objects should be able to communicate with Java classes and functions like Java Database Connectivity (JDBC). Countless companies are either already working on Java and ActiveX integrated solutions, have preliminary versions out, or have announced that they're going to pay very close attention to the marketplace.
Even in the worst case, where ActiveX competes with Java and causes a standards rift akin to the old Mac versus Windows debate, thousands of development houses whose bread and butter is made on Windows programming will be cranking out ActiveX components all the time. That adds up to a significant number of development resources that will continue to use ActiveX no matter what happens, which is better than what can be said for a variety of other new technologies that have fallen by the wayside in recent years.
How many Windows programmers are there? How many Visual Basic developers are there? If you're a large corporation, chances are pretty good that you have one, the other, or both classes of those developers in-house. If you're a small company with a smaller budget, the chances of having a VB or Windows C++ programmer in-house are even higher, percentage-wise. If you, as a company or an individual, have invested significant time and effort into learning a certain programming language, the cost to switch you over to a new environment can be pretty high. ActiveX and VBScript aim to change that.
Because VBScript is a subset of Visual Basic, it's no trouble at all for a VB programmer to switch "down" to VBScript and learn what functions are no longer available to him, as well as learn ActiveX object syntax. Rather than a reduction in the toolset, it's an extension of what the programmer can already do, with no toolkits to buy, no distribution licensing to worry about, and plenty of possibilities.
While creating ActiveX controls isn't exactly a walk in the park, experienced C++ programmers (especially those with OLE and COM object experience) are just extending their knowledge base, not retraining themselves on a new language or a new set of tools. The same environments that they have on their systems, be they from Borland, Microsoft, or anyone else, will undoubtedly gain ActiveX built-in functions to make the development process easier, so future upgrades will roll in the ActiveX cost already.
In all cases, training and software resource costs for employees are kept to a minimum. This is bottom-line good news for any company, regardless of size. No need for extensive training, combined with the ability to maintain familiar development environments, means that ramp-up time for development is also kept to a minimum, yielding more profits sooner.
Two choices: a huge pile of unorganized papers, or a filing cabinet that you know is organized and updated on a regular basis. While the former may aptly describe my desk, most of us would choose the latter as the best place to hunt down a specific piece of information that should already be stored there.
Distributed applications and client-side processing using ActiveX mean less time wasted when network traffic is high or a server is being obstinate, less time spent trying to figure out how the data presented on a page corresponds to the original information, and more time available for interpreting that original data in the way it was intended. Most important, employees will have increased the rate at which they can locate the information they need, when and how they need it.
You're on the phone with someone at Company X, and you ask what you're sure is a question that he or she is not going to be able to handle. Expecting "Umm, let me transfer you..." or dreading the possible use of canned hold music while they hunt down someone from another department, you're shocked when he or she says it'll be no problem to look that up for you, continues discussing other tidbits with you, and then relays the answer you were looking for, and even offers to e-mail further documentation to you right now. Inspired, you ask a couple of other questions that some other companies you called last week still haven't gotten back to you on. Issue after issue, it's the same-the person you're talking to has all the information you need and then some.
What kind of image would you have of that company if you called them? Probably the same kind you'd want your customers to have of you-prompt, efficient, knowledgeable, and very well organized. The benefits of a corporate intranet don't stop at the company doors. If employees know they can track down the information they need, at times when they're the most desperate, they'll be more confident. Customers may not know you have an intranet, but they'll know you've got your stuff together, and it'll inspire confidence in them as well. All of these bolster your company's image to both employees and customers, which is in and of itself one of the most valuable returns you can get. A 10-person company can do business like it has a thousand employees, and a large company can provide a single point-of-contact to give customers a personal touch.
This idealized version of the intranet is far from being just a daydream. New developments and a constant flood of interested consumers keep the desire for companies to develop intranet solutions very high. HTML itself was a good stepping stone for information, but intranets are becoming more than just static pages. They're now hosts for distributed applications and client-side data processing, with the need to represent the latest and greatest information on a minute-by-minute basis. ActiveX and VBScript can be combined to meet the needs of your corporate intranet easily, effectively, and cost-efficiently.