Explore topic-wise InterviewSolutions in .

CORBA objects support OPERATIONS that take and return SIMPLE and complex IDL types.

CORBA objects support operations that take and return simple and complex IDL types.

CORBA OBJECTS are DEFINED as INTERFACES in IDL.

CORBA objects are defined as Interfaces in IDL.

The CORBA architecture is designed to SUPPORT the distribution of objects implemented in a variety of programming languages. This is achieved by defining an interface definition language that can be mapped to a number of EXISTING languages. IDL is used to define the SERVICES offered by a particular distributed object. CORBA defines a wire protocol for making requests to an object and for the object to respond to the application making the request. The IIOP protocol ensures INTEROPERABILITY between client applications and server based objects. CORBA then extends on this basic set of functionality by defining a set of low level services. These services are required by applications regardless of the exact nature of the applications. These services are defined in CORBA IDL. CORBA vendors preprocess the service IDL and then implement the service with varying degrees of robustness.

The CORBA architecture is designed to support the distribution of objects implemented in a variety of programming languages. This is achieved by defining an interface definition language that can be mapped to a number of existing languages. IDL is used to define the services offered by a particular distributed object. CORBA defines a wire protocol for making requests to an object and for the object to respond to the application making the request. The IIOP protocol ensures interoperability between client applications and server based objects. CORBA then extends on this basic set of functionality by defining a set of low level services. These services are required by applications regardless of the exact nature of the applications. These services are defined in CORBA IDL. CORBA vendors preprocess the service IDL and then implement the service with varying degrees of robustness.

In other words, when representing the concept of a "FOREIGN exchange rate" in IDL, should the IDL interface be called ForeignExchangeRate or Foreign_Exchange_Rate? Similarly should a method to "EXECUTE the trade" be called executeTheTrade() or execute_the_trade()? There are many stylistic issues that BOIL down to "I think it looks better this way or that way." But from a development/maintenance cost perspective, these have little if any value. However there are some nits that can bite you if you choose one over the other. If you expect to interoperate with Smalltalk, the underscore can create an ambiguity, particularly if you mix the two STYLES. For example, the IDL names execute_the_trade() and executeTheTrade() both are mapped into the Smalltalk name executeTheTrade(), which could create an ambiguity if the styles are mixed. In this case, it is best to avoid the underscores. Similarly if you expect to interoperate with the C language, the IDL :: TOKEN is mapped to an _ in C, which can create ambiguities. In this case it is best to avoid the underscores. It's a small point, to be sure, but it can catch up to you in the long run.

In other words, when representing the concept of a "foreign exchange rate" in IDL, should the IDL interface be called ForeignExchangeRate or Foreign_Exchange_Rate? Similarly should a method to "execute the trade" be called executeTheTrade() or execute_the_trade()? There are many stylistic issues that boil down to "I think it looks better this way or that way." But from a development/maintenance cost perspective, these have little if any value. However there are some nits that can bite you if you choose one over the other. If you expect to interoperate with Smalltalk, the underscore can create an ambiguity, particularly if you mix the two styles. For example, the IDL names execute_the_trade() and executeTheTrade() both are mapped into the Smalltalk name executeTheTrade(), which could create an ambiguity if the styles are mixed. In this case, it is best to avoid the underscores. Similarly if you expect to interoperate with the C language, the IDL :: token is mapped to an _ in C, which can create ambiguities. In this case it is best to avoid the underscores. It's a small point, to be sure, but it can catch up to you in the long run.

CORBA's goal is to address interoperability at various levels. There is a history to this. In the EARLY versions of CORBA, interoperability between platforms and programming languages was addressed. This included the standardization of IDL and the mapping of IDL to a programming language. While a client and server DEVELOPED with the same vendor's ORB could talk to one another, a client and server developed with different vendors' ORBs were not likely to interoperate. CORBA 2.0 introduced interoperability between different ORB vendors. This resulted from the introduction of a standard wire protocol called General Inter-ORB Protocol (GIOP), and the incarnation for GIOP for the internet, known as Internet Inter-ORB Protocol (IIOP). So CORBA 2.0 compliant ORBs will interoperate. This means a client using ORB vendor A can talk to a server using ORB vendor B. Interoperability is actually a broader issue than just have ORB vendor A talking to ORB vendor B. FULLER interoperability means that various services interoperate. For EXAMPLE, while a CORBA object can talk to a DCOM object via a protocol bridge, can the CORBA Transaction SERVICE talk to the Microsoft Transaction Service to have a seamless transaction between systems? This broader interoperability at the service level is being addressed now.

