interceptors
Describe the functions which must be exported by any supplied Orber native interceptor.
This module contains the mandatory functions for user supplied native interceptors and their intended behavior. See also the User's Guide.
Warning!
Using Interceptors
may reduce the through-put significantly
if the supplied interceptors invoke expensive operations. Hence,
one should always supply interceptors which cause as little overhead
as possible.
Warning!
It is possible to alter the Data
, Bin
and Args
parameter for the in_reply
and out_reply
,
in_reply_encoded
, in_request_encoded
,
out_reply_encoded
and out_request_encoded
,
in_request
and out_request
respectively. But,
if it is done incorrectly, the consequences can be serious.
Note!
The Extra
parameter is set to 'undefined' by Orber when calling
the first interceptor and may be set to any Erlang term. If an
interceptor change this parameter it will be passed on to the next
interceptor in the list uninterpreted.
Note!
The Ref
parameter is set to 'undefined' by Orber when calling
new_in_connection
or new_out_connection
using
the first interceptor. The user supplied interceptor may set NewRef
to any Erlang term. If an interceptor change this parameter it will be
passed on to the next interceptor in the list uninterpreted.
Functions
new_in_connection(Ref, PeerHost, PeerPort) -> NewRef
new_in_connection(Ref, PeerHost, PeerPort, SocketHost, SocketPort) -> NewRef
Ref = term() | undefined
PeerHost = SocketHost = string(), e.g., "myHost@myServer" or "192.0.0.10"
PeerPort = SocketPort = integer()
NewRef = term() | {'EXIT', Reason}
When a new connection is requested by a client side ORB this operation
is invoked. If more than one interceptor is supplied, e.g.,
{native, ['myInterceptor1', 'myInterceptor2']}
, the return value
from 'myInterceptor1' is passed to 'myInterceptor2' as Ref
.
Initially, Orber uses the atom 'undefined' as Ref
parameter
when calling the first interceptor. The return value from the last
interceptor, in the example above 'myInterceptor2', is passed
to all other functions exported by the interceptors. Hence,
the Ref
parameter can, for example, be used as a unique
identifier to mnesia or ets where information/restrictions for
this connection is stored.
The PeerHost and PeerPort variables supplied data of the client ORB which requested a new connection. SocketHost and SocketPort are the local interface and port the client connected to.
If, for some reason, we do not allow the client ORB to connect
simply invoke exit(Reason)
.
new_out_connection(Ref, PeerHost, PeerPort) -> NewRef
new_out_connection(Ref, PeerHost, PeerPort, SocketHost, SocketPort) -> NewRef
Ref = term() | undefined
PeerHost = SocketHost = string(), e.g., "myHost@myServer" or "192.0.0.10"
PeerPort = SocketPort = integer()
NewRef = term() | {'EXIT', Reason}
When a new connection is set up this function is invoked. Behaves
just like new_in_connection
; the only difference is that
the PeerHost and PeerPort variables identifies the target ORB's bootstrap
data and SocketHost and SocketPort are the local interface and port
the client ORB connected via.
closed_in_connection(Ref) -> NewRef
Ref = term()
NewRef = term()
When an existing connection is terminated this operation is invoked. The main purpose of this function is to make it possible for a user to clean up all data associated with the associated connection.
The input parameter Ref
is the return value from
new_in_connection/3
.
closed_out_connection(Ref) -> NewRef
Ref = term()
NewRef = term()
When an existing connection is terminated this operation is invoked. The main purpose of this function is to make it possible for a user to clean up all data associated with the associated connection.
The input parameter Ref
is the return value from
new_out_connection/3
.
in_reply(Ref, Obj, Ctx, Op, Data, Extra) -> Reply
Ref = term()
Obj = #objref
Ctx = [#'IOP_ServiceContext'{}]
Op = atom()
Data = [Result, OutParameter1, ..., OutPramaterN]
Reply = {NewData, NewExtra}
When replies are delivered from the server side ORB to the client side
ORB this operation is invoked. The Data
parameter is a list in which
the first element is the return value value from the target object and
the rest is a all parameters defined as out
or inout
in
the IDL-specification.
in_reply_encoded(Ref, Obj, Ctx, Op, Bin, Extra) -> Reply
Ref = term()
Obj = #objref
Ctx = [#'IOP_ServiceContext'{}]
Op = atom()
Bin = #binary
Reply = {NewBin, NewExtra}
When replies are delivered from the server side ORB to the client side
ORB this operation is invoked. The Bin
parameter is the reply
body still uncoded.
in_request(Ref, Obj, Ctx, Op, Args, Extra) -> Reply
Ref = term()
Obj = #objref
Ctx = [#'IOP_ServiceContext'{}]
Op = atom()
Args = [Argument] - defined in the IDL-specification
Reply = {NewArgs, NewExtra}
When a new request arrives at the server side ORB this operation is invoked.
in_request_encoded(Ref, Obj, Ctx, Op, Bin, Extra) -> Reply
Ref = term()
Obj = #objref
Ctx = [#'IOP_ServiceContext'{}]
Op = atom()
Bin = #binary
Reply = {NewBin, NewExtra}
When a new request arrives at the server side ORB this operation is invoked before decoding the request body.
out_reply(Ref, Obj, Ctx, Op, Data, Extra) -> Reply
Ref = term()
Obj = #objref
Ctx = [#'IOP_ServiceContext'{}]
Op = atom()
Data = [Result, OutParameter1, ..., OutPramaterN]
Reply = {NewData, NewExtra}
After the target object have been invoked this operation is invoked
with the result. The Data
parameter is a list in which
the first element is the return value value from the target object and
the rest is a all parameters defined as out
or inout
in
the IDL-specification.
out_reply_encoded(Ref, Obj, Ctx, Op, Bin, Extra) -> Reply
Ref = term()
Obj = #objref
Ctx = [#'IOP_ServiceContext'{}]
Op = atom()
Bin = #binary
Reply = {NewBin, NewExtra}
This operation is similar to out_reply
; the only difference is
that the reply body have been encoded.
out_request(Ref, Obj, Ctx, Op, Args, Extra) -> Reply
Ref = term()
Obj = #objref
Ctx = [#'IOP_ServiceContext'{}]
Op = atom()
Args = [Argument] - defined in the IDL-specification
Reply = {NewArgs, NewExtra}
Before a request is sent to the server side ORB, out_request
is
invoked.
out_request_encoded(Ref, Obj, Ctx, Op, Bin, Extra) -> Reply
Ref = term()
Obj = #objref
Ctx = [#'IOP_ServiceContext'{}]
Op = atom()
Bin = #binary
Reply = {NewBin, NewExtra}
This operation is similar to out_request
; the only
difference is that the request body have been encoded.