Common and not domain specific separation of interface and implementation generic (do not depend on the client object) how to find services is a different.

• common and not domain specific

• separation of interface and implementation

• generic (do not depend on the client object)

• how to find services is a different story

COS: Common Object Services

TECHNOLOGY

CORBA 2 Object Request Broker

Naming

Event

PersistentObject

Life Cycle

Concurrency

Externalization

Relationship

Transaction

Query

Properties

Licensing

Security

Time

Trader Collections

Messaging

CORBAservices

CustomInterfaces

ProprietaryInterfaces

CORBAservicesSpecializations

CORBAfacilitiesSpecializations

ApplicationInterfaces

User InterfaceManagement

InformationManagement

SystemManagement

TaskManagement

CORBAman CORBAtel

CORBAdomains(Domain Interfaces)

CORBAfacilities

Others.......

CORBA-financials

CORBAmedBusinessObjects

DistributedDocument

ComponentsCommon

Management

Adopted Langauge Mappings:C, C++, Smalltalk, Ada95

Interoperability Protocols:Internet (IIOP GIOP) -- DCE ESIOP

CORBAdomainsSpecializations

InternetMobileAgents

ElectronicCommerce

Spec Now

Planned

Key

Naming Service

Naming Service

• White pages• Binding: name-to-object association• Naming context: set of bindings with unique names• Resolving: name => object• Contexts can be bound in contexts• Naming Graph: directed graph where nodes are

contexts• Compound name: path in naming graph

A Naming Graph

user

home

sys

lib

bin l2

l1

c2c1

alden

bill

u1

u2

u3

parent

struct NameComponent {string id;string kind;

};

typedef sequence <NameComponent> Name;

enum BindingType {nobject, ncontext};

struct Binding {Name binding_name;BindingType binding_type;

};

Some Data Types

BindingIterator•boolean next_one(out Binding)•boolean next_n(long, out BindingList)•destroy()

Naming Context•bind(Name, Object)•rebind(Name, Object)•bind_context(Name, NamingContext)•rebind_context(Name,NamingContext)•Object resolve(Name)•unbind(Name)•NamingContext new_context()•NamingContext bind_new_context(Name)•destroy()•list(long, out BindingList, out BindingIterator)

Naming Service Interfaces

Interoperable Naming Service

• Extension of older Naming Service• Resolves interoperability issues (e.g. defines equality

between CosNaming::NameComponents)• Defines an interoperable, stringified form of a

CosNaming::Name• Defines a URL format for names• Allows multiple clients to access a common Initial

Naming Context

Stringified Names

= a.b/./c/.d

id kind

----------- -----------

a b

<empty> <empty>

c <empty>

<empty> d

corbaname URL Scheme• It allows URLs to denote entries in a Naming

Service• corbaname syntax

<corbaname> =

