DE4A Connector - Revision history

Javier.ferrero: Removed the link at the bottom of the page to the installation guide.

2022-02-24T10:18:23Z

Removed the link at the bottom of the page to the installation guide.

Mpttfp ismael.magdaleno: /* Installation and configuration */ Link added

2022-02-23T13:35:36Z

Installation and configuration: Link added

Mpttfp ismael.magdaleno: Links added

2022-02-23T13:28:47Z

Links added

Mpttfp ismael.magdaleno: Space added

2022-02-23T13:26:44Z

Space added

Mpttfp ismael.magdaleno at 13:24, 23 February 2022

2022-02-23T13:24:39Z

Mpttfp ismael.magdaleno: Link fixed

2022-02-23T13:23:40Z

Link fixed

Mpttfp ismael.magdaleno: Link added

2022-02-23T13:20:31Z

Link added

Show changes

Mpttfp ismael.magdaleno: /* Installation and configuration */ Link added

2022-02-23T13:17:30Z

Installation and configuration: Link added

Antonio.osuna at 15:35, 22 February 2022

2022-02-22T15:35:15Z

Antonio.osuna at 12:34, 22 February 2022

2022-02-22T12:34:17Z

@@ Line 258: / Line 258: @@
 *'''In-house solutions'''
 The Connector project includes some utilities that allow the data processing and internal tools to perform all the Connector tasks. Those utilities are within the Connector project as a module called ''de4a-commons.''
 [[Category:Wip]]

@@ Line 1: / Line 1: @@
-The DE4A Connector is a technical proxy that allows the final participants (DE or DO) to send requests for evidence or responses to other final participants over an [[Usage of third party specifications and components|eDelivery]] communication environment. In addition, to handle the message exchange process, the Connector is responsible for obtaining the message routing information, by exchanging information with external components such as the [[IDK]], the [[Usage of third party specifications and components|SML/DNS]] or the [[SMP]].
+The DE4A Connector is a technical proxy that allows the final participants (DE or DO) to send requests for evidence or responses to other final participants over an [[Usage of third party specifications and components|eDelivery]] communication environment. In addition, to handle the message exchange process, the Connector is responsible for obtaining the message routing information, by exchanging information with external components such as the IDK, the [[Usage of third party specifications and components|SML/DNS]] or the [[SMP]].
 To do so, it provides a common interface to DEs and DOs, making the complexity of the system transparent to the final participants and integration easier.
@@ Line 6: / Line 6: @@
 The security and integrity of messages, as well as the unique identification of the participants involved, are the cornerstones of the Connector component.
 [[File:De4a-schema-it1.png|Conceptual schema of the target DE4A system for the first iteration|alt=|center|frame]]

@@ Line 1: / Line 1: @@
-The DE4A Connector is a technical proxy that allows the final participants (DE or DO) to send requests for evidence or responses to other final participants over an [[Usage of third party specifications and components|eDelivery]] communication environment. In addition, to handle the message exchange process, the Connector is responsible for obtaining the message routing information, by exchanging information with external components such as the IDK, the [[Usage of third party specifications and components|SML/DNS]] or the SMP.
+The DE4A Connector is a technical proxy that allows the final participants (DE or DO) to send requests for evidence or responses to other final participants over an [[Usage of third party specifications and components|eDelivery]] communication environment. In addition, to handle the message exchange process, the Connector is responsible for obtaining the message routing information, by exchanging information with external components such as the [[IDK]], the [[Usage of third party specifications and components|SML/DNS]] or the [[SMP]].
 To do so, it provides a common interface to DEs and DOs, making the complexity of the system transparent to the final participants and integration easier.
