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.
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.
All contents are nice to learn at one place.Thanks.Keep on update the same
ReplyDelete