Cairo--Are We There Yet?

To provide a dialog-oriented version of the AD, Microsoft is releasing an alternative forms engine, Forms 2, with Office 97. I believe this engine is closer to the original Cairo forms engine for several reasons. First, it is highly OLE automatable. Second, a senior Microsoft employee told me two years ago that the Cairo forms engine would be pan-application and the operating system would use it. Microsoft had decided at that time to ship the Cairo forms engine with a future release of Office, and not as an operating system feature.

The Forms 2 engine is extremely powerful. It can host any ActiveX control, and the instantiation time is fast once the core engine is loaded and running. Brad Silverberg also told me that the Forms 2 engine's form definition language is actually an elementary HTML format, and that future versions of the forms engine will use raw native HTML format instead. This change will bring the forms engine in line with the IE 4/AD forms definitions.

The NT 4.0 desktop, although a component of Cairo, is not the configurable desktop that Microsoft promised--it's merely a stepping-stone. Microsoft could have added the forms engine to the operating system to fulfill its promise; instead, the company has side-tracked the forms engine into Office 97. Going for the full-blown IE 4/AD solution is, without question, full and complete delivery of Microsoft's promise. You can expect to see this solution during the first half of 1997.

Distributed Objects
Cairo's implementation of objects is a mix of delivered code and undelivered promise. OLE is here, it's now, and it's stable. Microsoft can choose among several object implementation models for Cairo--the original OLE model, the apartment threading model from NT 3.51, and the free thread model from NT 4.0. Each model gives the object server more control over how it serves multiple clients concurrently.

OLE development has become progressively easier over time. Coding OLE objects used to require C++, but now you can use VB4 for building OLE automation servers and clients with easy-to-use scripting that hides the complexity of the OLE registration registry.

ActiveX developers have taken a similar approach. ActiveX development used to require Visual C++ (VC++), but now developers can use VB5 Custom Control Edition (VB5CCE) to create full-fledged standalone ActiveX controls. This breakthrough is key to the success of the next wave of OLE development at the core of Cairo. Don't underestimate VB5CCE's importance as a tool for creating active tools within Cairo's AD framework.

Getting Objects to Talk to Each Other Across Networks
DOLE, also known as Remote OLE, lets OLE clients and servers communicate across standard network protocols and has been available since the VB4 Enterprise Edition shipped about two years

ago. Microsoft built the DOLE core engine into NT 4.0.

DOLE lets a client know which machine is the OLE server in a point-to-point connection using routing information hardwired into the client's Registry. Unfortunately, managing and maintaining these links with any precision is difficult. However, two different methods can give administrators more control over these connections.

The first approach involves a centralized OLE server lookup table. Imagine having some black-box OLE automation servers installed on several servers on your network. Each client is wired to a particular server. If that server goes down, the server's clients have no way of locating other object servers, even if the servers are serving the same objects.

Consider the manual load balancing required to make this switchover work. If you want to load balance the object servers, each server needs to broadcast its processor utilization into a centralized lookup table. When the client requests a particular object, the OLE system on the client checks with the centralized information store to find out which OLE server can provide the object the client needs and which server has the lightest load. The OLE system can then automatically wire the connection from the client to that server.

The amount of developmental effort required to make this configuration work will probably not be big because all the pieces are in place except for the centralized lookup table. This table is an ideal function for the forthcoming Cairo DS.

