Introduction to Common Object Request Broker Architecture CORBA Incheon Paik

1
Introduction toCommon Object Request Broker
Architecture(CORBA)Incheon Paik
2
Contents

• Overview of distributed programming challenges
• Overview of CORBA architecture
• CORBA programming with Java ORB
• WWW, Java and CORBA
• GIOP and IIOP
• Trends in Internet

3
Introduction

• Developing distributed applications whose
  components collaborate efficiently, reliabley,
  transparently, and scalably is hard.
• To help address this challenge, the Object
  Management Group(OMG) is specifying the CORBA
• OMG is a consortium of 700 more strong computer
  compaines and universities.
• Netscape, Sun, HP, DEC, Mircrosoft, IBM,
  Visigenic, IONA, etc.

4
History of OMG CORBA

• 1991 CORBA version 1.1 published
• 1992 - 1996 CORBA Core and Interoperability
  Architecture Communications
• 1994 CORBA 2.0 published, including
  Interoperable Specification
• 1994 - 1996 CORBAservices Basic Services for
  Object-Oriented Application
• May, 1996 CORBA Task Force issues Secure
  Interoperability Protocol
• 1995 - CORBAfacilities Application
  level Data Manipulation Storage

5
History of OMG CORBA

• 1997 CORBA version 2.1 Identify
  Problems
• 1998 CORBA 2.2 Portable Object
  Adapter Management of Lifetime Server Object,
  Portability
• CORBA 2.3 Object By Value
• 1999 CORBA 3 Internet Integration,
  QoS, CORBA Component Architecture

6
Source of Complexity

• Distributed application development exhibits both
  inherent and accidental complexity
• Inherent Complexity results from fundamental
  Challenges in the distributed application domain,
  e.g.,
• Addressing the impact of latency
• Detecting and recovering from partial failures of
  networks and hosts
• Load balancing and service partitioning
• Consistent ordering of distributed events

7
Source of Complexity

• Accidental complexity results from limitations
  with tools and techniques used to develop
  distributed applications.
• Lack of type-safe, portable, re-entrant, and
  extensible system call interfaces and
  component libraries
• Inadequate debugging support
• Widespread use of algorithmic decomposition
• Fine for explaining network programming
  concepts and algorithms but inadequate for
  developing large-scale distributed applications
• Continuous rediscovery and reinvention of core
  concepts and components

8
Motivation for CORBA

• Simplifies application interworking
• CORBA provides higher level integration than
  traditional "untyped TCP byte streams "
• Provides a foundation for higher-level
  distributed object collaboration
• e.g., Windows OLE and the OMG Common Object
  Service Specification(COSS)
• Benefits for distributed programming
  similar to OO languages for
  non-distributed programming
• e.g., encapsulation, interface inheritance, and
  object-based exception handling

9
CORBA Contributions

• CORBA addresses two challenges of developing
  distributed system
• Making distributed application development no
  more difficult than developing centralized
  programs.
• Easier said than done due to
• Partial failures
• Impact of latency
• Load balancing
• Event Ordering
• Providing an infrastructure to integrate
  application components into a distributed system
• i.e., CORBA is an "enabling technology"

10
CORBA Bank Example (Old Version)

• Ideally, to use a distributed service, we'd like
  it to look much like a non-distributed service
