Difference between revisions of "Protege 5 Development Environment"

From Protege Wiki
Jump to: navigation, search
(Accessing the server from the same jvm)
(Navigating the server file system)
Line 149: Line 149:
 
         IRI serverIRI = IRI.create(RMIClient.SCHEME + "://" + host + ":" + rmiPort);
 
         IRI serverIRI = IRI.create(RMIClient.SCHEME + "://" + host + ":" + rmiPort);
 
</pre>
 
</pre>
 +
If you know the name for a server document (the root directory, for example, should always exist) then you can retrieve it directly:
 +
<pre>
 +
        client.getServerDocument(serverIRI);
 +
</pre>
 +
This server document ([https://smi-protege.stanford.edu/repos/protege/protege4/libraries/org.protege.owl.server/trunk/src/main/java/org/protege/owl/server/api/RemoteOntologyDocument.java RemoteOntologyDocument]) can either be a directory
  
 
=== Uploading an ontology document to the server ===
 
=== Uploading an ontology document to the server ===

Revision as of 06:15, September 24, 2012

Introduction

The Protege 4 client server allows multiple Protege 4 clients (such as the desktop application) to browse and edit concurrently an ontology stored on a Protege 4 server.

The Protege 4 client server works in a way similar to SVN (update, commit, resolve conflicts). The conflict resolution mechanism is pluggable. You can read more about the client-server implementation (as a generic OWL-API server) in this paper. Here is the first of several videos that I am going to make to demonstrate server features:

Status

We are working on an alpha release. Most of the things that would block an alpha release are relatively easy to do. Here are some things that need doing:

  • Figure out common installation issues such as unix (e.g. including mac os x) init.d scripts, and setup as windows service. I think that this is important. The startup scripts are now working on linux and on os x.
  • Develop a security policy for server access. This would be very nice but some research is still required.
  • Improve the client side UI. The current version isn't very good but it is workable.
  • Add command line checkout, diff, log, update and commit operations. Would be very nice and except for diff is easy (at least the first cut meaning update to latest, etc).
  • Don't expose passwords as plaintext. We can live with this for a bit and eventually use the fix in Protege 3.
  • Branching. This shouldn't be too difficult and we plan to permit branches to go across server boundaries (e.g. git-like).
  • Update backwards to a previous revision. The underlying server implementation now supports this but it has not yet been exposed.

Many things already work including

  • Basic Client-Server interaction
  • Conflict management
  • Authentication (password is sent as plaintext)
  • Firewall compatibility
  • Extended sessions where a user logs out with uncommitted changes and commits them in a later session

Setting Up the Protege 4 Server Development Environment

The Protege server is going to be released with a version of Protege 4.2 very soon. At that time this page will be divided into instructions for users wanting to try it out and a developer page for developers. Until that time, we will only include the developer page.

Install From Svn

First checkout the development tree

     svn checkout https://smi-protege.stanford.edu/repos/protege/protege4/misc/composite/protege4.server/trunk

If you are using eclipse this will become your eclipse workspace later.

To configure the server, run ant install. This will build a copy of Protege with the server installed in the directory 'build/Protege'. At this point, you will have some ant targets that can replace some of the steps listed below:

  1. run.client runs the Protege client.
  2. run.server builds and runs the server. As part of this target the install target is also built.
  3. debug.server builds and runs the server with debugging turned on at port 8500.
  4. run.client builds and runs the client. As part of this target the install target is also built.
  5. debug.client builds and runs the client with debugging turned on at port 8501

Setting up Eclipse

To set up eclipse,

  1. run "ant install". This step ensures that the built sources will be included in the org.protege.owl.server project.
  2. unzip the ide-eclipse.zip file.
  3. start eclipse using protege.server as the workspace.
  4. import the projects (File -> Import -> General -> Existing Projects Into Workspace).

The next part doesn't work yet but should be coming soon. This eclipse workspace will come with a couple of runnables:

  • Client starts the Protege OWL Client.
  • Server starts the Protege OWL Sever
  • ConnectToAntServer connects to the "ant debug.server" script for debugging.

Programatic access to the server

Some of the key classes used to access the OWL server are:

  • the Client which provides a low level api for server access. A Client object can also be used by classes such as the ClientUtilities to provide easy higher level operations such as uploading, downloading and updating ontologies.
  • the VersionedOntologyDocument is an object representing an open ontology corresponding to a server document at a particular document revision. An instantiation of the Client and VersionedOntologyDocument are sufficient to do many operations on a checked out ontology including update, commit and save.

Connecting to the server programatically

Connecting to the Protege server involves two steps, authentication and connection. Both the authentication protocol and the connection protocol are fully pluggable on the server, so the exact method of connecting to the server depends on how the server is configured. However currently we only support one authentication mechanism, a very simple username/password mechanism, and two connection protocols, the rmi protocol for accessing the server remotely and the local protocol for accessing a server running on the same jvm.

Accessing the server through rmi

Accessing the server with standard authentication and rmi can be done with the following steps:

        String host = "171.65.32.14";
        int rmiPort = 4875;
        AuthToken tim = RMILoginUtility.login(host, rmiPort, "redmond", "troglodyte");
        RMIClient client = new RMIClient(tim, host, rmiPort);

The first step authenticates the user "redmond" on to a server running on the same machine but in a different process. This authentication step results in a AuthToken object (tim) that can then be used to connect to the server. The result of the above steps is an object that implements the Client interface.

Accessing the server from the same jvm

The best way to access the server when running on the same jvm is to use a local transport. This transport bypasses all network protocols such as rmi and makes a direct connection to the server through rmi calls. The manner in which the local transport object is obtained depends on how the server is started. The normal case will be the standard Protege server installation where the code accessing the server is run from a plugin. In this case the LocalTransport object can be obtained from OSGi declarative services. An example of this approach can be found here. This example can be run by

  • checking out the project from the svn location.
  • copying the local.properties.template to local.properties and changing the server.home to the appropriate location of the Protege server.
  • running ant install to install the plugin to the Protege server plugin directory.
  • (re)starting the Protege server so that it will pick up the new plugin.

Alternatively, if you start the server without OSGi (see manual setup) then you can arrange to register the LocalTransport somehow so that classes that need it can find it.

To obtain the LocalTransport object through declarative services, create a server component declaration like this one:

<?xml version="1.0"?>
<scr:component name="org.protege.owl.server.example.component" 
               immediate="true"
			   xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0">
	<implementation class="org.protege.owl.server.example.EntryImpl"/>
	<service>
		<provide interface="org.protege.owl.server.example.Entry"/>
	</service>
	<reference name="LOCALTRANSPORT"
	    interface="org.protege.owl.server.connect.local.LocalTransport"
	    bind="initialise"
	    cardinality="1..1"/>
</scr:component>

This declaration tells OSGi declarative services to send any active LocalTransport objects to the initialise method of the EntryImpl class.

Once the LocalTransport object has been obtained, the client can easily be obtained after authenticating as follows:

        AuthToken token = Authenticator.localLogin(transport, "redmond", "troglodyte");
        Client client = transport.getClient(token);

This client can be used just as any ordinary client. In the example plugin it is used to list the contents of the root directory of the server:

        RemoteServerDirectory serverRoot = (RemoteServerDirectory) client.getServerDocument(localRoot);
        boolean isEmpty = true;
        for (RemoteServerDocument doc : client.list(serverRoot)) {
            logger.info("Found doc : " + doc);
            isEmpty = false;
        }
        if (isEmpty) {
            logger.info("Server root is empty");
        }

In a more realistic plugin, the bioportal import plugin for instance, it is used to copy and update ontologies from the NCBO BioPortal into a directory on the Protege server.

Navigating the server file system

Documents on the Protege server are identified by an IRI. Thus for example, the root directory for the server at 171.65.32.14:4875 would look like this:

        rmi-owl2-server://localhost:5100

This IRI can be construced programatically as follows:

        String host = "171.65.32.14";
        int rmiPort = 4875;
        IRI serverIRI = IRI.create(RMIClient.SCHEME + "://" + host + ":" + rmiPort);

If you know the name for a server document (the root directory, for example, should always exist) then you can retrieve it directly:

        client.getServerDocument(serverIRI);

This server document (RemoteOntologyDocument) can either be a directory

Uploading an ontology document to the server

Downloading an ontology document from the server

Saving a server ontology locally along with server metadata

Loading a server ontology and server meta data from a local file

Uploading an ontology onto the server

Extending the server with a plugin

Here I will talk about the metaproject and server components.

Starting the server manually

Here I will talk about starting the server directly without using OSGi or configuring it with declarative services.