Questions and Answers
Question 1: Does current Domibus ‘Split and Join’ implementation use MessageFragment concept based on OASIS ebXML Messaging Services Version 3.0: Part 2, Advanced Features Specification ?
Answer: Yes, Domibus implements Split and Join based on OASIS ebXML Messaging Services Version 3.0: Part 2, Advanced Features
Question 2: Are you aware of any Domibus limitations for messages up to 2 GB if not using the ‘Split and Join’ profile enhancement e.g. minimum environmental requirements, file types, preferred file formats ?
Answer: We have noticed that Domibus needs 3-4 times of RAM memory than the exchanged message size at a certain point in time. For instance to exchange 1 GB, Domibus needs 3-4 GB of memory, 2 GB Domibus needs 6-8 GB of memory, etc. There are no limitations regarding file types or file formats.
Question 3: Are you aware of any Domibus limitations for messages over 2 GB if using the ‘Split and Join’ profile enhancement e.g. minimum environmental requirements, file types, preferred file formats, compression method. ?
Answer: When using Split and Join, the same limitation at point 2 still applies for message fragments. There might be limitations not related to Domibus but related to infrastructure involved in exchanging the large files. Eg forward proxy, load balancer, reverse proxy, WAF, etc. must be able to support large files.
Question 4: Have you done any performance tests for Domibus ‘Split and Join’ implementation vs standard up to 2GB mechanism
Answer: Unfortunately we don't have performance tests to compare Split and Join with standard mechanism up to 2 GB. We are planning to perform such tests in the future.
Question 5: Does Domibus ‘Split and Join’ implement any verification process for transfer completeness?
“Sum of parts = Original object” e.g. hash function or/and attributes comparison
Answer: In the Split & Join protocol only fragments are signed and NRR-acknowledged. There is no separate signature on the source message and no non-repudiation receipt. Non-repudiation of signing for the Source Message is obtained by transitivity (or by "assembling") by considering the sum of the non-repudiation of signing on each piece (fragment). You can find more information about the integrity and encryption applied in Split and Join in eDelivery profile 1.15 section 4.6.5 and in the document created following the public consultation.
Question 6: Does Domibus ‘Split and Join’ implement any mechanism to protect message’s integrity and confidentiality ?
Answer: Yes, please check previous Answer 5.
Question 7: Does Domibus ‘Split and Join’ implement any error management process ?
Answer: Yes, the error management implemented for Split and Join is according to the eDelivery profile 1.15 section 4.6.4. Error Handling.
Question 8: Does Domibus ‘Split and Join’ implement any retry/non duplicate management process ?
Answer: Yes, the retry/non duplicate management process is ensured for the message fragments in the same way as it is implemented for normal UserMessages.
Question 9: Does PMode configuration needs to be adjusted in case of if using the ‘Split and Join’ ?
Answer: Yes, a splitting configuration must be created to specify the fragment size, if compression is used for the message fragments and the join interval. Then this splitting configuration must be applied for the leg configuration for which you want to activate it. You can find here a Pmode with a splitting configuration.
Question 10: Do you provide a Domibus test environment? Any dedicated instance ?
Answer: We don't have a test environment to test Split and Join functionality. But you can setup two Domibus instances in your environment to exchange messages with Split and Join.
Question 11: How should we handle the retry of sending a message from a application to ActiveMQ if the ActiveMQ server is down ?
Description:
When the backend submits messages to domibus, the backend receives acknowledgement in the reply queue, so the backend is sure that the message was accepted/rejected by domibus. We are thinking about the same solution while submitting a message from domibus to the backend.
Please consider such a situation: Domibus receives a message from another access-point by AS4, then it forwards to ActiveMQ to pass the message to the backend. ActiveMQ stores the message in persistent-store and the whole cluster of ActiveMQ is killed (e.g. the electricity pipe is broken). As we checked, in the Domibus the message is marked as delivered, but the backend does not contain the message.
Do you have any option to send it to the backend again? Have you implemented any resilience or acknowledge pattern here?
Answer 12: The JMS message stays in the JMS queue until it is consumed by your backend, there should not be any loss even if electricity is down. Are you using a transaction manager in your backend when you consume messages from ActiveMQ?
Question 13: Do you use local ‘XadES keystore’ for AS4 payload signing process? Is exist possibility to use cloud service in type of SimplySign for AS4 payload signing ?
Answer: Domibus does not support XAdES signature nor cloud service providers for signing. If you would like see support in Domibus for such features please submit a change request.
Question 14: Do you use Discovery or any other services supporting dynamic discovery of AS4 services ? (C2-C3 communication)
Answer: Yes, Domibus can be configured to use dynamic discovery when sending and/or receiving messages. Please check the profile enhancements 4.3. Dynamic Receiver and 4.4. Dynamic Sender in eDelivery profile 1.15 .
Question 15: Based on our knowledge Domibus itself is based on SOAP and the messages for the C1 and C4 interfaces are similar to those of AS4 when it comes to Stubs. Do you recommend the API in the 4C model (C1-C2) and (C3-C4) to be based on SOAP, according to the documentation it is not necessary, what is your opinion and experience on this topic ?
Answer: I think you are referring to the WS Plugin interface which resembles a lot the AS4 syntax. Please note that even if it resembles a lot, the WS Plugin interface is proprietary and can evolve independently. Domibus supports 3 interfaces: Soap Web service in the WS Plugin, JMS in the JMS Plugin and file system in the FS Plugin. You can also implement another interface in a custom plugin. Choosing a specific interface depends on a lot of factors and we can only make a recommendation in a case by case scenario.
Question 16: Is it possible to acquire information on the flow of processing attachments larger than 15MB (I'm talking about the target 2GB here), have you performed any performance tests using attachments of this size, Do you allow for encrypting and signing these messages in accordance with e.g. OASIS specification.
What type of key was used to perform the crypto operations listed above, i.e. a key available within the infrastructure (software/hsm) or via a cloud service.
Answer: There is not difference between exchanged messages of 15 MB or 1 GB, all messages are signed and encrypted. We did performance tests with smaller payloads using a private and public keys stored in local JKS files. Starting with 5.0, Domibus can reliably handle a throughput of more than 1,000 messages/s* and, with added support for table partitioning, ensures this high level of performance even as the size of the database increases. These results were measured during a 2-hour period with Domibus working in single-tenancy mode, deployed in a 4-node cluster, using Oracle WebLogic Server and Oracle Database, with a message size of 5 kB, configured to receive 500 messages/s and send 1,000 messages/s. The performance results are dependent on several variables, such as message size, data base disk speed, RAM, etc.
Question 17: What kind of mechanism do you use to store attachments? Could you clarify differences between Domibus 5.0 vs 5.0.2 ?
https://ec.europa.eu/digital-building-blocks/code/projects/EDELIVERY/repos/domibus/browse/Domibus-MSH/src/main/java/eu/domibus/core/payload/persistence/filesystem/PayloadFileStorage.java?at=refs%2Ftags%2F5.0.2
Answer: Domibus supports two ways to store attachments: database or file system. For large files we recommend storing the payloads on the file system. There is no difference on how the payloads are stored between Domibus 5.0 vs 5.0.2
Question 18: Why is the Bus used for domain communication? refers to the bus (Bus) from the apache-cxf stack, it is used to receive/transmit messages in the cluster
Answer: The Bus is a concept specific to Apache CXF library is not a traditional Bus that is used to integrate systems or receive/transmit messages in the cluster.