The authors are software engineers at Taligent and can be contacted at potel@taligent.com and jgrimes@taligent.com.
Developers spend more time today maintaining or rewriting software that already exists rather than innovating. By providing a fully object-oriented programming environment and powerful set of software building blocks, Taligent hopes to reverse this trend. Taligent's objective is to change how software is created, maintained, and used.
To achieve this objective, Taligent will deliver an application programming environment, development environment, a set of operating-system services, and a new human interface. Built with object-oriented technology, the Taligent system is designed to improve developer productivity, support business-critical computing, and better align desktop computing with the way users work and think. Taligent believes there is an increasing demand to address these issues in order to revitalize growth in the computer industry, attract new computer users, and enhance the value of computing through the 1990s and beyond.
Taligent, an independent system-software company founded in March 1992, is owned in part by Apple Computer, Hewlett-Packard, and IBM. All four companies will license, market, and support Taligent's software products, due to be released in a series, beginning in the first half of 1995.
This article presents an overview of the software technologies designed by Taligent.
To remove the barriers that exist between today's software and operating systems, Taligent has factored the major aspects of system software--development, operation, and applications--into reusable sets of software called "frameworks." As Figure 1 illustrates, Taligent's architecture is based on an integrated web of these frameworks.
Frameworks are collections of objects that provide an integrated service intended for customization by the developer. The usage of the term here is a slight variance from others in the industry, who use the term "application framework" to refer to a single entity--a large, monolithic class library such as Microsoft MFC, Borland OWL, or Apple's MacApp. Frameworks, in the Taligent sense, refer to smaller, more manageable sets of functionality at a level of abstraction set between a large class library and a single class.
The central problem that frameworks solve is complexity. Everyone knows that highly functional systems are complex, making them difficult to use. Object technology--in particular, class libraries--provides part of the answer through abstractions. Well-designed classes abstract behavior and present it through an interface that hides (encapsulates) the associated data and other helper functions. This approach scales well to systems of hundreds of classes. For systems containing thousands of classes, an intermediate level of abstraction is needed. Taligent frameworks deliver services that are higher level than classes. Examples are frameworks for compound documents, user-interface construction, file systems, I/O devices, database access, microkernel services, network protocols, many types of media, and so on.
Because frameworks provide an infrastructure and flexible interfaces, they avoid many of the problems that traditional procedural programming models impose upon developers. They make it easier to add extensions, factor out common functionality, facilitate integration, and improve upon software maintenance and reliability. Frameworks foster a higher level of code and design reuse than do other software methodologies.
As yet, frameworks are not supported explicitly by object-oriented programming languages. In Taligent's C++-based system, for example, frameworks are a programming convention and a programming-model concept; this is useful, but abstract. Programming conventions that have language support are generally more useful, so perhaps future languages will provide explicit support.
Taligent frameworks provide two object-programming interfaces: the Client API (which provides functionality similar to an object library) and the Framework API (which provides a separate, richer interface for customization, extension, and code reuse).
Taligent's frameworks are designed with the assumption that they will be customized to create solutions for a family of related problems. Developers will, therefore, find code that not only solves a set of related problems, but also can be reused.
Taligent's web of frameworks (see Figure 2) is divided into three main areas: TalAE (which includes most of the object-programming frameworks), TalDE (which is an extensible set of tools frameworks designed expressly for object programming), and TalOS (which provides extensible frameworks for more-traditional operating-system functions).
The Taligent Application Environment (TalAE) is a complete implementation of the Taligent object-oriented application-programming model. TalAE contains more than 100 frameworks, covering areas such as graphics, database access, multimedia, user interface, internationalization, networking, and distributed computing. TalAE is both distributed and portable, and will run on existing 32-bit operating systems (such as OS/2, AIX, HP-UX, and PowerOpen), as well as future versions of Apple's System and Taligent's own Object Services. Taligent has released TalAE to its three investor companies, which will begin the deployment of TalAE on their respective platforms starting in the first half of 1995.
The Taligent Development Environment (TalDE) is a suite of framework-based developer tools that complement the TalAE. TalDE supports programming in C and C++, and also provides testing and debugging tools for class and framework developers. Over time, a range of development language and tool products for the TalDE will be available from both Taligent and third parties. The TalDE is an integrated development environment that will include dynamic browsers, incremental development, an automated build facility, online documentation, multiuser source-code control, and a GUI constructor. TalDE is currently scheduled to be deployed in mid-1995.
Taligent Object Services (TalOS) is designed to be an ideal platform to host the TalAE, a "native," fully object-oriented operating environment. The TalOS uses a Mach Version 3.0-based microkernel enhanced for objects. The TalOS also provides system-level frameworks that facilitate customization of all low-level parts of the system (including I/O drivers, file systems, networking, and communications). TalOS is currently scheduled to be deployed in late 1995 or early 1996.
The open structure of Taligent's frameworks enables third parties to extend or customize the system at all levels. The goal is a high degree of interoperability with existing standards (such as network protocols, file systems, data formats, and remote services). In addition, Taligent will support the Object Management Group's (OMG) CORBA specification for distributed-object access in open, multisystem environments.
To promote industry acceptance as an open-system standard, Taligent intends to submit interface specifications for TalAE to X/Open for adoption. Taligent plans to work with X/Open to establish a testing-based certification program to make these object APIs available to third parties.
When TalAE is hosted on existing operating systems, current software (legacy applications) will continue to run as before on the host operating system, thus facilitating migration to the new programming model. As a first step in deploying the Taligent technology, Taligent's partners--Apple, IBM, and Hewlett-Packard--will port a reference release of the TalAE to their own preemptive, multitasking-operating systems (such as AIX, OS/2, HP-UX, PowerOpen, and a future version of Macintosh System 7). Subsequently, the TalAE will be hosted by Taligent on its own TalOS, which will be ported to leading hardware architectures (including Intel, PowerPC, and PA-RISC). Given this strategy of deploying the TalAE on multiple operating systems and multiple hardware platforms, developers will write to one programming environment and gain volume deployment.
When the TalAE is hosted on the TalOS, legacy software will still be supported using adapters written by Taligent's investors and third parties, allowing users to access and retain value in software designed for earlier systems.
In the Taligent system, each framework is built expressly to allow developers to customize or change it. Like any good library, a framework has a Client API that represents a calling interface for that set of services. Frameworks can be thought of as servers in a client/server sense. For example, in a file-system framework such as the one in Taligent's Object Services, you have a client API that looks like the file-system interfaces you see today--open, close, read/write, rename, delete. In today's systems libraries, you get these in a black-box implementation. If you like this implementation, you're in good shape. If you don't like it, your options are limited. You must either replace it or learn to live with it. You don't have the choice of changing it as you do in the Taligent system.
Taligent enables this customization with a second API, the Framework API. The Framework API opens up the inside of the framework for customization. In effect, it describes how a generic implementation of the framework is actually organized, allowing the developer to inherit not just code, but design. For example, Taligent's graphics frameworks are useful "as is" via their client API for doing precision two-dimensional graphics and photorealistic, shaded, three-dimensional graphics. However, because it has a framework API, you can customize your own drawing algorithms or 3-D shaders and make many other unique changes to suit your purposes.
Customized versions of frameworks are created by adding and replacing Taligent code with your code, subclassing, and overriding the framework API of that particular framework. (An example of this is presented later.) You might also extend what's there in new directions. By either customizing or extending, you can create a new software library that implements a variant of the original delivered with the Taligent system.
With Taligent, the modified version works in the system just the same way that the original did. You will have the same client API. That's the basis of polymorphism--the idea that you can create your own customized version, plug it back in the system, and have it work in a compatible way with the original.
Another important aspect of Taligent's frameworks is integration. The Taligent frameworks contain a considerable amount of code designed to talk to the other frameworks in the system. The Taligent graphics system isn't isolated. It assumes communication with the printer frameworks, font framework, color framework, and graphics drivers. It is designed as a coherent architecture, so all that functionality works together in a reasonable way. Most importantly, you inherit that integration when you subclass from these frameworks.
TalAE uses frameworks at all levels. It is more than just having an application framework or a set of tools for object programming. In other systems, if you want to go beyond the functions in the application framework, you fall back on the regular procedural APIs of the underlying operating system. In the TalAE case, the entire programming model is object oriented--the same approach that some people use today in application frameworks is used pervasively throughout the Taligent system itself. This means that when you add a framework to this system, your framework is on the same technical footing as any framework already there. This blurs the distinction between system and application.
Taligent isn't planning on doing this all alone. Taligent will provide the initial set of implementations, populating each of the frameworks with basic functionality. Taligent engineers are working closely with those at Apple, HP, and IBM, who have many ideas about what they want to add to these frameworks. You can expect implementations from Taligent's partners to support the same basic APIs, plus added functionality and support for their unique hardware. Over time, this will lead to more diverse systems. Third-party developers can also extend and customize this system.
The frameworks in TalAE are organized into three main groups: the application frameworks, the domain frameworks, and the support frameworks. The application frameworks are comparable in functionality to MacApp or, in NextStep, the AppKit, together with some of the User Interface frameworks. TalAE also has a Text Editor framework that is a built-in, word-processing building block, and a Graphics Editing Framework that is a built-in, interactive-graphics building block.
The domain frameworks in TalAE are for graphics (both 2-D and 3-D), multimedia, and basic text, plus international support.
The support frameworks provide basic application services such as fonts, color, and testing. In addition, there are support frameworks for distributed-computing services, and software-portability frameworks that allow targeting multiple-host operating systems and hardware platforms.
To see the Taligent system architecture in more detail, consider the frameworks in four key areas: compound documents, graphics, internationalization, and data access.
Figure 3 shows the compound-document framework. To use it, you must answer four questions:
The compound-document framework also supports collaboration, allowing any document to be shared and worked on simultaneously by multiple users. The document framework also supports scriptability, allowing users to store commands in a file and play them back later. The system will interoperate with emerging compound-document standards such as OpenDoc and OLE--as well as with existing popular file types.
The Taligent graphics system has extensive 2-D and 3-D functionality--high-precision 2-D as well as full 3-D rendering capabilities. The graphics framework uses a world model based on 64-bit floating-point coordinates. Other features in the framework include: extensive 2-D and 3-D geometry (including NURBS curves and surfaces); fully extensible attributes (color and line style for 2-D, and shaders and numerous shaders for 3-D); full 3x3 transformations for 2-D modeling and viewing; and full 4x4 transformations for 3-D modeling. The framework also includes outline fonts, a font-server framework, color matching, multiple color spaces in 2-D, 3-D geometry constructors (sweeps, extrusions), antialiasing, camera, and lighting models.
The international system is 16-bit Unicode throughout, not just for a few special utilities. All strings in the system use 16-bit characters--even filenames and network names. The international framework also includes style sheets, ideographic scripts/ languages, ligatures, kerning, and tracking. Also supported are multilingual typing, collate, search, and replace. There will also be inline Asian input methods.
The Data Access framework is designed to simplify forming SQL queries. It includes subclasses supporting different flavors of databases (for example, SQLNet for Oracle databases, OpenClient for Sybase, and DRDA for DB/2). It also supports ODBC for other kinds of databases--as well as supporting flat-file data. Since it is a framework, you can write your own vendor-specific subclasses, where you need a unique kind of data-access capability. The data abstractions in this framework allow access by rows, columns, or cells. There is also the capability to upload or download data in bulk, and to filter by using table/column filters.
Developer-provided frameworks are similar in structure to Taligent frameworks. Suppose a company wants to have an online catalog of their products, yet doesn't want to create the software from scratch. In such a case, the product is, in effect, a catalog-forms package. It could be constructed as shown in Figure 4.
Say that the catalog ISV has developed thousands of lines of code (LOC) that implement a framework specifically for building online catalogs. This framework could be designed to be modified in two ways by the customers. First, the pages must be populated with data (the company's products, for example). This is accomplished by providing the data for the pictures and accompanying text. The framework handles pagination, indexing, cross-referencing, and so on. This is the normal use of the framework, as done by most of the catalog ISV customers.
Second, as shown in Figure 4, this company's developers have further modified the framework to provide capability not explicitly included by the ISV--to provide online inventory information for the catalog items (myDataLookup), to display it in the catalog (myDrawView), and to update that inventory data when an order is placed (myDataNotify). This can be accomplished by overriding the catalog framework's DrawView method with the myDrawView method, which in turn calls the other two new methods. The methods can be overridden because the ISV has defined them as virtual functions and provided the interface information. It is typical in framework designs to make many of the functions virtual so that their behavior can be modified in the future. The cost is low, is paid once, and enables future modification. In this simple example, the modifications to the behavior require less than a hundred lines of code, compared to thousands of lines of code for the base framework. This example gives an idea of the expected order-of-magnitude productivity benefit from reuse of design and code, as compared to "modification-by-replacement" strategies required by other approaches to component software.
Another unique aspect to the Taligent system is the Taligent desktop, called the "Workspace." In today's personal computer systems, you essentially have one "place"--your home place, your office desktop. In the Taligent system, other kinds of desktops may be optimized for the different places in which customers want to work, for different functions the customer works on at a given time, for different departments within the company, and so on.
Taligent's "People, Places, and Things" metaphor can be used to model an enterprise in this way. In this model, you might use a graphical business card to represent an individual person. To represent a group of people, you might use a picture of an address book. There are other things you can represent with the People metaphor--roles, for example, so you can delegate your signature authority to someone else while you're away.
To accomplish these goals, change is needed in the human interface of existing computer systems, but the change is different than you might think. More (or different) icons or 3-D glasses are not what is required. What is needed is an interface paradigm that works the way humans did, before and without computers. The acronym HCI is often used to refer to the field of Human-Computer Interaction, also known as user-interface design and human-factors research. However, what each of us should be working on instead is HCHI--Human-Computer-Human Interaction. In other words, computers should facilitate interactions among people.
The move from an application-centered view of computer functionality to a document-centered view is a good step. "Applications" and files were invented by the computer industry and had to be learned by the user and developer communities in order to use computers effectively. The emerging document-centered view is better because we already know about documents--they exist outside the digital world.
The next point in this evolution is task-centered computing. Tasks make up important processes in the home and in organizations. They are tasks we did yesterday and will need to do tomorrow--tasks that may be partially manual and partially on the computer, partially on our own desks and partially with others.
Applications today don't represent people--only some of their attributes (such as name and address). The Taligent system uses objects called "Business Cards" to serve as references to people. This representation makes it convenient to mail someone, say, a document object. Also, People don't exist in the ether, they exist in Places (such as offices, homes, libraries, cars, hallways, conference rooms, and so on). Some systems today provide primitive places. For example, the familiar desktop can be considered a place--it is a container for documents, trash cans, disks, and the like. This idea can be generalized and used as a richer metaphor for organizing the user's world, and most importantly, as a way to visualize Human-Computer-Human Interaction.
Andert, Glenn. "Object Frameworks in the Taligent OS." Compcon 94 Digest of Papers. IEEE Catalog No. 94CH3414-0.
Fuller, Rodney. "Differences in Human-Computer and Human-Computer-Human Interactions." Human Factors and Ergonomics Society, CSTG Bulletin, April/ August 1993.
Grimes, Jack. "Objects 101: An Implementation View." Compcon 94 Digest of Papers. IEEE Catalog no. 94CH3414-0.
"Lessons Learned from Early Adopters of Object Technology," Taligent White Paper, 1993. Available from the authors.
"Leveraging Object-Oriented Frameworks," Taligent White Paper, 1993. Available from the authors.
Object Management Group. Common Object Request Broker Architecture (CORBA) Specification. Version 1.1.
The Taligent Guide to Designing Programs (Reading, MA: Addison-Wesley, 1994).
Taligent World-Wide Web home page: http://www.taligent.com/
Figure 1 Taligent's web of frameworks.
Figure 2 The Taligent system overview.
Figure 3 The compound-document framework.
Figure 4 The architecture of an ISV-supplied catalog framework product as modified by an in-house developer.
Copyright © 1994, Dr. Dobb's Journal