Q) What is CORBA? What does it do?
A) CORBA is the acronym for Common Object Request Broker Architecture, OMG's open, vendor-independent architecture and infrastructure that computer applications use to work together over networks. Using the standard protocol IIOP, a CORBA-based program from any vendor, on almost any computer, operating system, programming language, and network, can interoperate with a CORBA-based program from the same or another vendor, on almost any other computer, operating system, programming language, and network.

Q) What are the goals of CORBA?
A) CORBA aims to allow interaction between potentially distributed component objects created by different manufacturers in different languages (location transparency and language transparency).

Q) What is a heterogeneous distributed system?
A) A collection of communicating machines running different operating systems.

Q) What is an ORB?
A) An ORB or Object Request Broker is software that allows servers to register the objects they provide and clients to find objects providing the services they want and then to interact with them.

Q) What are the roles of a skeleton and a stub in CORBA?
A) A stub and a skeleton are automatically generated from the IDL description of an interface. The stub behaves to the caller just like the called object - it provides the same methods and implements the same interfaces. However, when the methods are called, the stub interacts with the network to pass the request to the skeleton. The skeleton calls the appropriate method on the called object and passes the results back to the stub, which returns them to the caller.

Q) What is the role of an interface in CORBA?
A) An interface is used to define the services (methods) provided by an object and their parameters and results. The remote server provides an object which implements the interface. The client requests the interface from the ORB and the returned object must provide all the methods defined in the contract represented by the interface.

Q) What is the purpose of a request in CORBA?
A) A request is used to transfer the name of the method (the service) and the parameters between the client and the server.

Q) What is the purpose of IDL?
A) Interface Definition Language (IDL) is a programming language-independent language for specifying the names, parameters and return types of the interface methods. A module may contain several interfaces and may define constants to be used with the methods.

Q) What is the purpose of a mapping?
A) A mapping allows a compiler to translate an interface defined in IDL into a specific programming language. It allows the compiler to generate stubs, skeletons and various helper classes which can be used to develop implementations of the interface.

Q) What are the similarities and differences between RMI and CORBA?
A) Similarities
* Hide communication to remote objects behind method calls
* Use stub/skeleton approach
* Provide a Naming Service
Differences
* RMI is Java-only, CORBA is multi-language
* CORBA is more sophisticated - will have greater overhead
* CORBA offers many additional services e.g. persistence, events, application-domain services

Q) WHAT IS NOTIFICATION SERVICE?
A) The Notification Service extends the Event Service and adds several new kinds of functionality. CORBA has defined the Notification Service model that allows applications to send messages to objects in other applications without any knowledge of that receiving objects. The Notification model is an extension to the CORBA Event Service model. Applications that are providing messages to other applications are called suppliers and applications receiving the messages supplied are called consumers.
The suppliers and consumers are completely decoupled thus having no knowledge of their location. In addition, suppliers have no idea of how many consumers are listening to the messages being supplied.

Q) WHAT IS THE EVENT SERVICE?
A) The CORBA event service provides support for the producer/consumer pattern. It support a channel which provides the producer with the ability to create "events" and the consumers with the ability to receive these "events". Events are any valid IDL defined interface or data type. Both consumer and producer applications must be a CORBA server. There may be multiple channels in use. A single channel may have multiple producers and multiple consumers. A consumer receives all the events on the channel.

Q) Are there more than one type of event service?
A) The Event Service specification supports two types of event reception. One is push and one is pull. The push model allows consumers to receive ongoing events by just connecting. The pull model requires that the consumer poll for all events sent to the channel since the last pull. The Event service also allow the events to be either typed or in typed. In the typed model, the Event service ensures that the channel support a specific IDL datatypes. In the untyped model the Chnnel distributes events as an ANY. In this case, it is up to the consumer to enforce type safety.

Q) How does the notification service work?
A) The Notification model uses an architectural element called an event channel which allows messages to be transfered between suppliers and consumers. Consumers register with the event channel and express an interest of certain events. The channel receives events from suppliers and forwards the events to the interested consumers for that event. Suppliers and Consumers connect to the event channel and not directly to each other.

Q) How does the notification service extend the event service?
A) The Notification Service extends the Event Service in two areas:
Event Filtering - Event filtering allows that Notification channel to deliver only certain types of events to interested consumers. In the much simpler Event Service model all events are sent to all consumers.
Quality of Service - Quality of Service (QoS) allows an applications to change some of the elements defined in the Notification Channel, such as event delivery.

Q) When do I need a service like notification?
A) It depends on what your business requirements dictate. We can see a need for Notification in a scenario where you are interested in receiving certain information which another source owns.
The example that always comes to mind is the stock market. Information about stocks flows rapidly, and frequently. This information can be supplied through a Notification channel to which many consumers can register their interest in certain stocks. As new information about the stocks is collected, a supplier can push that information to the Notification channel which will pass this information to all the interested consumers on that channel.
There are many more examples but the bottom line here is that it can be used in a variety of scenarios and they will have to be analyzed to see where Notification fits in.

Q) Can I federate notification channels?
A) Yes. You will have to do this within your program but the concept becomes clear once you have done it. The way you do the federation is to create two channels and essentially connect them together logically. The consumer proxy of one channel, channel A, is supplied to the supplier proxy of the other channel, channel B. The reverse is done with the supplier proxy of channel B where it's exchanged with channel A and voila we are now federated.
So essentially what you have is a channel that becomes a consumer and which will forward the events to its consumers.

Q) What is the purpose of the life cycle service?
A) The basic purpose of the Lifecycle Service is to provide basic capabilities to CORBA Objects, such as the ability to create, copy, move and destroy themselves. More than any other service, the Lifecycle Service is tied to the actual ORB implementation used to provide CORBA support.

Q) What is the purpose of the object transaction service?
A) The OTS provides a mechanism for distributed CORBA Objects to participate in a distributed transaction through a two phase commit protocol.

Q) What is the purpose of the COS TRADER SERVICE?
A) The Trader Service was designed to provide access to CORBA objects based upon capabilities as opposed to name or interface type. The Trader Service is a factory since its purpose is to return other CORBA Objects. Unlike the Naming Service, a global name or identifier is NOT used to specify the CORBA Object to return. The Trader Service has been likened to the Yellow Pages, while the Naming Service is more like the White Pages.

Q) What is the purpose of the persistent state service?
A) The Persistent State Service (PSS) is designed to be a CORBA-friendly form of persistence management. The PSS superceeds the POS. Unlike the POS that attempted to provide both a client IDL interface for persistence control and a server-side layer for allowing CORBA implementation objects to save their state, the PSS focuses on only the latter.
At a high-level the PSS is an IDL defined abstraction layer of data storage. It needs to be implemented for a particular datastore, such as a file system, a relational database, or an OODB. This allows CORBA implementation objects to be abstracted from their storage mechanisms, much like ODBC/JDBC abstract relational databases.

Q) What are objects by value?
A) The Objects By Value (OBV) defintion includes semantics of pass-by-value similar to that of standard programming languages. The current CORBA specification only defines object reference semantics. The Objects By Value specification defines extensions to CORBA (and IDL) that allows designers the flexibility to allow the receiving side of a parameter to receive a new instance of the object.

Q) What is the purpose of the persistent object service?
A) The Persistent Object Service was designed to provide two things:
A database like access to CORBA objects. This provided CORBA clients with IDL control interfaces to a CORBA object's underlying storage. A means for CORBA objects to uniformly save their state into a database. This was an internal API for implementation objects (the objects that really have the state) to save their data into a database.
The Persistent Object Service was not widely received and potentially never implemented by any vendor. As a specification, it has been retracted. The Persistant State Service (PSS) superceedes the POS.