-The Connector component provides the AS4 Gateway functionality, so it can assume both the role of Data Requestor and Data Transferor. This first approach makes the Connector a stand-alone web application that can be deployed on any suitable application server. As an alternative, the Connector can make used of an external AS4 Gateway to provide the message exchange feature, in which case two components should be deployed: the DE4A Connector along with the chosen AS4 Gateway (i.e. Domibus).
+The Connector component provides the [[AS4 Gateway]] functionality, so it can assume both the role of Data Requestor and Data Transferor. This first approach makes the Connector a stand-alone web application that can be deployed on any suitable application server. As an alternative, the Connector can make used of an external AS4 Gateway to provide the message exchange feature, in which case two components should be deployed: the DE4A Connector along with the chosen AS4 Gateway (i.e. Domibus).
 The security and integrity of messages, as well as the unique identification of the participants involved, are the cornerstones of the Connector component.

@@ Line 6: / Line 6: @@
 The security and integrity of messages, as well as the unique identification of the participants involved, are the cornerstones of the Connector component.
 [[File:De4a-schema-it1.png|Conceptual schema of the target DE4A system for the first iteration|alt=|center|frame]]
 == Functionalities provided ==

@@ Line 256: / Line 256: @@
 The Connector project includes some utilities that allow the data processing and internal tools to perform all the Connector tasks. Those utilities are within the Connector project as a module called ''de4a-commons.''
-==[[Installation and configuration guide|Installation and configuration]]==
+==Installation and configuration==
-Follow the link to [[Installation and configuration guide|Installation and configuration]].
+Follow the link to the [[Installation and configuration guide|Installation and configuration]] guide.
 [[Category:Wip]]

@@ Line 1: / Line 1: @@
-The DE4A Connector is a technical proxy that allows the final participants (DE or DO) to send requests for evidence or responses to other final participants over an eDelivery communication environment. In addition, to handle the message exchange process, the Connector is responsible for obtaining the message routing information, by exchanging information with external components such as the IDK, the SML/DNS or the SMP.
+The DE4A Connector is a technical proxy that allows the final participants (DE or DO) to send requests for evidence or responses to other final participants over an [[Usage of third party specifications and components|eDelivery]] communication environment. In addition, to handle the message exchange process, the Connector is responsible for obtaining the message routing information, by exchanging information with external components such as the IDK, the [[Usage of third party specifications and components|SML/DNS]] or the SMP.
 To do so, it provides a common interface to DEs and DOs, making the complexity of the system transparent to the final participants and integration easier.
@@ Line 14: / Line 14: @@
 === Dynamic discovery of Services ===
-In order for the Connector to be able to send a message to the corresponding endpoint, the eDelivery dynamic discovery mode of operation is used. This operation mode is based on the use of the SML/DNS and SMP components of the eDelivery infrastructure. The main elements stored in the SML/DNS and SMPs for this purpose are the following:
+In order for the Connector to be able to send a message to the corresponding endpoint, the [[Usage of third party specifications and components|eDelivery]] dynamic discovery mode of operation is used. This operation mode is based on the use of the [[Usage of third party specifications and components|SML/DNS]] and SMP components of the eDelivery infrastructure. The main elements stored in the SML/DNS and SMPs for this purpose are the following:
-* ''ParticipantIdentifier'': The Data Owner/Data Evaluator identifier who is publishing its AS4 communication point (of the Connector linked to it).
+* ''ParticipantIdentifier'': The Data Owner/Data Evaluator identifier who is publishing its [[Usage of third party specifications and components|AS4]] communication point (of the Connector linked to it).
 * ''DocumentTypeIdentifier'': Canonical evidence type.
 * ''ProcessIdentifier'': Orchestration type (request/response).
@@ Line 29: / Line 29: @@
 * Response signature validation is mandatory.
 * The communication between SMP and SML requires the usage of a client certificate.
-The service metadata lookup will be performed as a step prior to the AS4 message exchange. Therefore, the participant IDs and other related information must be known by the Connector in advance.
+The service metadata lookup will be performed as a step prior to the [[Usage of third party specifications and components|AS4]] message exchange. Therefore, the participant IDs and other related information must be known by the Connector in advance.
 === Supported interaction patterns ===
@@ Line 59: / Line 59: @@
 === AS4 implementations ===
