Introduction to

Introduction to

1999 년 10 월 29 일

김 정 선[email protected]

한양대학교 공학대학

전자컴퓨터공학부

한양대학교 객체기술연구실

Brief overview of

Object Management Architecture (OMA)

Common Object Request Broker Architecture (CORBA)

– CORBA is one of the key components of the OMA.

Agenda


Distributed Object Computing

Driving force: Internet & Multithreaded, net-aware OS, etc Consequences: Client/Server & Components Revolution

DistributedObject Computing

DistributedComputing

Object-OrientedProgramming


Distributed objects are self-contained objects that can plug-and-play across languages, operating systems, and networks.

Extremely well-suited for creating flexible C/S systems because data and business logic is encapsulated within objects, allowing them to be located anywhere.

Distributed Objects


Facts of Life Today

Gateway/RouterMVS - IBMSunOS - SparcHP/UX - HPPAOS/2 - PowerPCWindows NT - AlphaWindows - Pentium

WAN

Ethernet

ATM

FDDI


Engineering tradeoff

Cost effectiveness

Legacy systems

Reasons for Heterogeneity


Ideally, heterogeneity and open systems enable us to use the best combination of HW & SW components.

However, without standards for interoperability, the development of software applications whose components are interoperable, reusable, portable, and collaborate efficiently, reliably, transparently, and scalably in a distributed heterogeneous environment is very, very hard.

Motivation for CORBA


To help address this challenge, the Object Management Group (OMG) is formed (1989) to develop, adopt, and promote standards for the development and deployment of applications in distributed heterogeneous environment.

OMG is a consortium of over 800 computer companies• e.g., Sun, HP, DEC, IBM, IONA, etc.

Object Management Group (OMG)


The OMA is a common architectural framework on which every OMG’s object technologies are based.

The Object Model defines the semantics of the objects distributed across a heterogeneous environment (i.e., CORBA objects) can be described.

The Reference Model characterizes interface boundaries and interactions between those objects.

Object ManagementArchitecture (OMA)


An object is an identifiable, encapsulated entity that provides one or more services that can be requested by a client.

A client of a service is any entity capable of requesting the service.

Clients can issue requests for services only through well-defined object’s interface, described by Interface Definition Language (IDL).

An interface is a set of possible operations that a client may request of an object.

The Object Model


An object reference is an opaque object name that reliably denotes a particular object.

The implementation and location of each object are hidden from the requesting client.

The Object Model(Cont’d)


The ORB delivers requests to objects and returns any responses to the clients making the request.

OMA Reference Model


Object Services CORBAservices

Domain-independent interfaces that are used by many distributed object programs.

– For example, a service providing for the discovery of other available services is almost always necessary regardless of the application domain:

Naming Service -- allows clients to find objects based on names;

Trader Service -- allows clients to find objects based on their properties.

Other object services include lifecycle, security, transactions, events, as well as many others.


Object Services(Cont’d)

Service Category Description CORBAservices

Infrastructure services Services related to the ORB Security, Timemechanisms

Information management Services to retrieve and Collection, Externalization,manipulate data Persistent, Property,

Query, Relationship

Task management Services to manage Concurrency, Event,distributed events and Transactiontransactions

System management Services to manage Licensing, Lifecycle,metadata, licensing, and Naming, Traderobject life cycle


Common Facilities

Like CORBAservices, horizontally-oriented interfaces, but they are oriented towards end-user applications.

Examples include:

Compound documents

Printing

Task management

Electronic mails


Domain Interfaces

Vertically-oriented, domain specific interfaces

For example,

Manufacturing domain

Telecommunications domain

Health care (medical) domain

Financial domain.


These are interfaces developed specifically for a given application.

Because they are application-specific, and because the OMG does not develop applications (only specifications), these interfaces are not standardized.

However, if over time it appears that certain broadly useful services emerge out of a particular application domain, they might become candidates for future

OMG standardization.

Application Interfaces


The CORBA defines standard interfaces and characteristics of the ORB component of the OMA.

The main features of CORBA are: ORB Core

OMG Interface Definition Language (IDL)

Interface Repository/Implementation Repository

Language Mappings

Stubs and Skeletons

Dynamic Invocation and Dispatch

Object Adapters

Inter-ORB Protocols (GIOP/IIOP)

CORBA


CORBA Architecture


OMG IDL is an object-oriented interface definition language.– Used to specify interfaces containing operations and attributes.– OMG IDL support interface inheritance (both single and multiple i

nheritance).

OMG IDL is designed to map onto multiple programming languages.

– e.g., C, C++, Smalltalk, COBOL, Ada, Java

OMG IDL is not a complete programming language, it is just a declarative language.

Language-independence

CORBA IDL


OMG IDL supports the following features:

Modules Interfaces Operations Attributes Inheritance Basic types (e.g., char, short, double, string etc) Arrays Sequences Struct, enum, union, typedef Constants Exceptions

OMG IDL Features


IDLize Everything in CORBA


IDL compiler automatically generates client-side stubs and server-side skeletons.

– Sometimes called proxy or surrogates.

