Requirements for OO + Web Integration

Introduction

This section of the Internet Tool Survey is a listing of some of the unmet requirements of OO + Web integration. These requirements come from several sources:

• our experience,
• discussion at OMG Internet SIG meetings,
• discussions at ARPA I3 and DTII/IC&V meetings, and
• preparations for the Internet Tools Survey.

The requirements are grouped according to function. As the reader will see, this is a preliminary requirements list: the requirements are incomplete, high level, qualitative and not quantitative, some are motherhood, many are not refined, other groupings are possible, not all requirements are unmet, and some require tradeoffs. Still, we are not aware of another similar listing in this area. So this is a start.

Architectural Requirements

These are requirements of the architectural framework minus the component functionality that can be added to the framework. Both the Web and OMG architectures meet some of these requirements already.

• high performance
• rapid uniform access to information
• access to unstructured, semi-structured, structured legacy and new information sources
• rapid application development
• low or no cost
• decrease software development time and cost
• by shared libraries and reference implementations
• by common domain models adopted by communities
• scaleable open architecture framework
• simple, understandable, modular, extensible architecture
• based on suite of (de facto widely adopted) standard protocols (e.g., IETF, OMG, ANSI)
• accelerate consensus leading to standards
• rough consensus and running code with two or more interoperable systems available
• reference implementation widely available
• increase functionality modularly with open component interfaces and wire formats
• platform independence
• support for multiplicity
• must support many object models and interoperation between them
• many differences in object models - Java, IDL, SQL3 ADTs, …
• creates object model interoperation problems
• creates OMG variants as in OMG[IDL] and OMG[Java]
• must also support interoperation between these object models and standard Internet data representations (MIME, etc.)
• must support many programming and scripting languages
• must support many component object services including basic services, customizations of these, compositional services, and federated services
• componentware
• encapsulation of service implementations
• component interoperability via
• component test suites
• standard component interfaces and standard data formats
• customization of services via inheritance
• composition mechanisms for components
• federation of like services
• reduce complexity of clients and servers
• consider peer-peer
• light weight protocols
• decentralized
• memoryless
• hierarchical
• need client and server sides to be OMG Inside
• evolvable
• provide migration path from today's protocols to tomorrow's
• quality-of-service
• global or decentralized load balancing - dynamically distribute the load among replicated resources according to demand and transient network conditions
• decisions made dynamically on quality of service observations (variable reliability and bandwidth). Need explicit QoS abstractions. Must be able to allocate processing, communications, and storage across the network.
• avoid risk of OO hiding details (which ESIOP, size of collection) - this info may need to be exposed
• accounting mechanisms that can stop agents that exceed their resources
• ability to support band-width limited interactions using multiple communication paths with different bandwidth characteristics including some optimization

Functionality requirements

These are requirements of components that must fit into an architectural framework.

