Introducing the HP LaserJet 1100A Printer-Copier-Scanner

PC Magazine

  PC Tech

Component Technology: Past and Future

Introduction

Who spends? Who saves?

What Happened Next?

Promises vs. Products

Who's on the Field?

Components in Play

A Buyers' Market

Where We Are. . .



X10.com - The SuperSite for Home Automation!

Find the best buys on computershopper.com - click here!

 
  Categories
Programming

Component Technology: Past and Future
Components in Play

Continued from Who's on the Field?

When the ball gets snapped on the component playing field, who makes the play? In a DCOM space, the handler is likely to be an ActiveX component; in a CORBA space, the handler is likely to be an instance of a JavaBeans class.

ActiveX components were created by Microsoft when the company needed to slim down its unwieldy OLE (Object Linking and Embedding) technology. Designed for the generous communication bandwidth of in-memory communication, OLE carried overhead (such as the memory structures needed to define an on-screen window) that was not always needed and whose burden was unacceptable on bandwidth-limited Internet connections.

ActiveX components are made up of binary code that's specific to a particular processor, meaning that an Internet populated by ActiveX components can quickly become a Windows-on-Intel (or "Wintel") environment. Because ActiveX components execute directly on the processor of an Internet client PC, they can do anything that the PC's user is allowed to do.

On a completely insecure operating system such as Windows, the open-ended privileges of ActiveX allow a downloaded component to do anything at all, making the viewing of active network content a high-risk proposition.

JavaBeans components are intermediate Java byte codes, executed by a Java Virtual Machine as implemented on the client software/hardware platform. Unlike ActiveX code, JavaBeans are in no way specific to any operating system or processor architecture: It is the job of the Java Virtual Machine to translate platform-neutral byte code into the local hardware's corresponding native instructions. The resulting indirection makes it possible for developers to limit a remote component's privileges.

Many people erroneously believe that Java security is an all-or-nothing proposition, having seen only Java applications (which have no security limits) and Java applets (which place stringent limits on high-risk activities such as access to the client machine's local files). Actually, Java security is extremely fine-grained: For example, a particular Java environment might let imported code open only files whose names begin with the letter G.

There is a large vocabulary of check() methods that a Java developer can tailor to a particular situation, defining in detail exactly what will be permitted. With their precise control of the privileges available to active network content, JavaBeans components are intrinsically less worrisome to a network administrator than ActiveX controls.

The security model for ActiveX is based on cryptographic signing, which tells you whom you can sue if rogue ActiveX components damage your local resources. The security model for JavaBeans can prevent such damage from taking place, and it can trigger a warning that a malicious action has been attempted.

Next: A Buyers' Market

Published as Enterprise Computing in the 4/20/99 issue of PC Magazine.

 
 SPONSORED LINKS
Finance  Introducing the newest standard. 1 minute. e.card
WIN  A FREE Toshiba Laptop!
Software  Looking for software? Buy Smart, Buy Fast, BuyDirect!
Software  X10.com -- The SuperSite for Home Automation
Books  Find BOOKS up to 40% off at barnesandnoble.com
 ZDNET FEATURED LINKS
Freebies!  50 FREE downloads -- the top programs of the year
Shop & Save  How-To-Buy Guides: Find the best deals online
Learning  FREE trial of ZDU online courses available now!
 MAGAZINE OFFERS
Free Issue  Get a risk-free issue of RED HERRING magazine today!

TOP
Copyright (c) 1999 Ziff-Davis Inc.