Generate server interfaces / stubs

[narve]

This, and issue #19 , is an optional task that could be useful for server side implementations of UMEI.

Typically, FMOs already have an API that will remain as-is. At least as a first step UMEI will be added as an additional API layer, then translated to FMO-specific API. This process will require some glue code. Generating server stubs for this glue code based on the OpenAPI spec will make it easier to implement. Furthermore, it will increase the chances that different FMOs have compatible implementations of UMEI.

[narve]

In NODES' case, we would generate server stubs for .Net (ASP Net Core). These server stubs would probably include data classes (DTOs) for the different data types (Order, Trade, etc) as well as interfaces (IOrderService etc).

@lde-nside How about N-Side, which technology are you using? Is this something you would consider useful?

[cdmNSIDE]

Hello Narve,

We usually generate data transfer objects (DTO) for our server based on the API specifications (with an open api generator).
Initially we didn't plan to externalise those DTOs to make them accessible to the market participants.
But we could indeed think of grouping those objects in a library that could be shared.
It's however not our priority for this UMEI...

[narve]

Like for the client libraries: It is not a priority, but if we're doing it, why do it separately? We can save effort and increase consistency by cooperating. Have you decided which server technology you are going to use?

[narve]

FYI: I have created code to generate client and server stubs for UMEI when integrating it with our existing solution. Let me know if you are interested in a demo/walkthrough.