Thanks Evan and Kenton.
@Evan, I'll definitely check out the plugin.
On Jul 21, 12:30 am, Kenton Varda <ken...@google.com> wrote:
> 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?
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("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.
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
implementation.
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 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.
