Forcing Asynchrony in Java Services for Baratine

Baratine server for micro-services - one of the most unusual platforms on which I had the opportunity to work. The design of this server is based on several principles that complement each other.

• Asynchronous service interfaces
• Making service calls in a single thread
• Unrequited ownership of data
• Asynchronous Web
• Asynchronous service execution platform
  
  

  Asynchronous service interfaces

Baratine's micro services are described by interfaces. The interface defines the operations provided by the service. A feature of the asynchronous interface is that the interface methods return the result asynchronously, like the Future object.

For example, a familiar interface for a credit card payment transaction might look like this:

public interface CreditService { PaymentStatus pay(int amount, CreditCard card); } 

This method returns the result when the payment is made, and the code using it looks like this:

 CreditService _creditService; PaymentStatus executePayment(int amount, Client client) { return _creditService.pay(amount, client.getCreditCard()); } 

The asynchronous interface does not return a result, but populates the Future – object asynchronously:

 public interface CreditService { void pay(int amount, CreditCard card, Result<PaymentStatus> result); } 

Custom code for such an interface might look like this:

 CreditService _creditService; void executePayment(int amount, Client client, Result<PaymentStatus> result) { return _creditService.pay(amount, client.getCreditCard(), result.then()); } 

The peculiarity of this client code is that the code transfers its Future object to the final Payment service using result.then ().

In cases where the client needs to further process the result, you can use the lambda, which will be called upon filling in the result:

  void executePayment(int amount, Client client, Result<PaymentStatus> result) { _creditService.pay(amount, client.getCreditCard(), result.then( status -> { log(status); return status; } )); } 

At first glance, asynchronous interfaces may not seem very convenient, but this organization of code allows you to quickly release threads to perform the following tasks, and customers get results on their readiness.

Making service calls in a single thread

Micro services in Baratine run in one dedicated to this service stream. The flow is allocated to the service immediately upon the appearance of calls. In general, calls to the service come from a variety of clients. Calls are placed in a queue and executed sequentially by one dedicated thread.

In this context, it should be noted that services should be written in such a way as not to occupy the thread while waiting for the execution of operations. To do this, use Future – objects of type io.baratine.service.Result (see above). They allow you to transfer the processing of the result of calling expensive blocking operations to the future.

For example, payment using a checking account can take several hours, and the user payment initiation code will be executed in real time in fractions of a millisecond.

 CheckingService _checkingService = ...; void executePayment(int amount, Client client, Result<PaymentStatus> result) { _checkingPayment.pay(amount, client.getCheckingAccInfo(), result.then( status-> { log(status); if (status.isAppoved()) { shipGoods(); } else { handleFailedPayment(status); } } )); ); } 

In the above code, the execution of the lambda of the then () call will be delayed until _checkingService returns the payment result, and the executePayment () method will immediately become available for the next call.

Execution in a single thread has a positive effect on performance by reducing the number of context changes and good coordination with the processor cache.

Unrequited ownership of data

Owning write access to a master copy is one of the distinguishing features of the micro-services architecture on Baratine . Since the micro service handles calls sequentially rather than in parallel, data can be stored in the memory of a single instance of the service and is always the last, most current copy of the data.

(In this case, the use of the word "copy" is not entirely appropriate and is used idiomatically).

The micro data service has an extended life cycle in which, before the service goes into use, Baratine executes the service method with the @OnLoad annotation or loads instance fields from the asynchronous object database (Kraken) that is part of Baratine .

A micro service supported by data can represent a system user as follows:

 @Asset public class User { @Id private IdAsset _id; private UserData _data; } 

In the above code, the UserData instance with the user data will be loaded from Kraken.

Asynchronous Web

To achieve speed and better interfacing with asynchronous services, the principle of asynchrony subordinated to itself and the execution of Web requests. This is achieved by using the Future – object for the answer.

io.baratine.web.RequestWeb, like io.baratine.service.Result, provides an opportunity to postpone filling out the answer until the response data is ready.

For example, the code for a request using the REST protocol might look like this:

 @Service public class QuoteRestService { QuoteService _quotes; @Get public void quote(@Query("symbol") String symbol, RequestWeb requestWeb) { _quotes.quote(symbol, requestWeb.then(quote -> quote)); } } 

In the above code, the quote () method is annotated with Get and makes the method available for Web requests. In the Baratine platform, a single instance of the service responds to all incoming requests in the same thread reserved for this service. In this architecture, performance is achieved by a quick return from the quote () method by delegating a request-specific operation to a specific quote service responsible for Quotes - QuoteService.

Asynchronous service execution platform

In the process of working on the platform, the tendency of asynchrony to spread to the platform components began to crystallize on its own. Thus, all embedded services provided by the platform are asynchronous.

So as a result of the development of the system, database services (Kraken), Scheduling, Events, Pipe, Web appeared; and they all repaired the rule of asynchrony.

As one of the developers of this system, I would be very interested to know the opinion of the Habra community about Baratine .