Using the public server that is provided by the KIELER project may introduce a significant latency to the layout process, depending on the size and structure of the models you are using and the type of internet connection you have. Another aspect is confidentiality. You may not want to send your models to a public server, even if the connection is being secured by HTTPS. For these reasons you may want to set up your own server that is providing layout in your internal network. In the following we will take a look at what it takes to set up the server in your environment and how you can configure it to your needs.

Download and Installation

...

• a java runtime environment, preferably the latest release of version 6 (http://www.oracle.com/technetwork/java/javase/downloads/),
• the latest release of the reference implementation of JAX-WS, currently version 2.2.6 (http://jax-ws.java.net/), and
• the current version of graphviz (http://www.graphviz.org/Download.php).

The server of KWebS is implemented in java. Therefore we begin the installation with the java runtime environment. The server uses a SOAP web service based on JAX-WS and the java platform comes with support for JAX-WS already. The included version is quite old, therefore, after you installed the java runtime, you need to update the built-in version by using the endorsed-mechanism from java:

...

The next step is to decide which service variants you want to provide. There are three two of them (plus the HTTP Post which is available via the support server):

• SOAP over HTTP,
• SOAP over HTTPS, and
• jETI.

As the following listing shows, you can define the variants to be published by the server in the provider configuration. In the given example, SOAP over HTTP and jETI are is available:

# Use this option to configure whether the JAXWS layout will be published HTTP based
de.cau.cs.kieler.kwebs.jaxws.publishHttp=true

# Use this option to configure whether the JAXWS layout will be published HTTPS based
de.cau.cs.kieler.kwebs.jaxws.publishHttps=false

# Use this option to configure whether the layout will be published jETI based
de.cau.cs.kieler.kwebs.publishJeti=true

The next step is to define how the variants are being published. All variants per default only accept requests from localhost. In order to make them publicly available you need to configure from which IPs the variants are accepting requests from. You can also define the port a variant is listening on and the HTTP context it is bound to. In the following example they are accepting requests from 0.0.0.0, meaning that they accept incoming requests from any client. The SOAP over HTTP variant is bound to port 8442 and the context layout. You cannot define a context for the jETI variant due to the proprietary nature of the transport protocol jETI uses.

# Use this option to configure the address, port and context under
# which the SOAP variant will be published over HTTP
de.cau.cs.kieler.kwebs.jaxws.httpAddress=http://0.0.0.0:8442/layout

# Use this option to configure the address under which the jETI
# variant will be published
de.cau.cs.kieler.kwebs.jeti.server.hostname=0.0.0.0

# Use this option to configure the port under which the jETI
# variant will be published
de.cau.cs.kieler.kwebs.jeti.connector.sepp.port=9867

If you decide to publish the SOAP over HTTPS variant you need a server certificate in order to secure the connection. While a certificate that has been officially signed by a Certificate Authority (CA) is preferable, the server provides a java key store containing a self signed certificate. It is located in the folder server/kwebs/security/keystores beneath the root directory of your server installation, the name of the key store is server.jks. Furthermore, due to the nature of the SSL-implementation of the java platform, the server provides the corresponding client trust store that clients can use to add the server certificate to the list of certificates the java runtime implicitly trusts (client.jks). The server also contains a script (GenerateCertsAndKeystores.sh) that allows you to generate these by yourself. You can find it in the folder server/cmd beneath the root directory of your server installation. The script requires the presence of OpenSSL (http://www.openssl.org/). While it is generally already installed on Linux platforms, for a Windows based server you need to download and install the OpenSSL toolkit (http://www.openssl.org/related/binaries.html).

...

In the given example the key store is located at security/my.jks relative to the servers root directory and the password is MyPassword.

Using the Start/Stop Scripts

After an initial start of the kwebs binary, kwebs_start.* and kwebs_stop.* scripts will be unpacked to the root directory. They can be used to properly start and stop the server via a management application. The application can only be contacted via local host. For the stop script to work properly the correct password and keystore have to be passed. The default values are shown next.

-kp=mserver -kl=server/kwebs/security/keystores/mserver.jks