| DCOM Explained by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98

Previous | Table of Contents | Next

### In Summary

In Microsoft’s world only two approaches for building distributed applications using the Internet are possible. Microsoft does not provide a Java version of the COM libraries, so DCOM itself cannot be downloaded, primarily because Microsoft does not want to encourage the use of Java, which has the potential to seriously undermine their hold on the desktop. This means that Microsoft’s first solution for Internet use is based on the normal HTTP and Web server-based model of connectivity. A Windows client accesses Microsoft’s Web server from Microsoft’s Web browser and through the Web server gains access to DCOM and applications via Active Server Pages.

Figure 12.6 Example configuration for a known user

This approach is limited, as we have seen, because of the use of the HTTP protocol. It means that building applications which run over the Internet is going to be something of a dispiriting experience if you are using DCOM because of the limitations of the technology. Essentially, DCOM is not designed to support distributed applications over the Internet. Alternatively, a known user can use Windows, with DCOM preinstalled, and use the Web browser to download ActiveX components which can then be used to run the application. This approach can be used to ensure that users have an up-to-date version of the software and is very handy if you have thousands of users wanting to use the application. This is where we think DCOM will shine in the future—easy upgrading of software—fat clients—over the internal network.

But there are problems even with this approach that we will explore in more detail in the section on security, but that can be summed up by saying that ActiveX components which are allowed free rein of your desktop could be lethal.

In the world of the other middleware vendors the casual user could be running anything, and as such, the use of Java and the Java interface provides the common client interface. Using their approach, the user has no need to use Windows, which is why Microsoft does not support the approach.

The developer can use the Java-based client for access to the system whatever the role of the user—known, unknown, casual, or regular user. The advantages of this approach are that the user always uses a common interface to access that application—or all applications if you are using the same middleware to support all applications—and the developer only has to develop one client. The disadvantages are that another interface has been introduced that the user has to learn (he or she may still be using Motif or Windows for other applications) and the Java Virtual Machine may not be running on every platform.

Microsoft also argues that if the AWT is used, the user is being denied the richness of the normal Windowing environment—more of a Lowest Common Denominator approach. But I’m not sure that this either is true or that this really matters if the interface is simple to learn and use.

The alternative approach is for the developer to build multiple clients—a Java interface and a Web browser for the casual user and other client interfaces for regular company access using Windows or even Motif as the interface. The interface will then not be the same. The advantages with this approach is that the end user keeps the familiar interface to access the application if he or she is a regular user within the company, but an easy-to-use interface is available for use by the casual user—within the company or outside it—via the Web browser and Java. The disadvantage is that the user may end up having to learn more than one interface depending on what role he or she is taking anyway (he or she may be classified as a regular user for one application and a casual user for another application). Another disadvantage from the developer’s point of view is that he may end up developing several versions of the client.

All this points to the fact that in the future if we use other middleware, we may be developing clients that use this Java virtual machine-based approach for all applications. Where does this leave DCOM and Microsoft? It will be interesting to see.

Previous | Table of Contents | Next