Before You Read This Document

This document contains an overview of the Habanero developers API or framework. If you do not have Habanero on your computer, you should download and install it. You can read the user's guide to familiarize yourself with using Habanero. Habanero makes extensive use of Java. If you need to learn more about Java, read the Java tutorial.

After you're familiar with the language you can learn to write Java applications that run collaboratively under Habanero. You will create new Java classes that make use of the API presented by the Habanero framework. You will link your new classes into the Habanero client, and then you will be ready to run your Java application as a collaborative tool in Habanero. To learn more about making collaborative applications to run under Habanero, refer to the developers reference or see the tutorial linked from the previous page.

What Is Habanero?

The Habanero framework allows the sharing of Java objects with colleagues over the Internet, that is, it is an API designed to let you create collaborative applications. Taking advantage of the speed with which the Internet allows people to share information, Habanero makes applications truly collaborative and truly cross-platform for an unlimited number of participants.

Habanero includes all the networking facilities as well as the serialization, arbitration, and routing software necessary to share state data and key events between multiple collaborators' copies of a software tool. There is no inherent limit to the number of tools per session, nor is there a limit on the type of tools that can be shared.

Who Can Benefit From Using Habanero?

Habanero is designed for creating and converting Java applets and applications into collaborative applications or as we call them, "Hablets". Habanero is based on a client/server architecture which shares Java objects. The Habanero server provides software mechanisms for arbitration, routing, and networking. However, Habanero differs from a standard server-client paradigm because it is based on the notion of replication. That is, Habanero works by replicating data and events in each client under the control of an arbitrator at a single server. Because Habanero is flexible it works both in a fully client-server paradigm and in a fully replicated paradigm as well as all stages between them.

This concept of replication is central to Habanero's speed and flexibility. For example, consider the case where several clients want to run a telnet session collaboratively. If each client were to telnet into the host, the host could be overwhelmed. If, however, there were only one telnet session, the host would interact with only that one telnet session. Then the telnet display is shared collaboratively through Habanero and an unlimited number of clients could view on which the events and data are replicated under the direction of the Habanero server.

The Habanero code is arbitrarily divided into two parts, the Habanero environment and the Habanero framework. The Habanero environment consists of the Habanero server, the Habanero client, and Habanero applications. The Habanero framework consists of the API to Habanero. The environment is built upon the framework. The separation of code into these two arbitrary parts allows Habanero to separate the tasks of sharing the information, which is what the framework does, and of displaying the shared information, which is what the environment does.

Habanero applications communicate information through a Habanero client, which passes on information to the Habanero server, and the Habanero server then communicates this information with the other Habanero clients.

The Habanero server consists of the following software components: serializers, arbitrators, and communications managers. (Communications managers could also be known by the more descriptive name of routers.) That is, the server has software that reads events from and writes events to a stream, software that controls the order in which events execute, and software that makes sure events get shared by everything that needs them. Events and data are sent to the server, and the server makes sure that these events and data are sent out to each client.

The Habanero serializer takes advantage of the JDK 1.1 capability to serialize. Serializing is the process of copying an object. An object can be an event or data. The Habanero serializer then assigns each object a numbered ticket. The tickets are used to guarantee that events happen in the same order as they are replicated on all clients.

For collaboration to work smoothly, there must be a central point of control. Arbitration is the process of deciding the order in which events are processed. Habanero uses the metaphor of "floor control" borrowed from the field of Computer-Supported Cooperative Work. In CSCW, floor control is the mechanism by which the software decides "who gets to do what when" based on the parliamentary notion of the presiding person controlling the parliamentary process. The president recognizes one of the participants and gives control of the deliberative floor to that participant, as in, "The chair recognizes the Senior Senator from Illinois, who now has the floor." The Habanero server includes an arbitrator for every application. The arbitrator looks at every collaborative action and determines whether or not that action can be executed.

The central arbitrator makes sure that all the clients see the events in the same order. Arbitrator code at the client ensures that events execute in the order prescribed by the tickets assigned by the serializer. The tickets also provide a minimal level of authentication because clients know not to execute actions that do not have tickets associated with them. This authentication mechanism may be expanded in the future by using extended tickets. Extended tickets might include information such as security features, one-time coding guarantors, and other information to ensure that the action cannot be faked. But these extensions do not currently exist.

