Explanations of terms:

Object life cycle Defines how CORBA objects are created, removed, moved, and copied

Naming Defines how CORBA objects can have friendly symbolic names

Events Decouples the communication between distributed objects

Relationships Provides arbitrary typed n-ary relationships between CORBA objects

Externalization Coordinates the transformation of CORBA objects to and from external media

Transactions Coordinates atomic access to CORBA objects

Concurrency Control Provides a locking service for CORBA objects in order to ensure serializable access

Property Supports the association of name-value pairs with CORBA objects

Trader Supports the finding of CORBA objects based on properties describing the service offered by the object

Query Supports queries on objects

What is CORBA?

CORBA, or Common Object Request Broker Architecture, is a standard architecture for distributed object systems. It allows a distributed, heterogeneous collection of objects to interoperate.

Common Object Request Broker Architecture

The Common Object Request Broker Architecture (CORBA) is a standard defined by the Object Management Group (OMG) that enables software components written in multiple computer languages and running on multiple computers to work together.

CORBA uses an interface definition language (IDL) to specify the interfaces that objects will present to the outside world. CORBA then specifies a “mapping” from IDL to a specific implementation language like C++ or Java. Standard mappings exist for Ada, C, C++, Lisp, Smalltalk, Java, COBOL, PL/I and Python. There are also non-standard mappings for Perl, Visual Basic, Ruby, Erlang, and Tcl implemented by object request brokers (ORBs) written for those languages.

The OMG

The Object Management Group (OMG) is responsible for defining CORBA. The OMG comprises over 700 companies and organizations, including almost all the major vendors and developers of distributed object technology, including platform, database, and application vendors as well as software tool and corporate developers.

Interface:

CORBA IDL is simpler an elegant than COM IDLCOM has better tool support for creating and managing IDL than CORBA

Datatypes: IDL Datatypes ::

The Interface Type

The Interface describes the services provided by a CORBA object. These services appear in the form of operations (or methods), resembling methods

in Object Oriented Languages. The difference is that IDL is used only to specify the interfaces of these methods,

whereas the language like Java and C++ are used to specify interfaces and (usually) provide implementations for those interfaces methods.

 The IDL interface type is very much like the Java interface type because neither provides an implementation for the methods defined.

However, the major difference is  that IDL interfaces can contain attributes, whereas Java interfaces don’t.

An IDL interface definition can thus be compared to a C++ header file containing a class definition. Also a C++ class whose methods are all pure virtual can be considered analogous to the IDL interface.

All methods defined within an IDL interface are public they can be called by any other object having a reference to the interface’s implementation object.

IDL interfaces usually describe remote objects. So it provides some additional modifiers to further describe the interface and its members.

 

Methods and Parameters

Methods defines the functionality of the objects. Although the object’s implementation determines how the object behaves, the

interface’s method definitions determine what behavior the object implementing that interface provides

These method definitions are often called method signatures or just signatures.

IDL methods can use any IDL data types as input and output parameters – primitive types, structs, sequences and even interfaces.

The general syntax,

[oneway] return_type methodName(param1_dir param1_type param1_name, param2_dir param2_type param2_name, …);

The param dir modifier specifies the direction of each parameter (in, out, inout) A method signature, often simple called a signature, describes what a method

does, what parameters (and their types) the method takes as input, and what parameters it returns as O/P.

 

in, out and inout parameters

in parameter servers as input to the method out parameter is an output from the method inout parameter serves as an input to and an output from the method. In remote method terms, any in  and inout parameters are marshaled across the

network to the remote object. After the method executes, any out and inout parameters along with the method’s

return value are marshaled back to the calling object.

 

oneway methods

When an object calls a method on a remote object, that calling object waits (this is called blocking) for the method to execute and return.

When the remote object finishes processing the method invocation, (called a request) it returns to the calling object then continue its processing.

In general blocking refers to any point at which a process or thread is waiting for a particular resource or another process/thread.

Within the context of CORBA, if a client invokes a remote method and must wait for the result to be returned, the client is said to ‘block’.

A request is simply another name for a RMI. This term is commonly used when referring to the operation of a distributed system.

In the CORBA’s Dynamic Invocation Interface (DII), the remote method can be invoked through a request object.

When a method is declared oneway, it means that the object calling that method will not block. Rather, the object will call the remote method and then immediately continue processing, while the remote object executes the remote method.

The advantage of this approach is that the calling object can continue working rather than wait for the remote object to complete the request.

The disadvantage is that the method invocation returns before the method execution is completed, so the method cannot return a value.

Therefore, for an oneway method, the return value must be declared as void, and all parameters must be declared as in.

Another disadvantage is, a oneway method cannot raise any exception. Also, the calling object has no way of knowing whether the method executed successfully; the CORBA infrastructure makes a best-effort attempt to execute the method, but success is not guaranteed.

Therefore, the oneway methods are most useful for situations in which one object wants to inform another object of a particular status but

o Does not consider the message to be essentialo Does not expect a response

Multithreading can be used to overcome this blocking problem by creating a separate thread to invoke the remote method.

While that thread is blocked, waiting for the result to be returned, other threads can continue working.

Any CORBA interface can be used from any CORBA client.

Proxies, Stubs & Skeletons:

COM client & server stubs are called as Proxy & Stub and in CORBA called as Stub & Skeleton.

COM proxy-stub DLLs are used by all language environments. In CORBA, a separate stub-skeleton must be generated for each ORB/language combination.

Object handles:

CORBA supports multiple inheritance in the interface hierarchy. COM supports single inheritance only; however a COM object supports more than one distinct interface.

Object Creation:

CORBA factories are customized persistent CORBA objects.

Invocation:

CORBA supports user-defined exception types in IDL.

Destruction:

CORBA reference counts are maintained separately in the client and server.

CORBA Products :

The Java 2 ORB The Java 2 ORB comes with Sun’s Java 2 SDK. It is missing several features.

VisiBroker for Java A popular Java ORB from Inprise Corporation. VisiBroker is also embedded in other products. For example, it is the ORB that is embedded in the Netscape Communicator browser.

OrbixWeb A popular Java ORB from Iona Technologies.

WebSphere A popular application server with an ORB from IBM.

Netscape Communicator Netscape browsers have a version of VisiBroker embedded in them. Applets can issue request on CORBA objects without downloading ORB classes into the browser. They are already there.

Various free or shareware ORBs CORBA implementations for various languages are available for download on the web from various sources.

What are the goals of CORBA?

CORBA aims to allow interaction between potentially distributed component objects created by different manufacturers in different languages (location transparency and language transparency).

What is a heterogeneous distributed system?

A collection of communicating machines running different operating systems.

What is an ORB?

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.

What is the purpose of a request in CORBA?

A request is used to transfer the name of the method (the service) and the parameters between the client and the server.

What are the roles of a skeleton and a stub in CORBA?

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.

What is the role of an interface in CORBA?

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.

What is the purpose of IDL?

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.

What is the purpose of a mapping?

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.

What are the similarities and differences between RMI and CORBA?

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

WHAT IS THE INTERFACE REPOSITORY?

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.

WHY DOES CORBA NEED THE INTERFACE REPOSITORY?

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.

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.

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.