CORBA's goal is to address interoperability at various levels. There is a history to this. In the early versions of CORBA, interoperability between platforms and programming languages was addressed. This included the standardization of IDL and the mapping of IDL to a programming language. While a client and server developed with the same vendor's ORB could talk to one another, a client and server developed with different vendors' ORBs were not likely to interoperate. CORBA 2.0 introduced interoperability between different ORB vendors. This resulted from the introduction of a standard wire protocol called General Inter-ORB Protocol (GIOP), and the incarnation for GIOP for the internet, known as Internet Inter-ORB Protocol (IIOP). So CORBA 2.0 compliant ORBs will interoperate. This means a client using ORB vendor A can talk to a server using ORB vendor B. Interoperability is actually a broader issue than just have ORB vendor A talking to ORB vendor B. Fuller interoperability means that various services interoperate. For example, while a CORBA object can talk to a DCOM object via a protocol bridge, can the CORBA Transaction Service talk to the Microsoft Transaction Service to have a seamless transaction between systems? This broader interoperability at the service level is being addressed now.

Interoperability DESCRIBES WHETHER or not two components of a system that were developed with different tools or different VENDOR products can work TOGETHER. CORBA addresses interoperability at various levels.

Interoperability describes whether or not two components of a system that were developed with different tools or different vendor products can work together. CORBA addresses interoperability at various levels.

There are many different performance characteristics that are important. Performance should also scale linearly as connections or objects increase. While raw throughput between one client and one server is important, it is not the only or the most CRITICAL characteristic. Many characteristics of the CORBA implementation should be considered. As always, actual application requirements to the relative importance of these different characteristics. With the high speed nature of most CORBA implementations, raw client/server throughput is often not a bottleneck. It is also important that factors such as the number of operations does not slow down individual remote invocations. Here is a list of some important performance characteristics.

• Scalability ACROSS connected client applications.
• Scalability across objects within a CORBA server.
• Raw throughout between one client and one server.
• Activation time of server processes.
• Activation time of CORBA objects.
• STREAMING time for different IDL types.
• Connection time associated with the first remote operation, _narrow CALL, _is_a call etc.
• Minimum memory consumed by a CORBA object.
• Number of file descriptors consumed by a complex network of distributed objects.

There are many different performance characteristics that are important. Performance should also scale linearly as connections or objects increase. While raw throughput between one client and one server is important, it is not the only or the most critical characteristic. Many characteristics of the CORBA implementation should be considered. As always, actual application requirements to the relative importance of these different characteristics. With the high speed nature of most CORBA implementations, raw client/server throughput is often not a bottleneck. It is also important that factors such as the number of operations does not slow down individual remote invocations. Here is a list of some important performance characteristics.

• Scalability across connected client applications.
• Scalability across objects within a CORBA server.
• Raw throughout between one client and one server.
• Activation time of server processes.
• Activation time of CORBA objects.
• Streaming time for different IDL types.
• Connection time associated with the first remote operation, _narrow call, _is_a call etc.
• Minimum memory consumed by a CORBA object.
• Number of file descriptors consumed by a complex network of distributed objects.

They can. Different CORBA implementations can vary significantly in performance. Good implementations should be fairly similar SINCE network performance defines the maximum achievable performance CHARACTERISTICS. Network latency does represent the significant PORTION of DISTRIBUTED invocation latency.

They can. Different CORBA implementations can vary significantly in performance. Good implementations should be fairly similar since network performance defines the maximum achievable performance characteristics. Network latency does represent the significant portion of distributed invocation latency.

Yes: connection-less architectures. With a connection-less architecture, an object does not "know" any thing about the object references which REFER to it, including the NUMBER of references. This is the style found most OFTEN on the WORLD WIDE Web.

