The discussion we had in the previous section on the CoGetObjectClassFromURL() call, leading to URL Monikers, bind contexts and callback objects certainly wasn't for the faint of heart. And as long as the building of COM/DCOM based applications requires a high level of expertise, there will continue to be very few applications in circulation. The requirement here is to hide the details and make things as simple as possible. Witness that there are very few truly OLE-compliant applications on the general market despite the fact that OLE technology has been available for the past 6 years. The complexity and difficulties in dealing with the technology have created an artificial barrier to adoption.
A high priority for Microsoft's ActiveX initiative is the goal of making it simple for the developer. This is accomplished by hiding the complexity as much as possible from the end user and general programmers. With support of COM/DCOM by Visual Basic, VBA, VBScript and Java available (mainly through OLE automation), users and programmers can start experimenting with DCOM without having to go through the steep learning curves. The first generation of these COM/DCOM capable tools is just becoming available. In the future, we can look forward to enhanced ease of use/programming that ought to put things like IDL files, type library registrations, and direct registry editing behind us once and for all.
On the server end, the new Active Server Platform architecture will eventually allow for the creation of powerful, high performance, scalable server applications without being an operating system guru.