Protege Client Server Tutorial Advanced - Revision history

Tredmond: /* Running Custom Code on the Server */

2010-10-01T18:37:56Z

‎Running Custom Code on the Server

Tredmond: /* Accessing the Server Programatically */

2010-10-01T18:37:31Z

‎Accessing the Server Programatically

Dustinburke at 18:54, March 5, 2010

2010-03-05T18:54:52Z

TaniaTudorache at 21:31, February 20, 2009

2009-02-20T21:31:15Z

TaniaTudorache at 21:30, February 20, 2009

2009-02-20T21:30:56Z

TaniaTudorache at 21:30, February 20, 2009

2009-02-20T21:30:03Z

TaniaTudorache at 18:35, February 18, 2009

2009-02-18T18:35:35Z

TaniaTudorache at 18:31, February 18, 2009

2009-02-18T18:31:52Z

TaniaTudorache at 17:55, February 18, 2009

2009-02-18T17:55:02Z

TaniaTudorache at 02:30, February 18, 2009

2009-02-18T02:30:55Z

@@ Line 232: / Line 232: @@
 ''In Progress.  This page is more of a skeleton than the actual needed documentation.''
-On some occasions, in a client-server situation, it is useful or necessary to run some code on the server rather than on the client.  One common reason for this is that an otherwise reasonable block of code may perform very slowly in client-server mode because it makes too many calls over a possibly low latency and bandwidth constrained network. Instead of having the client make several calls to the server, it may make sense to ship the code over to the server and have the code run directly in the server context.  An example of a ProtegeJob can be found in the project that can be checked out of svn from [http://smi-protege.stanford.edu/repos/protege/dev-plugins/trunk/example.job here].  The actual ProtegeJob itself can be found in [http://smi-protege.stanford.edu/repos/protege/dev-plugins/trunk/example.jobsrc/edu/stanford/bmir/job/MyJob.java MyJob.java].
+On some occasions, in a client-server situation, it is useful or necessary to run some code on the server rather than on the client.  One common reason for this is that an otherwise reasonable block of code may perform very slowly in client-server mode because it makes too many calls over a possibly low latency and bandwidth constrained network. Instead of having the client make several calls to the server, it may make sense to ship the code over to the server and have the code run directly in the server context.  An example of a ProtegeJob can be found in the project that can be checked out of svn from [http://smi-protege.stanford.edu/repos/protege/dev-plugins/trunk/example.job here].  The actual ProtegeJob itself can be found in [http://smi-protege.stanford.edu/repos/protege/dev-plugins/trunk/example.job/src/edu/stanford/bmir/job/MyJob.java MyJob.java].
 # writing a ProtegeJob is actually pretty easy despite the slighty esoteric issues below.  You just need to make a class that has all the data needed for the job and write a run method.

← Older revision		Revision as of 18:37, October 1, 2010
Line 227:		Line 227:
	</pre></code>		</pre></code>

		+
		+	= Running Custom Code on the Server =
		+
		+	''In Progress. This page is more of a skeleton than the actual needed documentation.''
		+
		+	On some occasions, in a client-server situation, it is useful or necessary to run some code on the server rather than on the client. One common reason for this is that an otherwise reasonable block of code may perform very slowly in client-server mode because it makes too many calls over a possibly low latency and bandwidth constrained network. Instead of having the client make several calls to the server, it may make sense to ship the code over to the server and have the code run directly in the server context. An example of a ProtegeJob can be found in the project that can be checked out of svn from [http://smi-protege.stanford.edu/repos/protege/dev-plugins/trunk/example.job here]. The actual ProtegeJob itself can be found in [http://smi-protege.stanford.edu/repos/protege/dev-plugins/trunk/example.jobsrc/edu/stanford/bmir/job/MyJob.java MyJob.java].
		+
		+	# writing a ProtegeJob is actually pretty easy despite the slighty esoteric issues below. You just need to make a class that has all the data needed for the job and write a run method.
		+	# you need to make sure that the ProtegeJob class is found on the server. In your case this might mean that you need to write a plugin for the server that contains the ProtegeJob classes that you are using. Alternatively you could put the ProtegeJob in a jar on the server classpath.
		+	# OWLModel's cannot be transferred over the wire. This means that objects that contain an OWLModel, e.g. an OWLClass, need to have their internal OWLModel's restored when they arrive over the wire from the client or from the server. This is done with a localize(KnowledgeBase) method. If you override the ProtegeJob.localize method remember to call super.localize.
		+	# To get the OWLModel that you need during the execution of the ProtegeJob use the ((OWlModel) getKnowledgeBase()) line.
		+	# Be aware of what data is being sent over the wire. An inline ProtegeJob will pick up data from its enclosing class. It is probably better to put a ProtegeJob in its own class or make it a static class.

	'''Read more about the Protege multi-user support in the [[Protege_Client-Server_Tutorial\|Protege client-server tutorial]].'''		'''Read more about the Protege multi-user support in the [[Protege_Client-Server_Tutorial\|Protege client-server tutorial]].'''

← Older revision		Revision as of 18:54, March 5, 2010
Line 229:		Line 229:

	'''Read more about the Protege multi-user support in the [[Protege_Client-Server_Tutorial\|Protege client-server tutorial]].'''		'''Read more about the Protege multi-user support in the [[Protege_Client-Server_Tutorial\|Protege client-server tutorial]].'''
		+
		+	= See Also =
		+	* [[Troubleshooting Client Server Connections]]

← Older revision		Revision as of 21:31, February 20, 2009
Line 16:		Line 16:
	= How Does RMI Work? =		= How Does RMI Work? =

−	We recommend that you take a look at the [[Protege_Client_Server_RMI\|How RMI ~~works~~ wiki page]]. This will help you better understand and debug RMI related problems.	+	We recommend that you take a look at the [[Protege_Client_Server_RMI\|How RMI Works wiki page]]. This will help you better understand and debug RMI related problems.

@@ Line 14: / Line 14: @@
 __TOC__
-= How RMI works =
+= How Does RMI Work? =
 We recommend that you take a look at the [[Protege_Client_Server_RMI|How RMI works wiki page]]. This will help you better understand and debug RMI related problems.

← Older revision		Revision as of 21:30, February 20, 2009
Line 13:		Line 13:

	__TOC__		__TOC__
		+
		+	= How RMI works =
		+
		+	We recommend that you take a look at the [[Protege_Client_Server_RMI\|How RMI works wiki page]]. This will help you better understand and debug RMI related problems.

@@ Line 176: / Line 176: @@
 -Dserver.upload.kilobytes.second=128 -Dserver.download.kilobytes.second=500
 </pre></code>
-However we anticipate that these settings will be more useful if applied on the client because then
+However we anticipate that these settings will be more useful if applied on the client because then a profiler, such as [http://www.yourkit.com YourKit], can determine how much time is being used for latency and how much time is being used for downloads and uploads.  If set on the client the upload time tells the client to simulate delays to mimic a transfer rate for data from the client to the server and the download time tells the client to simulate delats to mimic the transfer rate for data from the server to the client.
 Note that some tools measure upload and bandwidth in kilobits per second.  So a dsl connection with 6 megabits/second download and 512 megabits/second upload is getting 768 Kilobytes/second download and  64 Kilobytes/second upload.

← Older revision		Revision as of 18:31, February 18, 2009
Line 76:		Line 76:
	Finally, when we log in from a Protege client, we need to tell the client where to find the rmiregistry. This is done by appending :5100 to the hostname in the rmiregistry connection screen:		Finally, when we log in from a Protege client, we need to tell the client where to find the rmiregistry. This is done by appending :5100 to the hostname in the rmiregistry connection screen:

−	<code><pre>smi-protege.stanford.edu:5100.</pre></code>	+	<code><pre>smi-protege.stanford.edu:5100</pre></code>

@@ Line 37: / Line 37: @@
 To set the port that the rmiregistry listens on (the default is 1099), the rmiregistry command must be invoked as:
-<code><pre>rmiregistry portno.</pre></code>
+<code><pre>rmiregistry portNumber</pre></code>
 For a more specific example, suppose that we use port 5100 for the rmiregistry and we start rmiregistry with the command:
@@ Line 47: / Line 47: @@
-. '''If you ran Protege server using the run_protege_server script''', then you need to uncomment the line that starts with PORTOPTS:
+'''1. If you ran Protege server using the run_protege_server script''', then you need to uncomment the line that starts with PORTOPTS:
 '''In Linux/Mac OSX''':
@@ Line 62: / Line 62: @@
-. '''If you ran Protege server using the Advanced method (making commands in the console)''', then you need to set 2 JVM arguments:
+'''2. If you ran Protege server using the Advanced method (making commands in the console)''', then you need to set 2 JVM arguments:
-<code><pre>-Dprotege.rmi.registry.port=5100.</pre></code>
+<code><pre>-Dprotege.rmi.registry.port=5100</pre></code>
 Suppose we choose port 5200 for the Protege server to listen on. We tell the Protege server to use this port with the following JVM option:
-<code><pre>protege.rmi.server.port=5200.</pre></code>
+<code><pre>protege.rmi.server.port=5200</pre></code>
 An example of these server settings can be found in the <protege-install-dir>/run_protege_server.sh Unix shell script.

@@ Line 33: / Line 33: @@
 = Working with Firewalls =
-If the Protege server is running inside a firewall, you need to open two ports to ensure access from outside the firewall. One port is for the rmiregistry and the other port is for the Protege server.
+If the Protege server is running inside a firewall, '''you need to open two ports to ensure access from outside the firewall'''. One port is for the rmiregistry and the other port is for the Protege server.
 To set the port that the rmiregistry listens on (the default is 1099), the rmiregistry command must be invoked as:
@@ Line 43: / Line 43: @@
 <code><pre>rmiregistry 5100</pre></code>
-We will also need to tell the Protege server what port to use to access the rmiregistry. This is done by adding the following JVM option to the command that starts the server:
 <code><pre>-Dprotege.rmi.registry.port=5100.</pre></code>
-Next, suppose we choose port 5200 for the Protege server to listen on. We tell the Protege server to use this port with the following JVM option:
+Suppose we choose port 5200 for the Protege server to listen on. We tell the Protege server to use this port with the following JVM option:
 <code><pre>protege.rmi.server.port=5200.</pre></code>
 An example of these server settings can be found in the <protege-install-dir>/run_protege_server.sh Unix shell script.
 Finally, when we log in from a Protege client, we need to tell the client where to find the rmiregistry. This is done by appending :5100 to the hostname in the rmiregistry connection screen:
-<code><pre>elliptic.dyndns.org:5100.</pre></code>
+<code><pre>smi-protege.stanford.edu:5100.</pre></code>
 The Protege client will determine how to find the Protege server when it contacts the rmiregistry.
@@ Line 67: / Line 89: @@
 There are several settings that can be configured in the client-server mode.
 == Server Side Settings ==
@@ Line 94: / Line 117: @@
 * REPEATABLE_READ - which means that the system assures a user in a transaction that data he reads will not change for the duration of the transaction.
 * SERIALIZABLE - which means that transactions are serializable. This is the most stringent form of transaction processing but it is also the most expensive and the most likely to cause problems with locked databases.
 == Client Side Settings ==
@@ Line 138: / Line 162: @@
 </pre></code>
 The input stream line shows the data read from the socket.  The compression ratio lines show the difference between the compressed data that actually goes over the wire and the uncompressed data that is read by the caller.
 == Client Side Settings ==