OntoPlugins – a flexible component framework Siegfried Handschuh Institute AIFB, University of Karlsruhe, 76128 Karlsruhe, Germany
[email protected] http://www.aifb.uni-karlsruhe.de/WBS
Abstract
1
Introduction
Building up from standardized units to complex things and products is a well-known construction principle from the engineer technology. With the development of software systems this concept gains ever more significance. Therefore Ont-O-Mat uses a flexible and expandable plug-in framework [1]. The Ont-OMat framework is developed in the research field of ontology based knowledge representation. There exist now two applications for this framework: (i) It is used for an annotation tool for web pages and (ii) it forms the flexible basis for the OntoEdit knowledge engineering environment. This framework offers the possibility to implement its functions by extensions. Such extensions are usually called snap-ins, add-ons or plug-ins. The term plug-in in the context of the framework means a software component, which implements the appropriate Java interface. The framework consists of a core for the plug-in management and a general plug-in which represents the core functionality. All additional functionality is totally enclosed in additional plug-ins.
2
Advantages
The architectural idea behind the Ont-O-Mat chassis is a component-based framework, thus, being open, flexible and easily extensible.
1
The architecture provides a plug-in and service mechanism. The components are dynamically plug-able to the core Ont-O-Mat. The plug-in mechanism notifies each installed component, when a new component is registered. Through the service mechanism each component can discover and utilize the services offered by another component. A service represented by a component is typically a reference to an interface. This provides among other things a de-coupling of the service from the implementation and allows therefore alternative implementations. The advantages of this architectural idea are: • Modular: A plug-in accesses over the service mechanism other plug-ins or the core OntO-Mat. The interface of an service reveal as little as possible about the inner working of an service. This isolates the client of the services from requiring intimate knowledge of the design of the service, and from the effects of changing those decisions. This information hiding is a primary criteria for system modularization. • Extensible: The system can be extended by plug-ins. Each new functionality can be realized as independent plug-in. The interoperability between the plug-ins is realized over services. Each plug-in can offer new services. • Flexible: Each unnecessary plug-in can be removed and each necessary plug-in can be loaded at run-time. Therefore the system can be configured in such a way that it has only the needed functionality. • De-coupling: The service mechanism provides a de-coupling of the service from the implementation and allows therefore alternative implementations.
3
Functionality
The framework consists of the core Ont-O-Mat and the various plug-ins. The core Ont-OMat provides different functionalities for the management and hosting of the plug-ins and the services. The plug-ins on the other hand implement certain Java interfaces in order to be plug-able into the framework and to offer services.
2
3.1
Ont-O-Mat
Ont-O-Mat realizes a Multiple Document Interface (MDI), with some standard menu entries. For plug-in administration Ont-O-Mat has some functionalities: A plug-in management console. The plug-ins are registered to the Ont-O-Mat with the console. The user must indicate the complete class name of the plug-in for that. The console loads and unloads the registered plug-ins. Furthermore it indicates the copyright messages and possible error messages of the plug-ins. Further, Ont-O-Mat has an option manager. This manager shows a list of the installed plug-ins. If a plug-in from the list is selected the associate option panel will be visible. Each plug-in that has settable options can offer such a panel. Each plug-in is examined with registering. It is discovered whether it offers a service or it would like using a service. Besides of the service mechanism Ont-O-Mat has further means of internal communication. Ont-O-Mat produces internal standard events, e.g. clipboard events or file events. These events are dispatched and each plug-in can utilize these events.
3.2
Plug-in
Each plug-in can provide menu entries within the menu bar and an icon within the toolbar. The menu entries and the icon are connected with actions of the plug-in. Apart from the own menu actions a plug-in can react to an Ont-O-Mat standard event, if it has registered itself for it. Further, it can share an event model with another plug-in based on the service mechanism. A plug-in can be in the role of a service-provider or a service-consumer, according to the Java interface it implements. A plug-in that implements the service-consumer interface registers it and intends to be notified of new services. On the other hand a plug-in that implements the service-provider interface register a new service with the framework. The framework notifies all currently registered service-user that this new service-provider plug-in has been added. After being notified of the newly available service, the listening plug-in requests an instance of the service from the framework. The framework tells the serviceprovider to deliver the service to the requesting plug-in. Each plug-in has access on the MDI Desktop of Ont-O-Mat. It can independently place 3
windows there. Also a data exchange is possible between these plug-in windows by drag and drop if these windows are appropriate implemented.
4
Interfaces
In order to build a plug-in, either directly the OntoPlugin interface must be implemented or one of its descendants like OntoPluginServiceConsumer or OntoPluginServiceProvider. In order to simplify the implementation of a plug-in there are specialized classes that already implemented these interface. E.g. so-called tab-widget plug-ins are user interface tabs that appear in the main Ont-O-Mat window beside the system tabs such as the classes tab. A tab-widget plug-in is simple to write, but it is less powerful.
4.1
OntoPlugin
Following methods of the OntoPlugin interface must be implemented by a plug-in: • init: This method is called after instantiation of the plug-in. The plug-in should perform any initializations here. The plug-in should try to load its preferences via the framework. • canExit: If any of the plug-in returns false, the exit process of the framework is interrupted. • exit: plug-in should perform cleanup operations here. First the plug-in’s canExit() method is called from the framework. If it returns true, its exit() method is called. After that, the plug-in is removed from the internal cache and its buttons and menu are removed from the GUI. • getPluginInfo: The plug-in can return here a short information message over itself, e.g. the copyright, the author and the intended purpose. • getPluginMenuName: Should return a name for the plug-in that can be displayed in a menu bar. Can return null when there should be no menu item for this plug-in. • getPluginName: Should return a user-friendly name for the plug-in.
4
• getToolbarActions: plug-ins that require toolbar buttons should return the actions here. The buttons will appear in an own separator section. • getErrorMsg: Should return an error message describing the status of the plug-in. May return null if the status is ok. • getMenuActions: plug-ins that require menu actions should return them here. The menu items will appear under the Tools — -getPluginMenuName- item. • getOptionsPane: This method should return a subclass of JComponent that implements an option page for the plug-in. The option pages will be displayed by the framework when the user selects the View — Options... menuitem. The component should not extend the dimensions (350, 350) approximately. If you require more space, use a JScrollPane or better a JTabbedPane on your options pane. When the option component is about to be displayed. its setVisible(true) method is called. Again, if the component is to be hidden its setVisible(false) method is called. Any reading or writing of options should take place in that method.
4.2
OntoPluginServiceProvider
OntoPluginServiceProvider is the Java interface for an plug-in that offer services in form of service classes. A plug-in which implements this interface is hence called a service-provider. A plug-in that implements the OntoPluginServiceConsumer interface is hence called a serviceconsumer. A service-provider supplies on request an instance of the desired service class. The service class can be the plug-in itself or a class on that the plug-in refers. The service-provider may always return the same instance, or it may construct a new instance for each request. A service class specifies a interface protocol between the service-provider and the service-consumer. The plug-in framework has the function to act a as rendezvous between a service-consumer and a service-provider. The service-consumer may ask the framework to provide an instance of a ”service”, based upon a reference to a Java Class object that represent that service. If such a service has been registered with the framework, then the service-provider associated with the service is asked to provide an instance of that service.
5
• getCurrentServices: This method is not used by the framework yet. In future this method will get the current service selectors for the specified service. A service selector is a service specific parameter, typical examples of which could include: a parameter to a constructor for the service implementation class, a value for a particular service’s property, or a key into a map of existing implementations. • getService: Invoked by the framework, this method requests an instance of a service. • getServiceClass: Invoked by the framework, this method returns the service class. • releaseService: Invoked by the framework, this method releases a reference to the specified service.
4.3
OntoPluginServiceConsumer
A plug-in that implements the OntoPluginServiceConsumer interface registers its intent to be notified of new services. • serviceAvailable: Invoked by the framework, the service-consumer is notified about a new service. • serviceRevoked: Invoked by the framework, the service-consumer is informed about the deletion of the service.
5
Plug-ins in Ont-O-Mat
There are already some plug-ins implemented for Ont-O-Mat: • General plug-in: The general plug-in is an implementation of the OntoPlugin interface. It is always loaded during run-time and cannot be removed with the management console. This plug-in represent the host framework. In the option menu it represents the settings for Ont-O-Mat. • OntologyServer: This plug-in is a service-provider. It releases the access to a service class with the interface IOntologyServer. This service class contains the data model of the ontology, as well as persistent storage. It supplies for the service-consumer methods for the access to the concepts, relations and instances of the ontology. Complex data 6
types are avoided as parameters of the methods in order to achieve a good information hiding of the service design and therefore to support modularization. • OntologyEditor: The OntologyEditor is a service-consumer. It uses the service, which is defined by the IOntologyServer interface. The OntologieEditor support the construction and modification of ontologies, it visualizes elements of the ontology, e.g. the concepts, relations and instances.
6
Future developments
The plug-in framework will be constantly improved. For the future following functions are planned: • Version: Each service will return a version number. A service-consumer will be able to ask for a certain version of an service. • Plug-in folder: User friendly installation of plug-ins. Automatic identification and loading of packed (jar)plug-ins from a certain folder. • Internet based update: The framework will support an update mechanism. This will permit it to examine whether on the home page of a plug-in a new version is present and to offer this new version to load automatically. • Recursive plug-in architecture: a plug-in consist of plug-ins. For that it needs to be able to act as a plug-in container like the framework.
References [1] S. Handschuh, S. Staab, and A. Maedche. Cream — creating relational metadata with a component-based, ontology-driven annotation framework. In submitted to K-CAP’2001, 2001.
7
