(Part of the CORBA FAQ, Copyright © 1996-99)
A server is defined as an Interface in CORBA IDL. Data passing between the client and the server is defined as IDL structures, sequences, etc. The IDL is compiled with an IDL compiler and the generated code is included within the client and server processes. The server implements a particular interface. The implementation is the distributed object. Clients communicate with the object through an object reference. When an operation is performed on the object reference, network communication occurs, operation parameters are sent to the server and the actual distributed object executes the operation. It then returns any appropriate data to the client.
[ Top | Bottom | Previous section | Next section ]
Depends on the specific vendor and product offering, but there is nothing in the standard that you will find terribly onerous.
Some applications want to make distributed requests, but not wait for the response. Ideally, they want to be notified when the response is available. Threads can be used to allow applications to make more than one request or to continue performing other tasks while waiting for a response, but the thread making a request is blocked until the response is available. CORBA communication is basically a synchronous request/response. This is true for all static invocations. Dynamic invocations do support a deferred request response. This means that an application can issue a request and poll for the response. CORBA communication can be used to notify applications when responses associated with earlier requests are available. This can lead to a more complex application architecture.
[ Top | Bottom | Previous section | Next section ]
[Recently created (12/1998) and modified list and added links (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]
Before you can use CORBA to client/server communication you must either implement your own request broker that supports portions of the CORBA specification including IIOP (not suggested) or you can obtain an object request broker that implements the CORBA specification. Many companies sell object request brokers that implement all or some of the CORBA specification, including various parts of the CORBA 2.x and 3.x specification, CORBA services, and other third-party integrations. Links to their company web sites are included (alphabetically) below:
Additional information can be found at: * OMG List of free stuff.
[ Top | Bottom | Previous section | Next section ]
[Recently created (12/1998). Click here to go to the next FAQ in the “chain” of recent changes]
The CORBA specification makes no specific statement regarding the blocking behavior of remote invocations. It does require that static invocations be synchronous. This means that an application will not proceed to the next line of code following a remote invocation until the remote invocation returns, either normally or abnormally. A non-blocking, or dispatching remote invocation will allow event processing for the duration of the remote invocation. This means that ORB or non-ORB events can be processed while an application is “waiting” for an invocation to return. ORB events could be object connection requests or object invocation requests. Non-ORB events might be GUI events such as mouse clicks, signal handling, or raw file descriptor activity. The CORBA specifications allows the CORBA vendor to decide on the blocking or dispatching behavior for remote invocations. CORBA products that use blocking transports such as the DCE RPC are un-able to support non-blocking remote invocations.
[ Top | Bottom | Previous section | Next section ]
[Recently created (12/1998). Click here to go to the next FAQ in the “chain” of recent changes]
Dead-locks can occur between two or more CORBA servers. Dead-locks can only occur under certain conditions. First of all, a cyclic or looping relationship must exist between the servers. For example: one server must make invocations on the second server which is in turn implemented to make an invocation upon the first server. This situation is referred to by some as nested call-backs. While cyclic relationship between servers might seem easy to avoid, it often arises, if CORBA is being used to support the combination of client/server request/response and server/client notification. If a cyclic relationship exists and a remote invocation blocks a process, a dead-lock will occur. Blocking can occur upon remote invocation if multiple threads are not used and the CORBA product does not dispatch events while remote invocations are being performed.
[ Top | Bottom | Previous section | Next section ]
E-mail us