Object Request Broker

The ORB directs requests to servers based on the Service Type needed and directs the server's responses back to the original requestor. Like a traffic policeman, the ORB capable of directing traffic to a specific destination and it controls the flow of traffic.

All ORB communication is via message objects. Four MO field names are reserved for use by the ORB, they are: "type", "code", "status" and "reqId".    The "type" field determines the service type required, the "code" determines, to the server, exactly what function to perform.    The "reqId" field is used by the ORB to match responses to requests.    A client initially builds a request with "type", "code", "status", and "reqId" integer fields ("reqId" is initially zero but MUST be present).    Two "code"s are reserved for the ORB, 1 is a server read, and 2 is a server response.    Types and Codes are defined in "orb.h".    The Orb uses a Request - Response protocol, that is, every Request has a Response, and the requestor must wait for the response.    If a client makes a request, it MUST wait for the reponse.    If a client makes multiple requests without waiting for respnoses and then exits, any un-assigned requests will be cancelled.    All requests between the Orb and clients or servers are always acknowledged (ACKed) either after the request is complete or immediately, depending upon how the Orb is configured for that service type.    When a server is assigned a task, the Orb sets it's status to busy until the server returns a response, or dies.    Upon boot up, each server must register it's service type with the Orb, whereupon the server becomes available for service request assignments.

Client & Server operation:
A request must contain correct type and code, with status and reqid set to zero.    The response will contain the same type field, the code set to "response", and status and requid set appropriately.    A server must capture the reqid and return it with the response so that the ORB may match the request id of a response to the original request.    Two "codes" are reserved, 1: a server registration, and 2: a response.    A support module is available for building servers called appSrv.

ORB operation:
Received requests are classified, by type, which determines whether to immediately ACK to the requestor or delay.    The type also determines if the request is immediately ready for assignment or must be marshaled.    The request may terminate a marshaled set of requests by making it ready for assignment (dispatch).    When a ready request and a ready server of the same type are found, the request is forwarded to the server, and the server and request are both marked busy.    If an immediate ACK is issued to a requestor of a certain type, that type is thought of as "Fire and Forget".    Most requests are forwarded to an available server and the server's response forwarded back to the requestor.

Marshaling is the ability to treat a set of request messages as a single request.    A set is determined by matching the content of a named field in each message.    The field name is determined by the ORB's configuration.    The message which terminates the set must have a unique "code".    If a request of a "type" defined as marshaled arrives but does not contain the set field, it is reported as an error.   

Load balancingis done by maintaining the ready/busy status of servers and assigning new incoming requests to available servers (not busy).    A server is marked busy when a request is assigned to it and available when the service is complete.    Since most server systems perform bests when re-using hot pages in memory, sporadic requests will be assigned to the most recently used server.   

The ORB is capable of managing servers distributed across many physical CPUs and accepting requests from clients on other machines.   

Client and Server crashes are monitored by the ORB so that a request may be re-assigned if it's server crashes, and a request is aborted if it's requesting client dies.    In the event multiple servers crash while servicing the same request the request is determined to be poisoned and returned to it's origin with an error status.   

Servers may return multi-packet results. Each non-terminal message packet will contain a Data To Follow MO flag bit.    This feature is handled invisible by the ORB and the msg facility   

If a request arrives and no server is available the request will be queued by the ORB until an appropriate server is available.   

The ORB is capable of reliable queuing (caching), as determine by request type, an arriving request will be written to a hard disk cache and the requestor ACKed immediately.    The request remains in the hard cache until it's servicing is complete.    When an ORB is started it reads the hard cache from disk and builds the appropriate request / type chains so that when servers report in, they are immediately assigned.   

Real-Time statisticsare maintained by the ORB for each type. These include Min, Average, and Maximum service and in-queue times along with arrival rates and request counts.   

Using the ORB: The two most common ways to talk to an ORB are as a server or client.    As previousle stated, the ORB speaks only in Message Objects, hence all clients and servers must communicate using MO.   

An ORB Client must create a request MO in an Io message, then insert the desired integer "type", "code", and a zero value "reqId" and "status" fields, additionally, such request information as is required by the desired service "type" server.    A handy way to create the request is via msgMkDst(), then msgSnd(), and finally msgRcv().   

An ORB Server must send a MO with the integer fields "type" = ServiceTypeSupported, and "code" = SRV_READ message to the ORB at the server's initialization.    The server must then wait for a service request from the ORB.    Upon receiving a service request, the server must save the "type", "code", and "reqId" fields.    The server must next extract any specific request information fields from the message and proceed with processing the request.    When processing is complete, the server should build a response message containing an MO and insert the saved "type", "code", "reqId", and a new "status" field.    The status should contain an infrastructure OK (1 one), a NOTFND (zero), or an error (negative value).    This message should tben be sent to the ORB and the original request message freed.    Again the msg layer of the infrastructure provides a good way to handle all messaging using: msgMkDst() (initial SRV_READ), msgSnd(), msgRcv(), msgMkRsp(), and msgFree().