• public static void main(String args)
• Bank.AccountManager manager Bank.AccountManager_
  var.bind(My Bank")
• Bank.Account account manager.open(name)
• float balance account.balance()
• System.out.println ("The balance in " name
  "'s account is " balance)

11
CORBA Bank Interface

• We need to write an OMG IDL. Interface for our
  Bank object
• This interface is used by both clients and
  servers
• // Bank.idl
• module Bank
• interface Account
• float balance()
• interface AccountManager
• Account open(in string name)

12
CORBA is Software Bus

• CORBA provides a communication infrastructure for
  a heterogeneous, distributed collection of
  collaborating objects.

13
Related Works

• Related technologies for application integration
  include
• Traditional RPC
• Provides "procedural" integration of application
  serveices
• Doesn't provide object abstractions
• Does not address inheritance of interfaces
• Widows OLE/COM
• Traditionally limited to desktop application

14
CORBA Components

• The CORBA specification is comprised of several
  parts
• 1. An Object Request Broker (ORB)
• 2. Basic Object Adapter (BOA), Portable Object
  Adapter(POA)
• 3. An Interface Definition Language (IDL)
• 4. A Static Invocation Interface (SII)
• 5. A Dynamic Invocation Interface (DII)
• 6. A Dynamic Skeleton Interface(DSI)
• 7. Interface and implementation repositories
• 8. Programming language mappings
• 9. An Interoperability Spec(GIOP and IIOP)
• Other documents form OMG descirbe common object
  services built upon CORBAservices
• e.g. , Event services, Name services, Lifecycle
  service

15
CORBA Architecture
16
CORBA Architecture

• The ORB is the foundation of all other CORBA
  services and facilities

17
Object Request Broker

• The Object Request Broker(ORB) is the central
  component in CORBA
• An ORB provides mechanisms for invoking methods
  on local/remote objects
• ORB mechanisms automate
• Object location, creation, activation and object
  management
• Message exchange between objects
• CORBA ORB provides security also.

18
Interface Definition Language (IDL)

• Developing flexible distributed applications
  on heterogeneous platforms requires a strict
  separation of interface from implementation(s)
• Benefits of using an IDL
• Ensure platform independence
• e.g., Windows NT to UNIX
• Enforce modularity
• e.g., must separate concerns
• Increase robustness
• e.g., reduce opportunities for network
  programming errors
• Enable language independence
• e.g., C, Smalltalk, COBOL to C, Java

19
CORBA IDL

• 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 inheritance)
• OMG IDL is designed to map onto multiple
  programming languages
• e.g., C, C, Smalltalk, COBOL, Modula 3, DCE,
  Java, etc.
• OMG IDL is similar to Java interfaces, class and
  C class

20
OMG IDL Compiler

• A OMG IDL compiler generates client stubs and
  server skeletons
• Stubs and skeletons automate the following
  activities (in conjunction with the ORB)
• Client proxy factories
• Prameter marshalling/demarshalling
• Implementation class interface generation
• Object registration and activation
• Object location and binding

21
Producing IDL file, Client, and Object
Implementation
22
Application Interfaces

• Interfaces described using OMG IDL may be
  application-specific, e.g.,
• Databases
• Spreadsheets
• Spell checker
• Network manager
• Air traffic control
• Documents
• Medical imaging systems
• Objects may be defined at any level of
  granularity
• e.g., from fine-grained GUI objects to multi-mega
  byte multimedia "Blobs"

23
OMG IDL Features

• OMG IDL is a superset of C, Java, etc.
• Note, it is not a complete programming language,
  it only defines interfaces
• OMG IDL supports the following features
• Modules
• Interfaces
• Operations
• Attributes
• Inheritance
• Basic types(e.g., double, long, char, etc).
• Arrays
• Sequence
• Struct, enum, union, typedef
• Consts
• Exceptions

24
Static Invocation Interface(SII)

• The most common way of using OMG IDL involves
  the "Static Invocation Interface" (SII)
• In this case, all the methods are specified in
  advance and are know to the client and the
  server via proxies
• proxies are also known as surrogates
• The primary advantage of the SII is its
  simplicity, typesafety, and efficiency

25
Dynamic Invocation Interface (DII)

• A less common way of using OMG IDL involves the
  "Dynamic Invocation Interface" (DII)
• The DII enables objects and their methods to be
  specified and called at run-time
• Uses meta-data stored in an "Interface
  Repository"
• The DII is more flexible than the SII apporach,
  e.g.,
