Banilad, Paul Ryan T.

Common Object Request Broker (CORBA)

Part 1 - Introduction

1. Briefly introduce the standard and its history.

CORBA Definition
o OMG’s open, vendor independent specification for an architecture and infrastructure
that computer applications use to work together over networks.
CORBA Key parts
o OMG Interface Definition Language (OMG IDL)
o Standardized protocols GIOP and IIOP

CORBA Benefits
o Interoperability among any vendor, almost any computer (including handheld or small embedded
device), OS, program language
o Load-balancing on multiple machines
o OMG’s standard fault tolerant architecture

CORBA History
o Founded in 1989 with 11 companies.
o Now includes about 800 members and is moving forward in establishing CORBA as the
“middleware that’s everywhere” through its worldwide standard specifications: CORBA/IIOP,
Object Services, Internet Facilities and Domain Interface Specifications, UML and other
specifications supporting analysis and design.

2. For what purpose was the standard created?

Vendor independent Interoperability (high level definition)

- Middleware that’s everywhere - is the main purpose of CORBA, which try to provide
perfect interoperability among any OS, hardware, and system. We might see the immediate
benefit by integrating legacy systems on mainframe computers and/or traditional client-
server models with relatively new component based systems on web technologies. Not only
the interoperability among the variety of system (architecture) styles but also
interoperability among different vendors produces significant benefit for users. “Open
system” was the first step for vendor independent interoperability but still had a limitation
in architecture point of views. CORBA could be rephrased to “the road to the perfect open
system”.
3. Who created it?
- CORBA was created by OMG or Object Management Group as a part of OMA or Object
Management Architecture.

4. Who uses it?

- CORBA is used by more than 600 companies including hardware companies, software
companies, cables companies, phone companies, banks, etc. This architecture is used in
a variety of industrial application systems all over the world.

5. Are there any related standards? If so, list then and briefly explain how they differ from the
standard that you selected.

- EJB and DCOM are other widely known architecture as distributed system architecture.
The following table shows the similarities and dissimilarities among three architectures.

CORBA DCOM EJB

Similarity1: To maximize reusability and rapid application development, component

based approach is applied. Component based approach heavily depends
Component based
on interface definition. OMG IDL, COM IDL, and so called Java IDL (simply
methodology
mapping for Java to the OMG IDL) are used.

Similarity2: Components can be distributed over network.

Distributed Network

Similarity3: Al services provide some sort of registry or repository to help locate the
corresponding service.
Naming and locating
service

Dissimilarity1: Multiple vendor Microsoft with some Sun microsystem with

support third parties other vendors
Vendor and players

Dissimilarity2: A variety of languages Some languages such Java

as VB/ VC++ / MS-Java
Language

Dissimilarity3: Platform independent Win32 Platform independent

with specification
Platform by JVM

EJB requires a J2EE server as container of beans while JINI is quite open architecture even
for device or other service providers. The method of invoking remote object is also different.
EJB use only RMI/IIOP but The JINI architecture lets programs use services in a network
without knowing anything about the wire protocol that the service uses. One
implementation of a service might be XML-based, and another RMI-based, and a third
CORBA-based.
Part 2 – Description of the Standard

1. Describe the standard from an architectural point of view.

The figure above describes the sequential flow of the basic object invocation mechanism
from client to server. Both stub in a client and skeleton in a server are compiled with IDL. So
clean separation of interface and implementation is achieved. The caller (client) does not
have to know where the actual implementation (object) resides since a client uses name
services (object reference) to access a remotely distributed object. The object reference is
defined by an IDL, which is the essential information of Name service in CORBAService. The
ORB delivers the request to the object and returns a result to the client through Transaction
service, which is also one of CORBAServices. Components/objects applications on both client
and server sides can be program language independent with client ORB interface and server
CORBA interface. The network protocol used in this communication is GIOP/IIOP.
 2. What is the underlying basic architecture of the standard?

