Corba Interview Questions

Page 1, Page 2

What is CORBA? What does it do?

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.

What is CORBA good for?

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.

Can you give me high-level technical overview?

CORBA applications are composed of objects, individual units of running software that combine functionality and data, and that frequently (but not always) represent something in the real world. Typically, there are many instances of an object of a single type - for example, an e-commerce website would have many shopping cart object instances, all identical in functionality but differing in that each is assigned to a different customer, and contains data representing the merchandise that its particular customer has selected. For other types, there may be only one instance. When a legacy application, such as an accounting system, is wrapped in code with CORBA interfaces and opened up to clients on the network, there is usually only one instance. For each object type, such as the shopping cart that we just mentioned, you define an interface in OMG IDL. The interface is the syntax part of the contract that the server object offers to the clients that invoke it. Any client that wants to invoke an operation on the object must use this IDL interface to specify the operation it wants to perform, and to marshal the arguments that it sends. When the invocation reaches the target object, the same interface definition is used there to unmarshal the arguments so that the object can perform the requested operation with them. The interface definition is then used to marshal the results for their trip back, and to unmarshal them when they reach their destination. The IDL interface definition is independent of programming language, but maps to all of the popular programming languages via OMG standards: OMG has standardized mappings from IDL to C, C++, Java, COBOL, Smalltalk, Ada, Lisp, Python, and IDLscript. For more on OMG IDL, click here. This separation of interface from implementation, enabled by OMG IDL, is the essence of CORBA - how it enables interoperability, with all of the transparencies we've claimed. The interface to each object is defined very strictly. In contrast, the implementation of an object - its running code, and its data - is hidden from the rest of the system (that is, encapsulated) behind a boundary that the client may not cross. Clients access objects only through their advertised interface, invoking only those operations that that the object exposes through its IDL interface, with only those parameters (input and output) that are included in the invocation. Figure 1 shows how everything fits together, at least within a single process: You compile your IDL into client stubs and object skeletons, and write your object (shown on the right) and a client for it (on the left). Stubs and skeletons serve as proxies for clients and servers, respectively.  Because IDL defines interfaces so strictly, the stub on the client side has no trouble meshing perfectly with the skeleton on the server side, even if the two are compiled into different programming languages, or even running on different ORBs from different vendors. In CORBA, every object instance has its own unique object reference, an identifying electronic token. Clients use the object references to direct their invocations, identifying to the ORB the exact instance they want to invoke (Ensuring, for example, that the books you select go into your own shopping cart, and not into your neighbor's.) The client acts as if it's invoking an operation on the object instance, but it's actually invoking on the IDL stub which acts as a proxy. Passing through the stub on the client side, the invocation continues through the ORB (Object Request Broker), and the skeleton on the implementation side, to get to the object where it is executed.

How do remote invocations work?

