| Name |
Description |
| CommandProcessorBuilder |
Class CommandProcessorBuilder. Provides a fluent interface to construct a CommandProcessor. We need to identify the following dependencies in order to create a CommandProcessor - A HandlerConfiguration containing a IAmASubscriberRegistry and a IAmAHandlerFactory. You can use SubscriberRegistry to provide the IAmASubscriberRegistry but you need to implement your own IAmAHandlerFactory, for example using your preferred Inversion of Control (IoC) container
- A IAmAPolicyRegistry containing a list of policies that you want to be accessible to the CommandProcessor. You can use PolicyRegistry to provide the IAmAPolicyRegistry. Policies are expected to be Polly !:https://github.com/michael-wolfenden/Polly Policy references. If you do not need any policies around quality of service (QoS) concerns - you do not have Work Queues and/or do not intend to use Polly Policies for QoS concerns - you can use NoPolicy to indicate you do not need them.
- A ILog that is the logger to use for diagnostic feedback. ILog is defined by LibLog !:hhttps://github.com/damianh/LibLog as an abstraction over logging frameworks and allows us to support your preferred logging framework
- A MessagingConfiguration describing how you want to configure Task Queues for the CommandProcessor. We store messages in a IAmAMessageStore for later replay (in case we need to compensate by trying a message again). We send messages to a Task Queue via a IAmAMessageProducer and we want to know how to map the IRequest (Command or Event) to a Message using a IAmAMessageMapper using an IAmAMessageMapperRegistry. You can use the default MessageMapperRegistry to register the association. You need to provide a IAmAMessageMapperFactory so that we can create instances of your IAmAMessageMapper. You need to provide a IAmAMessageMapperFactory when using MessageMapperRegistry so that we can create instances of your mapper. If you don't want to use Task Queues i.e. you are just using a synchronous Command Dispatcher approach, then use the NoTaskQueues method to indicate your intent
- Finally we need to provide a IRequestContext to provide context to requests handlers in the pipeline that can be used to pass information without using the message that initiated the pipeline. We instantiate this via a user-provided IAmARequestContextFactory. The default approach is use InMemoryRequestContextFactory to provide a RequestContext unless you have a requirement to replace this, such as in testing.
|
| DefaultPolicy |
Class DefaultPolicy We use Polly policies to provide Quality of Service. By default we provide them for a Task Queue and require you to register policies with The is a default policy which will retry once only. If you want better control over retries please use the PolicyRegistry to respectively determine retry attempts for putting onto and popping off the queue and for breaking the circuit if we cannot You can register additional policies (or reuse these) to provide QoS for individual handlers. The UsePolicyAttribute and ExceptionPolicyandler provide an easy way to do this using the policies that you add to this registry This is a default implementation of IAmAPolicyRegistry |
| HandlerConfiguration |
Class HandlerConfiguration |
| InMemoryRequestContextFactory |
Class InMemoryRequestContextFactory Creates a RequestContext that can be passed between pipeline stages. The RequestContext created is transient and has a lifetime of the pipeline itself. |
| InputChannel |
Class InputChannel. An IAmAChannel for reading messages from a Task Queue and acknowledging receipt of those messages |
| LifetimeScope |
|
| MessageFactory |
Used to create off-the-shelf messages: empty, and quit, used to control processing. |
| MessageRecoverer |
Class MessageRecoverer. Used to support reposting a message from a IAmAMessageStore{T} to a broker via IAmAMessageProducer |
| MessagingConfiguration |
Class MessagingConfiguration. Used to set the components of a work queue solution |
| OutputChannel |
Class OutputChannel. An IAmAChannel for reading messages from a Task Queue and acknowledging receipt of those messages |
| Reply |
Class Reply. Used for a Command that is a Reply in a Request-Reply exchange. Brighter supports publish-subscribe as its main approach to producers and consumers, but it is possible to support request-reply semantics as well. The key is that the sender must include a ReplyAddress in the Request (the IAmAMessageMapper then populates that into the MessageHeader as the replyTo address). When we create a Reply then we set the ReplyAddress from the Request onto the Reply and the IAmAMessageMapper for the Reply sets this as the topic so that it is routed correctly. |
| ReplyAddress |
Class ReplyAddress. The addrees to reply to when doing request-reply and not publish-subscribe |
| Request |
Class Request. Used for a Command that is a Reply in a Request-Reply exchange. Brighter supports publish-subscribe as its main approach to producers and consumers, but it is possible to support request-reply semantics as well. The key is that the sender must include a ReplyAddress in the Request (the IAmAMessageMapper then populates that into the MessageHeader as the replyTo address). When we create a Reply then we set the ReplyAddress from the Request onto the Reply and the IAmAMessageMapper for the Reply sets this as the topic so that it is routed correctly. |
