Information Technology Reference
In-Depth Information
CORBA, with its vendor-neutral position and set of open standards, has
always provided the most hope for a truly unified way to incorporate any
software object into a distributed assembly. However, the very openness of
CORBA and its associated loose specifications has contrived to be the cause
of its undoing. The CORBA products from most vendors—while compliant
with the standards—in fact differ somewhat from one another and hence
rely on vendor-specific protocols. This means that the key issue of standard-
ization is illusory. The lack of a tight specification, while appealing to poten-
tial vendors in that it allows them to build their own CORBA implementation,
means that the third-party market for CORBA-based applications does not
exist because there is no standard.
3.2.2.1.1 How CORBA Works
CORBA uses an ORB for implementing its interobject invocations. The latest
specification for the ORB specifies the Internet Inter-ORB Protocol (IIOP) as
the protocol by which objects are remoted . The ORB acts much like a bus or
backplane in a hardware device through which each CORBA object interacts
with other CORBA objects.
For a CORBA client object to request service from a CORBA server object, the
client must acquire a reference to the server component. The ORB will parse
the available services (methods) of the server object and connect them with
the request from the client object. The available methods are accessed by the
ORB from Interface Definition Language (IDL) skeletons programmatically
created for each server object. These IDL stubs are effectively the distributed
object's interface made available for reading, distribution, and connection by
the ORB. The IDL compiler provides type and method exposition information
for each skeleton that is then stored in an Interface Repository. Effectively, the
ORB is a message router and object invocation device that relies on IDL stubs
and skeletons to resolve the various service requests.
The server-side skeleton will receive the invocation from the ORB and
execute the requested method. Results from the method, as well as input
arguments from the client proxy, will be routed via IIOP to the ORB that is
responsible for providing them to the server stub. Hence, CORBA requires
multiple ORBs if a multiplatform solution is being deployed. The essence of
CORBA is the ORBs used to connect the various distributed objects. With
the advent of IIOP, some of the vendor specificity problems have been eased,
allowing ORBs from a variety of sources to interact successfully.
3.2.2.2 Microsoft Component Technologies
Microsoft developed the COM in the mid-1990s. COM provides a set of spec-
ifications for creating a COM component. A COM component can be created
in several languages, including non-object-oriented languages, which are
supported by Microsoft. Once the COM component is created, it is stored in
binary code so programs developed using different programming languages
Search WWH ::




Custom Search