The second approach is to use Web pages that call out active OLE servers with new Active Server Page (ASP) technology on Internet Information Server (IIS) 3 and IIS 4 (code named K2) servers (for information about IIS 4, see T.J. Harty, "IIS K2 Alpha," February 1997). You can now build Web-based client/server solutions that have ActiveX objects running on the server side. The server-side engine can call HTML-based Web pages or ASPs that contain server-side scripting. The engine can also call a variety of server-side technologies such as a database engine (direct database connectivity using ASPs is easy to set up using Microsoft's powerful Visual InterDev toolset--for information about Visual InterDev, see T.J. Harty, "Microsoft Visual InterDev 1.0, Beta," March 1997). All the future administration console screens for NT Server will go over to ASPs.

With well-designed client-side HTML pages, server-side objects, and seamless database connectivity, you can rewrite a traditional application into a server-based ASP using ActiveX controls as necessary on both the client and server to provide the complex wrapped functionality. I'm considering rewriting some of our VB-based client/server database applications to ASP-based HTML intranet applications. This ability has to be a delivery of the mind-set and thought processes behind Cairo.

Storage Technology
Cairo has always promised several new developments in storage technologies. The first is a full-blown content indexing engine to let users locate files anywhere on their networks. Microsoft incorporated the Cairo indexer engine as an ISAPI application that's available now as the indexer engine for IIS 2 and above. This high-performance engine allows full searching of the custom document tags I described in my article, "Exploring Cairo: Object File System," November 1995.

To make a searchable tree, you need a way to span multiple machines. NT's Distributed File System (DFS) has been in beta for a while (for information about DFS, see Sean Deuby and Tim Daniels, "DFS: A Logical View of Physical Resources," December 1996), but the real product will be Fault Tolerant DFS. Fault Tolerant DFS lets you create one large tree that spans clients and servers in your network. Obviously, such a tree is ideal for the indexer engine, and I expect we'll see more and more users leveraging this system in the future.

The final breakthrough in Cairo storage technology is the granddaddy of OLE storage, Structured Storage (SS) and the Object Filing System. Unfortunately, development on this front has gone quiet. However, Microsoft has notably improved SS in Office 97. For example, Word now allows multiple document versioning within one file, and many applications now allow concurrent read and write. I've heard that Microsoft's OFS, the set of server-side extensions to NTFS that lets it work with structured storage in a client/server fashion, is still under development but will see the light of day this year.

Directory Services
In addition to distributing objects and applications, you need a way to locate everything. Although Novell released its NetWare directory services (NDS) as part of NetWare 4.0, it failed to bring DS to the mainstream (for information about NT and NDS, see Craig Zacker, "Windows NT and NDS," March 1997). Like Novell, Microsoft also had the people, talent, and money to bring a world-class DS system to NT. However, Microsoft didn't have the incentive to move away from the traditional NT domain security model until the company could decide how such a new DS should work.

Microsoft began developing a new DS paradigm on an X500 DS system for Cairo. The company put this technology to use in Exchange Server. But as the Internet grew in prominence, the need to support TCP/IP and Internet Domain Name System (DNS) became critical. So the Cairo DS changed shape into the Lightweight Directory Access Protocol (LDAP)-based solution. So, at least from the DS point of view, the Internet and Cairo worked hand in hand: The Internet helped push the mind-set change necessary for us to benefit from the Cairo mentality.

DS is X500 and DNS based, replaces the NT Domain Security model, and will offer far more information and storage capabilities than NT's DS. Cairo's DS will be scalable to very large systems and offer very fine granularity. Just imagine a DS aimed to take on the Novell NDS and win, and you get the right idea. The new DS surfaces a huge number of properties about users, machines, processes, and so forth that you can browse from anywhere using ASP-based Web servers. The IIS 3 platform is key to the configuration and management of the new NT 5.0 directory, which you manage with ASP pages hosted in IIS 3 or IIS 4 and that the client views with a Web browser.

Under the new DS, a user has properties such as telephone number, location, and department. Now you can build rich information stores that aren't RDBMS based, but that you can browse using whatever tool you like, such as a Web client or database viewer.

Exchange Server wrapped the Cairo Mail promise into a product complete with a grotesque forms engine and an absurd storage solution. This product has many Cairo DS and NT 5.0 DS features. It is X500 based, with a rich DS that Microsoft originally designed for NT; it understands Internet mail; it has a rich object store; it supports OLE objects; and in many ways, it is a conceptualization of Cairo's original aims. But compare the scope of Exchange Server with the scope of the current Cairo plans, and the new 1997 solution is obviously going to make the 1994/95 Exchange Server look weak at the knees.

I won't dwell on NT DS here, for a couple of reasons. First, the code we have today is still an alpha build running on NT 4.0 alongside the existing NT DS system. Second, many of you will already have the NT 5.0 DS and ASPs because Microsoft distributed them as part of the December Microsoft Developer Network (MSDN) release, at least for Universal subscribers. Finally, the best place to start thinking about the NT 5.0 DS is not with the code, but with the OLE DS white papers on Microsoft's Web page at http://www.microsoft.com/msdn/sdk/techinfo/adwp.doc. You see, all the interfaces into the new DS will exist as OLE automation interfaces. This integration will make leveraging the new DS from within any application you like or from within a server-hosted ASP client/server solution easy. You can expect to see the final NT 5.0 DS ship with the NT 5.0 product, possibly in 1997, depending on how the testing goes.

Are We There Yet?
In some respects, we have lots of Cairo here today. Some parts are in beta, and others are in alpha release or still haven't seen the outside world.

Although we might have not yet reached the mythical Cairo and have been sidetracked with layovers in London, New York, and Paris, the destination city is now clearly within site. The journey has been very long indeed.

The best part of the trip is that the vision of Cairo is still intact. Some of the methodology has changed--we could not have envisioned the use of HTML as a page description language, for example, but you can't deny that we needed such a language, and HTML will do nicely. Nor could we have envisioned the rise in TCP/IP, but we needed a globe-spanning networking protocol for Cairo, and TCP/IP and DNS are up to the task.

When you spin in the sidetrack distractions of getting NT into shape and bringing together all the OLE technology and development tools required to support the Cairo vision, you soon see that Cairo was never going to be a mere product. It is actually the culmination of a lot of work, all pushing in roughly the same direction, lasting for many years. And Cairo isn't really a destination by itself. Once we get into serious OLE/ActiveX control development and can seamlessly distribute these controls between servers and clients, we will have achieved the final goal of moving from a file and print-share network model to an information-share model. We will have also expanded the scope of this new information model to encompass the whole world.

Yes, Cairo's late. Two years ago I thought Microsoft had lost its way and had given up any hope of turning its vision into a reality. The Internet gave Cairo a kick start, but also made the marketplace lurch out of its slumber. Will it work? It has to.

RELATED ARTICLES IN WINDOWS NT MAGAZINE
Jon Honeyball,
- "Exploring Cairo: Object File System," November 1995
- "Exploring Cairo: Forms Database Engine," January 1996
- "Exploring Cairo: Remote OLE," April 1996