Papers in PDF format

Avoiding Vendor Lock-in: An Open Approach To Building Internet-Based
Applications
Introduction
Rick Horowitz
Internet & EC Consulting Practice
SPL WorldGroup Consulting
U.S.A
rick_horowitz@splwg.com
For the first time in the history of the commercial computing industry, users of computer systems have the "real"
option to build commercial-grade business applications using open technologies available from multiple competing
vendors. The savings from such a strategy should be great, as multiple vendors will be forced to compete for the
hardware platform, system services, communications infrastructure, and development tools used to enable the next
generation of business applications. This short paper discusses the obstacles that vendors are placing in our way to
prevent us from true vendor independence.
Last Year’s Battleground
Last year’s standards battleground revolved mostly around Netscape, as they “improved” on the standards with
their own proprietary features. Netscape both won -- and lost -- this battle. They won by influencing the direction
of the web, setting de facto standards for protocols and features, and increasing the overall usage of the Internet.
They lost because they have been largely unable to lock customers in their proprietary extensions. Their key
competitors, including Microsoft, have implemented the most important Netscape extensions, including many of
Netscape’s proprietary APIs.
1. HTML: the document description language for hyperlinked web documents. Netscape created many nonstandard
HTML extensions, restricting HTML pages designed with such features to work well only with
Netscape Navigator. However, now that Microsoft has implemented virtually all of the proprietary Netscape
extensions, and has publically committed to supporting the HTML standards process, it appears that all
browser vendors, including Netscape, will fall in line with the standards. The tag line, “Best viewed with
Netscape Navigator”, is not seen nearly as frequently now as in the past. Stick to the HTML standards in your
apps. HTML will not be a future battleground for vendor lock-in.
2. HTTP: the protocol used between a web browser and a web server, allowing a browser to request downloads of
web pages, and enabling the transmission of HTML form data to web-based applications. This battleground is
quiet and should not become a source of vendor lock-in.
3. S-HTTP and SSL: two separate “standards” have emerged for secure (i.e. encrypted) transmission between the
web browser and web server. S-HTTP, promoted by the CommerceNet consortium, has received fairly wide
support, though SSL, from Netscape, has received even broader support, and should be considered a de facto
standard.
4. CGI, NSAPI (now called Netscape Server Plug-in API), and ISAPI: CGI is the “standard” means of
interfacing an application with a web server, allowing the application to receive and process user data from
HTML forms, and allowing the application to transmit dynamically created HTML pages back to the user’s
web browser. Although CGI is universally supported, its performance is poor. For this and other reasons (e.g.
vendor lock-in and functionality enhancements) Netscape and Microsoft have created alternative mechanisms
for interfacing a web-based application with a web server -- NSAPI and ISAPI, respectively. So far, although
these interfaces have been implemented by some other web server vendors, neither Microsoft nor Netscape
have implemented the other’s server API. Use of NSAPI or ISAPI could restrict future application portability
between web server vendors -- Caution!!
5. Netscape Client Plug-in API: Netscape invented the plug-in API in 1995, allowing downloaded native
applications to operate within the browser context, providing a greater level of integration between the browser