Yes: connection-less architectures. With a connection-less architecture, an object does not "know" any thing about the object references which refer to it, including the number of references. This is the style found most often on the World Wide Web.

CORBA does not directly support distributed reference counting. This was a conscious decision on the part of its DESIGNERS. While CORBA does not directly support reference counting, it is possible to build reference counting into a particular distributed OBJECT architecture. This can be done through an explicit SESSION management facility which can be exposed through factories or other remote interfaces. While it is possible to DESIGN reference counting into an application, it is the burden of the application designer/developer to ensure that such an APPROACH is implemented correctly.

CORBA does not directly support distributed reference counting. This was a conscious decision on the part of its designers. While CORBA does not directly support reference counting, it is possible to build reference counting into a particular distributed object architecture. This can be done through an explicit session management facility which can be exposed through factories or other remote interfaces. While it is possible to design reference counting into an application, it is the burden of the application designer/developer to ensure that such an approach is implemented correctly.

There are several reasons why reference counting might be important.

Clean-up: An APPLICATION might like to know that a remote object no longer has ACTIVE references. The typical reason is that object that are no longer in use can be removed from memory. This allows resources associated with a remote object to be reclaimed. This is ESPECIALLY important if a distinct remote object exists for each client application.

Reporting: In many cases it might be helpful to know the usage patterns for a particular remote object. Without reference counting, an object could only report the total number of method invocations performed. Information regarding the number of connected clients or average usage per client would only be available if a reference counting architecture was in place.

Load Balancing: In some cases, a client might gain ACCESS to a remote object via an out-of-process factory. The goal of the factory might be to support clients via a pool of remote objects hosted on different machines. The factory can choose which remote object to return based on actual usage. Reference counting might be ONE mechanism for determining a remote object's "load".

There are several reasons why reference counting might be important.

Clean-up: An application might like to know that a remote object no longer has active references. The typical reason is that object that are no longer in use can be removed from memory. This allows resources associated with a remote object to be reclaimed. This is especially important if a distinct remote object exists for each client application.

Reporting: In many cases it might be helpful to know the usage patterns for a particular remote object. Without reference counting, an object could only report the total number of method invocations performed. Information regarding the number of connected clients or average usage per client would only be available if a reference counting architecture was in place.

Load Balancing: In some cases, a client might gain access to a remote object via an out-of-process factory. The goal of the factory might be to support clients via a pool of remote objects hosted on different machines. The factory can choose which remote object to return based on actual usage. Reference counting might be one mechanism for determining a remote object's "load".

DISTRIBUTED reference counting is something typically performed EITHER by a remote object, the factory for the remote object or possibly by the ORB itself. The KEY concept is that something is tracking the NUMBER of connections to a particular remote object. The counter is incremented when a new reference to the remote object is created. The counter is decremented when a reference to the remote object is destroyed. The idea is that by looking at the counter, one can determine if the remote object is still in use.

Distributed reference counting is something typically performed either by a remote object, the factory for the remote object or possibly by the ORB itself. The key concept is that something is tracking the number of connections to a particular remote object. The counter is incremented when a new reference to the remote object is created. The counter is decremented when a reference to the remote object is destroyed. The idea is that by looking at the counter, one can determine if the remote object is still in use.

The CORBA LIFECYCLE specification defines a GenericFactory interface from which all factories should INHERIT, but this is not REQUIRED. The CORBA specification also defines a FACTORY for factories, known as a factory finder. The factory finder is a just a CORBA factory which ACT as a factory for other factory interfaces.

The CORBA Lifecycle specification defines a GenericFactory interface from which all factories should inherit, but this is not required. The CORBA specification also defines a factory for factories, known as a factory finder. The factory finder is a just a CORBA factory which act as a factory for other factory interfaces.

A factory is a CORBA Object that RETURNS another CORBA object via one of its CORBA OPERATIONS. There are many different TYPES of factories with many different purposes. In fact, the OMG has defined several services that are actually factories.

A factory is a CORBA Object that returns another CORBA object via one of its CORBA operations. There are many different types of factories with many different purposes. In fact, the OMG has defined several services that are actually factories.

