introduction to corba middleware workshop 20th june 2000 1 introduction to omg corba muddleware...

[email protected] Introduction to CORBA Middleware Workshop 20th June 20001

Introduction toOMG CORBA

Muddleware Workshop


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."


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


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.


Interoperability 1

Communication & Data Exchange

SystemX 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)


Role of OMG IDL

I D L

I D L

I D L

I D L

I D L

I D L

ORB

C

C++

COBOL

Ada

Smalltalk

Java

Client Side Object Implementation

Side COBOL

C

Ada

C++

Smalltalk

Java

I D L

I D L

I D L

I D L

I D L

I D L

ORB


IDL Variable TypesPRIMITIVE: 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


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)

};};


Object Access via the ORB

IDL

Client

ORB

IDL

ORB

Obj Impl

IDL

Client Obj Impl

IDL

ORB

IDL

Client

IDL

ORB

Obj Impl


ORB Components

POA

ORB Core (GIOP,IIOP)

Client Object Implementation

ClientStubs

ORBInterface

DynamicInvocation

ImplSkeletons

One interface

One interface per object operationOne interface per object adaptor

Proprietary interfaceNormal call interfaceUp call interface

DSI

DSI: Dynamic Skeleton Interface POA: Portable Object Adapter

Interfacerepository

ImplementationRepository


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


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


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)


GIOP: Object InvocationsUsing 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.


Messaging Extensions to GIOPCORBA 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.


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


Enter the Servant

Sometimes the simple One-Object-Reference for One-Running-Implementation model isn’t 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


Simple POA Model Configuration

POA

POA

?ORB

Clie

nt

Server

Servants

Object Reference Object IDs


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.


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.


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


Interoperability 2 Common Services and Facilities

SystemX System

Y

Naming TransactionsSecurity EventsTime Life cycleRelationship Trading

inheritance


OMA Overview

ApplicationObjects

HorizontalCORBA Facilities

Object Request Broker

CORBA Services

VerticalCORBA Facilities


Interoperability 3

Information SystemX

Information SystemY

version

Meta query

Self description

Self description

common self description languageor

meta object facility


Metadata Integration

BusinessSystem

Meta Query (meta data)

S/W DevelopmentSystem

ManufacturingSystem

UML BOFMOF++

Each information system will require slightly different meta modelling language but interoperability across all systems if derived from the same root language ( MOF).


Domains in the OMG OMA

CORBAservices

Horizontal CORBAfacilitiesBOF, basic Business Objects & Framework

FinancialObjects

TransprtationObjects

E-CommerceObjects

HealthcareObjects

TelecomObjects

ManufctringObjects

Acc

ount

ing

Ban

king

Insu

ranc

e

PDM

Tele

Net

wk

Mgm

t

Shop

Flo

or A

uto

ERP

Med

ical

MPI

Tele

Ser

vice

s

Stre

am C

ontr

ol

EC S

ervi

ces

E-Pa

ymen

t

Den

tal

Mar

ine

Rai

l

Offe

r Loc

/Tra

de

Inte

rmod

al


UMLModeling CORBAservices

CORBAfacilitiesBusiness Object Facility*

Common Business Objects*

CORBADomains

CORBADomains

CORBADomains

Met

a-O

bjec

t Fac

ility

SECU

RITY

IDL Interfaces, Mappings, & ORB

Realtime*, Embedded* optionsInteroperability: IIOP, Asynch*

Components*, Scripting**: coming soon

Analysis & Design;

Metadata

MOF a Key Part of OMG OMA


Meta modelling

Domain X Domain Y

Set of constructs for OO information modelling meta typesmeta relationsmeta schemas

typestype relationstype schemas

Defines a language forspecifying metamodels

Defines a languagefor specifying aparticular informationdomain.


Universal Object RepositoryA 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, …


Repository Browser

Desktop ObjectsTools Applications

Repository ServicesMOF, version, naming

Technology ModelsUML, CWM

Business ModelsOWD, ODF

RepositoryObjects

RepositoryObjects

Run Time Object Repository Architecture

Repository Object Model (MOF)


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 }


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.


OMG XMI Proposal

Specify a XML DTD’s 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 DTD’s


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


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).


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.

introduction to corba middleware workshop 20th june 2000 1 introduction to omg corba muddleware...

Documents