Thanks Evan and Kenton.

@Evan, I'll definitely check out the plugin.

On Jul 21, 12:30 am, Kenton Varda <> wrote:
> On Thu, Jul 15, 2010 at 2:22 AM, Jamie McCrindle
> <>wrote:
> > Hi all,
> > I've built a lightweight PB RPC implementation over HTTP which I'd
> > like to pad out with some more functionality but I have a few design
> > questions that I was hoping some of you folk in the group may be able
> > to help with:
> > 1. For completeness, it looks like an RPC implementation should
> > provide both RpcChannel and BlockingRpcChannel implementations or is
> > there a default implementation of BlockingRpcChannel around as in:
> Right, the RPC system needs to provide these.  An RPC system might choose to
> only provide one or the other, or both (maybe even as a single class),
> depending on the design.  The default implementation you suggested might
> just force the RPC system to create redundant background threads -- if the
> calling thread is going to block anyway, why not use it to handle network
> events in the meantime?

Good plan. I'm currently looking at everything being asynchronous but
for completeness, a BlockingRpcChannel should be implemented.

> > 2. I've been pondering how to inject in Service references. I like the
> > idea that I have a 'local' RPC implementation that could be swapped
> > out for a 'remote' one without having to change the client class. It
> > doesn't seem right to have this code in the client (i.e. recreate the
> > stub for every call):
> >        RpcChannel channel = rpc.newChannel("");
> >        RpcController controller = rpc.newController();
> >        Stub testService = TestService.newStub(channel);
> >        testService.test(controller, TestRequest.newBuilder().build(),
> > new RpcCallback<TestResponse>() {
> >            public void run(TestResponse parameter) {
> >            }
> >        });
> > But rather to inject an implementation of TestService and an
> > RpcController Factory into the client code and just have:
> >        RpcController controller = rpc.newController();
> >        testService.test(controller, TestRequest.newBuilder().build(),
> > new RpcCallback<TestResponse>() {
> >            public void run(TestResponse parameter) {
> >            }
> >        });
> > Because then different RPC implementations can be plugged in
> > (especially local vs. remote).
> This is exactly what I do in my own code.

Great stuff.

> > But on a related note, the code above
> > definitely creates a very tight coupling to Protocol Buffers as the
> > RPC mechanism... not that I particularly mind but a lot of other Java
> > 'RPC' type code attempts to abstract out the 'business logic' and the
> > remoting mechanism. Anyone had similar thoughts on how to do this with
> > PB RPC?
> You're coupled to protocol buffers, but not to the particular RPC
> implementation.  Protocol buffers is not such a bad thing to couple with --
> it's easy to write code to parse and serialize protobuf objects in any
> format.  Think of your protobuf classes as just dumb data objects that
> happen to have all the usual boilerplate (accessors, builders, etc.)
> automatically generated.

Yeah, I'm becoming comfortable with the idea of coupling to PB, at
least at the edges. There's a lot of mapping across of DTOs, though. A
great example would be PB to Hibernate. That said, I can't complain,
I'm using it to back onto MongoDB at the moment and iterop is pretty
easy as long as I don't use Dates.

> > 3. Regarding extending RpcController. Adding a timeout and a timestamp
> > seem pretty good candidates but the 'EnhancedRpcController' then
> > becomes a pervasive cast as well as a RPC implementation lockin e.g.
> > the code above becomes:
> Do you really want to be setting timeouts in your business logic?  In my
> experience, the answer is "no" -- code handling logistics should ideally be
> completely separate from code handling correctness.
> Instead, make it the responsibility of the RpcChannel to set such stuff.
>  For example, it could consult a config file, looking up the particular
> method specified by the MethodDescriptor, to find out what options to use.
>  Then the caller doesn't need to know anything about timeouts.

Makes sense. Of course, in this one specific case, the deadline is in
fact part of the 'business logic' :) but that should be only 1 cast
and in the general sense I agree it can be hidden behind the RPC

Thanks again for the feedback. I'll probably have more questions once
I'm further in.

You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to