Dr. GUI
October 6, 1997
What a full week it was—with too many sessions, too much food (the good doctor put on about five pounds), too much writing (the good doctor was doing other MSDN reporting as well), and a whole lot of puns. Dr. GUI thanks all the folks he met and especially those who pun-ished him in such a pun-ny manner in Dr. GUI's first (and hopefully not last) pun contest. (The good doctor's so into pun-ishment that he's been thinking of checking into a pun-itentiary. And after that string, perhaps he should.)
Enough of that. [Editor's note: It's about time!] Another part of what the good doctor has been up to is getting his head to stop spinning over all of the new technology he saw. (Stopping your head from spinning is like decompressing after you've been deep underwater: you have to do it gradually or you can get the bends.) There was indeed a lot of information on a lot of new technologies, and Dr. GUI's still trying to make it all make sense. ("Making it all make sense." Hmmm, we could make a tag line out of that phrase . . . naw, it's probably been done.)
So the good doctor's trying to come up with unifying themes to help. In almost all of the presentations, there was one primary unifying theme: Windows 2000. Several speakers, including Bill Gates, referred to Windows 2000 as a product that Microsoft is betting the company on. The new technologies for distributed computing are exciting and powerful—and they'll make your development easier as well as making your applications and systems more powerful and robust in addition to enabling new types of applications that just weren't possible before.
The name we've come up with to try to describe this is "Windows DNA Architecture," where DNA stands for "Distributed interNet Applications." (Dr. GUI didn't come up with the capitalization, OK?) Windows DNA is a renaming of some old names, especially the old "Active Platform" name. The technologies that fell under the "Active Platform" umbrella are still there and in fact improved—better than ever. But the name "Windows DNA Architecture" really describes the key new features that are designed to enable distributed computing as never before.
There are many dualisms in computing today: Applications can be designed as client-server or Web applications (among others), UI can be generated as documents or code, storage can be structured or unstructured, computers can be mobile or connected, and resources can be centralized or distributed.
None of these design choices is "right" or "wrong"—they're just more useful or less useful in certain situations. Some applications lend themselves to client-server or three-tier design, and some are best done with Web servers. There are good reasons to do UI as HTML pages sometimes, and good reasons to use the Win32 UI API including DirectX. (Or is that DirectEggs? Oops, pun-ish me again.) Some applications need to store data in a database, others need less structured storage, such as text files. Some applications run only on an individual PC or LAN. Some need to be able to work with unreliable network connections (such as phone lines to connect to the Internet—or, given the traffic on the Internet nowadays, any connection to the Internet) and intermittent connections, such as laptop and handheld PCs. And there are compelling reasons to both centralize and distribute resources.
But the fact that these different technologies for writing applications grew up independently means that they're often not compatible with each other. So today, you often have to make a dualistic "either-or" decision about which technologies to use. If the technology you didn't choose has some features you could use to make your life easier, that's too bad. Do without or implement it yourself.
A key theme of Windows DNA is bridging these dualisms—enabling you to make "both-and" rather than "either-or" decisions, and use the best of both worlds.
Since the Dynamic HTML control is an ActiveX control, you can embed it in programs built in any language that supports ActiveX controls: Visual Basic, Visual C++, Visual J++, and so on. That means that you can use the Dynamic HTML control as part of your program—not only to browse the Web, but also as your user interface. Since the Dynamic HTML control exposes then entire Document Object Model and since everything in a Dynamic HTML page can be changed on the fly, you have complete programmatic control of all aspects of your UI. And if you don't enjoy writing UI code, you can probably, with some luck, find folks who can not only prototype your UI in Dynamic HTML but can also write the final code from the prototype. Using Dynamic HTML will give you rich, easy-to-write interfaces.
But what if you really need access to Win32, OpenGL, or DirectX? Well, remember that Dynamic HTML can host ActiveX controls: just write a component that uses the technology you need and embed it in your Dynamic HTML UI. With this component approach, you have total flexibility.
The second key theme of Windows DNA is moving commonly used functionality into the operating system so that you don't have to write it over—and over, and over—again. We call this "auto-everything." Dr. GUI's friends at Microsoft are painfully aware of the chasm-like distinction between great tools and frameworks and horribly complex APIs. On one hand, we have tools and frameworks such as Visual Basic and MFC that take much of the drudgery and tedium out of writing applications, making you more productive. On the other hand, we have the incredible complexity of some raw APIs—such as the dozen or so multi-function interfaces you have to implement in order to build a visual ActiveX control from scratch.
The part of Windows DNA that provides a powerful, easy-to-use API for building component applications is called "COM+." COM+ includes services for transactions, resource management, dynamic and asynchronous invocation, data management, and server services. The emphasis in COM+ is on making sophisticated, complicated functionality such as transactions (that can be rolled back if not completed) and resource management (including reference counting) an "automatic" (or at least easy-to-use) part of the operating system so that the services can be used from any language. Just as MFC made writing Windows applications—even OLE servers—a snap, so too will COM+ (and visual tools) make sophisticated functionality all but automatic. The idea is that, just like a framework, COM+ will do all of the tedious stuff for you. All you have to do is write the code that's specific to the problem you're solving.
For instance, when you write a server component, all you'll have to write is the service logic and the shared data. COM+ will deal with queuing, connections, security, thread pools, and synchronization. When you write a client, you only have to deal with the UI, shared data, business rules, and interaction logic. COM+ will deal with protocols, caching, queues, drawing and multimedia, events, data binding, rendering, and UI interactions. And for components, all you need to deal with is meta-data and methods—COM+ will deal with data-binding, interception, versioning, the class factor, registration, IUnknown, reference counting, IDispatch, connection points, and persistence.
COM+ is not a replacement for COM; rather, it's an extension of COM. Although COM+ will do many things for you correctly and accurately, older programs or programs that just need to do things a different way can still use COM as they always have.
OLE-DB is an API that allows you to access all types of data—whether from a SQL database or a text file—in a consistent fashion. OLE-DB relies on OLE-DB providers—objects that expose particular data stores using a consistent object model. So if you expose your custom data formats to OLE-DB by writing an OLE-DB provider object, anyone will be able to access the data in a consistent, simple manner. By the same token, when you access data through an OLE-DB consumer object, you're able to access not only databases but also any data for which an OLE-DB provider has been written. It's not hard to imagine how powerful this is.
For easy access to OLE-DB data, you can use ADO (Active Data Object). ADO is an automation interface to OLE-DB data that can be used by any languages. Since it's so much more powerful than the former objects (DAO and RDO), it makes sense to use ADO exclusively.
Networks are great, but what happens when the network goes down? Or when you undock your laptop or handheld PC? Windows DNA has several technologies to allow your programs to work even though the machines aren't connected all the time.
Transactioning is the ability to roll back changes if the entire transaction can't be finished. For instance, let's say you lost your Internet connection between updating your inbound and outbound flights in a travel reservations database. You would not want to have your flight record half updated—it's either all or nothing. Transactioning allows you to define what constitutes a complete transaction and to have the system automatically cancel incomplete transactions, thus ensuring data integrity. COM+ will have support for automatic transactioning.
Messaging is the ability to send a command to another computer and have it queued for later automatic execution. An example today is what happens when you use a mail program to reply to mail off-line. The response is queued in the Outbox until you reconnect to the network, at which time it is sent. (Mail and mailboxes are a good model for messaging.) Now generalize this to any function call—for instance, a transaction to update a database record. When you use messaging to do such calls, the calls can be queued at many places along the way, thereby giving you support for disconnected networks and robust behavior in the event of interruptions of network service. COM+ also provides automatic messaging.
Windows 2000 supports two types of caching of user data and settings. First, it supports Intellimirror, which stores a copy of the user's settings and files on a server. This means that a user can walk up to any machine on the network and restore their settings and files—you can even replace a failed machine with a new one and have the new one set the same as the old one automatically. User-side caching is also important to allow users to download data to a mobile computer and to do work while not connected to the network.
For a number of reasons—bandwidth, geography, and so on—you want to distribute various computing resources all over the network rather than centralizing them on one machine. But if you have to manage that distributed system or have to try to find something on it, you soon wish that all the resources were on one huge central machine.
Active Directory enables you to find resources and users no matter where they are. Active Directory, which scales to millions of objects, allows you to store information on users, resources, configurations, credentials, policies, and so forth. Active Directory supports LDAP protocol, meaning that it can be accessed from any LDAP client. Since this directory is integrated into the OS, it's secure—and your programs can easily take advantage of it to find information on users.
Windows 2000 also supports a distributed file system, which allows replication including to disconnected clients.
There are a number of features in Windows 2000 that don't fit neatly into Windows DNA—but they're things you should know about so you can take advantage of them as appropriate.
Windows 2000 supports a number of features designed to make better use of PC hardware including Plug and Play, power management (including OnNow), a common driver model for Windows 98 and Windows NT (including signed drivers), and much more device support. It also supports 64-bit VLM (very large memory) address spaces and scales to more processors better than before. The file system supports disk quotas, file attributes, and real-time indexing.
Windows 2000 also supports multilingual UI so that the same NT binary can run anywhere, regardless of languages. That also means that there's only one Windows 2000 API for the whole world.
Much of the work of supporting networks better has gone into simplifying installation and configuring of networks (with Plug and Play-style easy installation) and extending the network infrastructure via new protocols. Distributed services include directory and security services, discussed above.
Windows 2000 should be the last time you ever install an OS. After the initial install, Windows 2000 will update itself with "self everything." It will be able to install patches and enhancement automatically, as well as detect and repair damaged or missing program files. Application installation will now be handled by the OS, which results in two advantages: the OS can do it right (and keep the OS files secure) and then it also has the information it needs to automatically uninstall.
In addition to the Dynamic HTML features, Windows 2000 supports DirectX 5.0 to parity with Windows 98, including video hardware acceleration, audio, and even force feedback joysticks. For Alpha users, note that Fx!32 allows you to run Intel Win32 binaries on Alpha NT machines.
Some of the features we've discussed aren't available now—but you still can write Windows DNA applications today using the following ideas:
First, use COM to componentize your applications. This will make it easier to modify your applications to work with COM+ later on and, more importantly, it will give you great mix-and-match flexibility and component reuse.
Use Dynamic HTML data binding to display data and ASP pages to create transactions. And use ADO to access data, since ADO works with OLE-DB.
Use ActiveX controls, Java with AFC, Dynamic HTML, and channels to provide rich UI for your users.
For maximum cross-platform client compatibility, author your UI in basic HTML. You can also use Dynamic HTML features that degrade gracefully—or even check the browser in your ASP page and download the right page. And remember that Dynamic HTML will be supported cross-platform as soon as Internet Explorer 4.0 is available for Macintosh and UNIX. (It should be even more widespread when it's a standard.)
Be sure to understand and integrate with Windows 2000 and zero-administration installation.