Q) What is a value type?
A) A Value Type is an object whose semantics lie between a CORBA interface and a structure. There are two types a Value Types that can be declare:
Concrete Value Types
Abstract Value Types
Concrete Value Types define state (properties) and the implementation is always local. Abstract Value Types do not define properties. Both Concrete and Abstract Value Types can define operations (interface) and inherit from other Value Types and interfaces.

Q) In what cases do I need a value type?
A) In some cases it is desirable to have a receiving party instantiate a copy of an object. This implies that the receiver knows how to implement the object (instantiate it, initialize it, provide implementations of the operations). More importantly, this also implies the receiver knows something about the semantics of the object and can utilize those semantics locally. The new instance created by the receiving side has a separate identity from the original object, and once the parameter passing operation is complete, there is no relationship between the two instances.

Q) What does OBV really provide?
A) From the OBV specification:
Valuetypes provide semantics that bridge between CORBA structs and CORBA interfaces:
* They support description of complex state (i.e arbitrary graphs).
* Their instances are always local to the context in which they are used (because they are always copied when passed in a remote call).
* They support both public and private (to the implementation) data members.
* They can be used to specify the state of an object implementation, i.e they can support an interface.
* They support single inheritance (of valuetypes) and can support multiple interfaces.
* They may be also be abstract.

Q) What is the purpose of the asynchronous messaging interface?
A) The AMI extends the request/response nature of CORBA into messaging services. The messaging services are richer than the "oneway" or "deferred synchronous" functionalities in the core CORBA specification, and also pull in elements from the Event and Notification Services. The AMI works with the notion of "implied IDL". The means that although the IDL for an interface, Foo, has a single operation, bar, there are other implied operations, e.g., try_bar, that are used to support asynchronous communications.

Q) Can CORBA be integrated with XML?
A) INDEX:XML@Integration with CORBA INDEX:CORBA@Integration with XML
Yes. And in a number of ways, depending on the need and approach.
Using IDL to communicate XML. This means setting up simple interfaces to communicate the XML Document Type Description (DTD) and the XML document itself. Obviously, there may be a repository of DTDs, and the actual communication of the XML document simply refer to its DTD.
Using XML as a transport. This means there is a DTD for, essentially, IIOP. A CORBA request or response is communicated in XML.
A variation on the previous item, once the XML to CORBA request/response conversion is in place, a gateway can take XML or CORBA requests from various sources and map them into XML or CORBA requests on various services.
Using XML as an abstract system description language. XML could be used to describe a system interfaces, workflow, API mapping logic, data definitions, other semantics, etc., and then this XML is used to produce IDL. Chances are the XML would also be used to code generate supporting system integration class libraries and potentially entire clients/servers.

Q) How does a value type differ from an interface type ?
A) An Value Type differs from an interface in that it potentially carries additional properties that define state and that the operation implementation are executed locally. If you recall, when we pass or receive an interface type ( an object reference ) and execute operations on it, these operations end up as remote invocations to the "real" implementation object. Again, Value Types are not meant to replace interface types, and should be used in very specific instances in which the receiving side can benefit from not making remote invocations.

Q) What is an abstract value type?
A) An Abstract Value Type is a Value Type that may not be instantiated. Only Concrete Types can be instantiated and implemented. Also, no state information may be specified in an Abstract Type.

Q) What does the quality of service give me?
A) The Quality of Service, or QoS, allows you to set and tune your service to the demands of your business. Notification defines the following QoS properties:
* Reliability
* Priority
* Expiery Time
* Earliest delivery time
* Order policy
* Discard policy
* Maximum batch size
* Pacing interal
* Proxy push supplier properties
* These properties can be applied at cartain levels of the Notification service:
* Notification Channel
* Supplier or Consumer admin objects
* Proxy suppliers and consumers
* Individual event messages
The QoS is a very powerful extension that allows you to modify the service according to your requirements both from an administrative and an application requirement perspective.

Q) How do I define notification events?
A) Notification events are defined using standard IDL. There are two types of events:
Structured Events
Untyped Events
Structured events provide a well-defined data structure into which messages can be inserted and sent to interested consumers. Messages can be defined using standard IDL structs and provide, both consumers and suppliers, with a much strongly typed event. In addition, a sequence of these events can be transmitted between suppliers and consumers that can increase the efficiency of communications between them. With the sequence you can batch any number of events and trasmit them all at once.
Structured Events can constain all IDL types that are defined in the standard IDL. Here's an example:
struct Message
{
long messageType;
string messageBody;
};
typedef sequence < Message > MessageSeq;
Suppliers would fill the contents of this messages and supply them to interested consumers that have registered with the notification channel.
The untyped event is simply a CORBA::any into which the event is inserted and sent to consumers. So the above example can be inserted into the CORBA::Any type and sent to any consumers on the channel.

Q) Under what conditions is DSI appropriate?
A) The dynamic nature of DSI provides certain advantages over static request dispatching. The following types of applications would require or benefit from DSI:
Server side bridges (protocol converters)
Monitoring applications
Interpreted or script driven services
Applications which utilize DSI do not need to include or import skeletons generated by an IDL compiler in order to provide a service. These serices can support request generically and must enforce type safety.

Q) What is ANY?
A) An any is an IDL type that can represent "any" other IDL type. An any is the most abstract type. It requires runtime information to determine what type (and value) it really is.

Q) What is TYPECODE?
A) A typecode is a type, whose values represent the types of other things. It is a meta-type. For example, a given typecode might have the value of XXX, which represents the type "float". In details of XXX are not particularly important.

Q) Do all types have a TYPECODE?
A) Yes.

Q) What are the typecodes for the built-in IDL types?
A) This depends on the language mapping. For example, in C++, there is a const instance of the TypeCode class for each of the built-in types.

Q) How do i get an objects's TYPECODE
A) An interface's typecode can be determined by calling _get_interface() on the object reference (IOR). This will return an InterfaceDef (Interface Definition) reference from the Interface Repository (IFR).
The typecode for things like float and string are well known in the language mapping. The typecode for things like structs are generated by the IDL compiler.
An any supports a call to determine its typecode. Note, the complete support for this requires Dynamic Anys.

Q) What is the interface repository?
A) The CORBA specification defines IDL as a mechanism for describing a set of interfaces and data types. These interface definitions can represented within a textual IDL representation. They can also be managed by, or stored within a repository service. IDL can be compiled into a running interface repository serice. This sercices can then provide information about other objects interfaces. The Interface Repository service is (of course) defined in IDL.

Q) Why does corba need the interface repository?
A) The CORBA specification support self desribing data types. These are supported by the ANY data type and its associated typecodes. The CORBA specification also provides Dynamic Invocation Interface and Dynamic Skeleton Interface . Since the IIOP specification does not provide self descirbing messages, an objects interface must be accessible via the Interface Repository. This capability is also critical for supporting up and down casting of super and sub interfaces types.

Q) What is the BOA?
A) The BOA has been deprecated by the OMG and replaced by the POA. ORB vendors may support both the BOA and POA or either. The CORBA specification defines the BOA pseudo object in PIDL. BOA stands for Basic Object Adapter. The BOA's main purpose is to allow an object server to interact with the ORB. A server process uses the BOA to tell the ORB when an object is ready to perform operations.

