(Part of the CORBA FAQ, Copyright © 1996-99)
[Recently did some wordsmithing (12/1998). Click here to go to the next FAQ in the “chain” of recent changes]
Performance is the most common reason.
Applications that perform a series of tasks that must be done sequentially cannot benefit from asynchronous communication. Applications that make only short duration remote operations have little need for asynchronous communication. Asynchronous communication can allow an application to perform additional tasks instead of waiting for tasks to complete. Applications that have a number of tasks that can be performed in any order can often benefit from distributed asynchronous communication. This becomes more important for applications that call lengthy remote operations. In order to benefit from asynchronous communication, an application must be able to perform some task after the request is issued but before the response is available. Tasks might include prompting for additional user input, displaying information, or making additional remote operation requests. Typical asynchronous communication candidates include applications that need to perform several lengthy database queries or complex calculations.
[ Top | Bottom | Previous section | Next section ]
Kind of. At the lowest level CORBA supports two modes of communication:
At the lowest level, the CORBA deferred synchronous communication does allow a certain degree of asynchronous communication. Polling for responses represents only one form of asynchronous communication. Other more sophisticated asynchronous communication can only be achieved by developing an architecture on top of the lowest levels of CORBA.
[ Top | Bottom | Previous section | Next section ]
[Recently added the last paragraph (12/1998). Click here to go to the next FAQ in the “chain” of recent changes]
Theoretically, no. They come from different families but hang out together a lot. Each has its own identity, but sometimes they can work together to make things go much more smoothly.
Applications that wish to perform multiple concurrent tasks can use multiple threads instead of multiple asynchronous or deferred requests. Just as the distribution of operations across processes can allow for concurrent processing, performing tasks in different threads can allow for concurrent processing. Distribution supports concurrent processing across a network and threading supports concurrent processing within a particular machine. An application that needs to perform concurrent distributed requests can issue requests in different threads or issue asynchronous requests. The use of threading adds complex synchronization issues to the development process.
See the section on threading for more about how CORBA fits with a multi-threaded architecture.
[ Top | Bottom | Previous section | Next section ]
Yeah, but you can fake it pretty easily.
While CORBA does support a deferred synchronous request/response, it does not directly support distributed requests with a callback driven response. A callback driven response allows an application to perform an operation on a distributed object, associate a callback with the response, continue with other processing. When the server responds, the associated callback is automatically executed within the original caller’s application.
[ Top | Bottom | Previous section | Next section ]
E-mail us