Core Architecture

The core architecture implements the most basic concepts of the programming model provided by ORBs, such as servant and proxy creation, invocation issue and dispatching, etc. Alternatives to the core architecture may be developed to provide other programming models, such as message-based communication. The following sections describe the core architectures defined by layers defined in OiL's standard distribution.

Base Core

Layer:	`base`
Classes:	*`oil.kernel.base.`**

The base core layer defines six components that provide the most basic implementation of the core architecture. 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 typically provided by a complementary layer, such as a RMI layer.

Client Broker: Façade component that provides client-side features (facet broker), such as proxy creation from some object reference information like CORBA's stringfied IOR or corbaloc. It requires a reference decoder to extract information from textual references (receptacle references), and a factory to create proxies from this information (receptacle proxies).
Object Proxies: Component that provides a factory to create the proxies used by applications (facet proxies). This component basically defines the programming model provided by OiL ORBs because it defines the features provided by proxies. The proxies use the object provided by receptacle invoker to perform remote invocations.
Operation Invoker: Component that manages invocations requests and replies issued through the provided facet invoker. Basically, it uses the object provided by receptacle requests to create channels to remote brokers, as well as send requests and receive replies through such channels.
Server Broker: Façade component that provides server-side features (facet broker), such as servant registration or control invocation processing. It requires a service to register active servant implementations (receptacle objects) and to accept the reception of remote invocations (receptacle acceptor).
Request Dispatcher: Component that provides a registry of active servants (facet objects) and effectively performs invocations requested remotely on the proper servant implementations (facet dispatcher).
Request Receiver: Component that accepts channels from remote clients, receives remote invocation requests, and send replies with the results of each invocation (receptacle listener) dispatched to servants (receptacle dispatcher). It provides an API to control acceptation of invocation requests (facet acceptor).
Basic System: Component that provides access to basic features of the underlying platform, such as support for network sockets (facet sockets).

Typing Extension

Layer:	`typed`
Classes:	*`oil.kernel.typed.`**

This layer extends the core architecture to add support for typing information about values and objects. Such support is essential for RMI technologies that rely on typing and interface information, such as CORBA or SOAP. 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 typically provided by a complementary layer, such as a RMI layer.

Client Broker: This component is extended to resolve interface of new proxies using the information provided by receptacle types.
Object Proxies: This component is extended to implement typed proxies that only provide members defined in its interface. Such information must be provided by receptacle indexer. This receptacle is also used to get implementation of operations that must be executed locally instead of remotely.
Server Broker: This component is extended to resolve interface of new servants using the information provided by receptacle types and associate this information to each servant (receptacle mapper).
Request Dispatcher: This component is extended to perform checks before dispatching invocations to allow only methods declared in the interface of each servant. Such information must be provided by receptacle indexer. This receptacle is also used to get implementation of implicit operations that are not implemented by the servant.

Threading Extension

Layer:	`cooperative`
Classes:	*`oil.kernel.cooperative.`**

This layer extends the base core to add support for multithreading so different clients can be served in independent threads and minimize the influence in each other response time. Moreover, it adds support to use a single proxy or remote connection by different threads transparently and without problems related to race conditions.

Operation Invoker: This component is extended to implement mutual exclusion mechanisms to avoid that different thread interfere with each other while performing invocations to the same server, since they will probably use a common channel to the remote context. For such the component requires access to thread synchronization mechanisms provided by the underlying system (receptacle tasks). Additionally, the component also provides a access control service (facet mutex) for the resources managed by the component, such as the channels to remote contexts. Such service is useful for implementation of RMI protocols that might receive data while sending invocations or send data while receiving replies.
Request Receiver: This component is extended to in the same was as the previous component, so it also provides access control to channels shared by different threads and an access control service (facet mutex) for components that require access to channels. Additionally, this component is also extended to created threads (receptacle tasks) so invocation requests are received and dispatched independently from each other.
Basic System: This component is extended to provide support for multithreading in the current platform. Basically, it supports thread creation, synchronization (facet tasks), and scheduling control (facet control).