Skip to Content
Last modified by Alexander Schulz-Rosengarten on 2023/07/11 10:33
From version 7.1
edited by uru
on 2013/12/04 01:10
Change comment: There is no comment for this version
To version 3.1
edited by msp
on 2012/04/23 13:36
Change comment: There is no comment for this version

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.uru
1 +XWiki.msp
Content
... ... @@ -1,3 +1,5 @@
1 +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.
2 +
1 1  = Download and Installation =
2 2  
3 3  If you want to use service-based layout inside your network, you can download the latest build of the server that fits to your platform from
... ... @@ -20,7 +20,7 @@
20 20  
21 21  = Setting required configuration options =
22 22  
23 -The server supports a set of configuration options. They are listed in [[Configuration options for the server>>doc:Configuration Options for the Server]]. For most of these the //default configuration//, which is part of the server, defines a default value. The one option that depends on your installation is the path to the {{code language="none"}}dot{{/code}} executable of the Graphviz package. Therefore you need to tell the server where it can find the package. In order to do so, you use the //provider configuration//. It is located in the file {{code language="none"}}kwebs.user{{/code}} in the root folder where you extracted the server to. For example, in the following listing the executable is located at {{code language="none"}}/usr/bin/dot{{/code}}:
25 +The server supports a set of configuration options. They are listed in [[Configuration options for the server>>url:http://trac.rtsys.informatik.uni-kiel.de/trac/kieler/wiki/Projects/KWebS/ConfigurationOptionsForTheServer||style="text-decoration: none;" shape="rect" class="wiki"]]. For most of these the //default configuration//, which is part of the server, defines a default value. The one option that depends on your installation is the path to the {{code language="none"}}dot{{/code}} executable of the Graphviz package. Therefore you need to tell the server where it can find the package. In order to do so, you use the //provider configuration//. It is located in the file {{code language="none"}}kwebs.user{{/code}} in the root folder where you extracted the server to. For example, in the following listing the executable is located at {{code language="none"}}/usr/bin/dot{{/code}}:
24 24  
25 25  {{code language="bash"}}
26 26  # Use this option to configure the path to the graphviz dot executable
... ... @@ -30,7 +30,8 @@
30 30  The next step is to decide which //service variants// you want to provide. There are three of them:
31 31  
32 32  * SOAP over HTTP,
33 -* SOAP over HTTPS
35 +* SOAP over HTTPS, and
36 +* jETI.
34 34  
35 35  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 available:
36 36  
... ... @@ -41,9 +41,11 @@
41 41  # Use this option to configure whether the JAXWS layout will be published HTTPS based
42 42  de.cau.cs.kieler.kwebs.jaxws.publishHttps=false
43 43  
47 +# Use this option to configure whether the layout will be published jETI based
48 +de.cau.cs.kieler.kwebs.publishJeti=true
44 44  {{/code}}
45 45  
46 -The next step is to define how the variants are being published. All variants per default only accept requests from {{code language="none"}}localhost{{/code}}. 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 {{code language="none"}}0.0.0.0{{/code}}, meaning that they accept incoming requests from any client. The SOAP over HTTP variant is bound to port {{code language="none"}}8442{{/code}} and the context {{code language="none"}}layout{{/code}}.
51 +The next step is to define how the variants are being published. All variants per default only accept requests from {{code language="none"}}localhost{{/code}}. 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 {{code language="none"}}0.0.0.0{{/code}}, meaning that they accept incoming requests from any client. The SOAP over HTTP variant is bound to port {{code language="none"}}8442{{/code}} and the context {{code language="none"}}layout{{/code}}. You cannot define a context for the jETI variant due to the proprietary nature of the transport protocol jETI uses.
47 47  
48 48  {{code language="bash"}}
49 49  # Use this option to configure the address, port and context under
... ... @@ -50,6 +50,13 @@
50 50  # which the SOAP variant will be published over HTTP
51 51  de.cau.cs.kieler.kwebs.jaxws.httpAddress=http://0.0.0.0:8442/layout
52 52  
58 +# Use this option to configure the address under which the jETI
59 +# variant will be published
60 +de.cau.cs.kieler.kwebs.jeti.server.hostname=0.0.0.0
61 +
62 +# Use this option to configure the port under which the jETI
63 +# variant will be published
64 +de.cau.cs.kieler.kwebs.jeti.connector.sepp.port=9867
53 53  {{/code}}
54 54  
55 55  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 {{code language="none"}}server/kwebs/security/keystores{{/code}} beneath the root directory of your server installation, the name of the key store is {{code language="none"}}server.jks{{/code}}. 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 ({{code language="none"}}client.jks{{/code}}). The server also contains a script ({{code language="none"}}GenerateCertsAndKeystores.sh{{/code}}) that allows you to generate these by yourself. You can find it in the folder {{code language="none"}}server/cmd{{/code}} beneath the root directory of your server installation. The script requires the presence of OpenSSL ([[http:~~/~~/www.openssl.org/>>url:http://www.openssl.org/||shape="rect"]]). 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>>url:http://www.openssl.org/related/binaries.html||shape="rect"]]).
Confluence.Code.ConfluencePageClass[0]
Id
... ... @@ -1,1 +1,1 @@
1 -8651412
1 +885184
URL
... ... @@ -1,1 +1,1 @@
1 -https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/KIELER/pages/8651412/Setting up Your Own Server
1 +https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/KIELER/pages/885184/Setting up Your Own Server