Introduction to OMG CORBA

1
Introduction toOMG CORBA
Muddleware Workshop

2
OMG Background

• Over 800 member companies, worlds largest
  software consortium
  
• Founded April 1989
• not-for-profit corporation
• Headquarters in Needham, MA, USA
• OMG defines object management as software
  development that models the real world through
  representation of "objects."
  

3
OMG Mission

• Create a component-based software marketplace by
  hastening the introduction of standardized object
  software
  
• Establish CORBA as the "Middleware that's
  Everywhere" through its world-wide standard
  specifications
  

4
Fundamental Objective
... of any distributed application or information
system is for the separate components to
co-operate and co-ordinate to do useful work and
/ or achieve some overall common system goal.
5
Interoperability 1
Communication Data Exchange
System X
System Y
interface x part getpart(in string partid)

bool putpart(in string partid)
common interface definition language( IDL)
common communication types (IDL Types)
common communication protocol (GIOP)
6
Role of OMG IDL
Client Side
Object Implementation Side
ORB
ORB
7
IDL Variable Types

• PRIMITIVE
• Integer
• short, long,
• signed unsigned
• Floating point
• float, double, long double, fixed
• char, wchar, boolean, octet
• Any
• CORBA Object Reference

• CONSTRUCTED
• Structs
• Unions
• Enums
• Sequences
• Strings, wstrings
• Arrays

8
So, An IDL Interface

• Module Lecture1
• typedef string mystringtype
• interface example1
• typedef short myshorttype
• long op1 (in long arg1,
• in myshorttype myshort,
• out mystringtype mystring)

9
Object Access via the ORB
10
ORB Components
11
How to Discover Objects?

• The client can-
• be provided with a stringified object reference
  which can be converted into an object reference.
  
  
• Use the CORBA Naming Service (White Pages)
• Use a Trader Service (Yellow Pages) to discover
  objects.
  
• A Java applet with a pre-built client can be
  downloaded and used.
  

Once an Object Reference is obtained both the DII
and Interface Repositories can be interrogated to
create arguments and create requests

12
GIOP General Inter-ORB Protocol

• Provides a set of message formats and a common
  data presentation language for communications
  between ORBS.
  
• The Internet Inter-ORB Protocol IIOP specifies
  how GIOP messages are exchanged over TCP/IP

13
GIOP Transport Assumptions

• Reliable
• Connection-oriented
• Connection initiation follows TCP/IP model
• View as byte stream
• Notification of connection loss
• Some target protocols SS7, ATM, OSI, IPX, TCP/IP(
  IIOP)

14
GIOP Object Invocations

• Using the seven messages CORBA provides three
  different models for object invocation-
  
• Synchronous - the client invokes an operation,
  then blocks waiting for a response
  
• Deferred Synchronous - the client invokes an
  operation, then continues processing. It can
  later go back and either poll or block waiting
  for the response. For use only by the DII
  interface only.
• Oneway - the client invokes an operation, the
  ORB provides only a best effort guarantee that
  the request will be delivered. There is no
  response. Intended really for using UDP transport
  and is not true client asychronous.

15
Messaging Extensions to GIOP

• CORBA 3.0 messaging specification adds -
• Asynchronous messaging - this messaging mode is
  required in building large scale distributed
  systems and not fully offered in CORBA 2
  
• Time-independent invocation- allows invocations
  on objects that are not active or currently
  disconnected.
  
• Quality of Service facilities - allows clients to
  specify the QOS they require for message
  delivery, message queuing and message priorities.

16
CORBA Object Adapters

• Mediate between CORBA objects and programming
  language implementations (servants) and provide
  the following services-
  
• Creation of CORBA objects and their references
• Demultiplexing of requests made on each target
  CORBA object
  
• Dispatching requests to the appropriate servant
  that incarnate or provide an implementation for
  the target CORBA object
  
• Activation/deactivation of CORBA objects

17
Enter the Servant

• Sometimes the simple One-Object-Reference for
  One-Running-Implementation model isnt enough. We
  can change the model on the server side without
  breaking anything on the client side -
• A Servant is a running implementation which
  provides the functionality for one or more
  Object References
  
• Policies specify how Servants map to Object
  References
  
• Object Ids (OIDs) identify Servants to the POA
• The POA includes components to activate,
  de-activate, and manage Servants

18
Simple POA Model Configuration
Object Reference
Object IDs
Servants
?
POA
ORB
POA
Client
Server
19
POA Model

• Servant
• A programming language implementation. An object
  may be associated with one or more servants, and
  the relationship may change over time.
  
