I tried playing around with some code to make Spring RPC be protobuf's transport and have it coexist with other Spring RPC services.
To give credit to Spring, they make it very easy to extend their framework:
- On the server side you need to extend doWriteRemoteInvocationResult and doReadRemoteInvocation of RemoteInvocationSerializingExporter.
- On the client side you need to overwrite doReadRemoteInvocationResult and doWriteRemoteInvocation of AbstractHttpInvokerRequestExecutor.
Well, if you want to use the Spring RPC transparent way of remoting services then you must overwrite getProxyForService of RemoteExporter to route Protobuf service calls (i.e. mimic the protobuf service stub). Alas, you can't do it since the service Protobuf does not have an interface with the method signature so you can't make a proxy out of it. And anyway, the methods protobuf service is generating are not intended to seem POJO like at all with the RpcCallback and RpcController arguments. It sucks a bit if you with to integrate protobuf in an existing environment.
One can always wrap the generated service so it will look like an innocent POJO, but on the other hand there is a good point in the protobuf way.
Using Spring RPC it is way too easy to forget you are calling a remote service. You make your business objects Serializable and just move them around, having most of Java data containers serializable just makes it easier. The next thing you know you're API has object serialized back and forth without justification. So Spring RPC is a big gun to shoot yourself in the foot with when you forget about the eight Fallacies of Distributed Computing.
My conclusion (for now) is that if you have to use Spring RPC for transport and have protobuf objects floating around, you better use a protobuf java seialization wrapper.