[ Previous | Next | Contents ] ... copyright 1996 George North. Frozen in time 1-Dec-96

Ubiquitous Software: An Information Network Paradigm



Chapter 3.
Components, Containers and Documents


"The emerging standards for component software and compound documents signal a broad movement to spread object-oriented concepts into the mainstream of application development."
Richard Adler



This chapter introduces reusable components and containers as foundation technologies for Ubiquitous Software (U_S). Java and JavaBeans are used as examples of developer environments for reusable components. The important topic of software reuse is used to develope the rational and market infrastructure needed for the success of a new paradigm.


U_S software engineering model is:

  • Object-Oriented Design: uses objects to orginize information, behavior, and idenity.
  • Network Aware Object-Oriented Programming: example, Java and JavaBeans.
  • Reusable Components: many different kinds of software work together like legos parts because of an Interface Definition Language (IDL).
  • Containers: purposeful collections of components used to build more complex software--containers are components. Models heterogeneous data (HD).
  • New Writing Space: authoring environment where domain experts create documents for digital and virtual libraries, electronic books, VLPs.
  • End Users: when accessing an Information Network, uses New Writing Space to browse documents and make new documents--this is an authoring environment where domain experts program.
  • This paradigm takes advantage of software reuse at every level of the development cycle.



    Reusable components (1)

    Component software is the primary technology for document-centric development--the foundation for a document-centric (compound document) software model. The key ingredients are its underlying object model, a data exchange model, structured storage, and automation.

    A component software object model differs from existing object-oriented technologies because it ensures interoperability across object languages, tools, and computing architecture. To accomplish this, a component software object model specifies standards for defining interfaces in terms of a language neutral format, an Interface Definition Language (IDL). Client applications can query the interfaces exported by objects and their invocation structures. This model also specifies that object behavior is organized and stored independent of the interface. This implies that component software provides consistent functionality across multiple interfaces. This is critical for general interoperability.

    A data exchange model unifies the mechanisms through which end users and applications interact. Examples include drag-and-drop, cut-and-paste, and API-base data exchanges. In the context of component software, drag-and-drop provides an explicit object-based metaphor for interacting with data and applications--it provides an excellent user interface for authoring compound documents.

    Structured storage permits assorted data within a compound document container to be managed as a single complex file instead of being dispersed over multiple independent files. Structured storage is similar to a hierarchial file management system, but within a single compound document file; data is organized in nested containers that function as directories and subdirectories within the "root" document. Individual data "files" act as streams that can be manipulated independently, in place, as persistent objects. In contrast, structured storage allows end users to freely navigate, to locate, create, or edit individual data contents. Using structured storage, document containers can be nested allowing great flexibility in constructing documents from existing documents. This makes reuse available to end users. When structured storage uses an information network all the complexity of persistent data can be hidden for users--also providing an excellent user interface for authoring compound documents.

    Automation permits document component interactions to be directly programmed by the user. It augments the way users manipulate compound documents. This can be considered to be an extension to the macros and scripts, previously confined to executing within applications centric environments. Using exported interface definitions, components can be threaded at runtime to do complex work that crosses capability boundaries. Automation enables work flow and workgroup applications to minimize end-user interventions for routine processing tasks. This reduces user training, errors and increases organizational productivity. document-centric software lets the end user specify which components are needed for individual tasks. This moves software engineering down to the level of domain experts where it belongs--again providing an excellent user interface for authoring compound documents.

    The reusability and interoperability of component software will likely accelerate the spread of object oriented concepts. Tied closely to the popular client/server architecture for distributed computing, component software defines object-based models that facilitate user directed interactions between independent light-weight processes. This approach promises to simplify the design and implementation of complex software and, equally important, simplify computer user interface (CUI). Reusable components is a foundation of authoring compound documents.



    Containers

    In a document-centric paradigm, containers are used to build compound documents. One key to simpler CUI is sharing of HD. This empowers individuals and groups to better manage their own work involving computers. Compound documents present a model that centers on data rather than applications. In essence, a compound document is the unifying container for sharing HD. The mechanisms that manage containment maintain associations between data and the software component for creating and manipulating the data. The mechanisms also manage the presentation of, and user interactions with, data and component models. Finally, the container provides interfaces and runtime capabilities that facilitate interactions to exchange data and invoke services. The net result is that a user created document appears to functionally and seemlessly integrate with the relevant software. Compound documents eliminate the need to shift explicitly across application contexts and windows to manage data. Without this burden of mechanical interactions, end users are free to focus more directly and productively on their work.

    The key technology concepts in compound documents include linking and embedding, nested containment, direct manipulation (drag-and-drop; visual editing) and control infrastructure. The document-centric approach provides a unified, object-based framework for modeling, manipulating, and storing HD. This facilitates data sharing and exchange across disparate computing platforms--across networks.

    Software developers benefit because domain problems can be decomposed into more manageable components, and because developers do not have to anticipate every possible composition of these components. More emphasis can be placed on analysis and design, on abstracting to hide complexity. Since each component object, by definition, explicitly states its pre- and post-conditions using an Interface Definition (using a program language neutral format), it can be more fully tested before integration.

    When the primary method of software distribution is a pervasive network, then developers gain access to users and markets not previously possible. document-centric software models can lead to more developers with smaller programming teams, targeting larger markets. Network distribution makes possible use reimbursement, and not just one time purchase/upgrade compensation. It is possible to consider software brokers paying developers monthly, based on contracts with end users.

    End users benefit because a document-centric approach to computer use (compared to application-centric) is more intuitive. Users see a simpler interactive model for moving data within and across distinct compound documents. Compound documents eliminate the need to switch between multiple application contexts. End users are free to focus more directly on their work. Users become system integrators. Aided by pervasive networks, end users need not be conscious of where or how these software components are made available. In this way, document-centric components becomes omnipresent--Ubiquitous Software.



    Java

    In the year since its announcement, Java established itself as the industry standard platform for building portable networked components. The Java platform is architecture-neutral, network-aware and compact.



    JavaBeans (2)

    JavaBeans builds on all of these strengths and extends the Java platform. Java is a static component model. Applets on Web pages cannot interact with the page or with other Java applets on the page. JavaBeans allows a richer, dynamic interaction. Using JavaBeans, developers can define independent components that can be used and reused inside a variety of Browser and non-Browser environments. JavaBeans objects can work in IBM's OpenDoc, as Microsoft ActiveX containers or with Netscape Communications Corp.'s LiveConnect tool for tying together Java applets, Web pages and graphics. "JavaBeans brings interoperability to a new level," claimed Jon Kannegaard, JavaSoft vice president. "JavaBeans are more reusable than ActiveX because they are platform-independent."

    JavaBeans components can be GUI widgets, non-visual functions and services, applets, or applications. Each of these components can be built by different developers at separate times. JavaBeans components communicate dynamically. This means that they do not need to be part of the same application build. Instead, JavaBeans components can be assembled as needed, even by end users over the Internet or an intranet, and components can be used to build yet more complex components.

    JavaBeans enhances the Java platform by adding new levels of dynamism, flexibility and reuse. Being portable across all Java enabled platforms and containers, commercial developers of JavaBeans have the broadest possible customer base to target. As an open standard, JavaBeans will be more available, more reusable, than any previous component architecture.

    JavaBeans components can range in size and capability from buttons, to applet size functionality, to a more full sized application such as a spreadsheet application. Containers are used to hold related components. Containers provide the context for components to be arranged and interact with one another. Containers can also be components. This kind of recursive definition provides a powerful design, abstraction, and implementation environment.

    JavaBeans model provides these needed services: runtime component interface publishing and discovery, event handling, persistence, and layout.

    Interface publishing and discovery is key to component software. It is the mechanism for components to "publish" or "register" their interfaces so that they can communicate dynamically with other components or application scripts.

    Event Handling is the communication mechanism for components that need or want service. These can be system events such as clicking the mouse, or component defined events.

    Persistence is how the state of components are saved in a non-volatile place. Component state is stored in the context of the container and in relationship to other components. This is one mechanism available to end users to create (program) a new document, and save it for reuse or as a component in a future document, or published on the internet for use by others.

    Layout is another key attribute of component models. It provides a way for a particular component to control its appearance within its own space. This is usually a component's visual appearance, but not always. For example, a mail message may be printed, or displayed on a CRT, or spoken using a telephone like devise. Layout also provides mechanisms and services for a component's appearance in relation to other components inside a container. For some types of components this may include boundary shapes or menu bars.

    Application builder support interfaces give developers access to components properties and behaviors. Developers can determine the properties and behaviors (events and methods) of arbitrary components and modify the state and appearance of components as well as establish relationship between components. For example, link a button click to an event handler.



    Sun's Developer Environments(4)

    According to Jon Williams, SunSoft's group marketing manager, the palette of JavaBeans components includes everything from a spreadsheet to a collaborative whiteboard to a database access interface.

    For the neophyte who simply wants to pull together a graphic presentation combining HTML, ActiveX and Java, SunSoft is readying Java Studio, a visual assembly tool in which JavaBeans components can be manipulated by point-and-click operations.

    For the professional developer, SunSoft is readying Java Plan. "It lets the systems analyst model the business by defining where data resources and network facilities are located," Williams said. "Once the analyst has a design in mind, Java Plan will generate about 30% of Java application automatically and allow the architect to specify how developers will collaborate on the project," Williams said.

    Another JavaBeans tool under development, code named Project Speedway, is a Java compiler that will work with a tool such as Java Workshop to compile Java code extremely quick. Project Speedway can also profile how much time the Java application is taking to complete such tasks as windowing or running threads.

    "The next version of JavaSoft's Java development tool will be enhanced to include software wizards that let the programmer build the components automatically," Williams said. "Without the wizards, you'd have to have to follow the JavaBeans specification manually," Williams pointed out.



    Software Reuse

    Software reuse is a long standing issue in Software Engineering. Recent developments surrounding the Internet, the WWW, Java, etc. have the potential to change the way we look at some computer science problem domains. U_S can be built on a document-centric framework from small, reusable, user configureable software components that are available on a pervasive network. Although U_S doesn't yet exist, its market is potentially larger than any yet targeted by computer technology.

    Developing reusable software is not easy; it is expensive and time consuming. Developer reuse efforts tend to be targeted at themselves, and not marketing to others. It seems that one factor limiting reuse is the size of its target market. An obvious way recover the increased cost involved in producing reusable software is a larger market.

    Taligent is a recent example of an effort to develope reusable component software. A joint effort by IBM, Apple Computer, and Hewlett Packard, Taligent mission was to development of a new generation of applications, based on object-oriented technology, that would work the same way across an entire organization, regardless of the underlying hardware platforms. This was a worthy goal, but the market for their products were developers like themselves. U_S will benefit developers, but its market is end users--its purpose to help users become developers.



    Market infrastructure

    The largest market in the computer industry is end users. In the personal computer world the market is families, teachers, small and large businesses--almost everyone. Computer ownership is a growing. The grass-roots popularity of the Internet and the World Wide Web is producing another increase in growth. The application-centric monolithic nature of the current software paradigm is not well positioned to take advantage of a very large and growing market of new inexperienced computer users. These new computer users represent a market of unprecedented size. Users who can benefit from a new Information Network paradigm. One that fosters usability. A computer model that doesn't require knowledge of its underlying complexity, one as easy to use as the telephone. Ubiquitous Software is such a paradigm.

    U_S provides a framework for hiding much of the complexity of today's application-centric, architecture-dependent computing paradigm. It will change how and when developers are compensated for their software, increase potentials for software reuse. This can create a category of software more easily available and less costly that any now offered. U_S represents a new paradigm because it provides a market for reusable component software not previously available. It will change the way we think about problem domains. Component software can be used for everything from graphical user interface push buttons and toolbars to database viewers. Authoring systems from different vendors could share identical component libraries--something that cannot be done today.

    Since Richard Adler's paper about standards for component software was published in March, 1995, much has happened. When he wrote this article, Microsoft's OLE and IBM's OpenDoc were two competing document-centric developer environments, one proprietary, one open, neither interoperating well with the other, neither taking advantage of networks to make software available. Some work was began with CORBA 2 specification called Universal Networked Object (UNO) (3).

    Mr. Richard's paper tries to answer the question of how competing standards interoperate. His conclusions are prophetic:

    "Claims that component software could potentially reverse trends toward industry consolidation should be viewed with skepticism. The major software vendors that are advancing component software standards will certainly adopt them internally. These vendors can be expected to continue bundling functionality, albeit in component form, into application suites and operating systems sold under volume-pricing models. However, it is premature to extrapolate such evidence to a diverse market ecosystem of component vendors of all sizes, not just small and huge. At a minimum, an entirely new market infrastructure is required to address issues such as component packaging, specification, pricing, distribution channels, support, and quality certification."(3)
    The competing standards do not interoperate. Implemented only internally, OLE and Open Doc would likely not have much effect on markets. Mr. Richard's states that an entirely new market infrastructure is required to advance component software.

    One year later, much has changed in favor of component software. The Internet's open standards and growing popularity, Sun's announcement in May, 1995 of its distributed pure object program language Java, Microsoft's December, 1995 conversion of OLE into internet based ActiveX, announcements by many vendors such as IBM and Oracle supporting Network Computers--make it seem that the whole of the computer industry is suddenly and collectively moving toward open standards, document-centric, interoperable component model.

    JavaBeans take the component software assembly paradigm to a another level. It is an architecture-neutral API for creating and using dynamic Java components. JavaBeans builds on the strengths of the component assembly model and extends the power further. Developers can use a variety of development tools to assemble applications from fully portable JavaBeans.



    Conclusion

    High levels of reusability are difficult to achieve, even within small individual development teams. To achieve reuse across vendors, integrators, in-house developers, and even end users would seem to be a considerably more difficult. Yet, a new market infrastructure is developing around the grassroots popularity of the Internet and intranet. This can provide large fertile markets for component software that were not recognized even as little as one year ago. Natural decomposition of problem domains complemented by OOD and OOP methods represent opportunities for developers. These are important steps toward achieving interoperablity and enhanced ease-of-use. Network base distribution makes possible per use compensation.

    More developers working on less complex problems for a larger market represents a new market infrastructure. Making architecture-neutral, document-centric, component software available on a pervasive network is a new Information Network paradigm--it is Ubiquitous Software.



    1. Adler, Richard M., Emerging Standards for Component Software, Computer, IEEE Computer Society, March 1995, p68 rmadler@tiac.net

    2. JavaBeans: A Component Architecture for Java, JavaSoft, White Paper, July 1996, http://splash.javasoft.com/beans/WhitePaper.html

    3. (UNO): Universal Networked Object is a class of General Inter-ORB Protocols (GIOP, IOP) supporting standardized messages between networked objects. Internet IOP (IIOP) is mandated by UNO and specifies support for inter-ORB communications over TCP/IP.

    4. Messmer, Ellen, SunSoft cooks up JavaBeans tools, NetworkWorld, Volume 13, Number 45, November 4, 1996, p47



    [ Previous | Next | Table of Contents | Top ]