Corba
Download
1 / 29

CORBA - PowerPoint PPT Presentation


  • 102 Views
  • Uploaded on

CORBA. Celsina Bignoli [email protected] Enterprise Computing. Corporation have similar computing environments: mixed set of HW platforms a mixed set of SW components programmers with very different skill sets need to maintain legacy code desire to avoid vendor lock-in. What is CORBA.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' CORBA' - tawny


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Corba

CORBA

Celsina Bignoli

[email protected]


Enterprise computing
Enterprise Computing

  • Corporation have similar computing environments:

    • mixed set of HW platforms

    • a mixed set of SW components

    • programmers with very different skill sets

    • need to maintain legacy code

    • desire to avoid vendor lock-in


What is corba
What is CORBA

  • CORBA (Common Object Request Broker Architecture)

  • cross-platform, cross-language, vendor-independent specification for object-based distributed computing

  • Introduced by the Object Management Group (OMG) in 1989


OMG

  • The OMG is a consortium that comprises over 700 companies and organizations

    • almost all the major vendors and developers of distributed object technology

      • platforms

      • databases

      • software tools

    • corporate application developers


Corba1
CORBA

  • CORBA can be thought as a language-independent version of RMI

    • similar lifecycle including definition of interfaces, generation of stubs and skeletons

  • glues together application written in different languages on different platforms

    • interfaces must be specified in a language-independent format


Corba architecture
CORBA Architecture

Client

Server

Invokes methods

implemented

by the server

Network

Skeleton

Stub

Marshalls invocation

and sends data to skeleton

Un-marshalls data and

invokes method on server


Corba components
CORBA Components

  • Interface Definition Language (IDL)

  • Wire Protocol (IIOP)

  • Language Mappings


Corba architecture1
CORBA Architecture

Client

Server

Invokes methods

generated from IDL

(implemented

by the server)

Marshalls invocation

and sends data

to skeleton

Automatically generated

from IDL

Un-marshalls data

and invokes method

on server

Automatically generated

from IDL

Stub

Skeleton

ORB

ORB

IIOP


ORB

  • The ORB is the distributed service that implements the request to the remote object.

    • It locates the remote object on the network

    • communicates the request to the object

    • waits for the results and when available communicates those results back to the client.

  • The ORB implements location transparency.

    • Exactly the same request mechanism is used by the client and the CORBA object regardless of where the object is located.

  • The ORB implements programming language independence for the request.

    • The client issuing the request can be written in a different programming language from the implementation of the CORBA object



Interface definition language idl
Interface Definition Language (IDL)

  • Used to specify an object interface, i.e. the contract between code using the object and the code implementing the object

  • indicates the operations the object supports, but not how they are implemented

    • the implementation of a CORBA object is provided in a standard programming language, such as the Java or C++

  • clients only depend on the interface

  • IDL interfaces are programming language neutral


Interface definition language 2
Interface Definition Language(2)

  • OMG IDL allows you to define the following :

    • Modularized object interfaces

    • Operations and attributes that an object supports

    • Exceptions raised by an operation

    • Data types of an operation return value, its parameters, and an object's attributes


Idl data types
IDL Data Types

  • Basic data types (long, short, string, float...)

  • Constructed data types (struct, union, enum, sequence)

  • Typed object references

  • The any type, a dynamically typed value


Bindings
Bindings

  • IDL defines language bindings for many different programming languages

    • OMG has standardized on language bindings for: C, C++, Java, Ada, COBOL, Smalltalk, Objective C, and Lisp

  • Developers can choose the appropriate programming language for the object implementation and a possibly different programming language for the client.

  • IDL declarations are compiled with an IDL compiler and converted to their associated representations in the target programming languages according to the standard language binding




Helloworld example
HelloWorld Example

Hello Client

Hello Server

Object Reference

sayHello Hello World!

Hello Servant

sayHello

Stub

Skeleton

ORB

ORB

IIOP

TCP/IP (network)


Defining the remote interface
Defining the Remote Interface

  • create a file Hello.idl with the following content:

    module HelloApp

    {

    interface Hello

    {

    string sayHello();

    oneway void shutdown();

    };

    };


Mapping hello idl to java
Mapping Hello.idl to Java

idlj -fall Hello.idl

  • The tool idlj reads OMG IDL files and creates the required Java files.

  • The idlj compiler defaults to generating only the client-side bindings. If you need both client-side bindings and server-side skeletons you must use the -fall option

  • A directory called HelloApp has been created containing a number of files


Generated files
Generated Files

  • Hello.java

    • This interface contains the Java version of our IDL interface.

    • The Hello.java interface extends org.omg.CORBA.Object, providing standard CORBA object functionality.

  • HelloPOA.java

    • This abstract class is the stream-based server skeleton

    • provides basic CORBA functionality for the server

    • The server class, HelloServant, extends HelloPOA.

  • _HelloStub.java

    • This class is the client stub, providing CORBA functionality for the client.

    • Implements the Hello.java interface.


Generated files1
Generated Files

  • HelloOperations.java

    • contains the methods sayHello() and shutdown().

    • The IDL-to-Java mapping puts all of the operations defined on the IDL interface into this file, which is shared by both the stubs and skeletons

  • HelloHelper.java

    • This class provides auxiliary functionality.

    • responsible for reading and writing the data types to CORBA streams

  • HelloHolder.java


Developing the server
Developing the Server

  • Create the servant class HelloImpl

    • implements of the Hello IDL interface; each Hello instance is implemented by a HelloImpl instance

      • contains one method for each IDL operation, in this example, the sayHello() and shutdown() methods

    • it’s a subclass of HelloPOA, which is generated by the idlj compiler from the example IDL.

      • Servant methods are just like ordinary Java methods; the extra code to deal with the ORB, with marshaling arguments and results, and so on, is provided by the skeleton


Portable object adapter poa
Portable Object Adapter (POA)

  • Abstract layer between the wire and the skeleton

  • responsible for

    • pull data from the wire

    • de-marshalling data

    • forward requests to skeletons


Naming services
Naming Services

  • The two options for Naming Services shipped with J2SE 1.5 are:

  • orbd, which includes both a Transient Naming Service and a Persistent Naming Service.

  • tnameserv - a Transient Naming Service.

    The example uses orbd.


Developing the client
Developing the Client

  • needs to look up the server

  • obtain a reference of the object on which it makes remote method calls

  • unaware the object is

    • remotely located

    • written in a different language

    • serviced by a different vendor ORB


Corba vs rmi
CORBA vs. RMI

  • both frameworks for building distributed systems

  • similar architectural principles

  • CORBA supports components written in different programming languages

  • RMI assumes client/server written in Java

  • RMI easier to learn and use

    • code is smaller and simpler

    • serialization makes it easier to maintain an application

  • CORBA unlike RMI has no notion of distributed garbage collection


Choosing corba vs rmi
Choosing CORBA vs. RMI

  • Depends on how you can answer some questions

    • will the application need to communicate with components that are NOT written in Java?

    • would the extra CORBA infrastructure be useful?

    • Will all future code that needs to communicate with the application always be written in Java?


Rmi iiop
RMI/IIOP

  • JRMP the native protocol of RMI is replaced with IIOP, the CORBA protocol


Rmi iiop applications
RMI/IIOP Applications

  • Steps

    • Remote interface like in RMI

      • extends Remote

      • methods throw RemoteException

    • Server extends PortableRemoteObject instead of UnicatsRemoteObject

    • stubs and scheleton are generated using rmic with the –iiop flag

    • CORBA naming service used instead of RMI registry

    • IDL can be generated from Step 1 and used to develop non-Java components


ad