1interceptors(3) Erlang Module Definition interceptors(3)
2
6 interceptors - Describe the functions which must be exported by any
7 supplied Orber native interceptor.
8
10 This module contains the mandatory functions for user supplied native
11 interceptors and their intended behavior. See also the User's Guide.
12 Warning:
14 Using Interceptors may reduce the through-put significantly if the sup‐
15 plied interceptors invoke expensive operations. Hence, one should al‐
16 ways supply interceptors which cause as little overhead as possible.
17 Warning:
20 It is possible to alter the Data, Bin and Args parameter for the in_re‐
21 ply and out_reply, in_reply_encoded, in_request_encoded, out_reply_en‐
22 coded and out_request_encoded, in_request and out_request respectively.
23 But, if it is done incorrectly, the consequences can be serious.
24 Note:
27 The Extra parameter is set to 'undefined' by Orber when calling the
28 first interceptor and may be set to any Erlang term. If an interceptor
29 change this parameter it will be passed on to the next interceptor in
30 the list uninterpreted.
31 Note:
34 The Ref parameter is set to 'undefined' by Orber when calling
35 new_in_connection or new_out_connection using the first interceptor.
36 The user supplied interceptor may set NewRef to any Erlang term. If an
37 interceptor change this parameter it will be passed on to the next in‐
38 terceptor in the list uninterpreted.
39
42 new_in_connection(Ref, PeerHost, PeerPort) -> NewRef
43 new_in_connection(Ref, PeerHost, PeerPort, SocketHost, SocketPort) ->
44 NewRef
45 Types:
47 Ref = term() | undefined
49 PeerHost = SocketHost = string(), e.g., "myHost@myServer" or
50 "192.0.0.10"
51 PeerPort = SocketPort = integer()
52 NewRef = term() | {'EXIT', Reason}
53 When a new connection is requested by a client side ORB this op‐
55 eration is invoked. If more than one interceptor is supplied,
56 e.g., {native, ['myInterceptor1', 'myInterceptor2']}, the return
57 value from 'myInterceptor1' is passed to 'myInterceptor2' as
58 Ref. Initially, Orber uses the atom 'undefined' as Ref parameter
59 when calling the first interceptor. The return value from the
60 last interceptor, in the example above 'myInterceptor2', is
61 passed to all other functions exported by the interceptors.
62 Hence, the Ref parameter can, for example, be used as a unique
63 identifier to mnesia or ets where information/restrictions for
64 this connection is stored.
65 The PeerHost and PeerPort variables supplied data of the client
67 ORB which requested a new connection. SocketHost and SocketPort
68 are the local interface and port the client connected to.
69 If, for some reason, we do not allow the client ORB to connect
71 simply invoke exit(Reason).
72 new_out_connection(Ref, PeerHost, PeerPort) -> NewRef
74 new_out_connection(Ref, PeerHost, PeerPort, SocketHost, SocketPort) ->
75 NewRef
76 Types:
78 Ref = term() | undefined
80 PeerHost = SocketHost = string(), e.g., "myHost@myServer" or
81 "192.0.0.10"
82 PeerPort = SocketPort = integer()
83 NewRef = term() | {'EXIT', Reason}
84 When a new connection is set up this function is invoked. Be‐
86 haves just like new_in_connection; the only difference is that
87 the PeerHost and PeerPort variables identifies the target ORB's
88 bootstrap data and SocketHost and SocketPort are the local in‐
89 terface and port the client ORB connected via.
90 closed_in_connection(Ref) -> NewRef
92 Types:
94 Ref = term()
96 NewRef = term()
97 When an existing connection is terminated this operation is in‐
99 voked. The main purpose of this function is to make it possible
100 for a user to clean up all data associated with the associated
101 connection.
102 The input parameter Ref is the return value from new_in_connec‐
104 tion/3.
105 closed_out_connection(Ref) -> NewRef
107 Types:
109 Ref = term()
111 NewRef = term()
112 When an existing connection is terminated this operation is in‐
114 voked. The main purpose of this function is to make it possible
115 for a user to clean up all data associated with the associated
116 connection.
117 The input parameter Ref is the return value from new_out_connec‐
119 tion/3.
120 in_reply(Ref, Obj, Ctx, Op, Data, Extra) -> Reply
122 Types:
124 Ref = term()
126 Obj = #objref
127 Ctx = [#'IOP_ServiceContext'{}]
128 Op = atom()
129 Data = [Result, OutParameter1, ..., OutPramaterN]
130 Reply = {NewData, NewExtra}
131 When replies are delivered from the server side ORB to the
133 client side ORB this operation is invoked. The Data parameter is
134 a list in which the first element is the return value value from
135 the target object and the rest is a all parameters defined as
136 out or inout in the IDL-specification.
137 in_reply_encoded(Ref, Obj, Ctx, Op, Bin, Extra) -> Reply
139 Types:
141 Ref = term()
143 Obj = #objref
144 Ctx = [#'IOP_ServiceContext'{}]
145 Op = atom()
146 Bin = #binary
147 Reply = {NewBin, NewExtra}
148 When replies are delivered from the server side ORB to the
150 client side ORB this operation is invoked. The Bin parameter is
151 the reply body still uncoded.
152 in_request(Ref, Obj, Ctx, Op, Args, Extra) -> Reply
154 Types:
156 Ref = term()
158 Obj = #objref
159 Ctx = [#'IOP_ServiceContext'{}]
160 Op = atom()
161 Args = [Argument] - defined in the IDL-specification
162 Reply = {NewArgs, NewExtra}
163 When a new request arrives at the server side ORB this operation
165 is invoked.
166 in_request_encoded(Ref, Obj, Ctx, Op, Bin, Extra) -> Reply
168 Types:
170 Ref = term()
172 Obj = #objref
173 Ctx = [#'IOP_ServiceContext'{}]
174 Op = atom()
175 Bin = #binary
176 Reply = {NewBin, NewExtra}
177 When a new request arrives at the server side ORB this operation
179 is invoked before decoding the request body.
180 out_reply(Ref, Obj, Ctx, Op, Data, Extra) -> Reply
182 Types:
184 Ref = term()
186 Obj = #objref
187 Ctx = [#'IOP_ServiceContext'{}]
188 Op = atom()
189 Data = [Result, OutParameter1, ..., OutPramaterN]
190 Reply = {NewData, NewExtra}
191 After the target object have been invoked this operation is in‐
193 voked with the result. The Data parameter is a list in which the
194 first element is the return value value from the target object
195 and the rest is a all parameters defined as out or inout in the
196 IDL-specification.
197 out_reply_encoded(Ref, Obj, Ctx, Op, Bin, Extra) -> Reply
199 Types:
201 Ref = term()
203 Obj = #objref
204 Ctx = [#'IOP_ServiceContext'{}]
205 Op = atom()
206 Bin = #binary
207 Reply = {NewBin, NewExtra}
208 This operation is similar to out_reply; the only difference is
210 that the reply body have been encoded.
211 out_request(Ref, Obj, Ctx, Op, Args, Extra) -> Reply
213 Types:
215 Ref = term()
217 Obj = #objref
218 Ctx = [#'IOP_ServiceContext'{}]
219 Op = atom()
220 Args = [Argument] - defined in the IDL-specification
221 Reply = {NewArgs, NewExtra}
222 Before a request is sent to the server side ORB, out_request is
224 invoked.
225 out_request_encoded(Ref, Obj, Ctx, Op, Bin, Extra) -> Reply
227 Types:
229 Ref = term()
231 Obj = #objref
232 Ctx = [#'IOP_ServiceContext'{}]
233 Op = atom()
234 Bin = #binary
235 Reply = {NewBin, NewExtra}
236 This operation is similar to out_request; the only difference is
238 that the request body have been encoded.
239Ericsson AB orber 5.1 interceptors(3)