DCOM Explained
by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98 |
Previous | Table of Contents | Next |
In Microsofts 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 Microsofts first solution for Internet use is based on the normal HTTP and Web server-based model of connectivity. A Windows client accesses Microsofts Web server from Microsofts 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 futureeasy upgrading of softwarefat clientsover 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 userknown, unknown, casual, or regular user. The advantages of this approach are that the user always uses a common interface to access that applicationor all applications if you are using the same middleware to support all applicationsand 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 environmentmore of a Lowest Common Denominator approach. But Im 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 clientsa 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 userwithin the company or outside itvia 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 developers 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 |