End-user Reusable Components on the Internet

W3C/OMG Workshop on Distributed Objects and Mobile Code Position Paper Submission

Submitted by:
Jeffrey Bonar
IBM, Mailstop = 9645
11400 Burnet Rd.
Austin, TX 78750

voice - 512.838.0937
fax - 512.838.1032
email - jbonar@austin.ibm.com

The Issue

The emergence of component models (and their recent endorsement as the OMG User Interface Common Facility) has moved the object revolution into the hands of end users. Most object technology focuses on how programmers reuse software resources. With components we choose a set of frameworks to provide end-users with a way to combine software resources that were not specifically designed to work with each other. So far, components have mainly focused on integration at end-users desktops: compound documents, application assembly, etc. Here, we discuss what needs to be added to our component models to work well with the Web.

Component models on the Web have profound implications. We are used to thinking of client side of the Web from the point of view of browsers: a self-contained platform independent world with well defined borders separating it from the client operating system and desktop. Components allow us to deconstruct this legacy of the historical roots of the Web. Bits of Web content can now define their own shape and organization. Users can choose their own desktop containers that do not follow the rules of HTML text layout. They can, for example, organize their "desktop" based on monthly calendar, customer phone log, a gannt chart, a 3D world, or some other containment metaphor. Conventional computer screens can disappear in favor of home entertainment centers, mobile electronic portfolios, etc. Within these containers, end-users can gather together and freely organize specific elements. Some of those elements are local, many are fetched as needed via a URL.

Component Models Before the Internet

Component models provide a set of conventions and APIs that allow disparate software elements to interoperate based on the casual needs of end-users. What do existing component models like OpenDoc, now the OMG User Interface Common Facility, and Microsoft's OLE/OCX/ActiveX/COM provide? They include capabilities for:

• compound documents - sharing screen real estate, irregularly shaped visual elements, and arbitrating user events.
• persistence - persistent saving of component editors and component content between execution. In business scenarios, connection to traditional transaction monitors and databases is also important.
• scripting - hooks for less-skilled programmers to casually assemble components into customized applications, using languages like LotusScript Basic, JavaScript, Microsoft Visual Basic, AppleScript, etc.
• linking - how do components share data? How do they communicate with each other?
• code management and registration - how do components register their availability and capability to handle standard file formats (e.g. GIF file viewer)? How do users discover what is available?

Internet Scenarios That Demand New Component Capabilities

Each of the component model features listed above needs to be evaluated in the context of the new kinds of scenarios enabled by the internet.

• Thin Clients - There will be several brands of "internet terminals" available by the end of 1996. These will be world-wide-web enabled machines only; designed to interpret HTML and execute Java p-codes with little or no user accessible local storage. Such clients put demands on persistence mechanisms to enable progressive downloads, and require light-weight client runtime support. What, for example, is the right scripting strategy for such clients? JavaScript embeds programming language code in HTML. Is this significant collapse of model and view right for thin clients, or is the Java, separate class files with clean object abstractions, approach correct?
• Virtual Reality Clients - At the opposite end of the spectrum from thin clients, internet applications are emerging that assume very high bandwidth multimedia, virtual reality, and other "new age user interface" clients. These clients require high performance access to content (via compression, ATM, and other technologies) and rich models of user-interface actions on the client. Are our current abstractions of user interface actions sufficient?
• Collaboration, Information Sharing and Searching - World-wide-web uni-directional links are inadequate for significant collaborative applications: you almost always want to know who points to a content node, not just where a content node points to. Abstractions for publication are also important: loose ideas and casual notes, working drafts, archival documents. Finally, the frustrations of semantics-free text search currently available from Web search engines points to the need for heuristic approaches to querying and information gathering.
• Business Data Access - Typical corporate applications require controlled access to relational data, often data stored in a legacy database. This introduces security concerns, transaction management concerns, and reliable information about scalability and capacity given a particular configuration. Businesses want to easily expose bits of their private computational infrastructure to public view for on-line ordering and customer support. Beyond the above concerns, businesses need ways to automatically manage and update distributed applications and application components.

Prepared 18 March 1996 by Jeffrey G. Bonar, jbonar@austin.ibm.com