Generic Invocation in RPC Frameworks: Principles, Implementations, and Practice at Zhuanzhuan

RPC frameworks often require generic invocation to support scenarios such as gateways and interface testing where dependent interface JARs are inconvenient.

1 Normal RPC Call

Using dynamic proxies, a client can invoke remote methods just like local ones. The service interface (e.g., HelloService ) is packaged in a JAR and shared by both server and client.

public interface HelloService {
    String hello(String name);
}

The server implements the interface:

public class HelloServiceImpl implements HelloService {
    @Override
    public String hello(String name) {
        return "hello, " + name;
    }
}

The client creates a proxy (the actual request/response handling is hidden inside the framework):

HelloService helloService = (HelloService) Proxy.newProxyInstance(
    this.getClass().getClassLoader(),
    HelloService.class,
    (proxy, method, args) -> {
        // framework packs method name, parameter types and arguments
        String methodName = method.getName();
        Class
[] parameterTypes = method.getParameterTypes();
        return request(methodName, parameterTypes, args);
    }
);
String result = helloService.hello("jack");
System.out.println(result);

2 Need in Gateways and Interface Testing

In large‑scale services, requiring every service and client to depend on the same interface JAR is impractical. Gateways and testing platforms need to invoke any RPC method without recompiling or adding new JARs, which motivates generic invocation.

3 Generic Invocation

Generic invocation allows calling a method without the service’s interface JAR, generalizing the method name, parameter types (as strings), and return value.

public interface GenericService {
    Object $genericInvoke(String methodName, String[] parameterTypes, Object[] args);
}

When parameters are primitive types, the call behaves like a normal RPC; for POJOs, a universal representation is required.

3.1 Java‑Bean‑Based Generic Invocation

This approach uses a unified JavaBeanDescriptor to describe POJOs, independent of the underlying serialization. Dubbo supports this method, converting between POJOs and descriptors at the serialization layer.

3.2 Serialization‑Intermediate Generic Invocation

Frameworks such as SOFA‑RPC rely on a serialization intermediate (e.g., GenericObject , GenericMap , GenericArray ) built on top of Hessian. Zhuanzhuan’s RPC framework adapts SOFA‑Hessian and also supports JSON‑based generic calls, where a JSON object or string represents the POJO.

Dubbo additionally supports JSON‑Protobuf generic calls, allowing a JSON description of a protobuf object that is deserialized back to a POJO by the serialization framework.

4 Practice at Zhuanzhuan

Zhuanzhuan uses generic invocation extensively in its unified testing API platform, enabling HTTP + JSON calls to any service, node, or method without any interface JAR or RPC framework JAR dependencies. The platform also provides JSON schema retrieval for method parameters and return values.

{
    "msg": "success",
    "data": {
        "schema": {
            "returnValue": {
                "type": "array",
                "items": {
                    "type": "object",
                    "id": "urn:jsonschema:com:bj58:zhuanzhuan:arch:user:atomic:entity:User",
                    "properties": {
                        "id": {"type": "string"},
                        "userName": {"type": "string"},
                        "userNamePinyin": {"type": "string"},
                        "mock": {"type": "boolean"}
                    }
                }
            },
            "parameters": {
                "pageNum": {"type": "integer"},
                "pageSize": {"type": "integer"}
            }
        }
    },
    "code": 0
}

Future gateway development at Zhuanzhuan will also rely on generic invocation.

5 Summary

Generic invocation is widely used in gateways and testing platforms. The two main implementations are Java‑Bean‑based (serialization‑agnostic but requires complex conversion) and serialization‑intermediate based (simpler to implement but tied to a specific serialization framework). Choosing the appropriate method depends on the specific project requirements.