Note

These docs are a work in progress. While conceptually correct, the diagrams/code samples on this page might not be 100% in line with the current implementation in Copper.

Transports

Modes

  • One-way (simplex)
  • Request/response (request-reply)
  • Events

Designs

Proxy - Client SDK

The use of proxies is a vital part of the inner working of Copper. It is what enables us to inject behaviors such as diagnostics, operation context and allow for user extensibility. It also decouples the user code, business logic, from any transport specific code.

As shown below, the proxy Copper uses a proxy without target for the client SDK. It adds a transport specific interceptor at the end, which enables switching transports without changing business logic or any other injected behavior.

Each of the different transports have their own implementation for this Transport client interceptor.

Listeners - Service SDK

Copper adheres to the same concepts as Azure Service Fabric. This means that it also has a listener concept. The concept of a listener is that you can expose a service via a listener, allowing it to receive requests from external parties.

Although the Azure Service Fabric implementation is very loose on the ICommunicationListener interface. E.g. this only has Open, Close and Abort. The listener concept in Copper is geared towards exposing a specific service through one of its facets (interface).

Messaging

Properties:

  • Queued interaction mode
    • Request/Response
    • One-way request
    • Events
  • Message Bus abstraction
    • MassTransit

Location transparency

The main benefit of location transparency is that it no longer matters where the resource is located. Because both parties connect to the same endpoint, the message bus, the exact location of a service is not needed, giving lots of flexibility in terms of hosting, and networking.

Competing consumer

Use a message queue to implement the communication channel between the application and the instances of the consumer service. The application posts requests in the form of messages to the queue, and the consumer service instances receive messages from the queue and process them. This approach enables the same pool of consumer service instances to handle messages from any instance of the application. The figure illustrates using a message queue to distribute work to instances of a service.

|||

Tooling

Sometimes there is the need to move messages from one queue to the next. E.g. re-submitting deadlettered messages to the live queue.

  • RabbitMQ Shovel plugin
  • Service Bus Explorer