CORBA Interview Question

UNDER WHAT CONDITIONS IS DSI APPROPRIATE?

The dynamic nature of DSI provides certain advantages over static request dispatching. The following types of applications would require or benefit from DSI:

Server side bridges (protocol converters)

Monitoring applications

Interpreted or script driven services

Applications which utilize DSI do not need to include or import skeletons generated by an IDL compiler in order to provide a service. These serices can support request generically and must enforce type safety.

 

WHAT IS AN ANY?

An any is an IDL type that can represent “any” other IDL type. An any is the most abstract type. It requires runtime information to determine what type (and value) it really is.

 

Your Ad Here

HOW DOES AN ANY REPRESENT ITS RUNTIME TYPE?

Your Ad Here

This is where typecodes come in. See the section on typecodes.

 

WHEN WOULD I USE AN ANY?

An any comes in handy whenever you need to write IDL and do not know which CORBA type is appropriate.

This ambiguity rarely occurs in application IDL. Usually you know what you are dealing with and you use that type explicitly. Or, if you have an operation that may handle one of a couple of types (e.g., a float or a short), then a union is a possible type. Note, if you have an operation that is needs an abstract interface representation, then interface inheritance can be used. The ultimate base interface is CORBA::Object.

There are some cases, though, where an any is needed in application IDL. There are also some places where an any is used in system and service IDL. This is because the operation has to be generic enough to work with a broad range of types. For example, imagine the need to represent a generic property, which is a name-value pair. We have three choices:

Force all values to be strings, and then use a single struct. This approach has the advantage of being simple IDL. However, this potentially falls apart if it is difficult to represent the value as a string. Even if the representation is not a problem, the representation conversion is a hassle:

structProperty

{

stringname;

 stringvalue;

   };

   interfaceFoo

   {

   PropertygetElement(instringkey);

   };

Write a lot of different structs, one for each type of value. This approach has the advantage of explicit typing with no conversion. However, this falls apart if we have to represent a type that we don’t know of, e.g., a user-defined struct. Also this would lead to a lot of variants of the same operation, one that handled each kind of struct:

    struct FloatProperty

    {

      string name;

      float  value;

    };

 

    struct ShortProperty

    {

      string name;

      short  value;

    };

 

    //more and more

 

    interface Foo

    {

      FloatProperty getFloatElement(in string key);

      ShortProperty getShortElement(in string key);

    };

 

Use an any. This approach has the advantage of simple IDL. Also, it is completely expandable to all types, including user-defined types. Additionally, the application does not have to do conversions (this is essentially done in the marshalling/unmarshalling code). The disadvantage of this approach is the runtime typing — this impacts both the application code and the speed of the ORB communication:

 

   structProperty

   {

   stringname;

     any   value;

   };

interfaceFoo

   {

   propertygetElement(instringkey);

   };

 

Your Ad Here

OKAY, SO WHY NOT USE ANYS ALL THE TIME?

Sometimes the genericism of an any is appealing. But make sure you need this feature. The disadvantages of using an any include:

There is no compile-time type information. This makes the application code harder to write, debug, maintain, etc.

Communicating an any is relatively expensive for the ORB.

AN ANY SEEMS VERY DYNAMIC, SO WHAT’S A DYNAMIC ANY?

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

WHAT IS A TYPECODE?

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

DO ALL TYPES HAVE A TYPECODE?

Yes.

 

WHAT ARE THE TYPECODES FOR THE BUILT-IN IDL TYPES?

This depends on the language mapping. For example, in C++, there is a const instance of the TypeCode class for each of the built-in types.

 

WHAT ARE THE TYPECODES FOR THE USER-DEFINED TYPES?

Sticking with the above C++ example, there is a const instance of the TypeCode class for each user type. The IDL compiler generates this.

HOW DO I GET AN OBJECT’S TYPECODE

An interface’s typecode can be determined by calling _get_interface() on the object reference (IOR). This will return an InterfaceDef (Interface Definition) reference from the Interface Repository (IFR).

The typecode for things like float and string are well known in the language mapping. The typecode for things like structs are generated by the IDL compiler.

An any supports a call to determine its typecode. Note, the complete support for this requires Dynamic Anys.

 

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.

1

2

3

4

5

6

7