interceptors(3erl)					     Erlang Module Definition						interceptors(3erl)

NAME

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

DESCRIPTION

       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  intercep-
       tor in the list uninterpreted.

EXPORTS

       new_in_connection(Ref, PeerHost, PeerPort) -> NewRef
       new_in_connection(Ref, PeerHost, PeerPort, SocketHost, SocketPort) -> NewRef

	      Types  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 .  Ini-
	      tially,  Orber  uses the atom 'undefined' as Ref parameter when calling the first interceptor. The return value from the last inter-
	      ceptor, in the example above 'myInterceptor2', is passed to all other functions exported by the interceptors. Hence, the Ref parame-
	      ter 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

	      Types  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

	      Types  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

	      Types  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

	      Types  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

	      Types  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

	      Types  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

	      Types  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

	      Types  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-speci-
	      fication.

       out_reply_encoded(Ref, Obj, Ctx, Op, Bin, Extra) -> Reply

	      Types  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

	      Types  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

	      Types  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.

Ericsson AB							   orber 3.6.20 						interceptors(3erl)