1 | // Protocol Buffers - Google's data interchange format |
2 | // Copyright 2008 Google Inc. All rights reserved. |
3 | // https://developers.google.com/protocol-buffers/ |
4 | // |
5 | // Redistribution and use in source and binary forms, with or without |
6 | // modification, are permitted provided that the following conditions are |
7 | // met: |
8 | // |
9 | // * Redistributions of source code must retain the above copyright |
10 | // notice, this list of conditions and the following disclaimer. |
11 | // * Redistributions in binary form must reproduce the above |
12 | // copyright notice, this list of conditions and the following disclaimer |
13 | // in the documentation and/or other materials provided with the |
14 | // distribution. |
15 | // * Neither the name of Google Inc. nor the names of its |
16 | // contributors may be used to endorse or promote products derived from |
17 | // this software without specific prior written permission. |
18 | // |
19 | // THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS |
20 | // "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT |
21 | // LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR |
22 | // A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT |
23 | // OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, |
24 | // SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT |
25 | // LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, |
26 | // DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY |
27 | // THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT |
28 | // (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE |
29 | // OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. |
30 | |
31 | // Author: kenton@google.com (Kenton Varda) |
32 | // Based on original Protocol Buffers design by |
33 | // Sanjay Ghemawat, Jeff Dean, and others. |
34 | // |
35 | // DEPRECATED: This module declares the abstract interfaces underlying proto2 |
36 | // RPC services. These are intended to be independent of any particular RPC |
37 | // implementation, so that proto2 services can be used on top of a variety |
38 | // of implementations. Starting with version 2.3.0, RPC implementations should |
39 | // not try to build on these, but should instead provide code generator plugins |
40 | // which generate code specific to the particular RPC implementation. This way |
41 | // the generated code can be more appropriate for the implementation in use |
42 | // and can avoid unnecessary layers of indirection. |
43 | // |
44 | // |
45 | // When you use the protocol compiler to compile a service definition, it |
46 | // generates two classes: An abstract interface for the service (with |
47 | // methods matching the service definition) and a "stub" implementation. |
48 | // A stub is just a type-safe wrapper around an RpcChannel which emulates a |
49 | // local implementation of the service. |
50 | // |
51 | // For example, the service definition: |
52 | // service MyService { |
53 | // rpc Foo(MyRequest) returns(MyResponse); |
54 | // } |
55 | // will generate abstract interface "MyService" and class "MyService::Stub". |
56 | // You could implement a MyService as follows: |
57 | // class MyServiceImpl : public MyService { |
58 | // public: |
59 | // MyServiceImpl() {} |
60 | // ~MyServiceImpl() {} |
61 | // |
62 | // // implements MyService --------------------------------------- |
63 | // |
64 | // void Foo(google::protobuf::RpcController* controller, |
65 | // const MyRequest* request, |
66 | // MyResponse* response, |
67 | // Closure* done) { |
68 | // // ... read request and fill in response ... |
69 | // done->Run(); |
70 | // } |
71 | // }; |
72 | // You would then register an instance of MyServiceImpl with your RPC server |
73 | // implementation. (How to do that depends on the implementation.) |
74 | // |
75 | // To call a remote MyServiceImpl, first you need an RpcChannel connected to it. |
76 | // How to construct a channel depends, again, on your RPC implementation. |
77 | // Here we use a hypothetical "MyRpcChannel" as an example: |
78 | // MyRpcChannel channel("rpc:hostname:1234/myservice"); |
79 | // MyRpcController controller; |
80 | // MyServiceImpl::Stub stub(&channel); |
81 | // FooRequest request; |
82 | // FooResponse response; |
83 | // |
84 | // // ... fill in request ... |
85 | // |
86 | // stub.Foo(&controller, request, &response, NewCallback(HandleResponse)); |
87 | // |
88 | // On Thread-Safety: |
89 | // |
90 | // Different RPC implementations may make different guarantees about what |
91 | // threads they may run callbacks on, and what threads the application is |
92 | // allowed to use to call the RPC system. Portable software should be ready |
93 | // for callbacks to be called on any thread, but should not try to call the |
94 | // RPC system from any thread except for the ones on which it received the |
95 | // callbacks. Realistically, though, simple software will probably want to |
96 | // use a single-threaded RPC system while high-end software will want to |
97 | // use multiple threads. RPC implementations should provide multiple |
98 | // choices. |
99 | |
100 | #ifndef GOOGLE_PROTOBUF_SERVICE_H__ |
101 | #define GOOGLE_PROTOBUF_SERVICE_H__ |
102 | |
103 | |
104 | #include <string> |
105 | #include <google/protobuf/stubs/callback.h> |
106 | #include <google/protobuf/stubs/common.h> |
107 | |
108 | #ifdef SWIG |
109 | #error "You cannot SWIG proto headers" |
110 | #endif |
111 | |
112 | // Must be included last. |
113 | #include <google/protobuf/port_def.inc> |
114 | |
115 | namespace google { |
116 | namespace protobuf { |
117 | |
118 | // Defined in this file. |
119 | class Service; |
120 | class RpcController; |
121 | class RpcChannel; |
122 | |
123 | // Defined in other files. |
124 | class Descriptor; // descriptor.h |
125 | class ServiceDescriptor; // descriptor.h |
126 | class MethodDescriptor; // descriptor.h |
127 | class Message; // message.h |
128 | |
129 | // Abstract base interface for protocol-buffer-based RPC services. Services |
130 | // themselves are abstract interfaces (implemented either by servers or as |
131 | // stubs), but they subclass this base interface. The methods of this |
132 | // interface can be used to call the methods of the Service without knowing |
133 | // its exact type at compile time (analogous to Reflection). |
134 | class PROTOBUF_EXPORT Service { |
135 | public: |
136 | inline Service() {} |
137 | virtual ~Service(); |
138 | |
139 | // When constructing a stub, you may pass STUB_OWNS_CHANNEL as the second |
140 | // parameter to the constructor to tell it to delete its RpcChannel when |
141 | // destroyed. |
142 | enum ChannelOwnership { STUB_OWNS_CHANNEL, STUB_DOESNT_OWN_CHANNEL }; |
143 | |
144 | // Get the ServiceDescriptor describing this service and its methods. |
145 | virtual const ServiceDescriptor* GetDescriptor() = 0; |
146 | |
147 | // Call a method of the service specified by MethodDescriptor. This is |
148 | // normally implemented as a simple switch() that calls the standard |
149 | // definitions of the service's methods. |
150 | // |
151 | // Preconditions: |
152 | // * method->service() == GetDescriptor() |
153 | // * request and response are of the exact same classes as the objects |
154 | // returned by GetRequestPrototype(method) and |
155 | // GetResponsePrototype(method). |
156 | // * After the call has started, the request must not be modified and the |
157 | // response must not be accessed at all until "done" is called. |
158 | // * "controller" is of the correct type for the RPC implementation being |
159 | // used by this Service. For stubs, the "correct type" depends on the |
160 | // RpcChannel which the stub is using. Server-side Service |
161 | // implementations are expected to accept whatever type of RpcController |
162 | // the server-side RPC implementation uses. |
163 | // |
164 | // Postconditions: |
165 | // * "done" will be called when the method is complete. This may be |
166 | // before CallMethod() returns or it may be at some point in the future. |
167 | // * If the RPC succeeded, "response" contains the response returned by |
168 | // the server. |
169 | // * If the RPC failed, "response"'s contents are undefined. The |
170 | // RpcController can be queried to determine if an error occurred and |
171 | // possibly to get more information about the error. |
172 | virtual void CallMethod(const MethodDescriptor* method, |
173 | RpcController* controller, const Message* request, |
174 | Message* response, Closure* done) = 0; |
175 | |
176 | // CallMethod() requires that the request and response passed in are of a |
177 | // particular subclass of Message. GetRequestPrototype() and |
178 | // GetResponsePrototype() get the default instances of these required types. |
179 | // You can then call Message::New() on these instances to construct mutable |
180 | // objects which you can then pass to CallMethod(). |
181 | // |
182 | // Example: |
183 | // const MethodDescriptor* method = |
184 | // service->GetDescriptor()->FindMethodByName("Foo"); |
185 | // Message* request = stub->GetRequestPrototype (method)->New(); |
186 | // Message* response = stub->GetResponsePrototype(method)->New(); |
187 | // request->ParseFromString(input); |
188 | // service->CallMethod(method, *request, response, callback); |
189 | virtual const Message& GetRequestPrototype( |
190 | const MethodDescriptor* method) const = 0; |
191 | virtual const Message& GetResponsePrototype( |
192 | const MethodDescriptor* method) const = 0; |
193 | |
194 | private: |
195 | GOOGLE_DISALLOW_EVIL_CONSTRUCTORS(Service); |
196 | }; |
197 | |
198 | // An RpcController mediates a single method call. The primary purpose of |
199 | // the controller is to provide a way to manipulate settings specific to the |
200 | // RPC implementation and to find out about RPC-level errors. |
201 | // |
202 | // The methods provided by the RpcController interface are intended to be a |
203 | // "least common denominator" set of features which we expect all |
204 | // implementations to support. Specific implementations may provide more |
205 | // advanced features (e.g. deadline propagation). |
206 | class PROTOBUF_EXPORT RpcController { |
207 | public: |
208 | inline RpcController() {} |
209 | virtual ~RpcController(); |
210 | |
211 | // Client-side methods --------------------------------------------- |
212 | // These calls may be made from the client side only. Their results |
213 | // are undefined on the server side (may crash). |
214 | |
215 | // Resets the RpcController to its initial state so that it may be reused in |
216 | // a new call. Must not be called while an RPC is in progress. |
217 | virtual void Reset() = 0; |
218 | |
219 | // After a call has finished, returns true if the call failed. The possible |
220 | // reasons for failure depend on the RPC implementation. Failed() must not |
221 | // be called before a call has finished. If Failed() returns true, the |
222 | // contents of the response message are undefined. |
223 | virtual bool Failed() const = 0; |
224 | |
225 | // If Failed() is true, returns a human-readable description of the error. |
226 | virtual std::string ErrorText() const = 0; |
227 | |
228 | // Advises the RPC system that the caller desires that the RPC call be |
229 | // canceled. The RPC system may cancel it immediately, may wait awhile and |
230 | // then cancel it, or may not even cancel the call at all. If the call is |
231 | // canceled, the "done" callback will still be called and the RpcController |
232 | // will indicate that the call failed at that time. |
233 | virtual void StartCancel() = 0; |
234 | |
235 | // Server-side methods --------------------------------------------- |
236 | // These calls may be made from the server side only. Their results |
237 | // are undefined on the client side (may crash). |
238 | |
239 | // Causes Failed() to return true on the client side. "reason" will be |
240 | // incorporated into the message returned by ErrorText(). If you find |
241 | // you need to return machine-readable information about failures, you |
242 | // should incorporate it into your response protocol buffer and should |
243 | // NOT call SetFailed(). |
244 | virtual void SetFailed(const std::string& reason) = 0; |
245 | |
246 | // If true, indicates that the client canceled the RPC, so the server may |
247 | // as well give up on replying to it. The server should still call the |
248 | // final "done" callback. |
249 | virtual bool IsCanceled() const = 0; |
250 | |
251 | // Asks that the given callback be called when the RPC is canceled. The |
252 | // callback will always be called exactly once. If the RPC completes without |
253 | // being canceled, the callback will be called after completion. If the RPC |
254 | // has already been canceled when NotifyOnCancel() is called, the callback |
255 | // will be called immediately. |
256 | // |
257 | // NotifyOnCancel() must be called no more than once per request. |
258 | virtual void NotifyOnCancel(Closure* callback) = 0; |
259 | |
260 | private: |
261 | GOOGLE_DISALLOW_EVIL_CONSTRUCTORS(RpcController); |
262 | }; |
263 | |
264 | // Abstract interface for an RPC channel. An RpcChannel represents a |
265 | // communication line to a Service which can be used to call that Service's |
266 | // methods. The Service may be running on another machine. Normally, you |
267 | // should not call an RpcChannel directly, but instead construct a stub Service |
268 | // wrapping it. Example: |
269 | // RpcChannel* channel = new MyRpcChannel("remotehost.example.com:1234"); |
270 | // MyService* service = new MyService::Stub(channel); |
271 | // service->MyMethod(request, &response, callback); |
272 | class PROTOBUF_EXPORT RpcChannel { |
273 | public: |
274 | inline RpcChannel() {} |
275 | virtual ~RpcChannel(); |
276 | |
277 | // Call the given method of the remote service. The signature of this |
278 | // procedure looks the same as Service::CallMethod(), but the requirements |
279 | // are less strict in one important way: the request and response objects |
280 | // need not be of any specific class as long as their descriptors are |
281 | // method->input_type() and method->output_type(). |
282 | virtual void CallMethod(const MethodDescriptor* method, |
283 | RpcController* controller, const Message* request, |
284 | Message* response, Closure* done) = 0; |
285 | |
286 | private: |
287 | GOOGLE_DISALLOW_EVIL_CONSTRUCTORS(RpcChannel); |
288 | }; |
289 | |
290 | } // namespace protobuf |
291 | } // namespace google |
292 | |
293 | #include <google/protobuf/port_undef.inc> |
294 | |
295 | #endif // GOOGLE_PROTOBUF_SERVICE_H__ |
296 | |