If you CREATE the object reference from a string via a CORBA 2.0 compliant library then the object reference is an IOR. If you create the object reference via resolve_initial_references() the ORB libraries might create an OR or an IOR. Some ORBS from companies such as Expersoft and Visigenic ORBs support only native IIOP and thus all references are IORs. On the other hand, some commericial vendors who shipped ORBS that supported IDL before IIOP existed pass around references that are not IORs and thus these referencesmight not always be IORs. Many CASES an ORB vendor might support a proprietary protocol in addition to IIOP. Note: even if resolve_initial_references() returns and IOR, the IOR almost always refers to an object implemented with the same ORB environment as the application calling resolve_initial_references(). If the object reference is obtained from a server, a NameContext, or from a factory, the process and ORB libraries that originially created the object reference, determine if the reference is an OR or an IOR.

If you create the object reference from a string via a CORBA 2.0 compliant library then the object reference is an IOR. If you create the object reference via resolve_initial_references() the ORB libraries might create an OR or an IOR. Some ORBs from companies such as Expersoft and Visigenic ORBs support only native IIOP and thus all references are IORs. On the other hand, some commericial vendors who shipped ORBS that supported IDL before IIOP existed pass around references that are not IORs and thus these referencesmight not always be IORs. Many cases an ORB vendor might support a proprietary protocol in addition to IIOP. Note: even if resolve_initial_references() returns and IOR, the IOR almost always refers to an object implemented with the same ORB environment as the application calling resolve_initial_references(). If the object reference is obtained from a server, a NameContext, or from a factory, the process and ORB libraries that originially created the object reference, determine if the reference is an OR or an IOR.

You never learn, do you? Let's DISCUSS this at another time. When you are in a POSITION where you need this knowledge, you won't be getting your information from this document. In the meantime, learn all about NAMING SERVICE.

You never learn, do you? Let's discuss this at another time. When you are in a position where you need this knowledge, you won't be getting your information from this document. In the meantime, learn all about Naming Service.

It doesn't. Your local ORB creates a local proxy for the REMOTE OBJECT represented by the IOR. All your program ever sees directly is the object REFERENCE for the proxy. The ORB takes CARE of everything ELSE.

It doesn't. Your local ORB creates a local proxy for the remote object represented by the IOR. All your program ever sees directly is the object reference for the proxy. The ORB takes care of everything else.

You'll PROBABLY never need them because you'll probably never see an EXAMPLE of an IOR. These only exist in the NETHER WORLD between ORBS.

You'll probably never need them because you'll probably never see an example of an IOR. These only exist in the nether world between ORBs.

It DEPENDS. PROFILES are defined by the people who developed the protocol and registered its tag with OMG. IIOP uses a single-component profile, while DCE CIOP uses a multiple-component profile.

It depends. Profiles are defined by the people who developed the protocol and registered its tag with OMG. IIOP uses a single-component profile, while DCE CIOP uses a multiple-component profile.

A high-performance way for an ORB to tell another ORB what it needs to know to use the IOR properly. There are TWO types, single- and multiple-component. Both TYPICALLY contain information about the presence of ORB services such as Transaction SERVICE.

A high-performance way for an ORB to tell another ORB what it needs to know to use the IOR properly. There are two types, single- and multiple-component. Both typically contain information about the presence of ORB services such as Transaction Service.

The specific details can be found at the OMG WEB site, and probably shouldn't MATTER to you. But it doesn't hurt to KNOW that an IOR consists of a type ID and one or more tagged profiles.

The specific details can be found at the OMG web site, and probably shouldn't matter to you. But it doesn't hurt to know that an IOR consists of a type ID and one or more tagged profiles.

Yes, because this is something that inherently REQUIRES cooperation between DIFFERENT vendors and ORBs. Ordinary object REFERENCES exist within an ORB so there was no compelling REASON to standardize formats.

Yes, because this is something that inherently requires cooperation between different vendors and ORBs. Ordinary object references exist within an ORB so there was no compelling reason to standardize formats.

Then you need to know about interoperable OBJECT REFERENCES (IOR).

Then you need to know about interoperable object references (IOR).

