CORBA is useful in many situations. Because of the easy way that CORBA integrates machines from so many vendors, with sizes ranging from mainframes through minis and desktops to hand-helds and embedded systems,
It is the middleware of choice for large (and even not-so-large) enterprises. One of its most important, as well most frequent, uses is in servers that must handle large number of clients, at high hit rates, with high reliability.
CORBA works behind the scenes in the computer rooms of many of the world's largest websites; ones that you probably use every day. Specializations for scalability and fault-tolerance support these systems. But it's not used just for large applications; specialized versions of CORBA run real-time systems, and small embedded systems.
Reason for implementing Corba in client application
Client-side CORBA applications might require multi-threading to allow it to perform other tasks while it is waiting for a synchronous remote invocation to return. It might desire this functionality for several different reasons.
A client application might wish to leverage the static request/response style of invocation but achieve some degree of asynchronous communication. Perhaps the client wishes to perform several synchronous invocations within their own application threads.
This would allow a client to obtain results from several remote servers more quickly. There are several reasons the use of multi-threading might be preferred over the use of DII. DII might be complicate application source code. Application polling associated with the deferred synchronous invocation might result in a performance bottleneck.
A client-side CORBA application might need to respond to events such as incoming invocations, connect requests, or GUI events (mouse clicks, etc.) CORBA products that support only blocking style remote invocations will be unable to process any of these events.
This would mean that a client-side application would be unable to respond to GUI events for the duration of any remote CORBA invocations. This is not an issue for short duration invocations but becomes a problem for longer invocations or in failure or time-out situations. Performing remote invocations within dedicated threads can avoid this issue.