Stubs and Skeletons

Client Server

Local host Remote host

Stub Skeleton

ORB


Stubs and Skeletons(Cont’d)

A stub effectively creates and issues requests on behalf of a client.

– It works directly with ORB to marshal the request.

Once the request arrives at the server, the ORB and the skeleton cooperate to unmarshal the request and dispatch it to the object implementation.

Any response is sent back the way it came.


Static Request Invocations


Static Request Invocations(Cont’d)

Dispatching through stub and skeleton is called static invocation.

Stubs and skeletons are built directly into the client application and the object implementation. Therefore, they both have a complete a priori knowledge of the IDL interface of the CORBA objects being invoked.

The primary advantage of the SI is its simplicity, typesafety, and efficiency.


Every CORBA-based application requires access to the IDL type system when it is executing, because it needs to know the types of interfaces supported by objects, signatures of operations, etc.

Sometimes static knowledge of IDL type system is enough, but sometimes it is not.

The Interface Repository (IR) allows the IDL type system to be accessed and written dynamically at runtime.

Interface Repository


Dynamic Request Invocations


The DII interface allows a client to directly access the underlying request mechanisms provided by an ORB.

Applications use the DII to dynamically issue requests to objects without requiring IDL interface-specific stubs to be linked in.

Unlike IDL stubs (which only allow RPC-style synchronous and oneway (send-only) requests), the DII also allows clients to make non-blocking deferred synchronous (separate send and receive operations) calls.

Dynamic Invocation Interface


Dynamic Skeleton Interface


The DSI is the server side's analogue to the client side's DII.

The DSI allows an ORB to deliver requests to an object implementation that does not have compile-time knowledge of the type of the object it is implementing.

The client making the request has no idea whether the implementation is using the type-specific IDL skeletons or is using the dynamic skeletons.

Dynamic Skeleton Interface(Cont’d)


Likewise, the object implementation receiving the request has no idea whether the request is using the static invocation or dynamic invocation.

The DSI is useful for a certain class of applications, especially for bridges between ORBs and for applications that serve to bridge CORBA systems to non-CORBA services and implementations.

Dynamic Skeleton Interface(Cont’d)


The object adapter assists the ORB with delivering requests to the object and with activating the object.

More importantly, an object adapter associates object implementations with the ORB.

Responsibilities of object adapters include: – Object registration– Object reference generation– Server process activation– Object activation– Request demultiplexing– Object upcalls

Object Adapters


Object Adapters(Cont’d)

Object adapters can be specialized to provide support for certain object implementation styles (such as OODB object adapters for persistence and library object adapters for non-remote objects).

Basic Object Adapter (BOA) is a mandatory for every CORBA ORB implementation.

Portable Object Adapter (POA) is adopted as a new standard (CORBA 3.0).


An ORB is a logical entity (pseudo object) that may be implemented in various ways (such as one or more processes or a set of libraries).

To decouple applications from implementation details, the CORBA specification defines an abstract interface for an ORB.

This interface provides various helper functions such as converting object references to strings and vice versa, and creating argument lists for requests made through the dynamic invocation interface described soon.

ORB Interface


General Inter-ORB Protocol (GIOP)– specifies request format and transmission protocol that enables

ORB-ORB interoperability

Internet Inter-ORB Protocol (IIOP)– specifies a standard interoperability protocol for the Internet– GIOP implemented on top of TCP/IP– CORBA 2.0 compliant ORBs must support IIOP

Environment-specific inter-ORB protocols (ESIOPs) – e.g,, DCE

Interoperability Protocols


Networks

ORB

C++

ORB

Java

ORB

Smalltalk

ORB

Cobol

ORB

C

IIOP IIOP

CORBA Interoperability


Traditional RPC (e.g., DCE)– Only supports “procedural” integration of application services– Doesn’t provide object abstractions, message passing, or

dynamic invocation– Doesn’t address inheritance of interfaces

Windows COM/DCOM– Traditionally limited to desktop applications– Does not address heterogeneous distributed computing (yet)

• Distributed COM (DCOM) is now appearing on multiple platforms

Related Work


Related Work (Continued)

Java RMI

– Limited to Java only

– Can be extended into other languages (e.g., C or C++)

by using a bridge across the Java Native Interface (JNI)

– Well-suited for all-Java applications because of its tight

integration with Java virtual machine


Many ORBs are now available:– Visibroker from Visigenic/Borland/Inprise– Orbix from IONA– JavaIDL from JavaSoft– etc.

In theory, CORBA facilitates vendor-independent and platform-independent application collaboration

– In practice, heterogeneous ORB interoperability and portability still an issue ...

CORBA Implementations


Interface Definition Language (IDL) A mapping from IDL onto many programming languages A Static Invocation Interface, used to compose method reques

ts via proxies A Dynamic Invocation Interface, used to compose method re

quests at run-time Interface and Implementation Repositories containing meta-d

ata queried at run-time The Portable Object Adapter (POA), allows service program

mers to interface their code with an ORB

Summary of CORBA Features

Introduction to

Documents

Transcript of Introduction to