On Thu, Jul 15, 2010 at 2:22 AM, Jamie McCrindle
<jamiemccrin...@gmail.com>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?
> 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("example.com:12345");
> 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.
> 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.
> 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.
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