“corbaname:” <corbaloc_obj> [“#” <string_name>]

• examples– corbaname://555xyz.com/dev/Ncontext1#a/b/c– corbaname://555xyz.com#a/b/c– corbaname:///#a/b/c– corbaname:///

Naming Service Interfaces (cont’d)

NamingContextExt

•StringName to_string(Name)•Name to_name(StringName)•URLString to_url(Address, StringName)•Object resolve_str(StringName)

Obtaining Initial References

• resolving:Object obj = ORB::resolve_initial_references( “NameService” );

• narrowing:NamingContext nc = NamingContextHelper.narrow(obj);

Configuring Initial Service Refs.

• ORB-specific configuration

• using ORBInitRef– format: -ORBInitRef <ObjectID>=<ObjectURL>– example:-ORBInitRef NameService=IOR:00230021...

• using ORBDefaultInitRef– format: -ORBDefaultInitRef <URL>– example:-ORBDefaultInitRef corbaname://555obj.com/dev

Starting/Connecting to ORBacus Basic Services

• set CLASSPATH to OBNaming.jar

• starting the service:java com.ooc.CosNaming.Server -i -OAport 10000 > nameserv.ior

• connecting to the service:java MyClient -ORBservice NameService `cat nameserv.ior`

Trading Object Service

Trading Object Service

• It is the CORBA Yellow Pages

• Advertises services

• Discovers services

A Trader and its Users

Trader

Exporter Importer

ExportImport ReplyImport

Request

Service Invocation

Service Reply

Trading Graph

T T

T T

T

• To distribute the trading object service

• To contextualise the offer space

Service Description

• A service is described by a service type which includes:– an interface type– zero or more property type(s)

Property Strength

(default)

mandatory readonly

mandatory, readonly

Increasing Strength

IDL for properties

Properties are name-value pairs:

typedef Istring PropertyName;

typedef any PropertyValue;

struct Property {

PropertyName name;

PropertyValue value;

};

Offering a Service

TraderExporter

• service name• object reference• property values

• Offer identifier

Selecting a Service

Potential Offers

Considered Offers

Matched Offers

Ordered Offers

Returned Offers

servicetype constraints

preferences

searchcardinality

matchcardinality

returncardinality

Trader Types

• Query

• Simple

• Stand-alone

• Linked

• Proxy

• Full-Service

Query/Collection Service

Query Service

• It supports query operations on arbitrary CORBA objects (individually or in a collection)

• Query Languages: OQL, SQL Query

Query Evaluators

Object

Query Evaluator

Client

Object

Query Evaluator Query Evaluator

Database

Queryable Collections

Collections may form:• the scope to which a query is applied• the result of a query

Query Evaluator

QueryableCollection

query

QueryableCollection

Collection

query query

query

Iterator

resetnextmore

Collection

add_elementadd_all_elementsinsert_element_at

replace_element_atremove_element_atretrieve_element_at

create_iterator

CollectionFactory

create

The Collection Interfaces

Queryable Collection

QueryEvaluator

evaluate

QueryManagercreate

CollectionQuery

prepareexecute

get_statusget_result

The Query Interfaces

Collection Service

• It supports the creation and manipulation of groups of objects

• Common collections: sequences, queues, stacks, sets, bags, etc.

Collection Properties

• Ordering of elements

• Access by key

• Element equality

• Uniqueness of entries

Query vs. Collection Service

• The query service only supports a minimalist collection service

LifeCycle Service

LifeCycle Service

• Creating objects

• Deleting objects

• Copying objects

• Moving objects

Creating an object

HERE THERE

Client

• location of new object

• entity contacted for creation

• finding that entity

• initial values

Moving/Copying an object

HERE SOMEWHERE THERE

Client Document

• location of copied/migrated object

• entity contacted for copying/migration

• finding that entity

Creating an object

HERE THERE

Client Factorycreate_object

Deleting an object

HERE SOMEWHERE

Client Documentremove

Moving/Copying an object

HERE SOMEWHERE THERE

Client Document

FactoryFinder

move/copy

LifeCycle Service InterfacesFactoryFinder

Factories find_factories(Key)

GenericFactory

boolean supports(Key)Object create_object(Key, Criteria)

LifeCycleObject

LifeCycleObject copy(FactoryFinder, Criteria)void move(FactoryFinder, Criteria)void remove()

Moving/Copying an object

HERE SOMEWHERE THERE

Client Document

FactoryFinder

Factory

Externalization Service

Externalization Service

• writing and reading an object’s state to/from an external medium (disk, memory, etc.)

• externalised form can:– exist for arbitrary amounts of time– be transported by means outside of the ORB– be internalised in a different ORB

• standard externalisation format

• related to the Relationship and LifeCycle Services

Externalization Service Interfaces

Stream

IdentifiableObjectStreamableFactory

Streamable

FileStreamFactory

StreamFactory

LifeCycleObject

Relationship

Role

Node

StreamIO

•Key external_form_id•externalize_to_stream(StreamIO)•internalize_from_stream(StreamIO, FactoryFinder)

•externalize(Streamable)•Streamable internalize(FactoryFinder)•begin_context()•end_context() •write_<type>(<type>)

•write_object(Streamable)•write_graph(Node)•<type> read_<type>()•read_object(FactoryFinder, Streamable)•read_graph(Node, FactoryFinder)

create()

create(string)

create_uninitialized()

Persistent State Service

POS Components

PDS

POM

PO

Client

PIDPersistentObject

PersistentData Service

Protocol

PersistentIdentifier

Persistent ObjectManager

Datastore

Persistent Object Service (POS)

• POS is being deprecated by OMG because:– very little use or implementation– generally seen as too complex and imprecisely

specified– poor match to current persistence needs– industry now has a better understanding of what is

needed and the correct level of abstraction

• PSS will be a replacement for POS– focuses on “a way for CORBA object implementations to

maintain their own persistent state”– simple to use and implement– applicable to existing data storage technologies, but

independent of them– efficient– related to: POA, concurrency, transaction, query, OBV,

security

Persistent State Service (PSS)

PSS focus

ORB domain

Externalinterface

Servants

Internalinterface

Datastore domain

Relationship Service

Object Relationship Graphs

folder

person

book

library

logo

figure

document

containment

referencecheck_out

A role

A relationship

An entity

attribute: due_date

3º2º

0 .. *

1 .. 1

Key Features• explicit representation of entities and relationships

• arbitrary degree

• type and cardinality constraints

• roles and relationships can be extended with attributes and operations

• high performance

• can relate immutable objects

• traversal without activation

• three levels of service:

– base: simple relationships and roles

– graph: traversal of graphs of related objects

– specific: specialised relationships

• Flexible multidirectional relationships– object references are unidirectional

• Third party manipulation– relationship and role objects can be exposed to a third

party for manipulation

• Graph traversal

• Relationships and roles can have attributes and operations via IDL inheritance

Advantages over Object Refs

Property Service

Property Service

• dynamically associates properties with an object

• properties are name-value pairs

• provides “batch” operations

• clients can access and control property modes and constraints

• implementations can restrict creation, deletion, modification of properties

Some Data Types

typedef string PropertyName;

struct Property {

PropertyName property_name;

any property_value;

};

enum PropertyModeType {

normal, read_only, fixed_normal, fixed_readonly, undefined

};

Property Service Interfaces

PropertySetFactory

PropertySetDefFactory

PropertySetDef

PropertiesIterator

PropertySet Property

PropertyDefPropertyMode

creates

creates

defining, deleting,enumerating,existence-checking

PropertyNamesIterator

retrieving constraints,getting and settingproperty modes

Event Service

Event Service

• decouples the communication between objects• event: a piece of information that is contributed by an

event source• two event object roles (i.e. suppliers and consumers)• suppliers and consumers support standard IDL interfaces• two communication initiation approaches (i.e. push and

pull)• two communication types (i.e. generic and typed)

SupplierConsumer

Event Object Roles

• Suppliers– produce event data

• Consumers– process/use event data

SupplierConsumer

Push

Pull“What’s new?”

“News flash”

Communication Initiation Approaches

• Push model– supplier takes initiative

• Pull model– consumer takes initiative

SupplierConsumer

Consumer Supplier

Event Channel

Push/Pull

Push/Pull

Event Channel

• an intervening object which accepts events and distributes them to other objects (i.e. it is both a supplier and a consumer)

• it allows multiple suppliers and consumers to communicate asynchronously

Communication Types

• generic– communication via generic push or pull operations;

event data packaged in a single parameter

• typed– communication via operations defined in IDL; event

data passed by defined parameters

Transaction Service

What is a Transaction?

A unit of work that is:

• Atomic

• Consistent

• Isolated

• Durable

Why do we need a Transaction Service?

It allows transactions to include:

• Multiple, separately defined ACID objects

• Objects and resources from the non-object world

Note: The Transaction Service supports existing IDL Interfaces

Transaction Models

The transaction service supports:

• Flat transactions

• Nested transactions (optional)

Transaction Service Basic Elements

Transaction Service

Distributed Client/Server Application

Transactional Client

Recoverable ServerTransactional Server

ResourceTransactional Object

Recoverable Object

transaction context

Rest of Services

Concurrency Service

• Mediates simultaneous access to resources– makes actions atomic

• Transactional or non-transactional– if former: uses Transaction Service

• Serializes transactional and non-transactional clients

• Coordination of access to resources through locks

Concurrency Service (cont’d)

• lock modes:– read, write, upgrade locks– intention locks (variable granularity)

• multiple possession of locks

• two-phase locking

• nested transactions

Time Service

• obtaining time– UTC representation, 10-7 seconds unit, AD 1582 - 30,000

range– error estimates

• ordering time• time intervals• no support for time zones, dates• two main interfaces:

– TimeService, TimerEventService

Licensing Service

• mechanism for producers to control the use of their intellectual property

• may be useful in non-profit organizations

• policies implemented in terms of:– time (start/duration and expiration)– value mapping (units, concurrent use, metering)– consumers (assignment, reservation)

Security Service

• confidentiality

• integrity

• accountability

• availability

Security Service (cont’d)

• identification, authentication

• authorization, access control

• auditing

• security of communication

• non-repudiation

• administration

Rounding up

• Common Object Services– fundamental and basic– facilitate using and implementing objects– interfaces, not implementations– rarely available ‘out of the box’– subject to changes

Information

• CORBA Services documentation:– http://www.omg.org/library/csindx.html

• IDL:– http://www.omg.org/library/idlindx.html