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.
| Microsoft hasn't delivered on the promise of
Cairo, but 1997 should see it gel into a cohesive form. |
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
End of Article
Register
