Papers in PDF format

and the application than integration as helper applications could. The plug-in API has been adopted and
supported by Microsoft and some other browsers, making it usable as de a facto standard.
The Next Battleground - Java
The new battleground is Java. “Hey, wait a minute”, you might ask. “Sun created Java -- don’t they control it?”
Well, yes -- and no. Sun controls the name and they control the definition of the core Java libraries. But they don’t
have any control over additional class libraries that other companies might happen to make available to developers
of Java applications and applets.
Contrary to many people’s expectations, Microsoft is now marketing Java heavily, urging their customers to use it.
What, then, is the problem? The (potential) problem is that Microsoft is marketing Java as nothing more than a
language with which to build Microsoft-proprietary ActiveX controls (formerly OCXs). The advantages, say
Microsoft, are cross-platform execution, due to Java’s platform independence, and automatic integration with
Microsoft’s environment. Microsoft is even taking steps to create an independent standards organization to make
future ActiveX direction open to the industry, and claims that we will soon see distributed COM (the object
communication underpinning of OLE/ActiveX) on multiple platforms, including Unix and Mac. Extreme caution
is advised, however. Microsoft has a history of creating and controlling standards for its own benefit, generally to
the detriment of its competitors and even customers. This looks, smells, and sounds like a lock-in strategy.
Beware!
What about Netscape? Well, we like Netscape’s strategy a lot better than Microsoft’s, but don’t believe that it is
benign with regard to lock-in. Netscape’s standard is based on a conglomeration of technologies and APIs recently
renamed Netscape ONE. Some of the technologies found in Netscape ONE, such as the client plug-in API, are
supported by multiple vendors. Importantly, Netscape’s system services, including security (based on X.509),
messaging/email, and directory services (based on LDAP), are absolutely open and will be supported by many
vendors. Our main concern with Netscape’s strategy is the core of their application development strategy, a new
and to-be evolved set of Java class libraries, dubbed the Internet Foundation Classes (IFC). IFC will ultimately
provide access to the full range of Netscape services for Java-developed applications via the IFC APIs. Many of the
planned libraries appear to overlap with offerings in the works from Sun, including the initial offering within the
IFC umbrella, a UI library, that directly overlaps with AWT, the core UI library from Sun. Although Netscape is
licensing the technology to other vendors, which should, in theory, even the playing field, Netscape will hold a
performance advantage over other vendors unless licensees build IFC into their browsers, and could develop an
unbreakable competitive advantage over the rest of the marketplace by controlling the interfaces through which
applications derive system services -- ala Microsoft, today.
What about Sun Microsystems? Sun’s JavaSoft unit has been very busy defining a broad set of class libraries (i.e.
APIs) for important services including database access, security, payments, and the all-important JavaBeans effort
to unify all the major object document standards, including OLE/ActiveX, OpenDoc, and LiveConnect (Netscape).
Since Sun is freely licensing its Java technology for inclusion in other companies’ products, including both
Netscape and Microsoft, use of Sun’s base classes appears to be the safest and most open choice for the future. All
licensees of Java are required to support the entire core library, ensuring technical support, if not marketing support
for these evolving Java standards.
Conclusion
So, what is one to do? If one is happy to be a captive of either Microsoft or Netscape, the answer is easy. Put your
hands behind your back and enjoy your new handcuffs. They shouldn’t hurt any more than the old ones. On the
other hand, if one prefers an open approach that will not give you the vendor lock-in blues, investigate which
vendors are supporting which standards, align with vendors and consultants dedicated to truly open applications,
maintain a bias towards using Sun’s Java APIs, start some pilots, educate, educate, educate, and keep smiling. For
in the long run, you will come out the winner.