Figure 2 diagrams a remote invocation. In order to invoke the remote object instance, the client first obtains its object reference. (There are many ways to do this, but we won't detail any of them here. Easy ways include the Naming Service and the Trader Service.) To make the remote invocation, the client uses the same code that it used in the local invocation we just described, substituting the object reference for the remote instance. When the ORB examines the object reference and discovers that the target object is remote, it routes the invocation out over the network to the remote object's ORB. (Again we point out: for load balanced servers, this is an oversimplification.)   How does this work? OMG has standardized this process at two key levels: First, the client knows the type of object it's invoking (that it's a shopping cart object, for instance), and the client stub and object skeleton are generated from the same IDL. This means that the client knows exactly which operations it may invoke, what the input parameters are, and where they have to go in the invocation; when the invocation reaches the target, everything is there and in the right place. We've already seen how OMG IDL accomplishes this. Second, the client's ORB and object's ORB must agree on a common protocol - that is, a representation to specify the target object, operation, all parameters (input and output) of every type that they may use, and how all of this is represented over the wire. OMG has defined this also - it's the standard protocol IIOP. (ORBs may use other protocols besides IIOP, and many do for various reasons. But virtually all speak the standard protocol IIOP for reasons of interoperability, and because it's required by OMG for compliance.) Although the ORB can tell from the object reference that the target object is remote, the client can not. (The user may know that this also, because of other knowledge - for instance, that all accounting objects run on the mainframe at the main office in Tulsa.) There is nothing in the object reference token that the client holds and uses at invocation time that identifies the location of the target object. This ensures location transparency - the CORBA principle that simplifies the design of distributed object computing applications.

CAN CORBA ALLOW SERVERS TO CAUSE CLIENT SIDE EVENTS OR NOTIFICATIONS?

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.

WHY WOULD APPLICATIONS REQUIRE ASYNCHRONOUS COMMUNICATIONS?

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.

DOES CORBA SUPPORT ASYNCHRONOUS COMMUNICATION?

Kind of. At the lowest level CORBA supports two modes of communication: A synchronous request/response which allows an application to make a request to some CORBA object and then wait for a response. A deferred synchronous request/response which allows an application to make a request to some CORBA object. An empty result will be returned immediately to the application. It can then perform other operations and later poll the ORB to see if the result has been made available. At the lowest level, the CORBA deferred synchronous communication does allow a certain degree of asynchronous communication. Polling for responses represents only one form of asynchronous communication. Other more sophisticated asynchronous communication can only be achieved by developing an architecture on top of the lowest levels of CORBA.

ARE APPLICATION THREADING AND ASYNCHRONOUS COMMUNICATION RELATED?

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.

ARE THERE IMPORTANT FORMS OF ASYNCHRONOUS COMMUNICATION THAT AREN’T SUPPORTED DIRECTLY BY CORBA?

Yeah, but you can fake it pretty easily. While CORBA does support a deferred synchronous request/response, it does not directly support distributed requests with a callback driven response. A callback driven response allows an application to perform an operation on a distributed object, associate a callback with the response, continue with other processing. When the server responds, the associated callback is automatically executed within the original caller’s application.

CAN CORBA APPLICATIONS BE MULTI-THREADED?

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.

WHY WOULD I DECIDE TO IMPLEMENT A CORBA CLIENT APPLICATION WITH MULTI-THREADING?

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.

WHY WOULD I DECIDE TO IMPLEMENT A CORBA SERVER APPLICATION WITH MULTI-THREADING?

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

ARE THERE DIFFERENT THREADING MODELS THAT CAN BE USED WITHIN CORBA SERVERS?

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.

ARE THERE REASONS TO AVOID THE DEVELOPMENT OF MULTI-THREADED CORBA APPLICATIONS ?

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.

DOES CORBA DEFINE HIGH LEVEL APPLICATION ARCHITECTURES?

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.

DO COMMON APPLICATION ARCHITECTURES EXIST?

There are many common application architectures that can be used within a CORBA based application. Some architectures are related to the way in which a CORBA object is referenced, and a few of these are described below. NON-EXCLUSIVE OBJECTS VS. EXCLUSIVE OBJECTS: 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. OTHER ARCHITECTURAL DISTINCTIONS MADE AT THE OBJECT LEVEL: 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.

CAN CORBA APPLICATIONS HAVE CALLBACKS?

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.

WHAT IS AN OBJECT REFERENCE?

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.

WHY A HANDLE RATHER THAN A “HARD” ADDRESS?

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

FOR HOW LONG IS AN OBJECT REFERENCE VALID?

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.

WHAT IF I WANT A PERSISTENT REFERENCE?

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”.

HOW DO I STRINGIFY AN OBJECT REFERENCE?

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).

WHAT IS THE FORMAT OF AN OBJECT REFERENCE?

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.

WHO CREATES OBJECT REFERENCES?

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).

HOW DO I COMPARE REFERENCES?

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.

WHAT OTHER SURPRISES ARE THERE WITH IS_EQUIVALENT()?

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.

IS THAT ALL OF THE BAD NEWS ABOUT IS_EQUIVALENT()?

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.

SO WHY DON’T WE JUST COMPARE STRINGIFIED REFERENCES?

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.

THIS SOUNDS TOO COMPLICATED. SHOULD I JUST LEARN DCOM INSTEAD?

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

WHY DO YOU SAY, “MOST PEOPLE NEVER NEED THIS KIND OF KNOWLEDGE”?

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

THEN WHY DID YOU JUST DRAG US THROUGH THE MUD?

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

WHEN DO I USE _VAR INSTEAD OF _PTR?

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.

WHAT IF I WANT TO INVOKE METHODS ON AN OBJECT IN ANOTHER ORB?

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

DOES AN IOR HAVE A DEFINED FORMAT AND, IF SO, WHY?

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.

WHAT IS THE FORMAT OF AN IOR?

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.

WHAT IS A TAG?

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.

WHAT IS A PROFILE?

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

WHAT IS THE DIFFERENCE BETWEEN THE TWO TYPES OF PROFILES?

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.

WHY DID YOU SAY THAT THE SPECIFIC DETAILS PROBABLY SHOULDN’T MATTER?

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

BUT HOW DOES MY PROGRAM USE AN IOR?

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.

