1interceptors(3)            Erlang Module Definition            interceptors(3)
2
3
4

NAME

6       interceptors  -  Describe  the  functions which must be exported by any
7       supplied Orber native interceptor.
8

DESCRIPTION

10       This module contains the mandatory functions for user  supplied  native
11       interceptors and their intended behavior. See also the User's Guide.
12
13   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
18
19   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
25
26   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
32
33   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
40

EXPORTS

42       new_in_connection(Ref, PeerHost, PeerPort) -> NewRef
43       new_in_connection(Ref,  PeerHost,  PeerPort, SocketHost, SocketPort) ->
44       NewRef
45
46              Types:
47
48                 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
54              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
66              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
70              If,  for  some reason, we do not allow the client ORB to connect
71              simply invoke exit(Reason).
72
73       new_out_connection(Ref, PeerHost, PeerPort) -> NewRef
74       new_out_connection(Ref, PeerHost, PeerPort, SocketHost, SocketPort)  ->
75       NewRef
76
77              Types:
78
79                 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
85              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
91       closed_in_connection(Ref) -> NewRef
92
93              Types:
94
95                 Ref = term()
96                 NewRef = term()
97
98              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
103              The  input parameter Ref is the return value from new_in_connec‐
104              tion/3.
105
106       closed_out_connection(Ref) -> NewRef
107
108              Types:
109
110                 Ref = term()
111                 NewRef = term()
112
113              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
118              The input parameter Ref is the return value from new_out_connec‐
119              tion/3.
120
121       in_reply(Ref, Obj, Ctx, Op, Data, Extra) -> Reply
122
123              Types:
124
125                 Ref = term()
126                 Obj = #objref
127                 Ctx = [#'IOP_ServiceContext'{}]
128                 Op = atom()
129                 Data = [Result, OutParameter1, ..., OutPramaterN]
130                 Reply = {NewData, NewExtra}
131
132              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
138       in_reply_encoded(Ref, Obj, Ctx, Op, Bin, Extra) -> Reply
139
140              Types:
141
142                 Ref = term()
143                 Obj = #objref
144                 Ctx = [#'IOP_ServiceContext'{}]
145                 Op = atom()
146                 Bin = #binary
147                 Reply = {NewBin, NewExtra}
148
149              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
153       in_request(Ref, Obj, Ctx, Op, Args, Extra) -> Reply
154
155              Types:
156
157                 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
164              When a new request arrives at the server side ORB this operation
165              is invoked.
166
167       in_request_encoded(Ref, Obj, Ctx, Op, Bin, Extra) -> Reply
168
169              Types:
170
171                 Ref = term()
172                 Obj = #objref
173                 Ctx = [#'IOP_ServiceContext'{}]
174                 Op = atom()
175                 Bin = #binary
176                 Reply = {NewBin, NewExtra}
177
178              When a new request arrives at the server side ORB this operation
179              is invoked before decoding the request body.
180
181       out_reply(Ref, Obj, Ctx, Op, Data, Extra) -> Reply
182
183              Types:
184
185                 Ref = term()
186                 Obj = #objref
187                 Ctx = [#'IOP_ServiceContext'{}]
188                 Op = atom()
189                 Data = [Result, OutParameter1, ..., OutPramaterN]
190                 Reply = {NewData, NewExtra}
191
192              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
198       out_reply_encoded(Ref, Obj, Ctx, Op, Bin, Extra) -> Reply
199
200              Types:
201
202                 Ref = term()
203                 Obj = #objref
204                 Ctx = [#'IOP_ServiceContext'{}]
205                 Op = atom()
206                 Bin = #binary
207                 Reply = {NewBin, NewExtra}
208
209              This operation is similar to out_reply; the only  difference  is
210              that the reply body have been encoded.
211
212       out_request(Ref, Obj, Ctx, Op, Args, Extra) -> Reply
213
214              Types:
215
216                 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
223              Before  a request is sent to the server side ORB, out_request is
224              invoked.
225
226       out_request_encoded(Ref, Obj, Ctx, Op, Bin, Extra) -> Reply
227
228              Types:
229
230                 Ref = term()
231                 Obj = #objref
232                 Ctx = [#'IOP_ServiceContext'{}]
233                 Op = atom()
234                 Bin = #binary
235                 Reply = {NewBin, NewExtra}
236
237              This operation is similar to out_request; the only difference is
238              that the request body have been encoded.
239
240
241
242Ericsson AB                        orber 5.1                   interceptors(3)
Impressum