In supply chains the chain of business activities starts when a Seller and Buyer agree upon the transaction. This agreement typically includes terms related to transport, insurance, customs, the handover of responsibilities, and payments. The successful execution of this agreement often requires coordination among a large set of actors, including authorities and their subcontractors. This coordination is managed through a “choreography” of actions, where each action is triggered by planned or executed events.

Subcontractors and principals

In this context, the Seller and Buyer serve as the Principals, each responsible for their part of the agreement. Typically, each Principal selects preferred contractors to fulfil their portion of the agreement. These main contractors, in turn, become Principals to their own subcontractors, and this chain continues down the line.

The key challenge here is distributing notifications within this dynamic and temporary data exchange network, to ensure effective and efficient coordination of activities.

Provisioning an instance

The BDI framework assumes that commercial relationships between Principals and Subcontractors are established before any actual orders are placed. In this setup, URLs are known, and through the DNS  discovery mechanism, the URIs of endpoints for each party are also known. Digital identity and trust are established within the respective associations of each party.

Each Principal is responsible for provisioning a temporary network of subcontractors associated with a specific order.

Bootstrapping

The Principal publishes a specific notifications to a subcontractor, with metadata on “ Request order” . The data accessed by the subcontractor includes the details of the order request. The subcontractor responds with a notification containing metadata on order acceptance. The Principal then accesses the data to confirm the subcontractor’s acceptance and any additional details provided.

Common Order Log

Upon confirmation, the Principal adds the subcontractor as a subscriber to the common Order Log and posts this event in the Common Order Log. The Common Order Log creates notifications to all relevant parties when an event is posted. The principal posts relevant events from all parties to the Common Order Log,  ensuring that all relevant parties are informed of relevant events.

Closed Network

To secure and streamline interactions within the temporary network, the Principal sends a JWT (JSON Web Token) to the subcontractor. This JWT contains:

• Order Information: Specific details about the order.
• Role of the Subcontractor: Defining the subcontractor’s role within the order.
• Data Access Rights: Permissions tied to the subcontractor’s role, aligned with an agreed-upon or standardized semantic model.

The subcontractor uses this JWT token when interacting with other subcontractors within the context of the order. This token allows other subcontractors to:

• Validate the Subcontractor’s Role: Confirming that the subcontractor is part of the temporary network set up by the Principal.
• Verify Access Rights: Ensuring that the subcontractor has the appropriate rights to access data associated with the order.

The Principal repeats this process with all subcontractors until the provisioning of the network is complete.

Closing the Order and Dissolving the Network

Once all tasks related to the order have been executed, the Principal initiates the closure of the order by:

• Distributing a Closure Notification: Informing all parties that the order is complete.
• Removing Subscriptions: Subscriptions to the Order Log are removed after a specified period.
• Revoking JWT Tokens: Invalidating the JWT tokens to dissolve the temporary network.

This process ensures the temporary network is securely dismantled, preserving the integrity and confidentiality of the data exchanged during the order’s execution.