Q) What are the four BOA activation policies for a corba server?
A) NOTE: The BOA has been deprecated by the OMG and replaced by the POA. ORB vendors may support both the BOA and POA or either. CORBA defines four activation policies for objects. Activation policies are specific to the server process that "owns" the CORBA object. The activation policy defines how objects are created within a server process. The BOA object ensures that these activation policies are enforced. Enforcement of these rules can simplify application development.
Note: The CORBA activation policies are specific to creation. This means that the activation policy does not manage the connection policy of a CORBA object. A particular un-shared server might have only one CORBA object in its address space. The activation policy does not forbid several client applications from having object references that point to the same CORBA object. An application is always free to _duplicate an object reference and pass it to some other application.
Shared Server: A shared server is a server process that is shared by many CORBA objects. This means that a shared server could have more than one instance of a particular CORBA object in its address space. This implies that different object references of the same type refer to different CORBA object implemented within the same process.
Un-Shared Server: An un-shared server is allowed to construct at most one CORBA object (of a given type) within its address space. This implies that different object references of the same type refer to CORBA objects implemented within different server processes.
Persistent Server: A persistent server is a shared server that manages the activation of objects itself. The BOA is not involved with enforcement of the activation policy. A persistent server might start up at boot time and create a fixed number of CORBA objects of varied types.
Per-Method Server: The per-method policy results in a separate server for each request made on the specified object. The BOA activates a per-method server for each and every request made on the object. The server runs only until the request has been serviced.

Q) What is the POA?
A) The Portable Object Adapter (POA) superceeds the Basic Object Adapter (BOA) as the primary way of making implementation objects available to the ORB for servicing requests. All object adapters are concerned with the mechanisms to create CORBA objects and associate the CORBA objects with programming language objects that can actually do the work. The POA provides an expanded set of mechanisms for doing this.

Q) Does the POA affect clients?
A) No. No object adapter or server-side concept affects clients. CORBA-compliant clients that used BOA-based servers should be able to use POA-based servers.

Q) How does the POA benefit non-distributed objects?
A) The POA is very consistent in the treatment of local and remote objects. Specifically, all CORBA calls on a CORBA object go through the POA, even if the target object is local (in the same address space). This allows the POA to uniformly apply the POA Policies.

Q) Does the POA affect servers?
A) Yes. Transitioning from a BOA-based server to a POA-based server needs to be done with some forethought. It is not necessarily a difficult task, but should be done carefully. The POA is policy based with lots of policy choices. The task is to determine the set of policy decisions that give you the functionality you want. Since the POA superceeds most of the BOA functionality, if you want to simply migrate a BOA-based server to a POA-based server without changing behavior, then this can be done rather easily. There are some API changes. See POA Policies. Chances are, though, if you are using the POA, you are going to want to take advantage of some of its benefits.

Q) How does the POA Make the association between servants and corba objects?
A) This is where the Object ID and and POA Active Object Map come in. So, for a given POA, the Object ID identifies a specific CORBA object, which is used in the Active Object Map to identify the servant.

Q) How does the POA manage object lifecycle?
A) The POA distinguishes between the CORBA object reference (IOR) and the implementation object that does the work. This implementation object is called a servant. A BOA-based approach has the IOR and servant existing at the same time. A POA-based approach can support this, but can also support IORs existing without being associated with servants, and also servants existing without being associated with IORs. Obviously, the association between an IOR and a servant has to be made at some point, to make the servant a useable CORBA object. But this association can be done on-demand. Consider the following example scenarios to motivate the advantages of on-demand association:
A pool of servants can be instantiated, and then associated in turn with IORs, as needed.
A set of IORs can be created for the purposes of publishing the references to the Name Service, without going through the work to actually instantiate the servants.
Moreover, the POA allows a single servant to simultaneously support several IORs.
All of the above significantly contribute to scalable applications.

Q) How are multiple POAS distinguished?
A) Each POA has a name.

Q) How are multiple POAS organized?
A) This is up to the application developer, but a POA hierarchy is supported. Each POA has a parent POA. There is an implicit Root POA.

Q) Why is the POA needed?
A) The POA was added to the CORBA specification for a number of reasons:
The BOA was under-specified. This meant that each ORB vendor provided different APIs and different extensions to make the BOA useful. The POA fixes this by being more completely specified. The POA, itself, is specified in IDL, and addresses complex issues in more detail than the BOA did. The BOA was insufficient for large-scale systems. The POA provides a lot more functionality than the POA with respect to implementing large-scale systems. Servers can better handle connections and requests from multiple clients through automatic, policy-driven behavior. Servers are better able to manage thousands, if not millions, of fine-grained objects via the POA's ability to manage lifecycles and associations of CORBA objects and implementation objects.
The BOA was not completely location transparent. Whereas some semantics of the BOA changed if the implementation object was actually in the same process as the caller (client) vs. being remotely located, the POA makes the semantics much more consistent. In fact, a CORBA call on a local object will still go through the POA. This allows the POA to uniformly apply policy and service decisions. In this sense, the POA is more like the "container" concept in EJB.

Q) What are the semantics of the POA hierarchy?
A) This is better answered by describing what the semantics of the POA hierarchy are not.
The POAs deal with policies, and the POA hierarchy is not a policy hierarchy.
The POA hierarchy does not imply any default policies. v The POA hierarchy does not imply any factoring of the servants by IDL interface or servant class.
In most cases, each servant is associated with at most one POA. The POA "owns" the servant and there are deletion responsibilities the POA will take. Deleting a POA will cause its servants to be deleted. Hence, the semantics of the POA hierarchy are only a containment hierarchy for POA deletion.

Q) Where does the POA manager fit in?
A) The POA Manager is really a different beast all together. The POA Manager groups one or more POAs and provides common system resources, such as a network connection, to its POAs.

Q) How does a request get to the right POA and right SERVANT?
A) The POA's name is part of the IOR. Also, of course, the Object ID is in the IOR. So once the request gets delivered to the right machine (part of the request's IOR), and to the right port (part of the request's IOR), the POA Manager listening on that port looks at the object key (part of the request's IOR). The object key contains the POA name and the Object ID. The POA Manager uses the object key to deliver the request to the right POA, and the POA uses the object key to determine the Object ID. Depending on the POA's policies, it directly or indirectly uses that Object ID to deliver the request to the right servant.

Q) So why not use ANYS all the time?
A) Sometimes the genericism of an any is appealing. But make sure you need this feature. The disadvantages of using an any include: There is no compile-time type information. This makes the application code harder to write, debug, maintain, etc. Communicating an any is relatively expensive for the ORB.

Q) An ANY Seems very dynamic , so whats a dynamic Any?
A) A Dynamic Any (DynAny) is not an IDL type, like an any. A DynAny solves a technical glitch in the role of the IDL compiler. A DynAny provides an API to construct an any even when the application code does not have benefit of the IDL (really the IDL generated code) that defines the type of the any.

Q) When would I use an ANY?
A) An any comes in handy whenever you need to write IDL and do not know which CORBA type is appropriate. This ambiguity rarely occurs in application IDL. Usually you know what you are dealing with and you use that type explicitly. Or, if you have an operation that may handle one of a couple of types (e.g., a float or a short), then a union is a possible type. Note, if you have an operation that is needs an abstract interface representation, then interface inheritance can be used. The ultimate base interface is CORBA::Object.
There are some cases, though, where an any is needed in application IDL. There are also some places where an any is used in system and service IDL. This is because the operation has to be generic enough to work with a broad range of types. For example, imagine the need to represent a generic property, which is a name-value pair. We have three choices:
Force all values to be strings, and then use a single struct. This approach has the advantage of being simple IDL. However, this potentially falls apart if it is difficult to represent the value as a string. Even if the representation is not a problem, the representation conversion is a hassle:
struct Property {
string name;
string value;
};
interface Foo {
Property getElement(in string key);
};
Write a lot of different structs, one for each type of value. This approach has the advantage of explicit typing with no conversion. However, this falls apart if we have to represent a type that we don't know of, e.g., a user-defined struct. Also this would lead to a lot of variants of the same operation, one that handled each kind of struct:
struct FloatProperty {
string name;
float value;
};
struct ShortProperty {
string name;
short value;
}; //more and more
interface Foo {
FloatProperty getFloatElement(in string key);
ShortProperty getShortElement(in string key);
};
Use an any. This approach has the advantage of simple IDL. Also, it is completely expandable to all types, including user-defined types. Additionally, the application does not have to do conversions (this is essentially done in the marshalling/unmarshalling code). The disadvantage of this approach is the runtime typing - this impacts both the application code and the speed of the ORB communication:
struct Property {
string name;
any value;
};
interface Foo {
Property getElement(in string key);
};

