Home

Scope

For the Infinispan server clients are available in several languages: Java, Ruby, Python, C++, .NET, JavaScript. Currently new features are implemented executing an independent development task for every programming language. As one can imagine, keeping all these clients updated to the same features set, with the same code quality and reliability needs a considerable effort.

The Goal

So within the Infinspan community there an ongoing discussion around the following goal:

Can we design an architecture/framework/development-environment that can save effort to the clients development?

This general question can be narrowed down to specific aspects of the developement process to spot out specific solution.

Two main aspect that have been spotted out at the moment are:

1. interoperable general (un)marshalling
2. network related features

Interoperable general (un)marshalling

This aspect relates to the possibility to produce a generic (it must not set constraints to the user application model) and complete (no need to add hand written code) marshaller for a designed programming language.

Network related features

This referes to the possibility to develop all the set of the common features related to the network/transport aspect on time for all the client's languages. The features are:

• topology intelligence
• retry on failure
• general failover

The ispn-grpc project

This project has been started with the idea to explore and experiment around the goal using the gRPC framework, which is an RPC/IDL implementation based on protobuf as definition language. So the idea (actually not new) is to setup a developement process that, once defined everything in gRPC, can generate (part of) the client in whatever programming language we want.

Design choices

Several choices have been made during the development: some are design driver, some other driven just by opportunity.

Define everything in gRPC

The idea behind this is that everything defined at the gRPC level is defined once (and formally) for all the languages. So I started with the definition of the service interface but, since gRPC is based on Protobuf a declarative language initially created for the streaming of objects, I wanted to explore the possibility to define into the service interface not only the services but also the user object model (application model). In this way the resulting interface is full typed (with the application domain types) at the IDL level and also at the programming language level, with the cross-language interoperability guarantee by gRPC/protobuf. This work specifically addresses the marshalling aspect, with the following pros and cons:

• marshalling and interoperability almost for free (+)
• the generated application model is equivalent at the 'object' level in every language, since the mapping is formally guarantee by protobuf (+)
• the generated objects are protobuf objects with a not always user friendly set of accessors (-)
• a change in the application model needs the redeploy of the client AND the server, so a strong continuous integration workflow is needed. (--)

Using an EmbeddedCache instead of developing a server connector

The current version of this project wraps an EmbeddedCacheManager with gRPC, this is just a convenient solution that I adopted to focus my effort on the gRPC design stuff. If something interesting comes out from this work an integration into the Infinispan server can be taken into account.