• It supports tools tools like a MIB browser that
  may not know all their components or operations
  at compile-time
• It also enables the use of deferred synchronous
  invocation
• The DII is also more complicated and less
  typesafe and efficient.

26
Dynamic Skeleton Interface (DSI)

• The "Dynamic Skeleton Interface" (DSI) provides
  analogous functionality for the server-side that
  the DII provides on the client-side
• It is defined in CORBA 2.0 primarily for using
  building ORB "Bridges"
• The DSI lets server code handle arbitrary
  invocations on CORBA objects

27
Object References

• An "Object reference" is an opaque handle to an
  object
• Object references amy be passed among processes
  on separate hosts
• The underlying CORBA ORB will correctly convert
  object references into a form that can be
  transmitted over the network
• Presumably by converting it to a "stringfied"
  reference
• The ORB passes the receiver's implementation a
  pointer to a proxy in its own address space
• This proxy refers to the object's implementation
• Object references are a powerful feature of CORBA
• e.g., supports "peer-to-peer" interactions

28
Object Adaptor

• CORBA "object adaptors" provide services for
  binding object references to their associated
  object implementations
• Several types of object adaptors are available
• Basic Object Adaptor(BOA)
• Objects and object references are known to the
  ORB
• Thus, an object implementation has to explicitly
  register objects to be activated
• Object-Oriented Database Adaptor(OODA)
• This adapter uses a connection to an o-o db to
  access the objects stored in it.
• Since the OODB provides the emthods and
  persistent storage, object may be registerd
  implicitly.

29
Object Adaptor

• Creation and Analysis of Object Reference
• Method Invocation
• Interaction
• Activation and Deactivation of Object and
  Implementation
• Matching to Object Implementation According to
  Object Reference
• Registration of Object
• Problem of BOA
• Inconsistency of Specification
• Difference of BOA Implementation
• Problem in Server Portability

30
Portable Object Adaptor

• Allow the Persistent Object
• Allow more Object Implementation
•  
• Characteristics
• Map an Object Reference to the Servant that
  Implements that object
• Allow Transparent Activation of Objects
• Associate Policy Information With Objects
• Make a CORBA object persistent over several
  server process lifetimes
• Object ID Namespace
• Policy of Multi-Threading, Security, Object
  Management
• Multi POA with different policy and name space
  exist in a server

31
EXAMPLE

• Bank Example
• Bank server maintains the user's account
• Clients can request to open his account and to
  ask his balance via CORBA interfaces and CORBA
  run-time
• Since the server(s) and the clients are
  distributed, the solution must work across LAN
  and WAN environments

32
Initial OMG IDL Bank Specification

• // Bank.idl
• module Bank
• interface Account
• float balance()
• interface AccountManager
• Account open(in string name)

33
Compiling the Interface Definition

• Running the Bank module definition through the
  IDL compiler generates client stubs and server
  skeletons
• The client stub acts as a proxy and handles
  object binding and parameter marshalling from
  requestor
• The server skeleton handles object registration,
  activation, and parameter demarshalling from
  target
• CORBA allows two ways to associate an object
  implementation to a generated IDL skeleton
• 1. BOAImpl -gt uses the Class form of the Adapter
  pattern(inheritance)
• 2. TIE -gt uses the Object form of the Adapter
  pattern (object composition)

34
Object Activation, invocation by the BOA
35
Main Server Program

• Developer Can Register or Activate the Objects on
  Server according to Policy
• // Server.java
• import org.omg.PortableServer.
• public class Server
• public static void main(String args)
• try
• // Initialize the ORB.
• org.omg.CORBA.ORB orb org.omg.CORBA.ORB.in
  it(args,null)
• // get a reference to the root POA
• POA rootPOA POAHelper.narrow(orb.resolve_i
  nitial_references("RootPOA"))
