Middleware Technologies [MCA II Yr, Anna University] by Roy Antony Arnold

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
  • Does not consider the message to be essential
  • 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.

• Combine other types to enable the creation of user-defined data types.

a) enumerated type

• The enumerated type, enum allows the creation of types that can hold one of a set of predefined value specified by the enum.
• Although the identifiers in the enumeration comprise an ordered list, IDL does not specify the ordinal numbering for the identifiers.
• This is similar to enum in C and C++

Ex:

            enum DaysOfWeek

            {

                        Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday

            };

b) structure type

• Contains any no. of member values of disparate types
• Structures are useful in IDL because, unlike CORBA objects, structures are passed by value rather than by reference.
• In other words, when a struct is passed to a remote object, a copy of that struct’s value is created and marshaled to the remote object.

Ex:

            struct DateStruct

            {

                        short year,

                        short month,

                        short day,

                        short hour,

                        short minute,

                        short second,

                        short microsecond

            };

c) union type

• Represents values of different types.
• Resembles a cross between a C/C++ union and a case statement.

Ex:

            union MultipleType switch(long)

            {

                        case 1:

                                    short myShortType;

                        case 2:

                                    double myDoubleType;

                        case 3:

                        default:

                                    string myStringType;

            };

• Here, the parameter is called as discriminator.
• A discriminator used in an IDL union is a parameter that determines the value used by the union. The constant values in the case statements must match the discriminator’s type.

Primitive Types

IDL features a variety of primitive types. These types store simple values such as integral numbers, floating point numbers, character strings, and so on.

a) void

• This is analogous to the void type in C, C++ and Java
• This is useful for methods that don’t return any value.

b) boolean

• Stores a boolean value either 0 (false) or 1(true)
• Depending on the programming language used, the IDL boolean type can map to an integral type (short int in C/C++) or to the language’s native Boolean type (as in Java)

boolean aBoolean;

c) char and wchar

• This is analogous to char type in C/C++ and Java. And directly maps.
• Stores a single character value
• The char data type is an 8-bit quantity

char aChar;

• In version 2.1, wchar or wide character type is an 16-bit quantity

Floating Point Types

a) float

• The IDL float type represents an IEEE single-precision floating point value
• Analogous to C, C++, and Java

float aFloat;

b) double and long double

• Represents an IEEE double-precision floating point value
• Corresponds to the double type in leading languages

double aDouble;

• The long double type, introduced in CORBA 2.1, represents IEEE double-extended floating point value, having an exponent of at least 15 bits and a signed fraction of at least 64 bits.

Integer Types

• Unlike most familiar programming languages, IDL doesn’t define a plain int type only short and long integer types.

a) long and long long

• The IDL long type represents a 32-bit signed quantity, like C/C++’s int and Java’s int

Ex: long aLong;

• In CORBA 2.1 the long type was added, which is a 64-bit signed quantity

b) unsigned long and unsigned long long

• The unsigned long type in IDL is an unsigned version of the long type

Ex: unsigned long anUnsignedLong;

• CORBA 2.1 added the unsigned long long type, which is a 64-bit unsigned quantity.

c) short

• Represents a 16-bit signed quantity, as in C, C++, and Java
• It’s range -2¹⁵ … 2¹⁵-1.

Ex: short aShort;

d) unsigned short

• Unsigned version of short
• Range   – 0…216-1

Ex: unsigned short aUnsignedShort;

e) octet

• It is an 8-bit quantity that is not translated in any way during transmission.
• The similar type is available in Java as byte.

Ex: octet aOctet;

f) string

• Represents a collection of characters. Similar to C++’s Cstring and Java’s String class.
• In ‘C’ character arrays are used as string.
• IDL supports fixed-length and variable-length strings.

Ex: string aFixedLength[20];

       string aVariantLength;

The const modifier

• const values are useful for values that should not change.
• The scope of the const value is interface or module.

Ex: const float pi = 3.14;

IDL Ground Rules

a) Case Sensitivity

• Identifiers are case sensitive.
• The names of identifiers in the same scope cannot differ in case only. Ex. in the myObject interface, IDL would not allow an operation named anOperation and another operation named anOPERATION to be simultaneously.

b) IDL Definition Syntax

• All definitions in IDL are terminated by a semicolon (;), much as they are in C, C++, and Java
• Definitions that enclose other definitions do so with braces. (modules & interfaces)
• When a closing brace also appears at the end of a definition, it is also followed by a semicolon it represents a module.

c) IDL Comments

• Both C-Style and C++-Style comments are allowed

// C++ comment allowed

/* C – Style Comment allowed */

d) Use of the C Preprocessor

• IDL assumes the existence of a C preprocessor to process constructs such as macro definitions and conditional compilation.

Ex: #ifdef….#endif, #include etc.

e) The Module

• The module construct is used to group together IDL definitions that share a common purpose.
• A module declaration specifies the module name and encloses its members in braces.

Ex:

module Bank {

interface Customer {

…

};

interface Account {

…

};

…

};

• The grouping together of similar interfaces, constant values, and the like is commonly referred to as partitioning and is a typical step in the system design process.
• Partitions are also often referred to as modules or as packages.

f) Coupling and Cohesion

• Loose coupling means that components in separate modules are not tightly integrated with each other; an application using components in one module generally need not know about components in another module. When there is little or no dependency between components, they are said to be loosely coupled.
• Tight cohesion means that interfaces within the module are tightly integrated with each other.
• Loose coupling of components reduces the possibility that changes to one component will require changes to another.