2.2. Introduction to Dynamic Delegation Discovery System (DDDS) infrastructure
2.2.1. Purpose of this guide
This guide is designed to provide you with an understanding of the DDDS. It explains the essential components required to set up DDDS infrastructure and their specific functions. It also highlights the benefits of integrating a DDDS into your message exchange networks.
We recommend reading this guide sequentially from start to finish, as each section builds upon the last to offer a complete overview. If you are already familiar with certain aspects, feel free to skip to sections of interest.
2.2.1.1. What you will learn
By the end of this guide, you will be equipped with the knowledge on how a DDDS operates. In particular, you will learn about the following:
-
Essential components required to set up DDDS infrastructure and their specific functions.
-
Benefits of integrating a DDDS into your message exchange networks.
2.2.2. Introduction
This guide walks you through the process of implementing Dynamic Delegation Discovery System (DDDS) infrastructure within message exchange networks, highlighting its advantages for business communication between different enterprises.
2.2.3. eDelivery Dynamic Discovery infrastructure
This section elaborates on the eDelivery Dynamic Discovery infrastructure, including its primary components:
-
Service Metadata Locator (SML)
-
Service Metadata Publisher (SMP)
-
Access Point (AP)
The guide uses a story-based approach to show how two enterprises can connect their information systems for exchanging business messages and then extend it to other business partners. This approach can help illustrate the reasons, purpose and benefits of using various components in the Dynamic Discovery infrastructure.
2.2.3.1. Business case
Meet Alice from ConnectGlobe and Bob from PerfectService. Both companies seek to enhance their communication by transitioning from email and paper mail to electronic invoicing and order placements through their information systems.
Alice wants to order goods from Bob and receive electronic invoices from him through her information system. Similarly, Bob wants to get orders from Alice and send her electronic invoices.
To achieve this, Alice and Bob agree to implement integration modules on top of their information systems. As a result, they get secure message exchanges over using HTTPS and TLS certificates. This not only streamlines communication but also lays the foundation for expanding their network.
This shift promises significant time and cost savings in processing business exchanges.
2.2.3.2. Reusing integration modules
The integration works very well for Alice and Bob. Alice wants to expand it to other business cases and message types.
Reusing a component greatly reduces the development and maintenance costs. Since the components are now loosely coupled, it makes it easier to maintain and develop new integration module features. It also allows different teams to be in charge of the integration or messaging service on the backend system.
In this situation, the backend team can focus on the content and processing of documents, while the integration team can focus on reliable and secure message exchange.
Decoupling of components also simplifies system maintenance and feature development, allowing for easier team management and potential outsourcing of the messaging service to a third-party provider. In consequence, Alice and Bob can replace the messaging service with new technologies and standards with minimal or no interruptions on the backend side.
2.2.3.3. Service Metadata Publisher (SMP)
Alice and Bob were happy with their integration and decided to invite their colleagues and other business partners to join them. At first, everything worked well, but as the number of partners increased, it became hard to maintain the configuration for each of them.
To manage the growing network and simplify configuration, Alice and Bob proposed a DDDS infrastructure layer to their messaging service, enabling automatic address and certificate retrieval for message exchanges. Behind that idea was an address book, similar to what Alice and Bob used internally for emails, looking up the address based on the receiver name or ID.
All the participants of the message exchange network would publish their addresses, certificates and other supported service capability metadata. Alice and Bob upgraded their Access Point with a Dynamic Discovery Client (DDC) enhancement that would look up the messages' recipient data and retrieve the missing information such as the receiver’s URL address and certificates.
This way Alice and Bob would not have to worry about collecting and maintaining the necessary transport data for the message exchange. They would just add the identifier of the recipients to the message, and the Access Point would find all the missing transport data from the address book and send the message to the right Access Point.
Because the "address book" contained the messaging service’s capabilities metadata, they renamed the component to Service Metadata Publisher (SMP).
2.2.3.4. Service Metadata Locator (SML)
Some of the partners already had their own SMP components, some were using them as a service offered by SMP providers. And since these partners were satisfied with their existing setup, they did not want to move over to the shared SMP component as this would bring more maintenance and operational costs.
Alice and Bob faced the challenge: how a DDC could find the right SMP component for the final recipient? They extended their DDDS infrastracture with the Service Metadata Locator (SML), a component designed to easily locate the appropriate SMP server for message recipients, using the Domain Name System (DNS).
The goal was also to make that SML component user-friendly and its job as simple as retrieving an HTML page in the web browser can be. When you enter the URL address in you browser, the HTTP request targets the right server though you don’t know the exact location of that server. Alice and Bob used the very same principle: DNS became the main technology of their SML service.
With this last component, everyone on the network could use their preferred SMP service instance or service provider. The network was ready to grow with new business partners.
2.2.4. Business domain owner
Every message exchange network has a community of participants that set up the network governance body, also known as the business domain owner.
The business domain owner, in our story represented by Alice and Bob, ensure the network is secure and efficient by taking care of the following:
-
Network purpose and objectives: What problems will it solve, what benefits will it bring to the participants? Who are targeted participants and what are their roles in the network?
-
Format and type of the participant identifiers: Who are the identifier providers and how to ensure the uniqueness of the identifiers?
-
Visibility of the network: Will it be open to the public or restricted to a specific community?
-
Types and structure of the documents they would exchange over the network, which is crucial for the backends to validate and process messages automatically.
-
Trust model of the network, to ensure authenticity, integrity and confidentiality of the messages. This is a combination of technical solutions and network policies.
-
How many SMP and SML providers there would be, who could operate them and how to ensure resources, sustainability and reliability of the services.
We will not go into more details on the business domain owner, but it’s important to know that this role is the key to the success of a network.
2.2.5. Delegated Dynamic Discovery process
This chapter provides an overview of how the Delegated Dynamic Discovery process works using all the described components.
2.2.5.1. Registering participant
Before a new participant in the network (called "party") can start sending and receiving messages, it needs to do the following:
-
Obtain its own unique identifier in the network. This identifier will be used to address the party and to locate its services. The party can then choose the AP and SMP service providers. The party can reuse existing AP/SMP service providers or develop/set up its own instances and register them in the network.
-
Register a unique identifier with the SMP service. The SMP adds the entry to the SML to bind the participant identifier to the SMP instance. This way anyone looking for the party’s data will be redirected to the dedicated SMP instance.
-
Start publishing on the selected SMP services/message types it can accept, along with the Access Point URL and transport certificates.
2.2.5.2. Submitting message
Here is a step-by-step explanation on how a network uses the delegated dynamic discovery process to submit a message from the sender to the recipient:
-
Create the message: The sender creates the message, assigning the recipient’s unique identifier as the receiver.
-
Send to Access Point (AP): The message is sent to the sender’s AP. At this stage, the sender’s AP lacks the recipient’s delivery details.
-
Query with Dynamic Discovery Client (DDC): To find the recipient’s details, the sender’s AP uses the DDC to query the Service Metadata Locator (SML) using the recipient’s identifier.
-
Retrieve SMP address data: The SML responds with the address of the recipient’s SMP, which holds their AP URL and certificate.
-
Verify data integrity and authenticity: Before proceeding, the sender’s AP checks the integrity and authenticity of the retrieved data.
-
Message delivery to recipient’s AP: Equipped with the necessary details, the sender’s AP delivers the message to the recipient’s AP.
-
Recipient’s AP validation: Upon receipt, the recipient’s AP validates the sender’s message for integrity and authenticity. If validated, the message is accepted.
-
Message retrieval by recipient: Finally, the recipient fetches the message from their AP, completing the exchange process. :toc: