Thanks for the breakdown, that's very helpful. I had some trouble finding details about how the PB RPC terminology mapped to what I'm familiar with.
It sounds like the system in question has a single "public" service with delegates calls to back-end services, distributed across machines available to it. It seems as though the public service provides an interface which is essentially a composition of the interfaces provided by the services available to it. The process of accepting requests for methods it provides on behalf of these back-end services, which it handles by delegating to the appropriate back-end service, is essentially multiplexing multiple services from a single network location. If this is at all accurate, then I believe that the API exported by the public service should be built, dynamically, based on the set of interfaces available to it. Taking this approach would allow each service to define its own interface. While all the functionality available on the network can be exposed as though it were all provided by a single entity, assuming there are no naming conflicts ;-) Or maybe I'm completely confused about the setup. Best regards, Shane On Wed, 2008-11-19 at 22:37 -0800, Kenton Varda wrote: > The design of an RPC system is a large topic and there are lots of > different ways you could do it. The RPC interfaces provided by > Protocol Buffers are meant to provide the minimum support necessary to > allow protoc to generate type-safe service stubs. How you want to > implement them is up to you. > > > This is described in the docs, but to summarize, the basic classes > are: > > > Service: An object that receives messages, possibly from remote > clients. protoc generates an interface corresponding to each service > in a .proto file. These interfaces are implemented by the server > application. > > > RpcChannel: Represents an abstract tunnel to a single service, > allowing you to send messages just to that service. This is an > abstract interface which should be implemented by the RPC library. > > > > RpcController: Manages state related to a single remote procedure call > -- that is, a single message sent to the server, and its corresponding > response. This is an abstract interface which should be implemented > by the RPC library. > > > > Stub: A fake implementation of a service interface which just forwards > messages to an RpcChannel. This makes the service appear to be a > local object when it is not. protoc automatically generates a stub > class for every service type. > > > > > Note that you could easily have multiple RpcChannels that share a > single TCP connection and lead to multiple service objects running on > a single server. The interfaces are designed to put as few > restrictions on implementations as possible. > > > On Wed, Nov 19, 2008 at 9:52 PM, codeazure <[EMAIL PROTECTED]> > wrote: > > OK, now you've confused me :-) > > I don't understand the exact relationship between all these > classes, > which is why I'm asking the question. If I want to build an > application where I have a number of services that share a > single TCP > port, what organisation do I need to use? > > You mention multiplexing services - what does that mean for a > client > application using the connection? > > A UML:diagram (or similar) showing the relationship between > controllers, channels & services would really aid my > understanding of > how this system would operate. Perhaps these terms are in > common usage > in other RPC systems, but because I haven't used any, I'm > uncertain > about what these entities do. I've read the documentation > several > times, but the overview of how it works hasn't clicked. > > Thanks, > Jeff > > On Nov 20, 12:54 pm, Kenton Varda <[EMAIL PROTECTED]> wrote: > > RpcController objects are per-request, not per-server or > per-service. For > > every RPC request you make, you should have another > RpcController object > > (though you can reuse an object by calling Clear() as long > as you aren't > > making two requests at once). > > RpcChannel objects are per-service. Is that what you were > thinking of? A > > single RpcChannel represents a connection to a single > Service. However, > > there's nothing stopping you from multiplexing multiple > RpcChannels across a > > single TCP connection, or creating a protocol that allows > you to choose > > between multiple services exported by a server when > constructing an > > RpcChannel. > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~----------~----~----~----~------~----~------~--~---