• // Create policies for our persistent POA
• org.omg.CORBA.Policy policies
• rootPOA.create_lifespan_policy(LifespanPolicyValue
  .PERSISTENT)

36
Main Server Program (Continued)

• // Create myPOA with the right policies
• POA myPOA rootPOA.create_POA(
  "bank_agent_poa", rootPOA.the_POAManager(),
  policies )
• // Create the servant
• AccountManagerImpl managerServant new
  AccountManagerImpl()
• // Decide on the ID for the servant
• byte managerId "BankManager".getBytes()
• // Activate the servant with the ID on myPOA
• myPOA.activate_object_with_id(managerId,
  managerServant)
• // Activate the POA manager
• rootPOA.the_POAManager().activate()
• System.out.println(myPOA.servant_to_referenc
  e(managerServant) "
  is ready.")
• // Wait for incoming requests
• orb.run()
• catch (Exception e)
  e.printStackTrace()

37
A Client Program

• // Client.java
• public class Client
• public static void main(String args)
• // Initialize the ORB.
• org.omg.CORBA.ORB orb org.omg.CORBA.ORB.init
  (args,null)
• // Get the manager Id
• byte managerId "BankManager".getBytes()
• // Locate an account manager. Give the full
  POA name and the servant ID.
• Bank.AccountManager manager
• Bank.AccountManagerHelper.bind(orb,
  "/bank_agent_poa", managerId)
• // use args0 as the account name, or a
  default.
• String name args.length gt 0 ? args0
  "Jack B. Quick"
• // Request the account manager to open a
  named account.
• Bank.Account account manager.open(name)
• // Get the balance of the account.
• float balance account.balance()
• // Print out the balance.
• System.out.println
• ("The balance in " name "'s account is
  " balance)

38
Implementing the Object

• // AccountManagerImpl.java
• import org.omg.PortableServer.
• import java.util.
• public class AccountManagerImpl extends
  Bank.AccountManagerPOA
• public synchronized Bank.Account open(String
  name)
• // Lookup the account in the account
  dictionary.
• Bank.Account account (Bank.Account)
  _accounts.get(name)
• // If there was no account in the dictionary,
  create one.
• if(account null)
• // Make up the account's balance, between 0
  and 1000 dollars.
• float balance Math.abs(_random.nextInt())
  100000 / 100f
• // Create the account implementation, given
  the balance.
• AccountImpl accountServant new
  AccountImpl(balance)

39
Implementing the Object

• try
• // Activate it on the default POA which
  is root POA for this servant
• account Bank.AccountHelper.narrow(_defau
  lt_POA().servant_to_reference(accountServant))
• catch (Exception e)
• e.printStackTrace()
• // Print out the new account.
• System.out.println("Created " name "'s
  account " account)
• // Save the account in the account
  dictionary.
• _accounts.put(name, account)
• // Return the account.
• return account
• private Dictionary _accounts new Hashtable()
• private Random _random new Random()

40
Run Example

• Activate OSAGENT
• Server Side
• ltpromptgt java Server
• Server Activation
• Client Side
• ltpromptgt java Client Account Name
• Client can receive the response from Server

41
OMG IDL Mapping Rules

• The CORBA specification defines mappings from
  CORBA IDL to various programming language
• e.g., C, C, Java, Smalltalk
• Mapping OMG IDL to Java
• Each module is mapped to package
• Each interface within a module is mapped to
  abstract class or fully implemented class
• Each operation is mapped to a Java method with
  appropriate parameters
• Each read/write attribute is mapped to a pair of
  get/set methods
• A read-only attribute is only mapped to a single
  get method

42
Binding a Client to a Target Object

• Three typical steps
• 1. A CORBA client (requestor) obtains an "object
  reference" from a server
• e.g., May use a naming service or a locator
  service
• 2. This object reference serves as a local proxy
  for the remote target object
• 3. The client may then invoke methods on its
  proxy
• Recall that object references may be passed as
  parameters to other remote objects

43
Experiences with Java ORBs

• ORB Interoperability
• Visigenics Black Widow(now, VisiBroker) supports
  the CORBA 2.0 IIOP
• DSTC provide a permanent ORB Interoperability
  showcase
• Java language binding for CORBA
• Development time can be significantly reduced
  when using Java instead of C
• Portability
• Java ORB profit from Java portability
• Performance
• Now, Java ORBs do not perform very well(about 20
  times longer)
• But, faster compiler (e.g., Just-in Time
  Compiler) will solve it
• Applet clients vs. CGI based clients
• Middleware advantages
• automatic generation of stub code
• separating interfaces from implementations
• automatic type checking

44
Internet Inter-ORB Protocol(IIOP)

• Interoperability Via ORB-to-ORB
• ORB Interoperability Architecture
• Example of CORBA 2.0 Interoperability
• Interoperable Object Reference
• General Inter-ORB Protocol(GIOP)
• Internet Inter-ORB Protocol (IIOP)

45
Interoperability Via ORB-to-ORB

• All of the clients connected to ORB 1 can access
  object implementations in both ORB 1 and ORB 2
• The same condition holds for clients connected to
  ORB 2
• This architecture scales to any number of
  connected ORBs

46
Interoperability via ORB-to-ORB
47
ORB Interoperability Architecture

• Immediate bridging
• two domains talk directly to each other over a
  single bridge that translate whatever parts of
  the message require it.
• fast and efficient but inflexible and require a
  lot of bridges
• Mediated bridging
• All domains bridge to a single common protocol
• common protocol is IIOP
• the number of bridge types only grows as fast as
  the number of different domains.
• this conforms to the backbone configuration of
  most large, multiprotocol networks mediated
  bridging configures naturally in these networks.

48
Example of CORBA 2.0 Interoperability
49
Interoperable Object Reference (IOR)

• Specialized Object Reference
• Be used by an application in the exact same way
  that an object reference is used
• allows an application to make remote method calls
  on a CORBA object
• An application which obtain IOR, it can access
  the remote CORBA object via IIOP
• The application constructs a GIOP message and
  sends it
• The IOR contains all the information needed to
  route the message directly to the appropriate
  server

50
General Inter-ORB Protocol (GIOP)

• Goal
• Widest possibility, availability, Simplicity,
  Scalability, Lowcost, Generality, Architectural
  neutrality
• GIOP consists of three specification
• The Common Data Representation (CDR) definition
• Trasnfer syntax, mapping from data types defined
  in OMG IDL to a bicanonica, low-level
  representation for transfer between agents.
• SPEC takes into account byte ordering and
  alignment

51
General Inter-ORB Protocol (Continued)

• GIOP message formats
• carry requests, locate object implementations,
  and manage communication channels.
• Message Header
• include magic number, version number, byte
  order, message type, message size
• Seven Messages
• Be sent by the client Request, CancelRequest,
  LocateRequest
• Be sent by Server Reply, LocateReply,
  CloseConnection
• Both may send MessageError

52
General Inter-ORB Protocol (Continued)

• GIOP transport requirements
• a connection-oriented protocol
• reliable delivery (byte order must be preserved,
  and acknowledgment of delivery must be available)
• participants must be notified of disorderly
  connection loss
• the model of initiating a connection must meet
  certain requirements

53
Internet Inter-ORB Protocol (IIOP)

• The mapping of the GIOP message transfer to
  TCP/IP connections is called IIOP
• GIOP can map to Novell IPX and OSI also
• TCP/IP Connection Usage
• Servers must listen for connection requests.
• A client needing a objects services must
  initiate a connection with the address specified
  in the IOR, with a connection request
• The listening server may accept or reject the
  connection.
• Once a connection is accepted, the client may
  send Request, LocateRequest, or CancelRequest
  messages by writing to the TCP/IP socket it owns
  for the connection.