santa claus and the corba component model

Santa & CCM Jeff Parsons

1

Santa Claus and the CORBA Component Model

Jeff Parsons

November 2, 2005


2

A Child’s Innocent Christmas


3

Just Beneath The Surface• Client – Role played by software that sends a request.• Server – Role played by software that receives and processes a request.• ORB (Object Request Broker) – Hides details of sending/receiving

requests. Client & Server each start one up.• Object – OO concept + distributed.• Object Reference – String of info about connecting/sending to Server.

Understood only by ORBs.• Proxy – Local (to Client) stand-in for Server. Associated with an Object

Reference by the Client’s ORB.


4

A Child’s CORBA Christmas

2. Proxy sends request

1. Server gets request

3. Client thread blocks 2. Server processes request

3. Server sends reply

4. Proxy gets reply

1. Client makes request on Proxy

5. Proxy returns reply to Client


5

Digging Deeper• Servant – Local to Server, does the actual execution of the

“function body”.

• Dispatch (verb) – To guide received requests to Servants.

• POA (Portable Object Adapter) – Part of Server’s ORB, does the Dispatching.


6

“There Ain’t No Santa Claus”

“Household” POA

Lookup

Dispatch

Servants (parents)

Execute


7

A CORBA-Enhanced Christmas• ORBs make remote calls look like local ones• Definition language for Client/Server interface

– Enables the generation of boilerplate code

– Guides the application developer

• POA policies enable flexibility in dispatching– Single parent

– Alternating custody

– Extended family household

– Multiple Clients (children)

– Etc.


8

Scaling and Expanding• POA policies multiply

– X each policy type used– X each POA

• Client and Server roles intermingle– Shopping for presents

• In stores

• Online

• By phone

– Optimizing efficiency• Item in stock?

• Best price?


9

Refining and Enhancing• Servant Configuration

– Shopping concurrency– IPC– Replication

• Multiple Christmas QoS Requirements– Wrapping presents– Setting up Christmas tree– Completing tasks by

Christmas Eve deadline– Keeping the Santa Claus

implementation secret from the child (maybe)


10

What Are We Lacking?• A systematic way of describing an object’s relationship to its

environment.– Many standardized services exist

– Use of these services is still ad hoc

• A more expressive way of describing relationships between objects.– All we have now is inheritance

– Language independence limits its usefulness

• A way of reducing the proportion of hand-written code.


11

The Component And Its Parts

Attributes

EventSinks

Facets Receptacles

EventSources

ComponentReference

• Component – New centerpiece, Objects now play a more supportive role. Can be written by 3rd party.– Attribute - More clearly intended

for configuration.– Port – General term for

interaction mechanism.• Facet – Interface provided to

Clients or other Components.• Receptacle – Interface required

by this Component.• Event Source – Sends

(publishes) asynchronous Events.

• Event Sink – Receives (subscribes to) asynchronous Events.


12

Component + Container

Container

Component

ORBPOA

ServiceService

• Home – Configurable “factory” for Components.– Create– Retrieve from repository

• Container – Component’s virtual environment.– ORB– POA(s)– Services

• Selected from spec-defined or custom services.

• May mediate port activity


13

A Child’s Component-Aware, Network-Centric Christmas

Household

RT ORBRT

POA

Security ServiceScheduling Service

Father

VoiceMail

Trading Service

JCPenney

ORBPOAPOA

Data Warehouse

RetailStore

Inventory

POA

Catalog

Child

Mother

Letter To Santa

Toys’R’Us

RetailStore

VoiceConversation

ORBPOA

Lifecycle Service

POA

CustomerService

Salespeople

Salesperson

CatalogMailing

Presents


14

Where We Started: Object-Oriented Programming• Object-oriented (OO) programming simplified software

development through higher level abstractions & patterns, e.g.,

Well-written OO programs exhibit recurring structures that promote abstraction, flexibility, modularity, elegance

– Decoupling interfaces & implementations

– Associating related data & operations

operation1()operation2()operation3()operationn()

data

class X


15

Motivations for Applying OO to Network Programming

• Abstract away lower-level OS & protocol-specific details for network programming

• Create distributed systems which are easier to model & build

• Result: robust distributed systems built with distributed object computing middleware

– e.g., CORBA, Java RMI, etc.

1 1Proxy

service

Service

service

AbstractService

service

Client

We now have more robust software & more powerful distributed systems

operation()Object : Class X

: Client

Middleware


16

Overview of CORBA •CORBA is distributed object computing middleware that shields applications from heterogeneous platform dependencies•e.g., languages, operating systems, networking protocols, hardware

• CORBA simplifies development of distributed applications by automating/encapsulating

– Object location – Connection & memory mgmt.– Parameter (de)marshaling– Event & request

demultiplexing– Error handling & fault

tolerance– Object/server activation– Concurrency– Security

• CORBA defines interfaces, not implementations


17

Example: Applying OO to Network Programming

• CORBA IDL specifies interfaces with operations– Interfaces map to objects in OO programming languages

• e.g., C++, Java, Ada95, etc.

– Operations in interfaces can be on local or remote objects

interface Foo { void MyOp (in long arg);};

IDL

class Foo : public virtual CORBA::Object { virtual void MyOp (CORBA::Long arg);};

C++


18

Limitations of OO-based CORBA Middleware

• CORBA does not specify how “configuration” & “deployment” of object implementations should be done to create complete applications

–Proprietary infrastructure & scripts are usually written to facilitate this

InterfaceDesign

ApplicationDevelopment &

Deployment

IDLDefinitions

IDLCompiler

Stubs&