USE _var when you can, because they are SIMPLER. Use _ptr when you have to, usually for performance reasons. Sometimes there are critical windows you can't afford to let the system take over memory management. As a very rough guide, think about _ptr when you have many fine-grained objects and KNOWN TIMING or performance problems.

Use _var when you can, because they are simpler. Use _ptr when you have to, usually for performance reasons. Sometimes there are critical windows you can't afford to let the system take over memory management. As a very rough guide, think about _ptr when you have many fine-grained objects and known timing or performance problems.

You're the one who WANTED to be an EXPERT. We just wanted to raise your AWARENESS so that you'll think twice when comparing object references. Besides, this is a good way to ILLUSTRATE how CORBA requires a LITTLE learning on your part.

You're the one who wanted to be an expert. We just wanted to raise your awareness so that you'll think twice when comparing object references. Besides, this is a good way to illustrate how CORBA requires a little learning on your part.

From a practical standpoint, these CONSIDERATIONS don't come up all that often, even for people who have to work at this level. Fortunately, most users can merely USE the Naming Service and work with (ESSENTIALLY) character strings for NAMES, and AVOID all the complexity above.

From a practical standpoint, these considerations don't come up all that often, even for people who have to work at this level. Fortunately, most users can merely use the Naming Service and work with (essentially) character strings for names, and avoid all the complexity above.

No, not at all. We've taken you into the depths of a TOPIC that has deep philosophical ROOTS, which has been the focus of arguments for many years. Most people never need this kind of knowledge. We warned you EARLIER, didn't we? And you just had to know, didn't you?

No, not at all. We've taken you into the depths of a topic that has deep philosophical roots, which has been the focus of arguments for many years. Most people never need this kind of knowledge. We warned you earlier, didn't we? And you just had to know, didn't you?

FIRST, the object MAY have moved in between the TIMES that its references were stringified, so the strings may not be identical. Also, there are POTENTIAL problems if you have multiple vendors because stringified object references can be quite ORB-specific.

First, the object may have moved in between the times that its references were stringified, so the strings may not be identical. Also, there are potential problems if you have multiple vendors because stringified object references can be quite ORB-specific.

Not REALLY. You ALSO have to remember that it TYPICALLY requires network traffic. It's easy to FALL into the wishful THINKING that the ORB can handle is_equivalent() for you, but, in general, it doesn't.

Not really. You also have to remember that it typically requires network traffic. It's easy to fall into the wishful thinking that the ORB can handle is_equivalent() for you, but, in general, it doesn't.

Remember that is_equivalent() is invoked on ONE of the two objects, and there are cases where this can cause deadlock. The following example ILLUSTRATES how this can happen on one PARTICULAR single-threaded ORB that won't allow a server to invoke a method on the client (contributed by Jeff Stewart, jstewart+@andrew.cmu.edu; used with permission): Suppose a server receives updates from cached clients and then has to update all clients except for the one that reported (updating the reporting client would cause a deadlock on this ORB). So, as the server iterates through its client list it must ensure that it does not invoke the reporting client. But it can't use is_equivalent() because this will eventually cause an invocation on the reporting client just to do the is_equivalent() check, inadvertently creating a deadlock.

Remember that is_equivalent() is invoked on one of the two objects, and there are cases where this can cause deadlock. The following example illustrates how this can happen on one particular single-threaded ORB that won't allow a server to invoke a method on the client (contributed by Jeff Stewart, jstewart+@andrew.cmu.edu; used with permission): Suppose a server receives updates from cached clients and then has to update all clients except for the one that reported (updating the reporting client would cause a deadlock on this ORB). So, as the server iterates through its client list it must ensure that it does not invoke the reporting client. But it can't use is_equivalent() because this will eventually cause an invocation on the reporting client just to do the is_equivalent() check, inadvertently creating a deadlock.

Use is_equivalent(), but don't take it too seriously. This method never lies to you, if it SAYS two references are equivalent, then they are. But they might be equivalent but not identical and is_equivalent() can potentially return false. SEE the OCTOBER 1996 column by Steve Vinoski and Doug SCHMIDT in C++ Report.

Use is_equivalent(), but don't take it too seriously. This method never lies to you, if it says two references are equivalent, then they are. But they might be equivalent but not identical and is_equivalent() can potentially return false. See the October 1996 column by Steve Vinoski and Doug Schmidt in C++ Report.

