Position Paper - Synergistic Web of Objects Tim Brinson Protocol Systems, Inc. tim@protocol.com The synergy of the WWW and CORBA will be based on a framework of communicating mobil objects. A major milestone of the WWW is just starting where the entities accessed over the WWW can contain not only multimedia but actual 'live' entities that turns the static information into animations and can respond to user input locally. This is afforded by advances in programming languages that provides portable code that can run in a secure environment. The users of the WWW will soon get boored with simple animations and interactive data and want to access real distributed services that require a flexible interactivity to distributed hosts. This will be driven in part by buisnesses wanting to sell services/products to the consumer. The specialized communications of the internet like ftp, telnet, nntp, and http do not provide the flexibility needed for the buisness services. These services could be based on low level TCP/IP sockets but requires a lot of special programming which hampers quick development. CORBA is the major contender for providing a high level, general purpose communications infrastructure. With the advances of mobil object technology (mainly Java), objects will move to the most appropriate place to perform their tasks. A single object does not work alone and the objects working together in general will need to be running in different locations. The standard communications capababilities being built for Java into web browsers is either too low (sockets) or too special purpose (nntp, telnet, ftp, http). The next generation of web browsers (e.g. Netscape 3.0) needs high level, general purpose communications based on a standard distributed object infrastrucute like CORBA. This is needed so applets do not have to keep reinventing the wheel for communications and so that the communications software built on top of the socket layer does not have to keep being downloaded to the client machine. The the next generation of http and Java packages will need to support encrypted communications so that the applets can be trusted to be unchanged from the source. This is needed so the applets can talk to objects located around the world, not just objects on the originating machine. CORBA is the most popular distributed object infrastructure. Objects can communicate when separated at any distance. The communicating objects can be implemented in any programming language and execute in different hardware and software environments. CORBA does have limited ability to move objects from one system to another but this is based on finding an appropriate object factory on the new system. The future services of CORBA will need to efficiently move objects from one location to another. Currently distributed objects can communicate using CORBA but their design is impacted significantly by the inefficiency of network delays. The objects need to be moved to the appropriate locations at run time to provide their services efficiently. By moving objects to the most appropriate locations the designers of objects will eventually be able to use the most natural object oriented model without concern for network delays. Java promises to be the major candidate for implementing these mobil objects due to the proliferation of web browsers that support Java and hide the underlying execution environment. CORBA services and facilities are needed that can locate the Java run time environment on machines, move the object there and activate it. The mobil objects will be controlled by a variety of means. An object implementaion may be hard coded with some control of where it will execute. Sometimes an object client will exclicately indicate that objects are to be moved to run in their environment. The agent technology is at its infancy but future systems may be dominated by objects being moved from one location to another via some run time intellegence. These decisions may be based on information that can not be programmed in ahead of time such as network bandwidth, server CPU burden and client CPU burden.