Q) What is CORBA good for?
A) 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.

Q) What is the interoperable name service(INS)?
A) The Interoperable Name Service (INS) fixes a technical glitch in the original CORBA Name Service. The original Name Service did not truly allow object references from different ORB vendors to be stored and accessed from within a single Name Server. This is fixed by the INS. There are no API or IDL changes, so application developers should not notice a difference.

Q) What is important interoperability beside IIOP?
A) The IIOP specification provides resolve initial references as a mechanism to obtain an initial object reference. This object referenced must be implemented with the same ORB product as the client. If this is not the case, then string to object can be used. CORBA 2.0 does not provide a mechanism to transport this string or provide direct access to "foreign objects" The Interoperable Name Service specification will address this and other related problems.

Q) Are IORS obtained in the same manner as object references?
A) Obtaining IORs is exactly the same as obtaining object references. The one caveat is that ORB::resolve_initial_references returns an IOR but it usually must be implemented within the same CORBA product environment.

Q) Can an application refer to objects implementes with multiple corba products?
A) Well, they're sure supposed to be able to do so. Here's how.
Let us assume that an application needs to access two objects. Object A is implemented with CORBA product Aa and object B is implemented with CORBA product Bb. Let us look at several scenarios:
The front-end application will be implemented with CORBA product Aa: The simplest approach is for the front-end application to obtain an object reference to A by calling ORB::resolve_initial_references(). Since the front-end application is implemented with product Aa it cannot obtain an object reference to B by calling ORB::resolve_inital_references(). It can acquire the stringified object reference to B and convert it to an IOR by calling ORB::string_to_object(). How does it obtain the stringified object reference? Object B's constructor could be implement to stringify itself and write the string to a file that is accessible to the front end application (access might be provided by NFS). Every CORBA product that supports IIOP should be support ORB::string_to_object().
The front-end application will be implemented with CORBA product Cc: This scenario is very similar to the first. The application can not use ORB::resolve_initial_references() since neither object A or B are implemented with product Cc. The front end application will obtain an IOR to A and an IOR to B by first acquiring stringified object references. It will then converting the strings to IORs by calling to ORB::string_to_object(). Every CORBA product that supports IIOP should be support ORB::string_to_object().
The front-end application will be implemented with CORBA product Cc. It will obtain IORs A and B from product Cc's implementation of the CORBA NameService. It will not need to acquire any stringified object references. The real question is how are IOR A and IOR B bound within product Cc's CORBA NameService. The processes implementing object A and Object B must acquire an object reference to product Cc's CORBA NameService. This can only occur by obtaining a stringified object reference to product Cc's CORBA NameService. How is the stringified object reference to product Cc's NameService initially created? A simple application implemented with product Cc obtains the NameService by calling ORB::resolve_inital_references(), it then stringifies it by calling ORB::object_to_string(), once this has been done it externalizes the string so that it can be accessed by the processes implementing object A and B.
Note: Stringified objects cannot be exchanged using CORBA based communication. This is your classic catch 22 situation

Q) Whay is an IOR?
A) An IOR is an Interoperable Object Reference. It is a specialized object reference. An IOR is used by an application in the exact same way that an object reference is used. An IOR allows an application to make remote method calls on a CORBA object. Once an application obtains an IOR, it can access the remote CORBA object via IIOP. The CORBA object can be implemented with any CORBA 2.0 compliant product that supports IIOP. The application that obtains the IOR can be developed with a different CORBA 2.0 product. The application constructs a GIOP message and sends it. The IOR contains all the information needed to route the message directly to the appropriate server.

Q) Can corba vendors simplify interoperability and the process of obtaining other vendors object references?
A) CORBA vendors can simplify the process of obtaining external object references by providing small pieces of code designed only to create external IORs. This might be a function called ExternalORB::create_external_references(). Vendors could provide this code to the public or directly to other ORB vendors.

Q) What is a servant manager?
A) The Servant Manager is application code that essentially replaces the functionality of the POA's Active Object Map (AOM). A servant manager is needed for sophisticated schemes to map Object IDs to servants.

Q) How does the POA support object relocation?
A) Very well, indeed. The POA is the unit of location and activation. This means the POA is the unit of relocation. This is powerful. Since a POA can one object, a few objects, or a lot of objects, by design, then objects can be relocated individually are in groups. A great way to think of the POA is as a named, logical endpoint.

Q) How do I migrate from BOA to POA?
A) There is no specific answer. The migration impacts will depend on the system complexity. In particular, many large systems developed with the BOA needed to do POA-like things any way to scale.
There will be some emerging case studies. It is likely that POA migration is one of those things that is not overly difficult, but should not be done without a thought. An important thing to understand is that the migration can be an evolutionary thing as the use of the POA does not affect clients, and mixed POA and BOA systems interoperate at the network (IIOP) level.

Q) What are the POA policies?
A) The POA policies are used to configure the POA for a particular application design or scalability optimization. For example, if you have lots of a fine-grain objects, you may want one kind of optimization, whereas if you have lots of long-duration operations, you may want another kind of optimization.
The list of POA policies includes:
Thread Policy
ORB_CTRL_MODEL - the ORB controls how threads are dispatched.
SINGLE_THREAD_MODEL - the is only one thread.

Lifespan Policy
TRANSIENT - the POA's object references are transient (i.e., likely conversational objects).
PERSISTENT - the POA's object references are persistent, which means the POA should be registered with an locator/activator (i.e., likely entity objects).

ID Uniqueness Policy
UNIQUE_ID - the POA does not allow a servant to be associated with more than one CORBA Object (Object ID).
MULTIPLE_ID - the POA will allow a servant to be associated with more than one CORBA Object (Object ID).
NOTE: The name of this policy is potentially confusing. The Object IDs are always unique for a given POA. This policy is describing the uniqueness or non-uniqueness of the association between Object IDs and servants.

ID Assignment Policy
USER_ID - the application code can/will determine Object IDs for the POA's CORBA Objects.
SYSTEM_ID - the POA will determine Object IDs for its CORBA Objects.

Implicit Activation Policy
IMPLICIT_ACTIVATION - Allows the POA to add the servant to the AOM under conditions where the association is implicit, e.g., calling servant_to_reference().
NO_IMPLICIT_ACTIVATION - Servants can only be associated with an Object ID through an explicit call to do so.

Servant Retention Policy
RETAIN - The POA uses an Active Object Map (AOM).
NON_RETAIN - The POA does not use an Active Object Map (AOM).
NOTE: The name of this policy is potentially confusing. The policy influences whether the POA has an Active Object Map (AOM) or not to track which servants are associated with Object IDs.
The application is always in control of making and breaking this association. The NON_RETAIN policy means that no AOM is used, and hence the application has supplied a Servant Manager.