WHAT ABOUT STRINGIFYING AN IOR?

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

WHEN I OBTAIN AN OBJECT REFERENCE, WHAT DETERMINES IF IT IS AN IOR OR JUST AN OR?

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.

WHAT IS A FACTORY?

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.

WHAT ARE SOME TYPICAL TYPES OF FACTORIES?

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();     };

DOES THE CORBA SPECIFICATION DEFINE ANY SPECIFIC CAPABILITIES FOR A FACTORY OBJECT?

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.

WHAT IS A DISTRIBUTED REFERENCE COUNTING ARCHITECTURE?

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.

WHY WOULD AN APPLICATION IMPLEMENT A DISTRIBUTED REFERENCE COUNTING ARCHITECTURE?

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”.

DOES CORBA SUPPORT DISTRIBUTED REFERENCE COUNTING ARCHITECTURES?

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.

WHAT PROBLEMS MIGHT BE ASSOCIATED WITH A DISTRIBUTED REFERENCE COUNTING ARCHITECTURE?

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.

IS THERE AN ALTERNATIVE TO DISTRIBUTED REFERENCE COUNTING ARCHITECTURES?

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.

CAN CORBA APPLICATIONS BE TUNED FOR BETTER PERFORMANCE?

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.

DO DIFFERENT CORBA IMPLEMENTATIONS PERFORM AT SIGNIFICANTLY DIFFERENT LEVELS?

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.

WHAT TYPES OF PERFORMANCE SHOULD I BE CONCERNED WITH?

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.

WHAT IS INTEROPERABILITY?

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.

HOW DOES CORBA SUPPORT INTEROPERABILITY?

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.

SHOULD I USE UNDERSCORES ("_") IN THE NAMES OF INTERFACES AND/OR METHODS?

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.

WHAT IS THE BASIC CORBA ARCHITECTURE?

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.

HOW ARE CORBA OBJECTS DEFINED?

CORBA objects are defined as Interfaces in IDL.

WHAT CAPABILITIES DO CORBA OBJECTS POSSESS?

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

WHAT ARE CORBA PSEUDO OBJECTS?

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.

WHY ARE PSEUDO OBJECTS NEEDED?

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.

WHAT IS THE PURPOSE OF IDL?

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:

DO I PROGRAM IN IDL?

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): IS IDL A SPECIFICATION LANGUAGE, AN IMPLEMENTATION LANGUAGE, OR BOTH? 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.

DOES MY IMPLEMENTATION NEED TO USE INHERITANCE JUST BECAUSE MY IDL INTRERFACE USES INHERITANCE?

Nope. 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.

HOW DO I EXPRESS AGGREGATION IN IDL?

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).

IS IT TRUE THAT CORBA IDL CAN SPECIFY INHERITANCE BUT NOT “VIRTUAL” METHODS?

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.

WHAT IS A GOOD IDL INTERFACE?

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.

HOW DOES A CORBA OBJECT PROVIDE ITS SERVICES?

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.

HOW ARE THE SKELETON AND IMPLEMENTATION OBJECT COMBINED?

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.

HOW ARE OBJECT REFERENCES OBTAINED BY APPLICATIONS?

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

WHAT IS A LANGUAGE MAPPING?

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.

WHAT ARE THE CURRENT LANGUAGE MAPPINGS FOR CORBA?

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

WHAT IS THE STATIC INVOCATION INTERFACE?

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.

WHICH IS THE BEST MECHANISM TO INVOKE OPERATIONS ON AN OBJECT?

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.

HOW DOES A ORB SUPPORT STATIC INVOCATION INTERFACE?

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.

WHAT IS THE STATIC INVOCATION INTERFACE?

The CORBA specification defines two mechanisms for invoking operations on a CORBA Object. Functionaly, the two mechanisms provide the same capabilities. They allow the IDL defined operations on any CORBA object to be invoked, they allow program variables to be passed to the operation as inbound and in/out parameters, and allow return values or out and in/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 (DII). Developers of client applications which use DII do not need to know the name of the operation or any of the parameter or return types when writing the program. The developer will utilize the DII mechanism which is part of the CORBA specification to make invocations of operations. DII also provides a facility to set up the parameters and return values of the particular invocation. DII is similiar to Java’s introspection features and RTTI in C++.

UNDER WHAT CONDITIONS IS DII APPROPRIATE?

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.

WHAT IS THE DEFERRED SYNCHRONOUS INVOCATION?

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.

WHAT IS THE DYNAMIC SKELETON INTERFACE?

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.

Page 1, Page 2