• modular security mechanisms
• CORBA and Web across Firewalls
• user authentication
• type information
• mobile objects that migrate between clients that do not trust each other
• safe mechanism for executing untrusted scripts
• confine untrusted code to execute in a secure application execution environment
• support for trusted path between user and code
• mediate access to different name spaces
• denial of service if agent overconsumes a resource
• scripting languages and programming languages
• support for multiple scripting languages and interoperation between them
• run-time types and user-definable marshaling and unmarshaling
• garbage collection
• high level for rapid application development
• easy integration glue language
• embeddable so it can be incorporated into C/C++ applications
• portable - runs on all the major platforms
• mobile - easy to send scripts between applications and platforms
• code size - if program is to fit inside a telephone
• it should also be possible to optimize the combination of executable size and available communications bandwidth for the same functionality (e.g., I might have a "thin client" version in the telephone (or other man-portable device), and a "fatter client" version of the same app in a computer installed in a vehicle, and also adjust the size based on how good the communications is going to be between the client and its "servers")
• safe -- see security
• real-time
• multimedia
• IMA's Multimedia Systems Services model and ISO MPEG-2 DSM-CC standard both use OMG IDL to describe their interfaces (paper 44)
• candidate object services (basic components) - this list augments what OMG already provides and is by no means exhaustive. In particular, it does not cover any domain-specific services.
• Caching services and federation of caching services
• Indexing services
• Translation services (see OMG Data Interchange Service)
• Externalization wire formats for C++, Java, …
• Inverse mappings from C++, Java, Smalltalk, … to IDL
• IDL-based simulations
• Schedule service
• Plan service
• Gateways to/from Internet Services or Extensions to Existing OMG Services
• IDL --> Java (see Sun JOE, JYLU)
• OMG Transactions integrated into Web server sessions
• candidate common facilities (compositional components)
• the network, database, file, and OO communities should talk to each other
• object file system
• wrap today's file systems to provide seamless strong typing
• must retain migration path
• new generation of information systems built from composed object services including:
• workflow system
• represent tasks, tools, sessions, data,
• CASE
• DBMS
• KBMS
• general purpose repository
• Web improvements needed
• replace URLs with location-independent URIs or URNs - global location-independent naming
• full read-write interactions
• caching and replication APIs
• need session control and transactions
• persistent connections - avoid reestablishing connection at every interaction - see Netscape cookies
• user wants quicker response, don't wait for server to point out invalid query
• improvements to CGI needed
• higher level object abstraction needed
• improved efficiency
• possibility of standardizing on transports such as IIOP
• avoid downloading basic comm. support with every applet or generalize to smart downloading based on what client has already
• Web GUI's
• event and change notification
• organize the web as an OODB
• CORBA improvements needed
• economy of componentware and mass adoption strategy needed
• need some interesting CORBA services on the net
• the masses need to get involved
• scaleable
• federation of services
• compositional glue mechanisms
• asynchronous messaging
• higher level DII interface
• hierarchical name service and hierarchical object caching
• mobile objects - efficiently move objects from one location to another (move objects nearer to the computation or the user). This is a general functionality requirement, if not in the sense of dynamic mobile objects (a la Java applets), certainly in the sense of configurability (with objects, it ought to be possible to define what parts of an application, what parts of "client", etc., reside on a given HW platform, simply by specifying what objects reside there; the others are communicated with remotely)
• portability of applications across different CORBAxxx implementations (since some OMG specifications are underspecified)
• interoperability of different CORBA products with respect to administration and security and service federation.
• object groups, replication, fault tolerance, 24x7 CORBA, mechanism transparent to application builder, developer sets policy, tradeoffs of availability and consistency, detection of out of date or inconsistent replicas, automatic or manual replication, how much to replicate, cost-benefit
• migration management
• remote access to databases - send SQL and get back results
• lightweight clients that can access any CORBA server
• ephemeral applications assembled on demand from componentware libraries
• global location independent naming
• stream interfaces
• real-time service attributes
• QoS traffic characteristics
• multiple interface objects
• event histories
• log all message traffic
• indexing support
• configuration support (as in document management systems)
• tuned to support WANs
• clusters (autonomous administrative domains, allows scaleable object location, controlled sharing of services)
• cluster-wide interface and implementation repositories
• multithreaded servers
• remote monitoring of services
• graphical system admin
• ability to interactively invoke server methods (test server before client code is written)
• client side object services or autodownloading these

This research is sponsored by the Defense Advanced Research Projects Agency and managed by the U.S. Army Research Laboratory under contract DAAL01-95-C-0112. The views and conclusions contained in this document are those of the authors and should not be interpreted as necessarily representing the official policies, either expressed or implied of the Defense Advanced Research Projects Agency, U.S. Army Research Laboratory, or the United States Government. 

© Copyright 1996 Object Services and Consulting, Inc. Permission is granted to copy this document provided this copyright statement is retained in all copies. Disclaimer: OBJS does not warrant the accuracy or completeness of the information on this page. 

This page was written by Craig Thompson. Send questions and comments about this page to thompson@objs.com.

Last updated: 1/3/97 sjf

Back to Internet Tool Survey -- Back to OBJS