Request Processing Policy
USE_ACTIVE_OBJECT_MAP_ONLY - The POA relies on its Active Object Map (AOM) only to determine which Object IDs are valid and associated with servants.
USE_DEFAULT_SERVANT - The POA will use a default servant for requests to Object IDs that are not in the AOM.
USE_SERVANT_MANAGER - The POA will use a servant manager to activate an Object ID/servant that is not in the AOM.
Note, there are some cases where the policies are inter-related in most practical situations. For example, a PERSISTENT Lifespan Policy probably implies a USER_ID ID Assignment Policy. Also,
the use of the USE_ACTIVE_OBJECT_MAP_ONLY requires the use of RETAIN, and the use of IMPLICIT_ACTIVATION requires the use of SYSTEM_ID and RETAIN. Since the POA and its policies are defined in IDL, this list may be extended, or features within a particular policy may be expanded.

Q) Can corba allow servers to cause client side events or notifications?
A) 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.

Q) Does corba support asynchronous communication?
A) 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.

Q) Are there important forms of asynchronous communication that arent supported directly by corba?
A) Yes, 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.

Q) Are application threading and asynchronous communication related?
A) 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.

Q) Why would applications require asynchronous communications?
A) 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.

Q) Why would I decide to implement a corba client application with multi-threading?
A) 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.

Q) Can corba applications be multi-threaded?
A) 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.

Q) Are there reasons to avoid the development of multi-threaded corba applications?
A) 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.

Q) Are there different threading models that can be used with in corba servers?
A) There are several different common architectures that can be used within multi-threaded CORBA servers. A server process needs the ability to process CORBA messages. These messages are processed by one or more threads, as determined by the application architecture. The CORBA specification does not specifically address threading capabilities within CORBA compliant ORBs.
An ORB vendor is free to support only single-threaded application or to support multi-threaded applications. If the ORB does support the development of multi-threaded applications, the ORB might only support a subset of the threading models listed below. Significant threading code might still need to be developed to achieve one of the models. For example, the ORB vendor might support a set of application hooks (i.e., interceptors or filters) and allow you to implement threading code with the native OS thread API. On the other hand, the ORB product might provide a built-in feature so no custom thread development needs to be done. The CORBA specification does not address this issue.
When you consider different threading models, it is important to consider what kind of concurrency is desired. While it may be advantageous that two or more threads can be concurrent, it may also be disadvantageous. Also, the resources consumed by idle or active threads, and also the resources consumed for thread creation and deletion, need to be considered.
Thread-Per-Request: With this architecture, the CORBA server ensures that each incoming message is processed in its own thread. This means that multiple requests will be processed concurrently. There are concurrency issues. If two or more requests (threads) are using the same object, then some form of concurrency control (locking) is needed. Also, if two or more requests (threads) are from the same client, then perhaps the requests should be serialized instead of allowed to execute concurrently.
Thread-Per-Client: With this architecture, the CORBA server ensures that each incoming message from a distinct client is processed in its own thread. This is similar to Thread-Per-Request except multiple requests from the same client are serialized. Requests from distinct clients are concurrent. The way that one client is distinguished from another is an interesting problem. Typically, this is done by looking a the network connection and determining that the clients are the same or different. The server needs the ability to monitor client connections and the inception and termination of this connections (typically at a network level, not an application level).
Thread-Per-Server-Object: With this architecture, the CORBA server ensures that each object in the server gets it own thread of execution. This means that multiple requests will be processed concurrently provided they are using different objects. Multiple requests using the same object are serialized. There are concurrency issues, and some locking strategy is needed. Also, deadlock is very possible. It may be that threading or locking at each object is too fine a grain, and a more appropriate choice is putting the thread/lock boundary around a group of coordinating objects.
For each of the above threading architectures, the required server threads can be either created on demand or recycled through a thread pool. The advantage of creating threads on demand is that an arbitrary number of threads can be supported. A thread is created, used, and then reaped. The Thread-Per-Request model would create/reap a thread for each request; the Thread-Per-Client model would create/reap a thread for each client connection; the Thread-Per-Server-Object model would create/reap a thread for each CORBA object instantiated in the server. Thread creation and reaping has some cost, which may be large or small depending on the operating system thread support.
A thread pool is an alternative to creating threads on demand. In this approach, a fixed number of threads are created and cycled in turn to meet the demand for threads. If the demand for threads exceeds the pool size, then further requests for threads are blocked until one of the existing threads is recycled. This approach has the advantage of capping the server resources.

Q) Does corba define high level application architectures?
A) 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.

Q) Can corba applications have callbacks?
A) 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.

Q) What is an object reference?
A) 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.

Q) What are NON-EXCLUSIVE OBJECTS and EXCLUSIVE OBJECTS?
A) Non-Exclusive Objects: A non-exclusive object is typically used to provide a common service to many client applications. A server process creates a single instance of a distributed object. This object can be named or is defined as an initial service. Clients obtain an object reference to the CORBA object by using the CORBA name service or by calling ORB::resolve_initial_references(). The non-exclusive object also provides an excellent mechanism to share data or information between connected clients. This is what EJB calls an EntityBean.
Exclusive objects: An exclusive object is an object that is referred to by only one client application. Exclusive object can live in their own server process or many exclusive objects can live in the same server process. The Object Adapter can be used to control the process boundaries. The deprecated BOA unshared activation policies can be used to ensure that each exclusive object lives in its own process. The POA and POA Locator can be used to control which objects are in which processes. Exclusive objects can ensure that no data or event conflict exists between clients. For example, let us assume that a CORBA object will perform a lengthy database query. By deploying the exclusive object in its own process, client applications will completely control the behavior of the server. The combination of an exclusive object and the unshared activation policy ensure that a server can provide its total attention to its client. The CORBA object will never need to share server side processing with some other CORBA object. It is the responsibility of the applications to ensure that an exclusive object is refereed to by only one client application. This is what EJB calls a SessionBean.
Note: Object level properties such as "non-exclusive" or "exclusive" are orthogonal to the the Object Adapter used to make the CORBA object available to the system.

Q) what are architectural distinctions made at the object level?
A) Stateful Objects: A stateful object is an object that maintains and changes internal state over time. If an object consists of data and methods, a stated object is an object who maintains and alters its data during the invocation of its methods. Stateful objects can exhibit behavior that varies based upon what the object has already done. For example, a get_next_item() method maintains returns the next item each time it is called. This behavior is enabled by saving state associated with the current record. State is specific to the object. Different objects in the same server process maintain their own state. In the case of an exclusive stateful object, state is specific to a given client application. Stateful non-exclusive object maintain a common state across a set of client applications. While stateful objects are very powerful, server-side failures can present problems. For example, let us assume that a client is scrolling through a set of records maintained by a CORBA object. If the CORBA server fails its state could be lost. The CORBA object is capable of being reactivated but the appropriate record would not be returned when the get_next_item() operation was called. Client applications might need to recreate their state within the new object. Another option would be for the object to persist its state and retrieve its state upon reactivation. In EJB, EntityBeans are implicitly stateful and SessionBeans are designated as either stateless or stateful.
Stateless Objects: A stateless object is an object that does not maintain any internal state specific to the invocation of methods. Stateless objects are not suitable for all applications. Stateless objects may perform the same functions as a stateful object. They might require "state" information to be passed as parameters. Stateless objects can allow for more flexibility with respect to fail- over, scaling across servers or dynamic load balancing. In the case of failure, servers and objects can be easily reactivate without worrying about prior state changes. With stateless objects, a client can perform operations on any object of the correct type. This means that it is possible for a collection of servers supporting the same interface to servicing clients. This can increase system scaling dramatically. In EJB, EntityBeans are implicitly stateful and SessionBeans are designated as either stateless or stateful.

Q) Why a handle rather than a Hard address?
A) CORBA is a dynamic environment and objects move around in an unpredictable manner. You need a soft locator rather than something static and brittle.

