The RMI architecture implements the support for some RMI technology, such as CORBA, ICE or SOAP. The following sections describe the core architectures defined by layers defined in OiL's standard distribution.
Layer: | corba |
Classes: |
oil.corba.idl.* oil.corba.giop.* oil.corba.iiop.*
|
The CORBA support layer defines a series of components that provide the support for OiL to interoperate with other CORBA ORBs. This layer complements the core layer extended with support for typing (<%=link("Core","typed","#typed")%>). Below, there is an image that illustrates the architecture defined by this layer, followed by a brief description of each component. Components in light gray are provided by the core layer extended with typing support.
registry
and types
, but the former only informs types stored locally, while the later can import definition from a remote CORBA Interface Repository (receptacle remote
).
Moreover, it provides facet compiler
to interpret IDL specification and load the information into the repository.
Facet indexer
provide information about the members provided by each interface, including reference basic operations and _get_*
and _set_*
attribute access methods.
Multiple receptacle observers
is used to notify about changes in the information stored in the repository.types
to resolve interface information when it is provided or receptacle invoker
to invoke operation _interface
of CORBA to discover the interface of the remote servant.
This component also allows indexing of methods declared in the IDL of the proxy interface (receptacle members
) as well as implicit operations, such as CORBA's reference operations: _interface
, _is_a
, _non_existent
, _is_equivalent
, etc.mapper
for registration of interface information of servants.
This component also allows indexing of methods declared in the IDL of the proxy interface (receptacle members
) as well as implicit operations, such as CORBA's reference operations: _interface
, _is_a
, _non_existent
, _is_equivalent
, etc.corbaloc
URL.
Receptacle types
is used to find out the interface of servants for generation of references.
Multiple receptacle profilers
is used to create IOR profiles that identify the access points provided to reach the servant when a reference for it is created.
Receptacle codec
is used to encode reference information in a byte stream, i.e. a string.profiler
) using receptacle codec
.
Currently, OiL's standard distribution provides only one component for encoding/decoding of IIOP IOR profiles.requests
) to create channels to remote ORBs (receptacle channels
) using information provided in IOR profiles, which are decoded using services provided by multiple receptacle profilers
.
Additionally, the provided service also allows to send invocation requests and receive replies returned, which are encoded and decoded through receptacle messenger
.
If receptacle mutex
is connected, them it is used to request exclusive access to channels before attempts to access it.listener
) to accept channels from remote ORBs (receptacle channels
).
Additionally, the provided service also allows to receive invocation requests and send replies, which are encoded and decoded through receptacle messenger
.
If receptacle mutex
is connected, them it is used to request exclusive access to channels before attempts to access it.
Furthermore, receptacle indexer
is used to retrieve typing information about each method invoked, because such information is necessary to extract the parameter values from GIOP messages.messenger
) using receptacle codec
.codec
).
If receptacle proxies
is connected then it is used to automatically create proxies for each object reference decoded.
If receptacle profiles
is connected then it is used to compare IOR profiles of object references decoded to find out whether they are references to local servants or not.
It receptacle objects
is connected then it is used to create implicit servants (see section <%=link("Features","Implicit Servants","#implicit")%>) and to retrieve servant implementation of local object references (see section <%=link("Features","Reference Resolution","#resolution")%>).sockets
.sockets
.Layer: | intercepted |
Classes: | oil.corba.interceptors.* |
This layer extends the CORBA base layer to redefine some components to use the template and port model provided by LOOP that supports port interception. This way, interceptors can be registered at specific ports of the architecture to implement invocation interception in CORBA brokers.
Layer: | gencode |
Classes: | oil.corba.giop.CodecGen |
This layer simply redefine component ValueEncoder
to use an alternative implementation based on dynamic generation of marshaling code for better performance of value encoding and decoding.
Layer: | ludo |
Classes: |
oil.ludo.* oil.corba.iiop.*
|
The LuDO support layer defines five components that provide the support for a very simple protocol designed for use within Lua. This layer is a comprehensible example of the implementation of a RMI protocol in OiL. Below, there is a brief description of each component provided by this layer.
requests
) to create channels to remote ORBs (receptacle channels
), and send invocation requests and receive replies returned.listener
) to accept channels from remote ORBs (receptacle channels
), and receive invocation requests and send replies.encoder
).sockets
.sockets
.