ForwardingConstructs are describing relationships between events and reactions.
Since we are dealing with REST servers,
- an event is a request, which has been received (Input) by one of the OperationServers offered by the application and
- the reaction is a request, which has to be sent (Output) via one of the OperationClients that are for addressing other applications.
Obviously, a definition of a ForwardingConstruct must comprise at least one Input (reference to an OperationServer) and at least one Output (reference to an OperationClient).
We are documenting the relationships, because we want to be able to modify them.
If we want to automate the modification (e.g. creating a subscription), there must be services available on the REST API for facilitating this.
In this case, the definition of a ForwardingConstruct needs also to comprise a Management (reference to an OperationServer).
Otherwise, the ForwardingConstruct would have to be altered by editing in the CONFIGfile.
Example:
The TypeApprovalRegister is subscribing for notifications about new registrations at the RegistryOffice.
A Forwarding from registration to notifying the TypeApprovalRegister has to be defined in the RegistryOffice.
This Forwarding has to comprise the following Servers and Clients:
- Management: The TypeApprovalRegister is informing the RegistryOffice about its TCP/IP address and OperationName for receiving notifications about new registrations by addressing the RegistryOffice's OperationServer /v1/inquire-application-type-approvals. The RegistryOffice creates or updates a stack of Clients with these information and it complements the corresponding ForwardingConstruct by an Output reference to the OperationClient.
- Input: Some new application is addressing the RegistryOffice's OperationServer /v1/register-application for registering.
- Output: The RegistryOffice is activating its OperationClient TypeApprovalRegister://v1/regard-application for sending the notification to the TypeApprovalRegister.