Arbitrators in Habanero began as centralized arbitrators located only at the server, but the term has come to include distributed arbitrators on all the clients. A Habanero arbitrator is basically a distributed object with part residing on the server and part on the client. There are proxies at each client so it looks to the hablet as if it is calling the arbitrator locally, but actually, Habanero arbitration happens at the server. An example of an arbitrator in Habanero would be code that enforces the rules of a game of checkers.

However, arbitrators are more general and thus can be more useful. At one extreme, arbitrators can be used to enforce game rules. In this case, the client program is replicated at each client and all important confrontation is done at the arbitrator. At the other extreme, arbitrators can contain an entire program at the arbitrator. In this case, the hablet essentially becomes an instance of a client program under the control of a server, and the clients are basically just GUIs in the classic client-server sense.

Arbitrators can also force the synchronization of events on all clients. For example, clients that run on different hardware may run at different speeds. To keep all events in lock-step, the arbitrator may require all clients to run no faster than the speed of the client on the slowest processor.

The Habanero communications managers (also known as com-managers and routers) are currently located in the server. The com-manager accepts events and makes sure that they go to all the appropriate clients. Although the com-managers are currently located in the server, Habanero is designed to allow each client to do its own routing.

Habanero takes care of networking for you. There is no need for your application to worry about establishing network connections. Future plans include giving Habanero the ability to multicast events rather than using TCP/IP.

The Habanero client communicates with a single Habanero server, which then communicates with other clients. The Habanero client contains software for serializing, arbitrating, routing, and networking. In essence, these duplicate the actions of the same kinds of software in the server; that is, the client and the server work from the same framework or API. Because Habanero is flexible, most or all of these tasks can be located either in the client or in the server.

The client provides the capability to define a Habanero session and to participate in existing sessions. In the latter case, the client provides a local version of the tools within the existing Habanero session. (You can, of course, use the client to run Habanero tools locally, but in that case they would not be available for collaborative use.)

The client allows you to identify yourself, to display session information including the session agenda, to display tool information, to display participant information, and to define what tools are available in the session.

If you have started and defined a session, the client also provides some security for the session via password protection or via a participant list. The participant list can either allow or deny users access to the session based on the user's IP address.

Habanero uses a hierarchical naming scheme to ensure that events from one client are shared with the corresponding part of all other clients. The hierarchical naming scheme makes use of the frames in which objects live and of the collobject to which a frame is attached. A collobject is a Habanero data type, an internal pointer to one of the Habanero tools.

Each session has a parent, which is the session manager. The session manager is the root of the hierarchy. The hierarchy progresses from the session manager, to the session, to the collobject, to the frame which contains the collobject, to the children of the frame, to the children of the children (as many generations deep as necessary), to the object. This hierarchical naming scheme ensures, for example, that when a button is pressed on one client, the same button is pressed on all the clients.

The purpose of the Habanero framework (the API) is to share events. When an event happens on a Habanero client, the purpose of Habanero is to share that same event with all the other clients. Let's follow the sequence of events that occurs when a button is pushed on a client, for example.

The button is pushed on a client running a session of a Habanero tool. Each session has multiple listeners associated with it. Listeners listen for events and then send on the event. One of the listeners thus takes note of the button being pushed and sends the information to a listener manager. Although there are several listeners associated with each listener manager, there is a one-to-one correspondence between listener managers and sockets. The listener manager sends the event "a button has been pushed" off to the Habanero server.

At the Habanero server, there are multiple listeners as there are on the client. A listener receives the event "a button has been pushed" from the Habanero client. The server processes this event, giving it a numbered ticket and an action_granted. The ticket and the action_granted are sent to all other clients. A listener on the client receives the ticket and the action_granted and then passes them to the target, which is the correct button on the correct Habanero tool.

[ Download ] [ User Docs ] [ FAQs ] [ Home ] [ Dev API ] [ Tools ] [ License ]

Habanero^® is a registered trademark owned by The Board of Trustees of the University of Illinois. Copyright 1996-1998. All rights reserved.   Java^(TM) is a proprietary trademark owned by Sun Microsystems, Inc.