Obiwan

Motivation

There is a clear need for data sharing and collaboration support in a large number of applications in different domains. In this project, we focus on applications in the area of co-operative work within virtual organisations; for example, a virtual teaching community, a virtual enterprise grouping several companies from different countries, a widely distributed software development team, a distributed game involving people anywhere in the world, etc.

This need for information sharing will increase along two main axis: wide area (i.e., across the Internet) and mobility (i.e., portable computers, webpads, personal digital assistants, smart cellular phones, etc.). As a matter of fact, besides the growing number of desktop computers connected to the Internet, there are other devices, generally called information appliances (info-appliances, for short), that are gaining enormous popularity; personal digital assistants (PDAs) is just one of them. The role of these info-appliances, currently handling agendas, calendars, etc. will certainly grow as more computing power and communications capability can be included. This is confirmed by the existence of operating systems and virtual machines for such devices; for example, Windows CE for a number of PDAs currently in the market, and Java for PalmPilot VII. In addition, the foreseen increase of bandwidth in wireless communication makes the connection of these info-appliances to the Internet a reality in the near future.

The OBIWAN Vision

We envisage a general scenario in which a user will want to access data using a PC in his office, using a laptop while in the airport or in the hotel, using a PDA in a taxi, etc. The user wants to live in this ``data ubiquitous world'' with no other concern besides doing his own work and, as much as possible, to keep on working in spite of any system problem that may occur (e.g. network partitions).

As an example, consider the following scenario in the building industry domain. (Obviously, in this example, we could consider other industry domain, or a virtual teaching or game environment, etc.) There is a virtual enterprise, grouping several companies from different countries, co-operating in the design and construction of a building to be located in Taiwan. An architect, while in his office in Lisbon, works on his PC; his job is to design the building in close co-operation with his colleagues in the same company. As expected, the architects have to co-operate with the engineers of another company, in London, also member of the virtual enterprise. In addition, there is a third company in the virtual enterprise, which is located in San Francisco, that is responsible for the infrastructure calculus so that the building resists to earthquakes. It is obvious that they all interact closely through a set of different applications that share the data describing the building.

The architects and engineers meet each other physically from time to time in each other offices (besides other non-related travels). For such meetings they carry their info-appliance, e.g. a laptop, so that they keep on working together on the building design. In addition, they are interested on using their info-appliances while travelling; in particular, they want to use their laptops, webpads or PDAs when visiting the exact place where the building is being constructed in order to check its advancement. This requires the possibility of setting up an impromptu network connecting different info-appliances in a simple and automatic way.

So, there is a constant need to access shared data no matter where you are and the info-appliance you use, and users want the same degree of responsiveness and performance as in a fully high-bandwidth low-latency wired connected environment. Sometimes these requirements may be impossible to fulfill but the system should be able to minimize the number of such occorrences.

This scenario means that at the system level there is a clear need for data sharing support, for any info-appliance, within and between distinct LANs (i.e. over wide area wired or wireless networks); some of these LANs can be short-lived in the sense that they exist as long as a group of people, who met together on purpose or occasionally, do interact on some place. Most importantly, this system support must be such that application development does not become an impossible task by forcing the programmers to deal with system issues such as fault-tolerance, memory management, application or system code installation and upgrade, security, etc.

Objectives

The overall objective of the OBIWAN project is to design and implement a system that: (i) is well suited to support distributed applications with strong sharing needs, such as those described in the previous section, and (ii) facilitates application development by releasing programmers from the need to handle complex system issues such as fault-tolerance, memory management, etc., while providing the right level of abstraction and functionality to deal with unexpected situations.

We believe that the notion of a generic object broker infrastructure, as proposed in this project, provides the means to achieve the above mentioned objective. Intuitively, to describe our object broker infrastructure, we can say that OBIWAN supports applications that manipulate an ocean of objects; these objects are scattered over a variety of locations and info-appliances, can flow among such appliances, and contain innumerous references connecting them.

More precisely, OBIWAN provides support for such objects in the sense that they can be invoked either remotely, by means of a remote method invocation, or locally by means of a caching mechanism that brings objects to the info-appliance where the application is running.

Thus, OBIWAN allows the application programmer, if he wants so, to control which objects should invoked remotely or locally. Obviously, the programmer can simply provide hints to the system and let it decide what the best option is. In addition, the programmer can also control, or simply provide hints to the system so that it can decide, what part of an object should be brought near an application, e.g. the whole object (data and code) or just its data or just its code.

As already said, we believe that the notion of a generic object broker is mostly adequate to the specific needs of wide area mobile sharing and collaboration support. However, there are some hard problems to solve which require an important research effort. This research effort, that the DSG is doing, is focused on the following areas: transactional support, memory management, code installation and upgrade, and access control. The adequacy of the results obtained in these research areas will be proven not only by careful performance measurements of the OBIWAN prototypes that will be developed, but also by building and testing some specific small-size concept-proving applications.

In summary, the main objective of the research in the OBIWAN project is to investigate the adequacy of a generic object broker infrastructure to support information sharing in wide area wired and wireless networks connecting a large variety of info-appliances.

Check out the Overview Slides in PDF.

Sponsoring bodies: Microsoft Research

Coordinator: Paulo Ferreira

Partners: INESC-ID and Microsoft Research

Homepage: N/A