To get the client and server communicating through a firewall, there are 2 ports that need to be opened up and some configuration of the Protege server and the Protege client(s) is required to ensure that these ports are being used.
- the RMIRegistry
- the Protege Server
Firstly, the RMIRegistry. This is used to help the Protege Clients find the Protege Server. Before the Protege Server starts, we need to make sure that the RMIRegistry is running. The
run_protege_server script (
.bat on Windows,
.sh for Unix and Mac) takes care of this by starting the RMIRegistry before starting Protege server.
By default, RMIRegistry listens on port 1099, so the simplest approach is probably to open that port on your firewall. However, there may be constraints that prevent this at your location that mean that you need to use an alternative. To specify the port that you wish RMIRegistry to use, we need to update the run_protege_server script file, in the second to last line as follows. (In this example, we'll tell RMIRegistry to use port 5100).
Find the line:
and update to read:
Having set the RMIRegistry up (or opened port 1099 on our firewall), we now need to configure the Protege Server so that it can contact the RMIRegistry (and register itself once it's running) and also to specify the port on which the Protege Server will listen for clients.
We do this by editing the
run_protege_server script again. This time a few lines from the end, you will find a line that contains
PORTOPTS=."-Dprotege". This will be commented out, on Windows with the 'rem' word at the start of the line or with '#' in Unix / Mac / Linux.
e.g. in run_protege_server.sh:
Code: Select all
#PORTOPTS="-Dprotege.rmi.server.port=5200 -Dprotege.rmi.registry.port=5100"
[/size]
becomes:
Code: Select all
PORTOPTS="-Dprotege.rmi.server.port=5200 -Dprotege.rmi.registry.port=5100"
[/size]
and on Windows:
Code: Select all
rem set "PORTOPTS=-Dprotege.rmi.server.port=5200 -Dprotege.rmi.registry.port=5100"
[/size]
becomes
Code: Select all
set "PORTOPTS=-Dprotege.rmi.server.port=5200 -Dprotege.rmi.registry.port=5100"
[/size]
Note that out-of-the-box, the Protege team have selected port 5100 for RMIRegistry and 5200 for Protege Server. You can change these to any ports that you like - or as guided by your firewall team. If you've decided to stick with the default RMIRegistry port (1099), change '5100' in that line to 1099, e.g.
Code: Select all
set "PORTOPTS=-Dprotege.rmi.server.port=5200 -Dprotege.rmi.registry.port=1099"
[/size]
In terms of your firewall configuration, you now need to open up the port for the Protege Server, out-of-the-Protege-box, this would be port 5200.
Save the edited script file and shutdown any Protege Server and RMIRegistry tasks that are running on your server. These need to be re-started for the port configurations that you've just made to take effect.
To connect to the server from the client, we just need to append the RMIRegistry port number to the hostname of the Protege Server - the RMIRegistry provides the Protege Client with all the details that it needs to connect to the Protege Server.
This is as you have done with the example screenshot that you sent.
The last potential issue that might need to be looked at if, having done the above, things are still not connecting is to sort out Network Address Translation across the firewall. I would recommend using hostnames rather than IP addresses for the server hosts as the DNS can help a lot with the NAT.
If you are still having trouble with Clients connecting to the Server, we can tell the Protege Server what it's 'outside the firewall' IP address is by updating an another property in the
run_protege_server script:
In the JVM Options section, find the line:
Code: Select all
HOSTNAME=-Djava.rmi.server.hostname=`hostname`
and replace `hostname` (or the Windows equivalent) with the IP address of the Protege Server host as it appears on the outside of the firewall. Note that this may affect the ability of any clients on the inside of the firewall to connect to the server.
Again, I think that using hostnames rather than IP addresses here will help a lot as the Clients and Server can use their relevant DNS server to resolve that kind of thing and should avoid the need for changing this property.
As before, save the edited script and restart the Protege Server for this change to take effect.
Hope this helps.
Jonathan