Some ORB calls such as resolve_initial_references() and string_to_object() generate an object reference. The object it REFERS to might or might not exist (the act of USING the object reference can RESULT in the creation of the actual object). Also, a factory might create an object reference by creating an object IMPLEMENTATION within the same PROCESS. The factory could generate the object reference and cause an object to be created (as above), or the factory could obtain the object reference from some other source (NameService, TraderService).

Some ORB calls such as resolve_initial_references() and string_to_object() generate an object reference. The object it refers to might or might not exist (the act of using the object reference can result in the creation of the actual object). Also, a factory might create an object reference by creating an object implementation within the same process. The factory could generate the object reference and cause an object to be created (as above), or the factory could obtain the object reference from some other source (NameService, TraderService).

We can't tell you because there is no STANDARD for this. OMG wanted to give ORB implementers as MUCH freedom as POSSIBLE to develop efficient, POSSIBLY platform-dependent schemes. Thus, the references are opaque and should be thought of as an interface without REGARD for their implementation.

We can't tell you because there is no standard for this. OMG wanted to give ORB implementers as much freedom as possible to develop efficient, possibly platform-dependent schemes. Thus, the references are opaque and should be thought of as an interface without regard for their implementation.

Use object_to_string(), and REVERSE the PROCESS using string_to_object(). There is some magic in string_ to_ object(); it not only does the necessary string-to-pointer conversion, it ensures that you get a currently VALID object reference that is equivalent to the original reference that was stringified (i.e., both REFER to the same object instance).

Use object_to_string(), and reverse the process using string_to_object(). There is some magic in string_ to_ object(); it not only does the necessary string-to-pointer conversion, it ensures that you get a currently valid object reference that is equivalent to the original reference that was stringified (i.e., both refer to the same object instance).

Stringify the object REFERENCE and save it in a persistent medium. But, we have to WARN you, you're about to get into deep WATER. Maybe you should just SKIP to the section on Naming Service, unless you want to be an "expert".

Stringify the object reference and save it in a persistent medium. But, we have to warn you, you're about to get into deep water. Maybe you should just skip to the section on Naming Service, unless you want to be an "expert".

Only during the session while your client is CONNECTED to the ORB. If a TARGET object moves during a session, the ORB will PROVIDE the equivalent of a transparent forwarding mechanism.

Only during the session while your client is connected to the ORB. If a target object moves during a session, the ORB will provide the equivalent of a transparent forwarding mechanism.

CORBA is a dynamic environment and OBJECTS move around in an UNPREDICTABLE manner. You need a soft locator rather than something static and BRITTLE.

CORBA is a dynamic environment and objects move around in an unpredictable manner. You need a soft locator rather than something static and brittle.

A transient, opaque HANDLE that identifies an object instance in your ORB. An object reference is the identifier needed to invoke methods on objects. Object REFERENCES are not global IDENTIFIERS that are valid across all machines in a DISTRIBUTED network. Their scope is limited to your local ORB.

A transient, opaque handle that identifies an object instance in your ORB. An object reference is the identifier needed to invoke methods on objects. Object references are not global identifiers that are valid across all machines in a distributed network. Their scope is limited to your local ORB.

YES. The words client and SERVER are really only applicable in the CONTEXT of a remote call. In other words, the "client process" can also receive CALLS on CORBA OBJECTS that it implements and hands out the references to.

Yes. The words client and server are really only applicable in the context of a remote call. In other words, the "client process" can also receive calls on CORBA objects that it implements and hands out the references to.

No, it's infrastructure. Which is good because the history of high-level "ONE size fits all" ARCHITECTURES hasn't been very good, has it? CORBA provides low level request/response communication. It ALSO provides general services that are IMPLEMENTED on top of request/response communication. The ACTUAL architecture used within a given application is not defined by CORBA. CORBA leaves these decisions up the application architect.

No, it's infrastructure. Which is good because the history of high-level "one size fits all" architectures hasn't been very good, has it? CORBA provides low level request/response communication. It also provides general services that are implemented on top of request/response communication. The actual architecture used within a given application is not defined by CORBA. CORBA leaves these decisions up the application architect.