Q) For how long is an object reference valid?
A) 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.

Q) What if we want a persistant reference?
A) 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".

Q) How do i stringify an object reference?
A) 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).

Q) What is the format of an object reference?
A) 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.

Q) Who creates object references?
A) 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).

Q) How do I compare references?
A) 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.

Q) What other surprises are there with IS_EQUIVALENT()?
A) 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.

Q) Is that all of the bad news about IS_EQUIVALENT()?
A) 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.

Q) Why dont we just compare stringified references?
A) 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.

Q) When do i use _VAR instead of _PTR?
A) 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.

Q) What if i want to invoke methods on an object in another ORB?
A) Then you need to know about interoperable object references (IOR).

Q) Does an IOR have a defined format and If so why?
A) 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.

Q) What is the format of an IOR?
A) 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.

Q) What is a tag?
A) A tag indicates the protocol ID from the most recent protocol change as the IOR flowed from its home ORB to your local ORB (we'll discuss what this is all about when we get into more detail on bridges and interoperability), and is something that is registered with OMG; for instance, IIOP has an ID of zero.

Q) What is a profile?
A) 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.

Q) How does my program use an IOR?
A) 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.

Q) When i obtain an object reference ,what determines if it is an IOR or just an OR?
A) 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.

Q) What is a factory?
A) 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.

Q) What are some typical types of factories?
A) There are several types of factories:
Generic: A generic factory is a factory (CORBA Object) that is capable of returning other CORBA Objects. These CORBA Objects are generic. This means that they can be of any type, rather than a specific type. The SomeFactory::GenericCreate() operation causes the SomeFactory interface to be a generic factory. The NamingContext object defined as part of the CORBA Naming Service is a classic example of a generic factory.
Specific: A specific factory is a factory (CORBA Object) that is capable of returning a specific type of pre-defined CORBA Object. The SomeFactory::SpecificCreate() operation causes the SomeFactory interface to be a specific (or typed) factory.
In-process: An in-process factory is a factory which is implemented in the same process as the object which is created or managed by it.
Out-process: An out-process factory is a factory which is implemented in a process different from the one of the object which is created or managed by it.
interface AnObject {
boolean ping();
};
interface SomeFactory {
CORBA::Object GenericCreate();
AnObject SpecificCreate();
};

Q) Does the corba specification define any specific capabilites for a factory object?
A) 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.

Q) What is a distributed reference counting architecture?
A) 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.

Q) Why would an application implement a distributed reference counting architecture?
A) 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".

Q) Does corba support distributed reference counting architectures?
A) 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.

Q) Is there an alternative to distributed reference counting architectures?
A) 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.

Q) What problems might be associated with a distributed reference counting architecture?
A) The designers of the CORBA specification chose not to support distributed reference counting for several specific reasons.
Error prone: Distributed reference counting relies upon the developer to properly increment and decrement the reference counting mechanism. Failure to do so can result in disappearing objects or orphaned objects that have no users.
Performance problems: In some cases, clients terminate abnormally without properly releasing references. This results in reference counts not being decremented. In order to survive such situations without leaving remote object orphaned, objects must occasionally ping clients to determine if they are alive. This can result in excessive network traffic and cause performance problems.
No support for persistent object references: CORBA allows object references to be stringified, stored, and objectified without losing their remote context. An object reference can be considered valid even if its connection terminates or if the remote object is destroyed. Supporting both persistent object references and reference counting is very difficult since counting stringified object references may not be possible. Some distributed frameworks such as DCOM are built around a distributed reference counting architecture.

Q) Can corba applications be tuned for better performance?
A) There are a number of ways to tune CORBA applications for better performance.
Remember that distribution should only be used if a reason to do so exists. Distribution does not make sense for the sake of distribution. If distribution does not serve a purpose then it should be avoided. Avoiding excessive distribution can result in better performance. Care should be taken when introducing distribution into an applications object model.
IDL interfaces can be tuned to minimize network latency. Invoking remote operations requires transmitting data across the network. Network performance is typically optimized by ensuring adequate bandwidth. Once the required bandwidth is achieved raw network performance cannot be increased. One key to tuning an IDL interface is to reduce the number of network transfers that need to occur. Calling an operation that returns 100 bytes might take 5 milliseconds. Calling an operation that returns 200 bytes of data might take around 6 milliseconds. Calling 2 operations that return 100 bytes might take a total of 10 milliseconds. One key to tuning IDL operations is to avoid implementing several get operations and to combine them into a single get operation which returns the appropriate combination of data.
Caching results of remote operations can avoid network overhead associated with calling the same remote methods more than once. Many applications can perform remote operations upon startup rather than during normal usage. Users are often more willing to wait at startup time rather than during application usage.
Many performance problems are associated with serialization and blocking conditions. For example, Let us assume that clients will be making remote operations to a single server. A single client's request causes the server to block for a extended period of time, the entire client community might have to wait. Make sure that multiple distributed operations are not becoming serialized within a single server process. Utilize multiple server processes or threaded servers instead.

Q) What types of performance should i be concerened with?
A) 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.

Q) Do different corba implementations perform at significantly different levels?
A) 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.

Q) What is the difference between the two types of profiles?
A) 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.

Q) What is interoperability?
A) 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

Q) How does corba support interoperability?
A) 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.

Q) Should I use underscores ("_") in the names of interfaces AND/OR methods?
A) 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.

Q) What is the basic corba architecture?
A) 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.

Q) Why are pseudo objects needed?
A) Keep in mind the CORBA is primarily a specification for accessing remote objects. There is support for location transparency and the case where CORBA objects can be accessed locally, but there is a bias in the specification for remote objects.
There is a need, however, to describe local objects, such as the ORB itself in the local process. In keeping with CORBA, the description of this local object is done in IDL, so that the description is programming language independent. To distinguish the use of IDL to describe a potentially remote object (the normal use of IDL), and the use of IDL to describe an exclusively local object, the concept of a Pseudo Object was introduced.
Pseudo objects use Pseudo IDL (also called PIDL) to describe their interfaces. PIDL is indentical to IDL, except the intention is that the object of a PIDL interface is not associated with an Object Reference for the purposes of remote access.

Q) How are corba objects defined?
A) CORBA objects are defined as Interfaces in IDL.

Q) What are corba pseudo objects?
A) CORBA Pseudo Objects are not real CORBA objects. A CORBA Object has an Object Reference, and can be accessed remotely. Pseudo objects do not have Object References and cannot be accessed remotely.

Q) What capabilites do corba objects possess?
A) CORBA objects support operations that take and return simple and complex IDL types.

Q) Do I program in IDL?
A) No, it is an interface language. Applications are not programmed in IDL. IDL is used to define two basic types of entities: Complex Data types shared between clients and servers: IDL supports 8 basic data types and allows complex data types to be composed of the basic types. Capabilities of Distributed Objects (CORBA Interfaces):

Q) What is the purpose of IDL?
A) IDL stands for Interface Definition Language. Its purpose is to define the capabilities of a distributed service along with a common set of data types for interacting with those distributed services. IDL meets a number of objectives:
* Language Independence:
* Distributed service specification:
* Definition of complex data types:
* Hardware Independence:

Q) Is IDL a specification language ,an implementation language , or both?
A) A specification language. IDL makes a strong separation between the specification of an object and the implementation of that object. Programmers who use the interface of an object have no idea whatsoever how that object is implemented. For example, the object doesn't even need to be implemented using an OO programming language. This is called "Separation of Interface from Implementation," and is a very important concept in OO in general and in CORBA in particular.