• Object ID
• Value used by the POA and Servant to identify a
  particular CORBA object. Hidden from clients.
  
• Object Reference
• The CORBA IOR, now encapsulating an Object ID and
  POA identity
  
• POA
• An identifiable entity within a server, with its
  own namespaces and policies. May be nested.

20
POA Model (2)

• Policy
• An object associated with a POA.
• POA Manager
• An object written by the developer, to be used by
  the ORB to manage POAs and their servants, and
  queue or discard requests.
  
• Servant Manager
• An object written by the developer, to be used by
  the POA to manage servants
  
• Adapter Activater
• An object written by the developer, called by the
  ORB. The Adapter Activater creates a child POA.

21
The POA Supports -

• Object Implementation Portability between ORBs
• Object Instances with Persistent Identities
• Transparent Activation
• Single Servant Implementing Multiple Instances
• Transient Objects with minimal programming
• Fine or Coarse Control of Behavior and
  Persistence by an Implementation
  
• Multiple Policies for Key Object Behaviors
• Implementations Inheriting from Static Skeleton
  Classes

22
Interoperability 2
Common Services and Facilities
System X
System Y
inheritance
Naming Transactions Security Events Time Life
cycle
Relationship Trading
23
OMA Overview
Application Objects
Horizontal CORBA Facilities
Vertical CORBA Facilities
Object Request Broker
CORBA Services
24
Interoperability 3
Self description
Information System X
Information System Y
Meta query
version
common self description language
or
meta object facility
Self description
25
Metadata Integration
Business System
S/W Development System
Manufacturing System
BOF
UML
MOF
Meta Query (meta data)
Each information system will require slightly
different meta modelling language but
interoperability across all systems if derived
from the same root language ( MOF).
26
Domains in the OMG OMA
27
MOF a Key Part of OMG OMA
28
Meta modelling
Set of constructs for OO information modelling
meta types meta relations meta schemas
Defines a language for specifying metamodels
types type relations type schemas
Defines a language for specifying a particular i
nformation
domain.
Domain X
Domain Y
29
Universal Object Repository

• A dynamic, extensible information system that
  stores and manages metadata-
  
• Business Information
• rules, processes, policies, organisational
  model
  
• Definition Information
• designs, models, programs, components,
  specifications..
  
• Metadata for a data warehouse
• Operational (runtime) information
• system configurations, CORBA IR,

30
Run Time Object Repository Architecture
Tools
Applications
Desktop Objects
Business Models OWD, ODF
Repository Services MOF, version, naming
Technology Models UML, CWM
Repository Object Model (MOF)
31
Emerging Repository Products

• IBM TeamConnection
• OO, MOF, XMI,
• Microsoft / Platinum
• OO, COM
• Unisys Universal Repository (UREP)
• OO, MOF, XMI, COM
• Oracle Repository
• OO, MOF, XMI

32
XMI Metadata Transfer

• XMI (XML-based Metadata Interchange )
• Will allow the interchange of metamodels and
  metadata between repositories or other tools in a
  serialised form.
  
• It is an interchange format and independent of
  middleware technology, no need for Orb -Orb
  connectivity to effect transfer.

33
OMG XMI Proposal

• Specify a XML DTDs to enable transfer and
  verification of -
  
• UML based models using a UML DTD
• MOF based metamodels using MOF DTD
• Specify a precise MOF to XML mapping
• Use OCL to specify stream production rules
• Allows interchange of any MOF based
  metamodel
  
• enable automatic generation of DTDs

34
COM-CORBA Interworking

• Motivation
• DCOM/COM /OLE/ActiveX are widely used for
  desktop integration of PC applications
  
• Compound documents
• Visual Basic / Visual C User Interfaces.
• OMG has little support for compound documents and
  visual user interfaces as yet.
  
• DCOM/COM is weak on support for distribution.
• CORBA was designed to support distribution.
• Java/Enterprise Java already work with OMG

35
CORBA-COM Interworking Specification

• Goal provide transparent bi-directional mapping
  between COM/OLE and CORBA.
  
• Adopted specification was submitted by consortium
  of 11 ORB vendors.
  
• Most of them have COM/OLE Interworking
  implemented in their ORB products.
  
• Adopted in March 1996.
• Microsoft decided not to be involved in this
  effort but rather pursue its own distributed
  object environment (DCOM).

36
Concluding Thoughts

• Distributed Object Architectures are much more
  than software communications buses
  
• Distributed meta object architecture is key to
• solving the integration problem especially at
  the
  
• large systems level
• building extensible systems
• self-discovery, navigation future
• maintainability
• Wireless Orb standard in progress.