General configuration (DMZ)
Lobster Integration has to be launched on the inner server and the CommunicationForwardManager on the DMZ server.
The administration of the partner channels is handled by the AuthenticationService.
The CommunicationLogService logs communication events in the database of Lobster Integration, for example, the arrival of a file via AS2 and its message ID, etc.
Special variants of both services are used on a DMZ server, as the DMZ is not equipped with a database for safety reasons: The MessageAuthenticationService and the MessageCommunicationLogService that exchange messages with the respective service of the inner server.
The MessageAuthenticationService in principle provides the same functionality to the DMZ server as the AuthenticationService on the inner server does. It is registered in the Service Factory of the DMZ servers (./etc/factory_dmz.xml) using the name AuthenticationService. The communication services, therefore, assume it is the AuthenticationService. This name can be changed in the configuration. The same is the case for the service pair MessageCommunicationLogService and CommunicationLogService.
The following diagram describes the cooperation between the MessageAuthenticationService on the DMZ server and its AuthenticationService on the inner server for receiving data via FTP using the DMZ server. This applies similarly to the MessageCommunicationLogService and the CommunicationLogService.
(1) The partner wants to upload a file using FTP via the DMZ server, which then will be processed by a profile. The FTP client connects to the FtpService of the DMZ server (port 21). The FTP service demands authentication from the client. The client sends the user name.
(2) The FtpService turns to its MessageAuthenticationService to enquire if an FTP channel is assigned to the partner and if so, which communication parameters are stored for the channel. The MessageAuthenticationService of the DMZ server forwards the request as a synchronous message to the inner server, because only this server manages the required information centrally.
(3) The MessageAuthenticationService contacts its MessageService to send the request via the configured message queue as a synchronous message. In the process, other information like the "defaultTarget" (IP and port) and the "defTargetService" (name of the inner AuthenticationService) can be handed over. Synchronous messages work using the request-response principle. The response is sent via the same queue. The MessageAuthenticationService is waiting for a response.
(4) The MessageService must know the route to the internal service (through configuration). If not configured, it inherits the routing information from the "defaultTarget", see (3). It hands over a synchronous message to the TCP/IP layer in order to send it to the remote interface of the MessageService of the inner server and waits for a reply.
(5) The TCP/IP layer of the DMZ server establishes a TCP connection to the IP address of the inner server using the destination port number. There, the remote interface of the MessageService of the inner server waits for connection requests.
(6) The firewall must allow the connection from the DMZ server to the remote interface of the inner MessageService.
(7) The connection is accepted by the remote interface and the message is being received. The TCP connection is kept alive to send back the reply.
(8) The remote interface hands the message over to the inner MessageService, which assigns it to the correct message queue. Thereby, it is handed over to the message consumers registered to this queue.
(9) The inner AuthenticationService has been registered as message consumer at this message queue by its parameter consumeMessages and receives the message with the request it contains.
(10) By accessing a database, a response is generated from the request and sent back as a message on the reverse path. After the reply has reached the DMZ server, it is delivered via the MessageService to the MessageAuthenticationService, which now can hand the requested communication parameters of the FTP channel over to the FtpService in order to accept or reject the login of the client. If no partner details are found for the client login or the request cannot be dealt with for different reasons, the login is rejected.
(11) After a successful login, the FtpService takes the file and sends it to the inner server via the MessageService. A different message queue is used than the one used by the AuthenticationService.
(12) If a matching profile is registered to this message queue, the file is sent to this profile for processing.
Note: Steps (11) and (12) are not covered here.
Note: After the standard installation of the DMZ server, everything is already pre-configured. The entries for the IP addresses in the following files need to be adjusted manually though.
./etc/startup.xml respectively ./etc/startup_dmz.xml
./etc/auth.xml respectively ./etc/auth_dmz.xml
./etc/commlog.xml respectively ./etc/commlog_dmz.xml