Suggestions: make it more agnostic, get rid of inheritance

[SAKryukov]

Austin,

I think JSON-RPC.NET is very inspiring, to say the least.

Still, I think it can be improved in the following way: you can keep your/users' service classes more agnostic to JsonRpcService and developed independently, without any coupling with your framework.

From your code sample and documentation is apparent that the service classes should be derived from JsonRpcService.
(Please prove me wrong if I'm wrong.)

This is the unnecessary coupling. If a user has some already developed service functionality, the need for this inheritance can break an existing class hierarchy and create some hassles. Take into account the absence of "strong" multiple inheritance (for classes) in .NET. At the same time, it's quite possible to make the same functionality agnostic to the hierarchy.

To bind the existing service class with the RPC, you can use either the existing service-implementing class or even the interface matching the service contract. You need some "registration" facility to use reflection to collect all the information on the contract, that is, the methods marked with [JsonRpcMethod] (or other attributes like that), with all the metadata related to the method: name, profile, and so on. You can register the implementation class with the facility. Even better, you can register the implementation and its interface (during runtime, check up if it implements the interface during runtime), having the interface accessible to both client and service assemblies, so the client part would need only the interface, and implementation on the client side would be some proxy. Moreover, you can also use .NET Reflection.Emit (maybe you already do, please clarify), to improve the performance, which would boost if you have more than one service implementation.

I believe this architectural change can greatly improve the usability keeping the performance.

Thank you.
—SA

[hovi]

Completely agreed. We are just browsing way to implement json-rpc server in our project and this need for inheritance is definitely inconvenience if not a no-go.

[SAKryukov]

Thank you for understanding. Since my last message, I've done my research and overcame the need for inheritance even for the service contract interfaces (however, the fact that the service contract type is an interface is validated during runtime, but this is more of an assertion, a sanity check). I plan to publish it soon. Before I do, I plan a more advanced step: secondary interfaces (interface references returned in the method return objects) implemented on the server side and dynamically presented to the client side in the form of proxies. Apparently, this is not for all applications, as it can make the server too vulnerable to the DoS/DDoS attacks, but for some, this is a must-have.

Thank you.
—SA

[Astn]

If you would like to avoid the inheritance then you can bind your services manually instead of using the Abstract Base Class.

https://github.com/Astn/JSON-RPC.NET/blob/master/Json-Rpc/JsonRpcService.cs
Eg:

 ServiceBinder.BindService(Handler.DefaultSessionId(), SomeServiceClassWithServiaceAnnotations);
 // or
 ServiceBinder.BindService(SomeSessionID, SomeServiceClassWithServiaceAnnotations);

[hovi]

@PremekPaska