You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Those tools are all declarative, embracing the desired state pattern by allowing users to declare the desired infrastructure's status so that tools can move it from its current state to the new desired one.
NServiceBus endpoints don't play nicely in such an environment. As an alternative to installers, which are less than ideal in locked-down environments such as production, it would be desirable to have endpoints capable of describing, outputting, or allowing dependant packages to query the desired infrastructure state, including the names and attributes of the queues to be created, subscriptions and related topics/exchanges (depending on the transport of choice), database names and schema (depending on the persistence of choice) and all other supported features influencing the required infrastructure (e.g., if the Outbox is enabled, storage configuration is needed).
There is a dependency between NServiceBus and the downstream packages. Some of the information that NServiceBus is aware of is needed in downstream packages to determine the necessary infrastructure. For example, at runtime, NServiceBus knows the Outbox is enabled or that the endpoints contain sagas, and the downstream package knows the Outbox schema details or knows how to define the sagas schema. The same goes for queues or topics/exchanges, where some knowledge is in NServiceBus and some is in transport.
Additional Context
No response
The text was updated successfully, but these errors were encountered:
Describe the feature.
Is your feature related to a problem? Please describe.
Cloud environments support declarative resource deployment. For example, AWS supports Cloud Formation through tools such as AWS Cloud Development Kit (CDK) or HashiCorp Terraform.
Those tools are all declarative, embracing the desired state pattern by allowing users to declare the desired infrastructure's status so that tools can move it from its current state to the new desired one.
NServiceBus endpoints don't play nicely in such an environment. As an alternative to installers, which are less than ideal in locked-down environments such as production, it would be desirable to have endpoints capable of describing, outputting, or allowing dependant packages to query the desired infrastructure state, including the names and attributes of the queues to be created, subscriptions and related topics/exchanges (depending on the transport of choice), database names and schema (depending on the persistence of choice) and all other supported features influencing the required infrastructure (e.g., if the Outbox is enabled, storage configuration is needed).
There is a dependency between NServiceBus and the downstream packages. Some of the information that NServiceBus is aware of is needed in downstream packages to determine the necessary infrastructure. For example, at runtime, NServiceBus knows the Outbox is enabled or that the endpoints contain sagas, and the downstream package knows the Outbox schema details or knows how to define the sagas schema. The same goes for queues or topics/exchanges, where some knowledge is in NServiceBus and some is in transport.
Additional Context
No response
The text was updated successfully, but these errors were encountered: