Tamino offers three communication methods:
via a web server,
via direct HTTP rsp. HTTPS, or
WSL (webserverless)
The desired communication methods are specified via the database
property communication method
(see the table
"Server properties" in the Tamino Manager documentation,
section Database
Handling).
Communication is stateless: a client issues a request and receives a reply. A physical connection between client and X-Machine lasts only for the duration of a request.
The communication via web server is the default in that a newly created database
specifies 'XTS and TCP/IP' as the communication method
database property (see the table
"Server properties" in the Tamino Manager documentation,
section Database
Handling).
To communicate with Tamino as such a web server must be configured to redirect the user's HTTP (or HTTPS) calls towards Tamino as described in the section "Configuring the Web Server" in the chapter, section Before You Start Using Tamino. Whether the communication between the user and the web server is HTTP or HTTPS depends solely on the configuration of the server and has nothing to do with Tamino communication. Communication from the server towards Tamino is either via TCP/IP or via XTS. XTS-based communication can further be secured using SSL for encryption. The default communication here is XTS. XTS uses TCP/IP also.
In case of TCP/IP communication Tamino listens for incoming requests on the port
that is specified via the database property
XML port
(see table "Port properties"
in the Tamino Manager documentation, section
Database
Handling). The port number is assigned when the database
is created.
In case of XTS communication Tamino listens for incoming requests on the port
that is specified via the database property
XML XTS port
(see table "Port
properties" in the Tamino Manager documentation, section
Database
Handling). If the property is not specified, the server
picks a port when it is started. A typical use case where a port needs to be
specified is when client and database are on opposite sides of a firewall, so
that a port must be opened there.
A database name is resolved to an IP address and port number via a directory server. The database registers itself with the directory server at startup and deregisters at shutdown. A web server an and a database have to use the same directory server to be able to communicate.
The following database server properties are also relevant for working with XTS (see the table "Server properties" in the Tamino Manager documentation, section Database Handling):
Property Name | Meaning |
---|---|
overwrite XTS
registration |
If a database with the given name is already registered in the directory server, its registry entry is overwritten. |
server host
name |
The hostname that can be optionally entered into the directory server at server startup. |
The SSL communication method is identical to XTS, but the communication between the web server and the Tamino database is encrypted. For SSL the following properties are relevant.
Property Name | Meaning |
---|---|
SSL certificate file
registration |
The absolute path to a file containing an SSL certificate. |
SSL key
file |
The absolute path to a file containing an SSL key. |
SSL password |
Optionally, an SSL password. |
Tamino XML Server is able to act as an HTTP server of its own rights. Clients can communicate with Tamino using a native HTTP and/or HTTPS protocol.
This is achieved by configuring a server property communication method (e.g. "HTTP and HTTPS"). A valid port number has to be assigned to the server property HTTP port. Via this port, messages based on either HTTP or HTTPS protocol are communicated.
The contents of the HTTP requests and responses in respect to Tamino server request protocol is not affected by this method of communication.
The Tamino Mass Loader (inoload) communicates via XTS or alternatively via TCP/IP. Thus when the communication method does not involve either of the two, the loader can't operate.
For HTTPS the following properties are relevant.
Property Name | Meaning |
---|---|
SSL certificate file
registration |
The absolute path to a file containing an SSL certificate. |
SSL key
file |
The absolute path to a file containing an SSL key. |
SSL password |
Optionally, an SSL password. |
SSL certificate chain
verification depth |
Optionally, the maximum depth for the certificate chain verification. |
SSL CA
file |
Optionally, the absolute path to a CA (Certificate Authority) file. |
SSL cipher
list |
Optionally, a user defined cipher list for OpenSSL communication. Per default the server uses the cipher list "ALL:!ADH:RC4+RSA:!SSLv2:!LOW:!EXPORT:@STRENGTH". |
SSL verify
client |
Optionally, yes or no. |
The Tamino installation provides a self-signed certificate in the directory $INODIR/$INOVERS/files/certs that can be used to test HTTPS communication.
The Tamino APIs for Java and for C offer a webserverless option. Clients can communicate with Tamino without using HTTP. The communication method XTS must be configured in this case. Client and database have to use the same directory server to be able to communicate.