Building multi-threaded applications REQUIRES an additional efforts in the area of DESIGN, DEVELOPMENT and testing. Issues like concurrency and synchronization become more critical. DIFFICULT to find software bugs are unfortunately EASY to introduce. A specific set of application requirements can often be met without resorting to the use of threaded clients or servers. This is not true with all applications. Some do require multi-threading to achieve their desired level of concurrency, performance or scalability.

Building multi-threaded applications requires an additional efforts in the area of design, development and testing. Issues like concurrency and synchronization become more critical. Difficult to find software bugs are unfortunately easy to introduce. A specific set of application requirements can often be met without resorting to the use of threaded clients or servers. This is not true with all applications. Some do require multi-threading to achieve their desired level of concurrency, performance or scalability.

CORBA server applications may be multi-threaded for serveral reasons.
A particular CORBA object may support an operation whose implementation performs some blocking routine. This may be a disk read or database query. Let us assume that the server application processes all CORBA events within a single main thread. This means that the server will be unable to respond to incoming connection requests or invocation requests while the blocking operation is in progress. Multi-threading can be used to avoid these sorts of SITUATIONS. The server can be more accessible if multiple threads are allowed to PROCESS (an block during) incoming CORBA events. A single multi-threaded server process supporting many (>25) CLIENTS is much more efficient that many (>25) single-threaded server processes each supporting its own client. RUNNING a single application with multiple threads requires less machine resources than running multiple applications. This advantage can be seen even if the operation invocations are of short duration and non-blocking.

CORBA server applications may be multi-threaded for serveral reasons.
A particular CORBA object may support an operation whose implementation performs some blocking routine. This may be a disk read or database query. Let us assume that the server application processes all CORBA events within a single main thread. This means that the server will be unable to respond to incoming connection requests or invocation requests while the blocking operation is in progress. Multi-threading can be used to avoid these sorts of situations. The server can be more accessible if multiple threads are allowed to process (an block during) incoming CORBA events. A single multi-threaded server process supporting many (>25) clients is much more efficient that many (>25) single-threaded server processes each supporting its own client. Running a single application with multiple threads requires less machine resources than running multiple applications. This advantage can be seen even if the operation invocations are of short duration and non-blocking.

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.

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.

The CORBA specification does not currently address multi-threaded architectures. Provided that the CORBA PRODUCT is THREAD safe, threaded CORBA applications can be developed. CORBA CLIENTS and servers can both be multi-threaded. Daemon processes provided with CORBA products may be IMPLEMENTED as multi-threaded servers by the CORBA vendor. Different multi-threaded models or multi-threaded architectures may be supported by a particular CORBA product. A particular ORB may provide frameworks to simplify the development of multi-threaded CORBA applications.

The CORBA specification does not currently address multi-threaded architectures. Provided that the CORBA product is thread safe, threaded CORBA applications can be developed. CORBA clients and servers can both be multi-threaded. Daemon processes provided with CORBA products may be implemented as multi-threaded servers by the CORBA vendor. Different multi-threaded models or multi-threaded architectures may be supported by a particular CORBA product. A particular ORB may provide frameworks to simplify the development of multi-threaded CORBA applications.

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.

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.

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.

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.

Kind of. At the lowest level CORBA supports TWO modes of COMMUNICATION: A synchronous request/response which allows an application to make a request to some CORBA object and then wait for a response. A DEFERRED synchronous request/response which allows an application to make a request to some CORBA object. An empty result will be returned immediately to the application. It can then perform other operations and later poll the ORB to see if the result has been made available. 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.

Kind of. At the lowest level CORBA supports two modes of communication: A synchronous request/response which allows an application to make a request to some CORBA object and then wait for a response. A deferred synchronous request/response which allows an application to make a request to some CORBA object. An empty result will be returned immediately to the application. It can then perform other operations and later poll the ORB to see if the result has been made available. 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.

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.

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.

