Application Server Support

Speaking with an ORB
Orbs speak in MOs (Message Objects).    A server must announce itself to the orb with it's correct “type” and “code” = 1 (Server Read Request) a special Orb request which registers the server as a type X server.    The Orb does not respond to a read request.   

A client must create a Message Object containing at least four fields all of which are integers:   
     “type” the service type required.
     “code” the specific service required from the server.
     “status” initially a zero.
     “reqId” also initially a zero. This Message Object is sent to an Orb.

The Orb verifies that it knows of the correct service (has a registered server of that type), assigns a request ID and changes the original “reqId” field to the appropriate value and queues it.    When an appropriate server becomes available, the Orb assigns the request to the server and marks that server and the request as busy.    The client's original message (with the “reqId” set to the assigned value) is forwarded to the server.   

The server performs the required service and sends a response message also containing at least four fields: “type” the server's type, “code” = 2 (service response), “status” = 1 if service OK, negative if an error, and “reqId” = the request Id from the Orb.    The implication here is that a server must capture the “reqId” from each new service request for returning with the matching response message.   

The Orb, upon receipt of the server's response message, uses the message's “reqId” to find the original request, marks the request as complete, the server as ready, and forwards the response to the original requester.   

The Orb is highly configurable and it's basic operation can be modified depending upon both type and code.    Request responses can be modified to immedate (Fire & Forget) or delayed until the server has completed.    Scope of a request may be modifed to allow multiple codes to be concatenated into a single request (Marshaling).    For instance, one popular mode is Fire and Forget, where the Orb receives a new request, verifies it has the correct service type, Acks the requester, then attempts to assign it to an available server.    This allows the requester to proceed even while the server is processing.   

If a server dies while processing a request, the request is reassigned to the next available server, unless a server has died while processing this request, three times, in which case the request is deemed poison, and the requester is Naked.   

Most of this stuff is done by the appSrv module so the server writer can focus on performing the service and let AS take care of the rest.    The server code writer uses the SRVC macro set (see appSrv.h) to build a table of service request types and registers it with the system, then hands control over to asMain.    From that point on, all of his registered functions are called as call-backs from asMain when an appropriate service request message arrives.    The server writer, performs the requested service, sends a response message(s) back to the Orb and returns.