-The message exchange is built on the AS4 protocol, which is an open standard for secure, payload-agnostic business-to-business document exchange via web services. Secure document exchange is governed by WS-Security aspects, including XML Encryption and XML Digital Signatures.
+The message exchange is built on the [[Usage of third party specifications and components|AS4]] protocol, which is an open standard for secure, payload-agnostic business-to-business document exchange via web services. Secure document exchange is governed by WS-Security aspects, including XML Encryption and XML Digital Signatures.
 There are many implementations of AS4, but the Connector currently implements phase4 and Domibus.
@@ Line 65: / Line 65: @@
 * '''Main features'''
-** It is a generic AS4 solution.
+** It is a generic [[Usage of third party specifications and components|AS4]] solution.
 ** It can be integrated in basically any Servlet-based application server.
 ** It can easily be used with Peppol.
@@ Line 83: / Line 83: @@
 ** It is maintained by the European Commission.
 ** It manages the participants’ information and the end-to-end communication parameters.
-** It is conceived as an eDelivery Access Point (external platform).
+** It is conceived as an [[Usage of third party specifications and components|eDelivery]] Access Point (external platform).
 * '''Implementation'''
@@ Line 94: / Line 94: @@
 === Kafka messages ===
-Within the data flow and message exchange, there are many key points where it is important to know how the data is being managed, as well as identifying intermediate errors and unhandled system states. In this respect, the Connector can send messages to a Kafka server to track the data flow and trace the state of the system at certain points.
+Within the data flow and message exchange, there are many key points where it is important to know how the data is being managed, as well as identifying intermediate errors and unhandled system states. In this respect, the Connector can send messages to a [[Usage of third party specifications and components|Kafka]] server to track the data flow and trace the state of the system at certain points.
 This feature is an advantage from a technical and business point of view, as the Connector performs the message exchange transparently to the other components.
@@ Line 101: / Line 101: @@
 ==== Message types ====
-The Connector implements a Kafka message producer through the de4a-kafka-client library of the de4a-commons package. This producer provides several types of messages or severity levels:
+The Connector implements a [[Usage of third party specifications and components|Kafka]] message producer through the de4a-kafka-client library of the de4a-commons package. This producer provides several types of messages or severity levels:
 * '''Success'''
@@ Line 111: / Line 111: @@
 ==== List of messages ====
-The messages currently sent from the Connector to the Kafka server are as follows:
+The messages currently sent from the Connector to the [[Usage of third party specifications and components|Kafka]] server are as follows:
 '''Services''' – ''(Info level)''
@@ Line 161: / Line 161: @@
 The message exchange performed by the Connector has been conceived to ensure different security aspects as:
-*'''Authenticity''': ensures the identity of the participant entities and any common component involved in the message exchange. It is achieved through the participant identifiers definition [9], eDelivery specification and AS4 implementations.
+*'''Authenticity''': ensures the identity of the participant entities and any common component involved in the message exchange. It is achieved through the participant identifiers definition, [[Usage of third party specifications and components|eDelivery]] specification and [[Usage of third party specifications and components|AS4]] implementations.
 * '''Integrity''': refers to the accuracy and completeness of data. Security controls focused on integrity are used to prevent data from being modified or misused by an unauthorized party, provided by the WS-security and XML message signature.
@@ Line 202: / Line 202: @@
 *Services metadata querying
 *In the SMP data exchange a message signature validation is being performed to maintain the content reliability. This validation consists of verifying the embedded signature on the message against the trust certificate configured in the Connector for that purpose.
-The signature of incoming AS4 messages is verified against the central AS4 Gateway CA globally used in DE4A project, internally validated by the implementation libraries that handle the reception and delivery.
+The signature of incoming AS4 messages is verified against the central [[Usage of third party specifications and components|AS4]] Gateway CA globally used in DE4A project, internally validated by the implementation libraries that handle the reception and delivery.
 ==Technology used==

← Older revision		Revision as of 12:34, 22 February 2022
Line 658:		Line 658:

	<code>/requestTransferEvidenceUSIDT</code>		<code>/requestTransferEvidenceUSIDT</code>
		+	[[Category:Wip]]