2. Introduction:
The Common Object Request Broker Architecture (CORBA) is a standard
defined by the Object Management Group (OMG) that enables software
components written in multiple computer languages and running on multiple
computers to work together (i.e., it supports multiple platforms).
CORBA provides a platform-independent, language-independent way to write
applications that can invoke objects that live across the room or across the
planet.
CORBA enables separate pieces of software written in different languages and
running on different computers to work with each other like a single application
or set of services. More specifically, CORBA is a mechanism in software for
normalizing the method-call semantics between application objects residing
either in the same address space(application) or remote address space(same
host, or remote host on a network).
Common Object RequestBroker Architecture enables separate pieces of
software written in different languages to interact with each other.
It uses an Interface Definition language (IDL) to specify the interfaces which
objects present to the outer world. CORBA specification tells there should be an
ORB (Object Request Blockers) through which an application would interact
with other objects.
In practice, the application simply initialize the ORB and access an interact
object Adapter which maintains things like reference counting, object
installation policies and object lifetime policy.
CORBA uses an interface definition language (IDL) to specify the interfaces
which objects present to the outer world. CORBA then specifies a mapping
from IDL to a specific implementation language like C++ or Java. Standard
mappings exist for Ada, C, C++, Lisp, Ruby, Smalltalk, Java, COBOL, PL/I
and Python. There are also non-standard mappings for Perl, Visual Basic,
Erlang, and Tclimplemented by object request brokers (ORBs) written for those
3. languages. Currently the OMG is working on a new IDL to C++11 language
mapping.
What is the OMG?
• Designers of CORBA
• Consortium of 700+ companies
– Not including Microsoft
Members:
platform vendors
database vendors
software tool developers
corporatedevelopers
software application vendors
Basic CORBAarchitecture:
REQUEST RESPONSE
OBJECT BUS
ORB (Object RequestBroker):
Handles all communication among objects
Each host (machine) has its own ORB
Client
Server
ORB
ORB
4. ORBs know how to talk to each other
ORB also provides basic services to client
Functions of the Object RequestBroker:
Find the object implementation for the request
Prepare the object implementation to receive the request
Communicate the data making up the request
Retrieve results of request
Stubs and skeletons:
Stub
lives on client
pretends to be remote object
Java objects call stub methods and the stubs communicate with
CORBA objects and vice versa
Skeleton
lives on server
receives requests from stub and talks to true remote object
delivers responseto stub
What is Corba goodfor?
Developing distributed applications
Locating remote objects on a network
Sending messages to those objects
5. Common interface for transactions, security, etc.
Client vs Server:
In CORBA, a client is a client relative to a particular object i.e. an object
with a reference to a “server” object
A client may also act as a server if it has an IDL and stubs and skeletons
Technically, a CORBA server contains one or more CORBA objects
Basic working:
Main components
The main components or CORBAare:
The ORB (object request broker)
o Enables the communication between clients, and objects located at
various clients
CORBA objects
o A "virtual" entity capable of being located by an ORB. Allows
requests to be invoked on it
Servants
o The programming language entity that implements one or more
CORBA objects
Object Adapters
6. o The "glue" between servants and the ORB
• Distributed object model
CORBA objects are binary components that can reside anywhere in a
network.
CORBA objects (components)can be transactional, secure, lockable, and
persistent.
Remote clients can access server objects without knowledge of their
location, platform
type, operating system, or implementation language.
Interfaces are specified in a neutral Interface Definition Language (IDL)
• Interface Repository
contains interface definitions for registered CORBA server components.
Interfaces are represented in a “metadata” format so that they can be
discovered dynamically at run time.
• The Object requestBroker(ORB)
functions as an object bus, facilitating location independent
communication among CORBA objects
provides a range of distributed services the CORBA standard provides a
specification
for ORB services
it is up to individual vendors and/or third parties to provide
implementations for varius
platforms/operating systems
• ORB Services:
o programming language bindings
o method invocations
static (compile time)
dynamic (run-time)
o interface repository
o local/remote transparency
within a process, among different processes onsame machine and across
heterogeneous networks
o Internet Inter-ORB Protocol(IIOP)
o Transaction processing
o security
Note that CORBA supports a true object model--i.e operations are
invoked on specific target objects.
o allows polymorphism
7. Can encapsulate existing (non-OO) applications through IDL interfaces to
function as CORBA objects
Types of Corba technology and business objects:
CORBAbasic types
Most of the CORBA types map directly onto C++ types and can be used
transparently to C++. The following basic C++ types map directly into CORBA
types:
Atomic data types:
o Boolean
o Char
o Double
o Float
o Long
o Octet (hexadecimal)
o Short
o ULong (unsigned long)
o UShort (unsigned short)
Enum (enumerations)
LongLong (long long)
Struct
ULongLong (unsigned long long)
WChar (wide character)
All of these types are scoped to the CORBA class and must be declared
accordingly. Their use in C++ is transparent and straightforward. For example:
CORBA::Short aShortvariable;
...
aShortVariable = 12;
...
CORBAtypes that return objectreferences
Other CORBA types are not as straightforward to use because they return object
references to the caller. The following CORBA types return object references to
the caller:
Any
Array
Sequence
String
8. Union
WString (wide string)
It is the responsibility of the caller to manage the object references and their
associated memory. There are two facilities provided by CORBA to do this:
A_var:
This is the facility most frequently used by client codebecause it is a
smart pointer that automatically releases its object reference when it is
deallocated or assigned a new object reference. This is the safest and
most straightforward approachto managing these types.
A_ptr:
This is a pointer type that provides the most basic object reference, which
has similar semantics to a standard C++ pointer.
Note:Avoid declaring C++ Static variables as _var. The _var holds a
reference to an object. During the end of the process, this object might
reference another object that was removed before end processing completes
for this static type. As a result, the _var might reference an inappropriate
address or null pointer and thereby cause an undesirable ending.
9. Application:
An n-tier designwith Corba technology:
CORBA Services
Another important part of the CORBA standard is the definition of a set of
distributed services to supportthe integration and interoperation of distributed
objects. As depicted in the graphic below, the services, known as CORBA
Services or COS, are defined on top of the ORB. That is, they are defined as
standard CORBA objects with IDL interfaces, sometimes referred to as "Object
Services."
10. There are several CORBA services. The popular ones are described in detail in
another module of this course. Below is a brief description of each:
Service Description
Object life cycle Defines how CORBA objects are created, removed,
moved, and copied
Naming Defines how CORBA objects can have friendly
symbolic names
Events Decouples the communication between distributed
objects
Relationships Provides arbitrary typed n-ary relationships between
CORBA objects
Externalization Coordinates the transformation of CORBA objects to
and from external media
Transactions Coordinates atomic access to CORBA objects
ConcurrencyControl Provides a locking service for CORBA objects in order
to ensure serializable access
Property Supports the association of name-value pairs with
CORBA objects
Trader Supports the finding of CORBA objects based on
properties describing the service offered by the object
Query Supports queries on objects
CORBA Products
CORBA is a specification; it is a guide for implementing products.Several
vendors provide CORBA products for various programming languages. The
CORBA products that supportthe Java programming language include:
ORB Description
The Java 2 ORB The Java 2 ORB comes with Sun's Java 2 SDK. It
is missing several features.
VisiBrokerfor Java A popular Java ORB from Inprise Corporation.
11. VisiBroker is also embedded in other products. For
example, it is the ORB that is embedded in the
Netscape Communicator browser.
OrbixWeb A popular Java ORB from Iona Technologies.
WebSphere A popular application server with an ORB from
IBM.
Netscape Communicator Netscape browsers have a version of VisiBroker
embedded in them. Applets can issue request on
CORBA objects without downloading ORB
classes into the browser. They are already there.
Various free or
shareware ORBs
CORBA implementations for various languages
are available for download on the web from
various sources.
Providing detailed information about all of these products is beyond the scope
of this introductory course. This coursewill just use examples from both Sun's
Java 2 ORB and Inprise's VisiBroker 3.x for Java products.
The Stock Application
The stocktrading application is a distributed application that illustrates the Java
programming language and CORBA. In this introductory module only a small
simple subset of the application is used. Feel free to expand upon the
application to enhance it once you are more comfortable with CORBA.
The stockapplication allows multiple users to watch the activity of stocks. The
user is presented with a list of available stocks identified by their stocksymbols.
The user can select a stockand then press the "view" button.
12. Selecting the "view" button results in a report about the stock, indicating the
name of the company, the stocksymbol, the current price, the last time it was
updated, the trading volume, and a graph that shows the stockprice over some
interval. This report is automatically updated as new stockdata becomes
available.
The stockreport also lets the user set an alarm by pressing the "Alarm" button.
The alarm can be set to activate when the price of the stock falls below a certain
price or when it exceeds a certain price.
When the price of the stock satisfies the alarm's condition, it activates and the
user is notified.
Later the application could be extended to allow users to buy and sell stocks.
SomeObjects in the Stock Application
From the above description, you can easily identify the following distributed
objects in the application.
Stock A distributed object that represents a particular
13. stock.
StockPresentation A distributed object in the GUI that presents the
stockdata to the user for a particular stock.
Alarm A distributed object that represents the alarm set by
the user.
AlarmPresentation A distributed object in the GUI that presents the
alarm going off to the user.
The Stock objectis now used to illustrate the CORBA distributed object model.
Benefits of Corba technology:
Maturity
Open standard
Wide platform support
Wide language support
Efficiency
Scalability
CORBA Success Stories
Above it was mentioned that CORBA is a type of middleware, but that there are
other types of middleware too. This naturally raises the question of why you
might wish to use CORBA instead of a different middleware technology. The
reason, as I discuss in this chapter, is that CORBA offers numerous important
benefits. You may find some of these benefits in other middleware technologies,
but you will be hard pressed to find another middleware technology that
offers all of these benefits.
2.1 Maturity
14. The original version of the CORBA standard was defined in 1991. This first
version of the specification was deliberately limited in scope. TheOMG’s
philosophy was to define a small standard, let implementors gain experience
and then slowly expand the standard to incorporate more and more capabilities.
This “slow but sure” approachhas been remarkably successful. In particular,
there have been few backwards-incompatible changes to the CORBA
specification. Instead, new versions of the specification have tended to add new
functionality rather than modify existing functionality. Today, CORBA is
extremely feature-rich, supporting numerous programming languages, operating
systems, and a diverse range of capabilities—such as transactions, security,
Naming and Trading services, messaging and publish-subscribe services—that
are essential for many enterprise-level applications. Many newer middleware
technologies claim to be superior to CORBA but actually have to do a lot of
“catching up” just to match some of the capabilities that CORBA has had for a
long time.
2.2 Open standard
CORBA is an open standard rather than a proprietary technology. This is
important for a variety of reasons.
First, users can choosean implementation from a variety of CORBA vendors
(or chooseone of the freeware implementations). You might think that
switching from one CORBA productto another would involve a lot of work.
However, the amount of work involved is likely to be much less than you might
think, particularly if you follow the practical advice in Chapter 25 about how to
increase the portability of CORBA-based applications. In contrast, if you use a
proprietary middleware system then switching to another proprietary
middleware vendor is much more challenging.
Second, the competition between different CORBA vendors helps to keep
software prices down.
Finally, many proprietary middleware technologies are designed with the
assumption that developers will build all their applications using that particular
middleware technology, and so they provide only limited supportfor integration
with other technologies. In contrast, CORBA was designed with the goal of
making it easy to integrate with other technologies. Indeed, the CORBA
specification explicitly tackles integrations with TMN, SOAP, Microsoft’s
(D)COM and DCE (a middleware standard that was popular before CORBA).
Furthermore, many parts of J2EE borrow heavily from concepts in CORBA,
which makes it relatively easy to integrate J2EE and CORBA. Some vendors
sell gateways between CORBA and J2EE that make such integration even
easier. Several CORBA vendors sell COM-to-CORBAand/or .NET-to-CORBA
gateways. This provides a very pragmatic solution to organizations that wish to
15. write GUI applications in, say, Visual Basic on Windows that act as clients to
server applications on a different type of computer, such as UNIX or a
mainframe. The Visual Basic GUI can be written as a COM/.NET client that
thinks it is talking to a COM/.NET server, but in fact communicates with a
gateway that forwards on requests to a CORBA server.
2.3 Wide platform support
CORBA implementations are available for a wide variety of computers,
including IBM OS/390 and Fujitsu Global Server mainframes, numerous
variants of UNIX (including Linux), Windows, AS/400, Open VMS, Apple’s
OS X and several embedded operating systems. There are very few other
middleware technologies that are available on such a wide range of computers.
2.4 Wide language support
CORBA defines standardized language mappings for a wide variety of
programming languages, such as C, C++, Java, Smalltalk, Ada, COBOL, PL/I,
LISP, Python and IDLScript. Some small organizations might use a single
programming language for all their projects, but as an organization increases in
size, it becomes increasingly likely that the organization will make use of
several programming languages. Likewise, the older an organization is, the
higher the likelihood becomes that some of its “legacy” (older) applications are
implemented in one programming language and newer applications are
implemented in a different programming language. For these organizational
reasons, it is important for a middleware system to supportmany programming
languages; unfortunately, not all middleware systems do so. One extreme case
of this is J2EE, which supports only Java. Another extreme case is the
SOAP middleware standard. SOAP applications can be built with a variety of
programming languages but, at the time of writing, the SOAP standard defines
only one language mapping (for Java). There may be several vendors who
support, say, C++ development of SOAP applications, but each of those vendors
provides their own proprietary C++ APIs. This means that there is no source-
codeportability of non-Java SOAP applications across different vendor
products.
2.5 Efficiency
The on-the-wire protocolinfrastructure of CORBA (discussed in Chapter 11)
ensures that messages between clients and servers are transmitted in a compact
representation. Also, most CORBA implementations marshaldata(that is,
convert data from programming-language types into a binary buffer that can be
transmitted) efficiently. Many other middleware technologies also use a
16. similarly compactformat for transmitting data and have efficient marshaling
infrastructure. However, there are some notable exceptions, as I now discuss.
SOAP uses XML to represent data that is to be transmitted. The verbosity of
XML results in SOAP using much more network bandwidth than
CORBA.1 SOAP-based applications also incur considerable CPU overhead
involved in formatting programming-language types into XML format and later
parsing the XML to extract the embedded programming-languages types.
Some other middleware technologies, such as IBM MQ Series, transmit only
binary data, which is efficient. However, this requires that developers write the
marshaling codethat copies programming-language types into the binary
buffers prior to transmission, and the unmarshaling codeto extract the
programming-language types from a binary buffer. In contrast, a CORBA IDL
compiler generates the marshaling and unmarshaling code, so that developers
do not need to write (and maintain) such low-level code.
2.6 Scalability
The flexible, server-side infrastructure of CORBA (Chapter 5) makes it feasible
to develop servers that can scale from handling a small number of objects up to
handling a virtually unlimited number of objects. Obviously, scalability varies
from one CORBA implementation to another but, time and time again, real-
world projects have demonstrated that a CORBA server can scale to handle not
just a huge amount of server-side data, but also high communication loads from
thousands of client applications. Most CORBA vendors will likely know of
customers who have tried a different middleware technology, found that it could
not scale sufficiently well and then switched to CORBA.
2.7 CORBASuccessStories
With such an impressive list of benefits as those discussed in this chapter, it is
little wonder that CORBA is being used successfully in many industries,
including aerospace, consulting, education, e-commerce, finance, government,
health-care, human resources, insurance, ISVs, manufacturing, military,
petrochemical, publishing, real estate, research, retail, telecommunications, and
utilities.
CORBA is used in everything from billing systems and multi-media news
delivery to airport runway illumination, aircraft radio control and the Hubble
spacetelescope. Most of the world’s telephone systems, as well as the truly
mission-critical systems operated by the worlds biggest banks, are built on
CORBA.
17. A discussion about real-world projects that have benefitted from the use of
CORBA is outside the scopeof this book. However, many CORBA success
stories are available on various web sites. For example, you can find over 300
CORBA success stories on www.corba.org. The web sites of some CORBA
vendors also contain more detailed success stories.
Implementation Steps:
CORBA object implementations are completely invisible to their clients. A
client can only depend on the IDL interface. In the Java programming language,
or C++, this is not the case. The user of an object declares variables by a class
name; doing so makes the codedepend on much more than just the interface.
The client depends on the object implementation programming language, the
name of the class, the implementation class hierarchy, and, in C++, even the
object layout.
18. The complete encapsulation for CORBA objects means the object implementor
has much more freedom. Object implementations can be provided in a number
of supported programming languages. This is not necessarily the same one the
clients are written in. (Of course, here everything is in the Java programming
language, but CORBA does notrequire this.)
The same interface can be implemented in multiple ways. There is no limit. In
the stock example, the following are possible implementations of
the Stock interface:
A stockimplementation class written in the Java programming language that
obtains values from a commercial feed
A stockimplementation class written in C++ that accesses a database on the
Internet
A stockimplementation written in Smalltalk that guesses stockprices
Step 1: Define the interface:
Hello.idl
module HelloApp {
interface Hello {
string sayHello();
};
};
Step 2: Map Hello.idl to Java:
Use the idlj compiler (J2SE 1.3)
idlj –fall Hello.idl
This will generate:
_HelloImplBase.java (server skeleton)
HelloStub.java (client stub, or proxy)
Hello.java
HelloHelper.java, HelloHolder.java
HelloOperations.java
Step 3: Implement the interface:
Implement the servant:
import HelloApp.*;
class HelloServant extends _HelloImplBase {
public String sayHello() {
return “nHello Theren”;
}
}
Step 4: Implement the server:
19. Import statements:
import org.omg.CosNaming.*;
import
org.omg.CosNaming.NamingCotextPackage.*;
import org.omg.CORBA.*;
class HelloServer {
public static void main(String argv[]) {
try {
Create and initialize the ORB:
ORB orb = ORB.init(argv, null);
Create the servant and register it with ORB
HelloServant helloRef = new HelloServant();
orb.connect(helloRef);
Get the root NamingConext:
org.omg.CORBA.ObjectobjRef =
orb.resolve_initial_references(“NameService”);
NamingContext ncRef =
NamingContectHelper.narrow(objRef);
Bind the object reference in naming
NameComponent nc = new
NameComponent("Hello", " ");
NameComponent path[] = {nc};
ncRef.rebind(path, helloRef);
Wait for invocations from clients:
java.lang.Object sync =
new java.lang.Object();
synchronized(sync) {
sync.wait();
}
Catch the exceptions
} catch(Exception e) {
System.err.println("ERROR: " + e);
e.printStackTrace(System.out);
} // end catch
} // end main()
} // end class
20. Step 5: Write a client:
Import statements:
import HelloApp.*;
import org.omg.CosNaming.*;
import org.omg.CORBA.*;
class HelloClient {
public static void main(String argv[]){
try {
Create and initialize the ORB:
ORB orb = ORB.init(argv, null);
Create the root naming context:
org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService");
NamingContext ncRef =
NamingContextHelper.narrow(objRef);
Resolve the object reference in naming:
NameComponent nc =
new NameComponent("Hello", " ");
NameComponent path[] = {nc};
Hello helloRef =
HelloHelper.narrow(ncRef.resolve(path));
Call the object:
String Hello = helloRef.sayHello();
System.out.println(Hello);
Catch exception:
} catch(Exception e) {
System.out.println("ERROR : " + e);
e.printStackTrace(System.out);
} } } // end catch, main, class
Step 6: Run the application:
Run the naming service:
prompt> tnameserver
Run the server
prompt> java HelloServer
Run the client
prompt> java HelloClient
21. Hello There prompt>
Java RMI & CORBA
A comparison of two competing technologies
With the introduction of CORBA supportto Java (as of version 1.2), developers
now face the question of whether to continue to use remote method invocation
(RMI), or make a move to CORBA. The choice is made more difficult if your
applications are already written in RMI - considerable effort might have to be
made to convert to CORBA. Is it worth the move? This article discusses the
pros and cons, and evaluates the potential of these two technologies.
What is Remote Method Invocation?
Remote method invocation allows Java developers to invoke object methods,
and have them execute on remote Java Virtual Machines (JVMs). Under RMI,
entire objects can be passed and returned as parameters, unlike many remote
procedurecall based mechanisms which require parameters to be either
primitive data types, or structures composed ofprimitive data types. That means
that any Java object can be passed as a parameter - even new objects whose
class has never been encountered before by the remote virtual machine.
This is an exciting property, becauseit means that new codecan be sent across a
network and dynamically loaded at run-time by foreign virtual machines. Java
developers have a greater freedom when designing distributed systems, and the
ability to send and receive new classes is an incredible advantage. Developers
22. don'thave to work within a fixed codebase - they can submit new classes to
foreign virtual machines and have them perform different tasks. When working
with remote services, RMI clients can access new versions of Java services as
they are made available - there's no need to distribute codeto all the clients that
might wish to connect. While codecan be accessed from a local or remote file-
system, it can also be accessed via a web server, making distribution easier.
RMI also supports a registry, which allows clients to perform lookups for a
particular service. The following diagram shows the interaction between
different components of an RMI system. Clients that know about a service can
look up its location from a registry and access the service. If a new class is
required, it can be downloaded from a web server.
Client connects to a registry server, accessesa RMI service, and downloads
new code as required from a web server.
Remote method invocation has a lot of potential, from remote processing and
load sharing of CPU's to transport mechanisms for higher level tasks, such as
mobile agents which execute on remote machines(Reilly, 1998). Because of the
flexibility of remote method invocation, it has becomean important tool for
Java developers when writing distributed systems. However, there are many
legacy systems written in C/C++, Ada, Fortran, Cobol, and other exotic
languages. If legacy systems need to interface with your RMI systems, or your
RMI systems need to interface with them, problems can occur. RMI is Java
specific, and you'll need to write a bridge between older systems. Additionally,
if you or your company plans on using other languages in the future, you may
also find yourself in a bind because of RMI's tie to Java - one day Java itself
may become a legacy platform. Writing interfaces to legacy systems isn't my
idea of fun programming!
What is CORBA?
Common Object RequestBroker Architecture (CORBA) is a competing
distributed systems technology that offers greater portability than remote
method invocation. Unlike RMI, CORBA isn't tied to one language, and as
such, can integrate with legacy systems of the past written in older languages, as
well as future languages that include supportfor CORBA. CORBA isn't tied to
a single platform (a property shared by RMI), and shows great potential for use
23. in the future. That said, for Java developers, CORBA offers less flexibility,
because it doesn'tallow executable codeto be sent to remote systems.
CORBA services are described by an interface, written in the Interface
Definition Language (IDL). IDL mappings to most popular languages are
available, and mappings can be written for languages written in the future that
require CORBA support. CORBAallows objects to make requests of remote
objects (invoking methods), and allows data to be passed between two remote
systems. Remote method invocation, on the other hand, allows Java objects to
be passed and returned as parameters. This allows new classes to be passed
across virtual machines for execution (mobile code). CORBA only allows
primitive data types, and structures to be passed - not actual code.
Under communication between CORBA clients and CORBA services, method
calls are passed to Object Request Brokers (ORBs). These ORBs communicate
via the Internet Inter-ORB Protocol(IIOP). IIOP transactions can take place
over TCP streams, or via other protocols (suchas HTTP), in the event that a
client or server is behind a firewall. The following diagram shows a client and a
servant communicating.
CORBA client sends a request
through its local ORB to a remote
ORB's servant
CORBA servant sends back a
response to a remote ORB
RMI vs CORBA
Comparing RMI and CORBA doesn'treveal an optimum solution - one is not
"better" than the other. The properties of these two technologies lend
themselves to different situations. A comparison of RMI and CORBA helps to
highlight individual strengths and weaknesses, but the applicability of one
technology over the other depends largely on the purposes for which it is to be
used, the experience of the developers who will design, implement and maintain
the distributed system, and whether non-Java systems are intended to access the
system now or in the future.
RMI pros and cons
Remote method invocation has significant features that CORBA doesn'tpossess
- most notably the ability to send new objects (codeand data) across a network,
and for foreign virtual machines to seamlessly handle the new objects (Reilly,
D). Remote method invocation has been available since JDK 1.02, and so many
24. developers are familiar with the way this technology works, and organizations
may already have systems using RMI. Its chief limitation, however, is that it is
limited to Java Virtual Machines, and cannot interface with other languages.
Remote method invocation
Pros Cons
Portable across many platforms Tied only to platforms with Java
support
Can introduce new codeto foreign
JVMs
Security threats with remote code
execution, and limitations on
functionality enforced by security
restrictions
Java developers may already have
experience with RMI (available since
JDK1.02)
Learning curve for developers that
have no RMI experience is comparable
with CORBA
Existing systems may already use RMI
- the costand time to convert to a new
technology may be prohibitive
Can only operate with Java systems -
no supportfor legacy systems written
in C++, Ada, Fortran, Cobol, and
others (including future languages).
CORBApros and cons
CORBA is gaining strong supportfrom developers, because of its ease of use,
functionality, and portability across language and platform (Reilly, D). CORBA
is particularly important in large organizations, where many systems must
interact with each other, and legacy systems can't yet be retired. CORBA
provides the connection between one language and platform and another - its
only limitation is that a language must have a CORBA implementation written
for it. CORBA also appears to have a performance increase over RMI, which
makes it an attractive option for systems that are accessed byusers who require
real-time interaction (Morgan, 1997).
Common Object Request Broker Architecture
Pros Cons
Services can be written in many
different languages, executed on many
different platforms, and accessed by
any language with an interface
definition language (IDL) mapping.
Describing services require the use of
an interface definition language (IDL)
which must be learned. Implementing
or using services require an IDL
mapping to your required language -
writing one for a language that isn't
supported would take a large amount of
work.
25. With IDL, the interface is clearly
separated from implementation, and
developers can create different
implementations based on the same
interface.
IDL to language mapping tools create
codestubs based on the interface -
some tools may not integrate new
changes with existing code.
CORBA supports primitive data types,
and a wide range of data structures, as
parameters
CORBA does not supportthe transfer
of objects, or code.
CORBA is ideally suited to use with
legacy systems, and to ensure that
applications written now will be
accessible in the future.
The future is uncertain - if CORBA
fails to achieve sufficient adoption by
industry, then CORBA
implementations become the legacy
systems.
CORBA is an easy way to link objects
and systems together
Some training is still required, and
CORBA specifications are still in a
state of flux.
CORBA systems may offer greater
performance
Not all classes of applications need
real-time performance, and speed may
be traded off against ease of use for
pure Java systems.
Summary
Functionality to some degree, they each possessstrengths that outshine the other
for particular tasks. A careful evaluation of the intended use of RMI or CORBA
is required, to determine which technology is the most appropriate. There aren't
any hard and fast rules that can be applied, and there is no clear victor in the
battle for the minds and hearts of developers. Time will tell which technology
(if any) becomes the more dominant, and in the immediate future both will An
examination of these two technologies shows that, while they do overlap in
continue to play a role.
COMPARISON B/W CORBAAND OTHER TECHNOLOGY:-
In the beginning there was RPC..
The first distributed computing technology to gain widespread use was the
Remote ProcedureCall (RFC 1831) commonly known as RPC. RPC is designed
to be as similar to making local procedurecalls as possible. The idea behind
RPC is to make a function call to a procedurein another process and address
spaceeither on the same processororacross the network on another processor
26. without having to deal with the concretedetails of how this should be done
besides making a procedure call.
CORBA
A CORBA application usually consists of an Object Request Broker (ORB), a
client and a server. An ORB is responsible for matching a requesting client to
the server that will perform the request, using an object reference to locate the
target object. When the ORB examines the object reference and discovers that
the target object is remote, it marshals the arguments and routes the invocation
out over the network to the remote object's ORB. The remote ORB then invokes
the method locally and sends the results back to the client via the network.
There are many optional features that ORBs can implement besides merely
sending and receiving remote method invocations including looking up objects
by name, maintaining persistent objects, and supporting transaction processing.
A primary feature of CORBA is its interoperability between various platforms
and programming languages.
DCOM/COM+
Distributed Component Object Model (DCOM)is the distributed version of
Microsoft's COM technology which allows the creation and use of binary
objects/components from languages other than the one they were originally
written in, it currently supports Java(J++),C++, Visual Basic, JScript, and
VBScript. DCOM works over the network by using proxy's and stubs. When the
client instantiates a componentwhose registry entry suggests that it resides
outside the process space, DCOMcreates a wrapper for the componentand
hands the client a pointer to the wrapper. This wrapper, called a proxy, simply
marshals methods calls and routes them across the network. On the other end,
DCOM creates another wrapper, called a stub, which unmarshals methods calls
and routes them to an instance of the component.
Java RMI
Remote Method Invokation (RMI) is a technology that allows the sharing of
Java objects between Java Virtual Machines (JVM) across a network. An RMI
application consists of a server that creates remote objects that conform to a
specified interface, which are available for method invocation to client
applications that obtain a remote reference to the object. RMI treats a remote
object differently from a local object when the object is passed from one virtual
27. machine to another. Rather than making a copyof the implementation object in
the receiving virtual machine, RMI passes a remote stub for a remote object.
The stub acts as the local representative, or proxy, for the remote object and
basically is, to the caller, the remote reference. The caller invokes a method on
the local stub, which is responsible for carrying out the method call on the
remote object. A stub for a remote object implements the same set of remote
interfaces that the remote object implements. This allows a stub to be cast to
any of the interfaces that the remote object implements. However, this also
means that only those methods defined in a remote interface are available to be
called in the receiving virtual machine.
28. The Future Scope of CORBA and CORBA Research
We believe the future of CORBA is very promising, particularly for real-time
systems. Real-time system development strategies will migrate towards those
used for ``mainstream'' systems to achieve lower development costand faster
time to market. We have seen real-time software development projects that have
lagged in terms of design and development methodologies (and languages) by
decades. These projects are extremely costly to evolve and maintain. They are
so specialized that they cannot be adapted to meet new market opportunities.
The flexibility and adaptability offered by CORBA make it very attractive for
use in RT systems. If the real-time challenges can be overcome, and our
progress so far shows that they can, then the use of Real-time CORBA is
compelling. Moreover, the solutions to these challenges will be sufficiently
complex, yet general, that it will be well worth re-applying them to other
projects.
In addition, CORBA can be adapted to ``niche'' markets, e.g., the RTOS market,
that aren't well covered by more traditional major players, e.g., Sun, Microsoft,
IBM. In this sense, CORBA has an advantage over other DOC technologies
29. (such as DCOM and Java RMI) since it can be integrated into a wider range of
platforms, i.e., it's open!
Homework Help
https://www.homeworkping.com/
Math homework help
https://www.homeworkping.com/
Research Paper help
https://www.homeworkping.com/
Algebra Help
https://www.homeworkping.com/
Calculus Help
https://www.homeworkping.com/
Accounting help
https://www.homeworkping.com/
Paper Help
https://www.homeworkping.com/
Writing Help
https://www.homeworkping.com/
Online Tutor
https://www.homeworkping.com/
Online Tutoring
https://www.homeworkping.com/
