Wednesday, September 9, 2009

CORBA Interview Question

Your Ad Here

WHAT ARE OBJECTS BY VALUE?

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

 

HOW CAN I USE OBV?

The valuetype definition supports both data members and operations, similar to C++ and Java class definitions. The receiving side creates its own copy of the object and all operations invoked on valuetypes are always local to the receiving process.

So, how can you use OBV? In our opinion, very carefully :-). This extension offers some flexibilities and a lot of rope to hang oneself. In particular, there are several very complex edge effects of the OBV specification, such as when interface references and valuetypes are intermixed. By focusing on a few, simple valuetypes that provide operations that are basic functionality (such as edit rules, data validations, conversions and queries (e.g., what day is 1/1/2000), and other utility operations), the use of valuetypes will be clearer to those that use them.

WHAT DOES OBV REALLY PROVIDE?

 

From the OBV specification:

Valuetypes provide semantics that bridge between CORBA structs and CORBA interfaces:

              They support description of complex state (i.e arbitrary graphs).

              Their instances are always local to the context in which they are used (because they are always copied when passed in a remote call).

              They support both public and private (to the implementation) data members.

              They can be used to specify the state of an object implementation, i.e they can support an interface.

              They support single inheritance (of valuetypes) and can support multiple interfaces.

              They may be also be abstract.

WHAT IS A VALUE TYPE?

A Value Type is an object whose semantics lie between a CORBA interface and a structure. There are two types a Value Types that can be declare:

Concrete Value Types

Abstract Value Types

Concrete Value Types define state (properties) and the implementation is always local. Abstract Value Types do not define properties. Both Concrete and Abstract Value Types can define operations (interface) and inherit from other Value Types and interfaces.

 

IN WHAT CASES DO I NEED A VALUE TYPE?

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

 

Your Ad Here

HOW DOES A VALUE TYPE DIFFER FROM AN INTERFACE TYPE?

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

 

WHAT IS AN ABSTRACT VALUE TYPE?

An Abstract Value Type is a Value Type that may not be instantiated. Only Concrete Types can be instantiated and implemented. Also, no state information may be specified in an Abstract Type.

 

WHAT IS THE PURPOSE OF THE ASYNCHRONOUS MESSAGING INTERFACE?

The AMI extends the request/response nature of CORBA into messaging services. The messaging services are richer than the “oneway” or “deferred synchronous” functionalities in the core CORBA specification, and also pull in elements from the Event and Notification Services.

The AMI works with the notion of “implied IDL”. The means that although the IDL for an interface, Foo, has a single operation, bar, there are other implied operations, e.g., try_bar, that are used to support asynchronous communications.

 

CAN CORBA BE INTEGRATED WITH XML?

INDEX:XML@Integration with CORBA INDEX:CORBA@Integration with XML

Yes. And in a number of ways, depending on the need and approach.

 

Using IDL to communicate XML. This means setting up simple interfaces to communicate the XML Document Type Description (DTD) and the XML document itself. Obviously, there may be a repository of DTDs, and the actual communication of the XML document simply refer to its DTD.

Using XML as a transport. This means there is a DTD for, essentially, IIOP. A CORBA request or response is communicated in XML.

A variation on the previous item, once the XML to CORBA request/response conversion is in place, a gateway can take XML or CORBA requests from various sources and map them into XML or CORBA requests on various services.

Using XML as an abstract system description language. XML could be used to describe a system interfaces, workflow, API mapping logic, data definitions, other semantics, etc., and then this XML is used to produce IDL. Chances are the XML would also be used to code generate supporting system integration class libraries and potentially entire clients/servers.

1

2

3

4

5

6

7

Your Ad Here

 

1 comment:

  1. All contents are nice to learn at one place.Thanks.Keep on update the same

    ReplyDelete