Reference Series |
Table of Contents For This Issue
|
| |
How Computers Work, Part I | |
August 2001 Vol.5 Issue 3 Page(s) 96-99 in print issue | |
Coming To Grips With Linked Objects In Windows Your Chance To Understand COM & OLE |
More than just a Spanish word of exclamation, OLE (Object Linking and Embedding; pronounced “oh-lay”) was a Microsoft technology created for the purpose of placing files and other objects into existing documents. It was as simple as an active hyperlink or
a Paint image inserted into your basic Word file, or as complex as programs and databases that function over the Internet. OLE was first introduced in 1992 as part of applications for Windows 3.1. Since then, it has gone through a lot of changes, not the least of which is a new name. Now the technology that was previously known as OLE is known as COM (Component Object Model). It works in many of the same ways that OLE used to and many ways that OLE users never imagined. Although the technology may not be known as OLE anymore, OLE served as a very solid stepping-stone to the development of present and future generations of data and service sharing. From the end user standpoint, COM and OLE have many benefits. We’ll explore what these are, how the technologies work, what made OLE so interesting, why COMis used now, and what each one means to you. A Little About OLE. Let’s begin by taking a small step back to talk about DDE (dynamic data exchange). This technology lets two different applications share data and tools and linked the shared information. If a spreadsheet was pasted into a Word document, the spreadsheet could be edited within Word and the information would be updated in the original document. Unfortunately, both applications had to be running for DDE to work. Once one application was closed, the link was severed. That’s where OLE came in. Though developed in 1992, OLE didn’t become a part of the Windows operating system until the release of Windows 95. It was used with Win3.1, but only as a segment of additional applications. At that time, Microsoft defined OLE as “the technology which allows users to take an object [such as a Word or Excel document] and drop it into a document [such as a PowerPoint presentation] by way of containerizing the object so that it can be embedded or linked in a remote application.” OLE was more than just the ability of an application to insert an object. After all, it wouldn’t be too useful to insert an Excel spreadsheet into a Word document if it was just a read-only picture. OLE not only allowed data to be shared in the form of objects but also for the sharing of abilities. Word was primarily a container in this situation, but the shared abilities of the applications let the spreadsheet be modified without having to open Excel, make the changes, and then reinsert the object. For a clearer definition of OLE, we broke down the concept and defined the individual parts of the phrase “Object Linking and Embedding.” Object. For the purposes of OLE, let’s say the object was a chunk of data. It could be a bitmap image, a paragraph of text, or an entire database file. When using OLE, size didn’t matter and neither did the type of data. You could insert any format into a completely different application. The object, such as a graphic image, could appear in the document or it could be represented by an icon denoting its file type. As an example, this could be an icon of a microphone for an audio object. The object was then taken from a server (also known as the source document) and placed into a client (also known as the destination document). These terms held true no matter where the server and client documents existed. The original object could be on the same PC as the destination document or from a server document that was actually across a corporate server, such as a LAN (local-area network) or the Internet. Embedding. During the time OLE was used, there were two ways to insert the object: linking or embedding. If an object was embedded in a document, the original object was copied and then placed in the document. Microsoft defined an embedded object as “a copy of the source data that can be edited with the tools from the source application; it has no link to the source data.” For example, if you embedded a spreadsheet into a Word document, the original spreadsheet remained the same, even if you made changes to the embedded version. An embedded connection let the client share the abilities of the server, such as being able to change the information in the cells of the spreadsheet or even add new rows and columns. But the information in the original server document remained unchanged by edits to an embedded object. Linking. A linked object, on the other hand, could also appear in the client document, but any changes made to it were also made to the source document. Microsoft defined a linked object as “a reference to the source and is updated dynamically if the source data is changed. Object linking is analogous to using Dynamic Data Exchange in previous versions of Office.” A linked object was essentially the original object placed into the client. The abilities to edit the object were still shared, but so was the data of the original object. Any changes made to the spreadsheet in our example above—even if they were made to the object in the Word document—would be reflected in the original spreadsheet. The nuances between linking and embedding are quite simple in an application. In Word, for example, you would select File from the Insert menu and browse to the object you wanted to link or embed. If you selected the file and then clicked OK, the file would be embedded. On the other hand, if you checked the radio button in front of Link To File in the Insert File box, the inserted object would be linked to the original source document. (NOTE: Unlike data in a linked object, data in an embedded object wasn’t updated automatically. It could be updated manually, however, by double-clicking the object.) Nesting. Another term used to describe objects was nesting. Nested objects were those that had been embedded into a client document, which was then embedded into a second client document. Let’s say, for example, you embedded a Paint image into one of the cells of a spreadsheet. Then you embedded the spreadsheet into a Word document. The Paint image would be considered a nested object, whereas the spreadsheet itself would simply be an embedded object. Changing To COM. More important than the ability to embed an object into another document was the idea of applications sharing their abilities, according a Microsoft spokesperson. According to Microsoft, OLE became more than just creating compound documents, it evolved into a way for one piece of software to get services from another piece of software. Then it in turn involved into COM, the Component Object Model. COM is a more standard way for applications to get services from each other. It lets people design new software they know will be able to use general utilities from Windows and other applications. For example, all the text boxes and error message boxes and drive browsing boxes you see in Windows use COM. When a new version of the Visual Basic program is written, they don’t have to write in all the programming for those boxes—they’re just standard COM components. COM has also grown one step further into MTS (Microsoft Transaction Server). MTS provides a sort of wrapper around the services that are exchanged between applications. Practical Uses. COM and OLE have obvious applications for the average computer user. The ability to share tools between applications saves on space and also increases each individual application’s functionality. A good example of this concept is the way in which Microsoft Word, Excel, and other Office applications share a common spelling checker. This object-oriented technology is also applicable in a corporate environment, where sharing files is almost a necessity. A linked file that is updated on the server can keep all the employees abreast of changes in a database. For example, if an employee will be in a meeting from 1:00 to 3:00 on a given afternoon, a database that houses availability could be linked to a document on each employees’ PC and kept constantly updated. Not only will everyone have access to the same information, but there is only a single copy of the database. This reduces data duplication, storage space, and trans fer bandwidth. COM and OLE make multimedia documents possible for almost any application. By embedding pictures and sounds into a Word document or Excel spreadsheet, for example, you can create a more colorful document. You can also include voice instructions about the information or images that help explain further details. The applications are nearly limitless. The corporate benefits of COM are also clear. Developing standard COM components has become a multimillion dollar industry. Keep in mind that the market for third-party COM components was $670 million in 1998. Having standardized ways of communicating between applications and the operating system makes programming and software development a much easier task. The History Of OLE & COM. Sharing data has been a part of computing almost since its inception. But technology that lets different applications reliably share data hasn’t been around very long. We’ll look at where COM and OLE came from, where they are now, and where they’re going in the future. As we mentioned earlier, a technology known as DDE existed before OLE. This was used in Windows 3.1 as a means of sharing information between applications. Because of limitations, such as not being able to maintain a link between source and client documents when one was closed, DDE was soon replaced by the more reliable object linking and embedding functions of OLE. OLE Version 1.0. Introduced in 1992 as part of applications designed for Win3.1 (it was later fully integrated into Windows NT), OLE allowed for sharing of data and services between applications. Now the Excel source document no longer had to be open to use Excel’s tools to edit a spreadsheet embedded in Word. Although more reliable than DDE, it was far from perfect. Printing linked and embedded objects in OLE 1.0 was difficult. The resulting printout often showed only an icon where the object should be. OLE Version 2.0. The following year, OLE 2.0 was released. In addition to being able to handle embedding text, graphics, and spreadsheets, OLE 2.0 supported animations, voice recordings, and other multimedia objects. OLE 2.0 also let users drag and drop objects from one application to another. OLE in Windows 95. OLE became available in a 32-bit operating system, and with this change came the ability to share data and services over a network. Embedding and linking objects over a network affected both client and server users; client users had access to much more data than they could store locally and server users had only one system to keep updated. And that’s just the beginning of OLE’s capabilities. In The Present Day. Learning from the examples of data and service sharing set by OLE, Microsoft introduced COM in 1996. They wanted to use this model to build server-side applications, but they needed more services. That is no longer the case. COM not only provides the architecture for using the services of different applications, it has created standards for building and evolving them as well. COM can still be used for simple tasks, such as embedding and linking objects into compound documents, but its primary use is in corporate networks. In the corporate environment, it lets users share resources and data from a common server. As a part of Win95, Windows 98, and WinNT, COM is now in use in systems worldwide. MTS. The next step in COM’s development is the MTS. It allows for sharing multiple services at once, as well as many other applications of component sharing. One of the major abilities of MTS is scaling. Scalable server-side applications are a good example. It may sound like a technical mouthful, but scaling essentially means trimming waste by ensuring that only the users who are actually accessing services get connected. According to Microsoft, If you have a thousand employees with a thousand database applications running each with a database connection, that can bog down a server. But if only 10 or so users are writing to or reading from a database at one time, you can scale it down to just those users. MTS keeps track of each user and provides access only when they need it. System-wide resources, such as memory, can also be similarly scaled down. MTS also plays a part in the average consumer’s life. One example is transferring money from one bank account to another. For example, you want to be sure both of these transfers occur. You don’t want the one where you transfer money out to work and the one where you transfer money in not to work. So MTS wraps both of them into one transaction—they both have to be completed or it’s rolled back to where nei ther happened. Enter COM+. The newest generation of COM, known as COM+, was introduced in Windows 2000. It contains all the abilities of previous versions, as well as new enhancements. From notifications sent to applications and users when data is changed in a COM component to the ability to send out data without having to wait for a reply, COM+ makes it even easier for developers to share data and services in any language and with any applications. It means less redundant programming for them and more almost-invisible benefits for the average user. by Joel Strauch View the graphics that accompany this article. (NOTE: These pages are PDF (Portable Document Format) files. You will need Adobe Acrobat Reader to view these pages. Download Adobe Acrobat Reader)
|