- The underlying basic architecture of CORBA is a layered architecture since the main
object of CORBA is to provide interoperability among a variety of vendors and systems.

3. What style(s) does it represent or define?

- CORBA needs encapsulation approach to make the external interfaces consistent among
them (IDL, ORB/CORBA interfaces, stub/skeleton) and fundamental communication
mechanism/layer to connect one another (ORB, GIOP/IIOP). Hiding implementation
(program independent) and providing common interfaces (vendor/system independent)
leads to ultimate goal, “Middleware that’s everywhere”.

4. Describe the component and connector mechanisms.

- CORBA is the architecture for distributed systems so it might be well described with
physical view, in which multiple machines can be specified. At the same time, IDL
(interface specification language) is also the key technology to integrate everything at
heterogeneous environment, which leads to the necessary of a layered architecture
representation. And finally the sequential diagram helps express the relations and roles
of each component.

Part 3 – Analysis of Properties and Tradeoffs

1. Analyze the standard. Discuss the quality attributes that the standard supports.
- The quality attributes that the standard supports are Reusability(Interoperability),
Modifiability, Extensibility, and Productivity.
2. How are these quality attributes supported?

Reusability (Interoperability)
A variety of systems, computer languages and vendors can be integrated into one total
enterprise system. This attribute goes into two “well known” Quality attributes. The
significant benefit of CORBA could be the integration of huge legacy systems such as
mainframe systems and new systems. For example, it is too costly to reengineer the
huge COBOL programs and systems in order to integrate with new systems while they
want a seamless integration for a total enterprise system. CORBA allows these
companies to reuse the most of legacy systems for the total system with minor
modification.

Modifiability
Since all implementation was hidden by IDL, the internal logic in a component can be
easily modified. And also the component location (server location) can be changed
without affecting calling components (clients) since Naming service provide the latest
information of server side components dynamically.

Extensibility
Since the number of vendors is growing, existing CORBA systems have a significant
probability to integrate more systems, devices and software into themselves. And also
naming service contributes extensibility by allowing the system to expand with more
servers.
 Productivity

We can integrate variety of software components written by different languages so

developer might be able to choose the best or most familiar language to develop each
component, which has favorable impact on productivity.

3. Discuss the quality attributes that are not well supported by the standard.
- The quality attributes that are not well supported by the standard is the Performance
and Security.
4. Why are these quality attributes not supported?

Performance
Since all communication with remote components has to go through CORBA
mechanism, the response time could be an issue because of more layers among
communication. So, platform dependent own socket programs over TCP/IP with C
language will produce much faster through put than the combined CORBA components.

Security
Since the total system will be highly distributed with multiple vendor products, more
security holes are likely to be embedded into the system. Moreover the root cause of
system troubles could be difficult to be identified in highly integrated environment.

5. What tradeoffs did the developers make in creating the standard?

Reusability (Interoperability) vs. Performance

To integrate a variety of systems in heterogeneous environment, developers had to add
more layers and steps for the communication mechanism and sacrifice performance
due to additional steps.

Extensibility vs. Security

The ability to extend system by adding new servers for load balanced or business needs
might increase the number of weak points (security holes) in the system. In theory, the
more network communications are executed, the more chances are raised for intrusion
(Distribution systems have weaker than centered systems).

6. Does it support any type of analysis or consistency checking?

- OMG provides ISO standards for some core specifications such as IDL and keeps
consistency among the products from a variety of vendor. In spite of the small number
(11) of the original organizations, the number of participants is growing up to 800 now.

7. Does the standard meet its stated intent?

- The original intent, “middleware that’s everywhere” seems to meet. Even though one of
the original organizations, Sun Microsystem, has started own architecture, EJB, but Sun
is positioning EJB to provide seamless integration with CORBA environment by RMI-IIOP
methods for communication. Another big architecture, DCOM from Microsoft, can also
be integrated with CORBA with DCOM/CORBA bridges. Overall CORBA’s original
intention is kept and the industry trend seems to be going forward to support CORBA.