CORBA communication is inherently asymmetric. Request messages originate from clients and responses originate from servers. The important thing to realize is that a CORBA SERVER is a CORBA object and a CORBA client is a CORBA stub. A client application might use object references to request remote service, but the client application might also implement CORBA objects and be capable of servicing incoming requests. Along the same lines, a server process that implements CORBA objects might have several object references that it USES to make requests to other CORBA objects. Those CORBA objects might reside in client applications. By implementing a CORBA object WITHIN an client application, any process that OBTAINS its object reference can "notify" it by performing an OPERATION on the client-located object.

CORBA communication is inherently asymmetric. Request messages originate from clients and responses originate from servers. The important thing to realize is that a CORBA server is a CORBA object and a CORBA client is a CORBA stub. A client application might use object references to request remote service, but the client application might also implement CORBA objects and be capable of servicing incoming requests. Along the same lines, a server process that implements CORBA objects might have several object references that it uses to make requests to other CORBA objects. Those CORBA objects might reside in client applications. By implementing a CORBA object within an client application, any process that obtains its object reference can "notify" it by performing an operation on the client-located object.

In order to invoke the remote object instance, the client first obtains its object reference. (There are many ways to do this, but we won't detail any of them here. Easy ways include the Naming Service and the Trader Service.) To make the remote invocation, the client uses the same code that it used in the local invocation we just described, substituting the object reference for the remote instance. When the ORB EXAMINES the object reference and discovers that the TARGET object is remote, it routes the invocation out over the network to the remote object's ORB. (Again we point out: for load balanced SERVERS, this is an oversimplification.)

How does this work? OMG has standardized this process at two key levels: First, the client knows the type of object it's invoking (that it's a shopping cart object, for instance), and the client STUB and object skeleton are generated from the same IDL. This means that the client knows exactly which operations it may invoke, what the input parameters are, and where they have to go in the invocation; when the invocation reaches the target, everything is there and in the right place. We've already seen how OMG IDL accomplishes this. Second, the client's ORB and object's ORB must agree on a common protocol - that is, a representation to specify the target object, operation, all parameters (input and output) of every type that they may use, and how all of this is represented over the wire. OMG has defined this also - it's the standard protocol IIOP. (ORBs may use other protocols besides IIOP, and many do for various reasons. But virtually all speak the standard protocol IIOP for reasons of interoperability, and because it's required by OMG for compliance.)

Although the ORB can tell from the object reference that the target object is remote, the client can not. (The user may know that this also, because of other knowledge - for instance, that all accounting objects run on the mainframe at the main office in Tulsa.) There is NOTHING in the object reference token that the client holds and uses at invocation time that identifies the location of the target object. This ensures location transparency - the CORBA principle that simplifies the design of distributed object computing applications.

In order to invoke the remote object instance, the client first obtains its object reference. (There are many ways to do this, but we won't detail any of them here. Easy ways include the Naming Service and the Trader Service.) To make the remote invocation, the client uses the same code that it used in the local invocation we just described, substituting the object reference for the remote instance. When the ORB examines the object reference and discovers that the target object is remote, it routes the invocation out over the network to the remote object's ORB. (Again we point out: for load balanced servers, this is an oversimplification.)

How does this work? OMG has standardized this process at two key levels: First, the client knows the type of object it's invoking (that it's a shopping cart object, for instance), and the client stub and object skeleton are generated from the same IDL. This means that the client knows exactly which operations it may invoke, what the input parameters are, and where they have to go in the invocation; when the invocation reaches the target, everything is there and in the right place. We've already seen how OMG IDL accomplishes this. Second, the client's ORB and object's ORB must agree on a common protocol - that is, a representation to specify the target object, operation, all parameters (input and output) of every type that they may use, and how all of this is represented over the wire. OMG has defined this also - it's the standard protocol IIOP. (ORBs may use other protocols besides IIOP, and many do for various reasons. But virtually all speak the standard protocol IIOP for reasons of interoperability, and because it's required by OMG for compliance.)

Although the ORB can tell from the object reference that the target object is remote, the client can not. (The user may know that this also, because of other knowledge - for instance, that all accounting objects run on the mainframe at the main office in Tulsa.) There is nothing in the object reference token that the client holds and uses at invocation time that identifies the location of the target object. This ensures location transparency - the CORBA principle that simplifies the design of distributed object computing applications.