IE4: The First Fat Client Browser

It is usually assumed that any browser-based application architecture is a thin client. As discussed in JDBC Brings the Fat Client to Java, this has not necessarily been true since the introduction of JDBC. With the introduction of Internet Explorer 4, Microsoft allows fat client applications to be implemented in the browser without Java.

Which Thin Client?

Thin client has at least two meanings, as discussed in Distinguishing the Mulitple Meanings of Thin Client and Fat Client. The first, which refers to physical platforms, is not what is considered here. Rather, this brief concerns itself with physical software architectures. In this context, thin client implies that only the user interface and minimal application logic reside on the desktop. The bulk of application logic and the database access component are deployed on servers. Thin client architectures are useful for a variety of systems, especially those that include significant business logic that may be shared with other systems or which may change frequently. This architecture can also be scaled effectively, and it is generally easier to manage the configuration.

Thin client architectures by no means require Java or a Web browser. In fact, they pre-dated both of these technologies. Virtually any tool can be used to create thin clients, including notorious "fat client tools" such as PowerBuilder and Visual Basic. It is at the discretion of the architects and designers of an application as to whether thin client is the proper model to implement.

Traditional Browser-based Clients

Browsers originally provided only a means to render HTML documents. Applications using such browsers for clients had to be architected such that logic (code) and data resided "behind" the Web server. The code was written in a variety of languages and accessed by the server via interfaces such as CGI, NSAPI, ISAPI and WSAPI. As scripting was added to browsers, some code moved to the client. The amount of such code, however, was kept relatively low, at least partially because of the restrictions placed on it. No access to local resources was permitted for security reasons. Further, script could only affect the appearance of a page as it was being rendered. Once displayed, the page was static. These restrictions made browser scripting significantly different than "normal" programming.

Much as has been the situation with Java, however, the lack of a means to directly access client/server RDBMS engines from browsers is probably the greatest barrier of entry for corporate IT shops trying to deploy browser-based applications. The bread-and-butter architectural style for these departments is, as characterized by Gartner Group, remote data management. To use traditional browsers requires a 3-tier architecture, with the accompanying thin client. While more sophisticated shops have been evolving in this direction already, most are not ready to take the plunge.

IE 4

With IE 4, Microsoft has changed the rules of browser-based deployment. Dynamic HTML, which will also be supported by Netscape, removes the scripting restriction about changing the appearance of a rendered page. Pages are completely dynamic, and the scripting environments have access to all elements on the page and their attached properties and styles. Microsoft extends dynamic HTML with scriptlets, providing developers with a means to encapsulate snippets of HTML and script into components. (Need I add that these are ActiveX-based on Win32 platforms?)

Whereas Dynamic HTML is an evolution, however, Remote Data Services (RDS, formerly known as Advanced Data Controller or ADC) is a giant leap. RDS is implemented as a set of COM objects in DLLs that ship with IE4. (It can also be installed for use with IE3.) The COM objects provide an API similar to ActiveX Data Objects (ADO), but the implementation includes a component behind the Web server to which the RDS objects talk, rather than connecting directly to the database as in ADO. This component need not be programmed, nor is there a need for any use of a Web application server, such as Active Server Pages. Static pages containing HTML and script can contain the code for an entire application that uses a remote database as a data source. No other objects need be loaded over the wire.

Support for Developers

While the architecture of applications using RDS is technically three-tier, development can have a decidedly 2-tier flavor, since all the code executes on the client. I expect the next version of Visual InterDev to provide RDS support, and I wonder whether there will be some crossover to the Visual Basic environment for development of VBScript applications.

Architectural Saving Grace?

With Microsoft making it so easy to maintain the status quo, developing fat client applications that just so happen to run in a browser, is there any hope for general architectural improvement in corporate development? I believe so, and some of the help comes from Microsoft. First, RDS itself includes an RDSServer COM object. This allows logic to be added to the RDS middle tier. Whereas a basic RDS client would have its SQL request simply forwarded to the RDBMS by the middle tier, RDSServer allows the client to talk to server-based code, which can perform additional processing of the data. Second, MTS will continue to gain importance as a central controller for a growing number of COM components on the back end.