Skip to main content.

Site Map

Site Map

Communication

A microservice should provide synchronous and asyncronous communication.

We provide (3) three communication protocols in our platform:

  • Synchronous Communication - Direct HTTP/HTTPS access to each microservice using a service client. Every microservice includes a client with token-based authentication for accessing the service.
  • Asynchronous Communication - We provide Service Bus integration for inter-process communication between microservies using Broadcasts. You can choose between single receiver (Queues) or multi-receiver (Topics and Subscriptions).
  • IntraProcess Communication - Our platform supports running multiple microservices in the same process eliminating network traffic.

Synchronous Communication

Synchronous communication involves realtime, direct HTTP/HTTPS access to a microservice. This could be client-to-server or microservice-to-microservice access. Microservices have built in security, so you must authenticate prior to calling a microservice method, unless it allows anonymous methods.

For each microservice we develop, we include an ApiClient interface and class in the ServiceBrick.Module.Api package. Each service client is derived from a base class that has built in token-based authentication processing. Prior to calling the service method, it will authenticate with the Service Brick Security Service to obtain a JWT token. This is a bearer token that is passed along with the API method request to authorize the client.

The following application settings define the API Configuration needed to access a microservice. When creating a client, it will first check for a Client configuration under its module first. If one isn't found, it will fallback to use the ServiceBrick:Client appsetting instead.

  • ServiceUrl - The base url to the service the client is calling
  • TokenUrl - The method to call for authentication to get the bearer token used for the service.
  • TokenType - password defines sending a registered user's email and password
  • TokenClient - The email address of the registered user.
  • TokenSecret - The password of the registered user.

{
    "ServiceBrick": {        
        "Logging": {
            "Client": {
                "ApiConfig": {
                    "ServiceUrl": "https://localhost:7000",
                    "TokenUrl": "https://localhost:7000/api/v1.0/Security/Authentication/AuthenticateUser",
                    "TokenType": "password",
                    "TokenClient": "email@servicebrick.com",
                    "TokenSecret": "MyPassword"
                }
            }
        },

        // This is the fallback config if the "[Brick/Module Name]:Client" key is not found above
        "Client": {
                "ApiConfig": {
                    "ServiceUrl": "https://localhost:7000",
                    "TokenUrl": "https://localhost:7000/api/v1.0/Security/Authentication/AuthenticateUser",
                    "TokenType": "bearer",
                    "TokenClient": "email@servicebrick.com",
                    "TokenSecret": "MyPassword"
                }
            }
    }
}

The following code shows how to obtain a client and create an object:


    public async Task MyExampleDependencyInjection(ILogMessageApiClient logMessageApiClient)
    {
        var msg = new LogMessageDto()
        {
            Application = "My App",
            Message = "Hello World"
        };
        var response = await logMessageApiClient.CreateAsync(msg);
    }

Asynchronous Communication

Asynchronous communication involves sending messages using a message broker, such as Azure Service Bus. Microservices should try to utilize asynchronous communication as much as possible for resiliency. We provide Service Bus integration for inter-process communication between microservies. You can choose between in-memory, single receiver (Queues) or multi-receiver (Topics and Subscriptions).

Access to your configured provider is handled through the IServiceBus interface. It is responsible for publishing Broadcasts which are domain/intergration events that cross service boundaries.

View our section on Eventing to learn more.

Intra-Process Communication

Our platform supports running multiple microservices on the same process for intra-process communication. Deploying two or more services together allows the ability to use the Business Rule Engine with Domain Events and Domain Processes for integration. This can eliminate network traffic completely for any chatty relationships between services.

A microservice only needs to include the ServiceBrick.Module.Api NuGet release package to access the interfaces for integration. This includes all built-in domain events for the platform. It just provides another solution that can be considered to develop your own custom microservice infrastructure.

View our section on Eventing to learn more.