Skeletons

ObjectImplementations

LanguageTools

Libraries

“Other”Implementations

Applications

• CORBA IDL does not provide a way to logically group together related interfaces to offer a specific service

–Such “bundling” must be done by developers


19

Boiler Plate X

Boiler Plate YBoiler Plate X

Example: Limitations of CORBA 2.x Specification• Requirements of non-trivial

applications:–Collaboration of multiple

objects & services–Deployment on diverse

platforms• Limitations – Lack of standards for

–Server configuration–Object/service configuration–Application configuration–Object/service deployment

• Consequences – tight couplings at various layers

– Brittle, non-scalable implementation

– Hard to adapt & maintain– Increase time-to-market

ServerORB/POA

ObjImpl

ObjImpl

ObjImpl

ServerORB/POA

ObjImpl

ObjImpl

COS

Svc

ServerORB/POA

ObjImpl

ObjImpl

COS

Svc

Client

CORBA BUS

invoke C

onfig C

Config B

Config A


20

Solution Approach: Component MiddlewareComponent middleware capabilities:

•Creates a standard “virtual boundary” around application component implementations that interact only via well-defined interfaces

•Define standard container mechanisms needed to execute components in generic component servers

•Specify the infrastructure to configure & deploy components throughout a distributed system


21

•Components encapsulate application “business” logic

•Components interact via ports•Provided interfaces, e.g.,facets•Required connection points, e.g., receptacles

•Event sinks & sources•Attributes

•Containers provide execution environment for components with common operating requirements

•Components/containers can also

•Communicate via a middleware bus and

•Reuse common middleware services

SecurityReplication NotificationPersistence

SchedulingA/V Streaming Load Balancing

…

Container

… …

Middleware Bus

Container

…

Overview of Component Middleware


22

Object Model – IDL Only• Interface Definition Language (IDL)

+ compiler generates code to

– Create and manage connections

– Send and receive data• Problem: Generic lifecycle &

initialization server code must be handwritten

• Ad hoc design• Code bloat• No reuse

StubFiles

ImplFiles

Generated Hand-Written

SkeletonFiles

Generates Inherits

Server

IDL Compiler

IDL File


23

Component Model – IDL + CIDL• Solution: Component Implementation

Definition Language (CIDL) is part of CCM strategy for managing complex applications

• Helps separation of concerns

• Helps coordination of tools

• Increases the ratio of generated to hand-written code

• Server code is now generated, startup automated by other CCM tools

Stub

Impl

Skel

IDL Compiler

IDL

CIDL

CIDL Compiler

Executor IDL

Servants

Executors

IDL Compiler

XMLComponentDescriptors

delegates


24

Deployment and Configuration 1/2• Platform-Independent Model (PIM)• Three broad areas – software, target, execution• Defined in two dimensions

PIM Data Model Run-time Model

Component Software

Meta-data to describe component based applications and their requirements

Interfaces to browse, store and retrieve such meta-data

Target Meta-data to describe heterogeneous distributed systems & their capabilities

Interfaces to collect & retrieve such meta-data and commit resources

Execution Meta-data to describe a specific deployment of an application into a distributed system

Prepare environment, Execute on target to Deployment plan, manage lifecycle


25

Deployment and Configuration 2/2• XML schema and file extensions capture the various kinds of

packaging, configuration and deployment information– Component Package Descriptor: .cpd

– Component Implementation Descriptor: .cid

– Implementation Artifact Descriptor: .iad

– Component Interface Descriptor

(CORBA Component Descriptor): .ccd

– Component Domain Descriptor .cdd

– Deployment Plan Descriptor

(Component Deployment Plan): .cdp

– Top Level Package Descriptor package.pcd

– ZIP file containing all of above + binaries .cpk


26

D&C Actors• Different stages & different actors

– Development

• Specifier/ Developer

• Assembler

• Packager

– Target

• Domain Administrator

– Deployment

• Repository Administrator

• Planner

• Executor

• Actors are abstract

– Usually humans & software tools

Development

Target Deployment

Domain

AccessesResources

Assembler

Assembler

Planner

DomainAdministrator

Specifies

CreatesComponent

ResourceRequirements

Impl Impl Impl

Properties

COMPONENT REPOSITORY

QoS Specs

Configurations

Dependencies

Specifier/Developer

CreatesComponent Assembly

ComponentComponent

ComponentComponent

Creates Packager

RepositoryAdministrator

Component Packages

Configures

DesktopPrinter Laptop computer

Ethernet Bridge

Firewall

Creates

Executor

Deployment PlanUses

Deploys

These actors & stages are simply making explicit existing processes


27

An Evolving Specification• Deployment and Configuration

– Recently revised by OMG.

– IDL and XML schema versions published.

– Revised Component Assembly concept more powerful.

• Lightweight CORBA Component Model– Tailored for embedded systems.

– Prunes away parts of spec oriented toward enterprise applications.

• Research feedback can influence evolution.


28

Questions?


29

Current Work – The ARMS Project• Adaptive Reflective Middleware System• Goal – design and implement Total Shipboard Computing Environment (TSCE).

– “Stealth” ship.– Crew size 1/3 that of similar size ships.– ~1000 nodes, ~5000 applications in multi-level network.

• TSCE will adapt to mission modes (port, navigation, battle) and to battle damage.• TSCE-wide Dynamic Resource Management (DRM) system uses components.

– Lockheed-Martin– BBN– Vanderbilt/ISIS– Raytheon– Johns Hopkins– Telcordia– SRC– University of Ohio– University of Illinois– Boeing

santa claus and the corba component model

Documents