Loading...
Please wait, while we are loading the content...
Similar Documents
Extending an Object − Oriented Model to Support Coordination
| Content Provider | Semantic Scholar |
|---|---|
| Author | Lenormand, Emmanuel Balter, R. |
| Copyright Year | 2007 |
| Abstract | The Guide distributed object−oriented platform provides an integrated environment for building distributed applications based on the object paradigm. It is intended to extend this model as well as the functionalities of the run−time system to provide better support of groupware applications involving the coordination of cooperating activities. This paper describes the extensions to the basic object−oriented model required to achieve this objective. 1 Background: The Guide Object−Oriented Model. The Guide platform provides an integrated environment for the development and execution of distributed applications handling persistent data. This environment allows distributed applications to be developed using a high−level object oriented language. The Guide platform comprises a run−time system, a number of applications services, built as objects, and a set of development tools, including the compiler of the language, a distributed debugger and a class browser. Two versions of the platform are available: one is running as a software layer on top of Unix; another version is implemented directly on top of the Mach 3.0 micro−kernel and provides full interoperability with the OSF−1 server. In Guide, applications are structured in terms of objects. Objects are fine−grained passive entities which are stored in a multi−site location transparent secondary storage. They are loaded on demand into a virtual memory for execution. The main execution unit used by applications is the job, which may be viewed as a multiprocess virtual machine composed of distributed concurrent activities operating on objects. A basic operation in the system is object invocation. An invocation specifies the system reference of the invoked object, the name of a method and the parameters of the invocation. The reference contains a unique object identifier, called Oid, and location hints. Since the 2 Extending an Object−Oriented Model to Support Coordination. objects may be located on different nodes, jobs and activities may be distributed. However, the distribution is hidden from the user. At the application level, communication between jobs and activities entirely relies on object sharing. Object sharing is controlled through the use of a set of synchronization constraints, expressed in terms of guards associated with methods, which are specified in the class of the object. The Unix version of the Guide platform was intensively used for the construction of pilot cooperative applications. This included a cooperative structured document editor, a workflow application dealing with the circulation of documents and folders within an enterprise and a multi−user distributed spreadsheet. Complementary experience was also gained from the implementation of the development environment itself, built in terms of objects. It includes a coordination service, which allows the cooperation of interdependent development tools, such as the browser, the syntactic editor, the compiler, and the debugger[Boyer94]. From these early experiments, it was possible to evaluate the benefits and weaknesses of the Guide approach for the expression and control of coordination. This analysis leads us to revise the Guide computational model to better fit cooperative application requirements. This study is currently in progress and we describe its guiding principles in Section 2. 2 Specific Requirements for Coordination. The way we understand coordination remains close to the definition given in [Malone90]: [Coordination is] the act of managing interdependencies between activities performed to achieve a goal. Our objective is not to define a coordination model but to provide a set of abstractions and tools which will allow the construction of a large variety of coordination models. Based on the current definition of the Guide model and system, the main issues to be addressed are: the ability to manage activities (section 2.1), integration of pattern−based and name−based communications within the name service (section 2.2) and additional communication and synchronization facilities based on event handling (section 2.3). Finally, section 2.4 introduces the concept of event broker which aims at combining the functionalities of the naming service and the event−based communication service. It is expected that the event broker would greatly assist application programmers in the design of coordination services. 2.1 Activity management. From Malone’s definition, it appears that activities (i.e. active entities) are central to the design of coordination capabilities. Thus there is a need for the actual management of activities. This includes creating, deleting, suspending, resuming a given activity, or a group |
| File Format | PDF HTM / HTML |
| Alternate Webpage(s) | http://sardes.inrialpes.fr/papers/files/94-Lenormand-ECOOP.ps.gz |
| Language | English |
| Access Restriction | Open |
| Content Type | Text |
| Resource Type | Article |