Q) Does my implementation need to use inheritance just because my IDL interface uses inheritance?
A) No,Even though a CORBA interface might utilize inheritance, the object implementation is not required to utilize inheritance. For example, given the following two IDL interfaces:
interface Base { void f(); };
interface Derived : Base { void g(); };
Suppose interface Base is implemented by class Base_impl and interface Derived is implemented by class Derived_impl. The key insight of this FAQ is that class Derived_impl does not need to inherit from class Base_impl. For example, Derived_impl could implement method f() directly, or it could contain a pointer to a Base_impl object and delegate f() to that object, or it could use some other technique.
This is an example of the separation of interface from implementation.

Q) What is a Good IDL interface?
A) Recognize that the interface to an in-memory object and an interface to a distributed object are likely very different.
Remote calls include network overhead. This puts a remote call in the "at least milliseconds" category, versus an in-memory call, which is in the "at least microseconds" category.
As much as possible, a single IDL operation should coorespond to a single unit of work in the business system.
IDL interfaces tend to be overly generous on the amount of information returned. This is because you don't want a situation where clients have to make follow up calls to get supporting data.
There are many different types of interfaces and design patterns. Some of the more common include:
Manipulation Interface - This is the interface used to manipulate a single object. E.g., a BankAccount.
Factory Interface - this is the interface used to create and delete objects. E.g., a Bank that creates and deletes BankAccounts. Or more explicitly, the interface could be named BankAccountFactory.
Search-To-Select Interface - This is the interface used to try to identify which object to manipulate. E.g., a BankAccountFinder that supports operations that take search data and return 0, 1, or more BankAccount object references or secondary keys.
Manager Interface - This is more a singleton, RPC style interface, whereby the object to manipulate is an argument in the operation rather than the object the call is made on. This style of interface can also be used to manipulate several objects in one call, and hence is used more in batch clients.
E.g., BankAccountManager that has an operation taking a sequence of BankAccounts to run credit checks on.
Distinguish conversational interfaces that are used by a client to represent a client-specific context versus entity interfaces that are used to represent a shared business object. The classic example is an order processing system, wherein the shopping cart is a conversational interface and the items being bought are entity interfaces.
Consider where the transactions are in the system and how these map to the interface operations.
Consider using the concept of idempotency. This helps with determining transaction completion status and recovery when asynchronous transactions are used or if the client is not a resource in the transaction.

Q) How do i express aggregation in IDL?
A) The aggregation of two objects is a very common OO design concept. Aggregation is also known as has-a and contains.
Since IDL doesn't support "public data," a programmer that is using an IDL interface cannot tell whether an aggregation is actually implemented using aggregation or by some other technique. In other words, IDL is a specification language that separates interface from implementation. In particular, IDL does not support implementation constructs such as aggregation.
However logical aggregation is supported by IDL: IDL lets you specify an operation that returns another interface, and this second interface could represent an object that is logically contained within the first object. Whether it's actually implemented using aggregation or not is an implementation issue, not a specification issue, and the implementer can do it either way without requiring any changes to the IDL interface.
Note that DCOM directly supports aggregation since DCOM combines implementation issues with specification issues. The COM <-> CORBA interworking specification actually maps aggregation to and from inheritance (CORBA IDL supports inheritance directly, and DCOM supports aggregation directly).

Q) Is it true that corba IDL can specify inheritance but not VIRTUAL methods?
A) Not really. Technically speaking, you can't specify "virtual" in CORBA IDL since "virtual" isn't a CORBA IDL keyword. However the effect of the C++ keyword "virtual" is to cause dynamic binding to occur, and since all CORBA IDL methods are implicitly dynamically bound, CORBA IDL actually does support the "virtual" concept.

Q) What is the initialization service?
A) The Initialization Service is used to find well-known system and user-defined services. The Initialization Service is best understood in the catch-22 presented by the Name Service: If the Name Service holds the system's application object references (IOR)... ...and the Name Service, itself, is composed of NamingContext objects (IORs) for storing and retreiving application IORs... ...and a client cannot access an object until it has its IOR...

Q) How does a client get a reference to a root NamingContext?
A) The reference has to be supplied to the client administratively. The Initialization Service provides a simple interface into this administrative information. The method is named "resolve_initial_reference()" and takes a string representing the name of the service, and returns a CORBA::Object accessing that service.

Q) What are the IDL interfaces defined with in the cosnaming module?
A) The CORBA Name Service is composed of two basic interfaces. The NameContext and the Binding Iterator. Remember that since the NameContext and the Binding Iterator are both CORBA interfaces, they are accessed via object references and are distributed. The NameContext contains "named" object references or other "named" NameContexts. It is similar to a directory that can contain named files or other named directories. NameContexts and Binding Iterators are usually implemented in the same Name Server process, but this is not a requirement. The CORBA NameService can be constructed as a set of interconnected NameContext objects and NameService processes.
The BindingIterator is used to iterate across object references contained within a particular NameContext. It basically provides a mechanism to get the number of named object references within a NameContext. It also provides a next_one and a next_n operation to retrieve individual named object references or contexts. Continuing with the directory analogy, The BindingIterator is a mechanism to do a ls or dir operation on a directory.

Q) How do i use a name context?
A) The NameContext interfaces supports two main operations, bind and resolve. Once a NameContext object reference is obtained, it can be used to "name" some other CORBA object, or retrieve an object reference by name. This means that you can call the bind method on a NameContext passing it an object reference and a name. This will place a named object reference into the NameContext for future resolve calls. If an application wishes to obtain an object reference by name is simply obtains the appropriate NameContext and call resolve with the particular name. This will cause the named object reference to be returned to the application making the resolve invocation.

Q) What if I do not know the name of the object?
A) The CORBA NameService was designed to allow object references to be obtained by name. Names need to be either agreed upon between servers or clients, or perhaps passed between components in the distributed application. It is also possible to use the BindingIterator interface to connect to any name object reference. The CORBA trading service might be more appropriate if the CORBA NameService is too limiting. Other architectures such as factories might be appropriate mechanisms to obtain object references.

Q) What is the quality of service provided by the event service?
A) The Event Service specification does not require a specific quality of service. It is up to the implementor of the event service to determine what the provided level is. For example, an event service implentation may ensure that events are deliver even if some piece to the event service fails. An event service could also support transactional events using OTS. An event service could also provide deliver via a non IIOP transport such as UDP broadcast or multicast. This could, of course, limit interoperability. An event service could also ensure that connections to a channel are persistent. This would mean that consumers would not have to re-connect if the server failed and then came back online.

Q) How does a corba object provide its services?
A) A CORBA Object provides a set of services to its object references. In doing so, the CORBA Object utilizes various parts of the ORB infrastructure. The skeleton (server side) infrastructure changed drastically in CORBA 2.3 when the Basic Object Adapter (BOA) was deprecated in favor of the Portable Object Adapter (POA).
The ORB and Object Adpter (OA) coordinate to provide the networking "know-how" of the CORBA Object, and the object implementation provides the actual oepration "know-how" of the CORBA Object. The ORB and OA are responsible for listening for requests, locating/activating the implementation object, and generating responses to caller. The BOA and POA are distinguished in the amount of standardization they provide and in the range of services they provide to manage policies and life-cycles of the CORBA and implementation objects. With either OA, the network request is delivered by the OA to the implementation object so that it can perform the real business logic associated with the request.

Q) What is a language mapping?
A) CORBA IDL is used to describe application and system interfaces in a manner that is independent of programming language and computer platform. A language mapping is a standard to convert the IDL to a particular programming language, like C, C++ or Java.

Q) How are the skeleton and implementation object combined?
A) The skeleton (server side) infrastructure changed drastically in CORBA 2.3 when the Basic Object Adapter (BOA) was deprecated in favor of the Portable Object Adapter (POA). This FAQ discusses both the BOA and POA.
The BOA offers two ways to associate the implementation object with the skeleton:
Derived: In the derived approach, the implementation object "is" also a skeleton. This is usually obtained via inheritance. The ORB's IDL compiler would generate an appropriate skeleton class (based on the IDL interface and data types) and the developer would derive their own implementation class from it. The skeleton is able to listen to the network, de-marshall/re-marshall data types, etc. The implementation knows how and what to do within the body of the CORBA operations. A CORBA server will simply instantiate the implementation and tell the BOA that it "is ready". Since the implementation "is" also a skeleton, the CORBA Object will be able to respond to CORBA requests.
Delegated: In the delegated approach, The ORB's IDL compiler would generate an appropriate skeleton class (based on the IDL interface and data types) which would then delegate the actual operation execution to another class. The skeleton is still responsible for reading and writing to the network, de-marshall/re-marshall data types, etc. The implementation knows how and what to do within the body of the CORBA operations. While the implementation does not actually inherit from the skeleton, it still needs to implement the same set of minimal methods corresponding the to IDL operations. A CORBA server will need to instantiate the skeleton, instantiate the implementation, instruct the skeleton as to the where abouts of the implementation (often known as TIEing the skeleton and implementation together) and the tell the BOA that the skeleton "is ready".
The POA is much more flexible and powerful than the BOA. The POA is fully described in another FAQ. The POA also introduces some new terminology, such as servant. This FAQ will use the BOA terminology to the extent possible.
At a basic level, the POA offers the same alternatives as the BOA for using derivation (inheritance) and delegation to associate implementation objects with the skeleton. Additionally, the POA provides the ability for a single implementation object to represent many CORBA objects in the skeleon. This is an important scalability mechanism.
At a more sophisticated level, however, the POA also allows the life-cycle of the implementation object to be independent of the life-cycle of the cooresponding CORBA object in the skeleton. Specifically, implementation objects can exist without being associated with the skeleton, and likewise the skeleton can represent CORBA objects that are not associated (always) with an implementation object. This is also an important scalability mechanism.

Q) What is the static invocation interface?
A) The CORBA specification defines two mechanisms for invoking operations on a CORBA Object. Functionaly, the two mechanisms provide the same capabilities. They allow basically the IDL defined operations on the CORBA object to be invoked, allow program variables to be passed to the operation as inbound parameters, and allow return values or out parameters to be passed from the server to the client. The first mechanism is known as the Static Invocation Interface (SII), the other is known as Dynamic Invocation Interface . Developers of client applications which use SII must know the name of the operation, and all parameters/return types prior to program compilation. The actual operation names and parameters/return values are in effect hard coded into the application source code.

Q) Which is the best mechanism to invoke operations on an object?
A) Generally speaking, SII is the easiest mechanism which can be used to invoke operations on a CORBA object. All applications which use SII could be implemented with DII. Not all applications which use DII can be implemented with SII. If an application can be developed with SII then it probably should be. This is because developing code with SII requires less code and is much more straight forward. The language compiler can be used to validate types and optimize code. There are certain conditions which make DII a better alternative.

Q) How doea a ORB support static invocation interface?
A) Implementations of the CORBA specification (i.e. a CORBA ORB) support SII in the following way. The ORB will provide an IDL compiler which is specific to that particular ORB product. When a developer compiles their IDL with the ORB vendor's IDL compiler, stubs and skeletons are created. These stubs and skeletons are static. This is because they do not change. If changes are made to the IDL, the stubs and skeletons must be regenerated by running the IDL compiler again. The IDL compiler generates a stub and skeleton based on the structure of the appropriate IDL interfaces. The stubs and skeletons are statically generated at IDL compilation time. These stubs are then either imported or included into the application which needs access to the CORBA Objects. The stubs and skeletons will have been generated to either directly or indirectly utilize IIOP to communicate. In many cases, the IDL compiler, will generate stubs to utilize Dynamic Invocation Interface to interact with the skeletons. The IDL compiler may also generate skeletons which utilize Dynamic Skeleton Interface to interact with the stubs.

Q) What is the deferres synchronous invocation?
A) DII also provides a deferred synchronous invocation. This feature is not part of CORBA 2.0's SII. Deferred synchronous invocations are submitted without having to wait for a response. This is similiar to a one-way operation except a return values and out parameters are possible, but must be polled for. CORBA 3.0 will support this type of invocation for both static and dynamic modes via the Asynchronous Messaging Service.

Q) What is the dynamic skeleton interface?
A) The CORBA specification defines two mechanisms for implementations of a CORBA Object to service its operation invocations. One is the static mechanism and the other is dynamic. The static mechanism requires that the implementation support the specific methods as required by statically known IDL interfaces. Implementations can do this through either a delegated or derived approach (i.e. inheritance or delegation/TIE). If the dynamic approach is taken, the implementation of the Object deals with the request generically and in a sense, has one "do-it" method for dealing with all requests. The implementatin must inforce type safety as apposed to relying on an IDL compiler or Language compiler to do it. DSI is much more complicated for a developer then relying on the IDL compiler to generate static request dispatching code.

Q) Under what conditions is DII appropriate?
A) The dynamic nature of DII provides certain advantages over SII. The following types of applications would require or benefit from DII:
Browsers for CORBA services (Naming, IR)
Application browsers
Bridges (protocol converters)
Applications accessing huge numbers of different interfaces
Monitoring applications
Applications which utilize DII do not need to include or import stubs generated by an IDL compiler in order to access a service. Applications like object browsers or monitors can access ANY objects without previous (complile time) knowledge of the interface. Using DII is more tedious than coding w/ SII. The DII interfaces must be used to specify the operation and each parameter's type and value. Type checking must be done by the developer using CORBA defined typecodes.

Q) How are object references obtained by applications?
A) Object references allow applications to issue distributed requests. How does an application acquire an object reference? CORBA provides a number of ways for this to occur. They basically fall into two categories, mechanisms to obtain initial object references and mechanisms to obtain subsequent object references. CORBA provides two standard ways to obtain an initial object reference:
ORB::resolve_initial_references(string): CORBA defines a vendor specific mechanism for obtaining an initial set of object references. While CORBA defines the interface for the mechanism, internals required to drive the functionality are not standardized. CORBA specifies that an application can obtain an object reference by calling resolve_initial_references(), but vendor specific configurations files, command line arguments, of environmental variable might be required for the call to succeed. Object references obtained in this way can most likely be implemented only within the same vendors ORB.
ORB::string_to_object(string): CORBA provides a vendor independent mechanism for obtaining an object reference. The string_to_object() operation returns an object reference directly from a particular string. The object reference is actually an interoperable object reference and thus can be implemented within an ORB supporting IIOP. Strings are basically encoded identifiers and are not human readable. The string can be hard coded into an application, stored and retrieved from a file, or obtained through some other IPC mechanism. Strings are initially created by calling object_to_string() on an actual object reference.
Once an application obtains an object reference, it can obtain subsequent objects by calling any remote operations on the original object reference that happen to return a CORBA object. CORBA refers to an object capable of returning an object reference as a factory. CORBA defines two services that are basically mechanisms by which subsequent object references can be obtained. These are listed below:
CORBA NameService , CORBA TraderService

Q) What are the current language mapping for corba?
A) The OMG has standardized the following language mappings for IDL:
C ,C++,Smalltalk ,Java ,Ada ,Cobol ,COM-based language bridge, e.g., Visual Basic .There is also a standardized reverse mapping from Java to IDL. There are other language mappings that are available from various vendors:
Tcl,PL/1 ,LISP ,Python,Perl .