SDSU CS 696 Emerging Technologies: Distributed Objects
Spring Semester, 1998
CORBAServices

To Lecture Notes Index
© 1998, All Rights Reserved, SDSU & Roger Whitney
San Diego State University -- This page last updated 21-Apr-98

Contents of Doc 29, CORBAServices

  1. References
  2. System Management
    1. Naming Service
    2. Life Cycle Service
    3. Licensing Service
    4. Object Trader Service
  3. Task Management
    1. Event Service
    2. Transaction Service
    3. Concurrency Control Service
  4. Information Management
    1. Property Service
    2. Relationship Service
    3. Query Service
    4. Externalization Service
    5. Persistent Object Service
    6. Object Collections Service
      1. Collection Interfaces
  5. Infrastructure Services
    1. Time Service
      1. Timer Event Service Interface
    2. Security Service

References


CORBAservices, chapters 1-17, March 1995
Much of this lecture is taken directly from the CORBAservices document. This document can be found at: http://www.omg.org/corba/csindx.htm

Inside CORBA: Distributed Object Standards and Applications, Mowbray & Ruh, 1997, chapter 4 pp 93-140

Pattern-Oriented Software Architecture: A System of Patterns, Buschmann, Meunier, Rohnert, Sommerlad, Stal, Wiley,1996, pp 341-343

Doc 29, CORBAServices Slide # 2

System Management

Naming Service


The Naming Service provides the ability to bind a name to an object relative to a naming context. A naming context is an object that contains a set of name bindings in which each name is unique. To resolve a name is to determine the object associated with the name in a given context.

Through the use of a very general model and dealing with names in their structural form, naming service implementations can be application specific or be based on a variety of naming systems currently available on system platforms.

Graphs of naming contexts can be supported in a distributed, federated fashion. The scalable design allows the distributed, heterogeneous implementation and administration of names and name contexts.

Because name component attribute values are not assigned or interpreted by the naming service, higher levels of software are not constrained in terms of policies about the use and management of attribute values.

Through the use of a "names library," name manipulation is simplified and names can be made representation-independent thus allowing their representation to evolve without requiring client changes.

Application localization is facilitated by name syntax-independence and the provision of a name "kind" attribute.

Doc 29, CORBAServices Slide # 3

Life Cycle Service


Defines conventions for creating, deleting, copying and moving objects

Creating is done using Factories


These operations work remotely

A client on machine HERE can copy a Document object on SOMEWHERE to THERE

Since objects are related to other objects the operation can act on graphs of objects

So you can copy an entire graph of objects from one machine to another

Graphs of objects are defined by the Relationship Service

Doc 29, CORBAServices Slide # 4

Licensing Service


Provides a mechanism for producers to control the use of their intellectual property

A license has three types of attributes
time, value mapping, consumer
Time includes, but is not limited to the attribute of Expiration/Duration.

Value Mapping includes, but is not limited to, the following attributes:
A unit is a quantity that can be used by policy mechanisms.
Allocative.
Use of an license with an allocative attribute removes it from the pool of available allocative licenses for a given product until it is returned
Consumptive.
Use of a license with a consumptive attribute permanently records its use
This can be used to provide metering capability
Consumer includes, but is not limited to, the following attributes:
Assignment or Reservation.
All licenses should be able to be assigned to or reserved for a specific entity or collection of entities


Doc 29, CORBAServices Slide # 5

Object Trader Service


Provides a matchmaking service for objects.

The trading object service allows traders and objects to:
export (advertise) services
import information about exported services, according to some criteria

An exporter advertises a service with a trader

An importer uses a trader to search for services matching some criteria

A service type, the information needed to describe a service, is associated with each traded service. It contains:
an interface type which defines service methods
zero or more named property types

Properties are <name, value> pairs

An exporter asserts values for properties of the service it is advertising

An importer can obtain these values about a service and constrain its search for appropriate offers based on the property values associated with such offers


Doc 29, CORBAServices Slide # 6

A service offer is the information asserted by an exporter about the service it is advertising. It contains:
the service type name
a reference to the interface that provides the service
zero or more property values for the service

Importers use standard constraint language to help select the services it wants

The constraint language consists of the following items
comparative functions
== , != , >, >=, <, <=, ~ (substring match)
in (element in sequence);
boolean connectives: and, or, not
property existence: exist
property names
numeric and string constants
mathematical operators: +, -, *, /
grouping operators: (, )



Doc 29, CORBAServices Slide # 7
Constraint Examples

"Cost < 5"
Consider offers with a Cost property value less than 5
"'Visa' in CreditCards"
Consider offers in which the CreditCards property, consisting of a set of strings, contains the string 'Visa'

"Cost >= 2 and Cost <= 5"
Consider offers where the value of the Cost property is in the range 2 <= Cost <= 5

"10 < 12.3 * MemSize + 4.6 * FileSize"
Consider offers for which the arithmetic function in terms of the value of the MemSize and FileSize properties exceeds 10


Doc 29, CORBAServices Slide # 8

Task Management

Event Service


Subject (Supplier, Publisher) changes state (or produces an item)

Observer (Consumer, Subscriber) reacts to the change in state (or consume the item)
Classic Supplier Consumer




Push verses Pull Model

Push
When supplier (publisher) creates a new item, it pushes it to the consumer (subscriber) whether they want it or not

Pull
When a consumer (subscriber) needs an item it requests it from the supplier (publisher), whether the item is ready or not

Event Service supports an event channel that allows push and pull suppliers to work with push and pull consumers

Doc 29, CORBAServices Slide # 9
Event Channel

When a push supplier pushes an item the event channel pushes the item to all its push consumers and saves the item until all its pull consumers have pulled the item

The event channel must periodically pull from all its pull suppliers. The pull can be initiated by a pull consumer or the event channel.


Doc 29, CORBAServices Slide # 10

Transaction Service


The Transaction Service supports the concept of a transaction.

A transaction is a unit of work that has the following (ACID) characteristics:

atomic
If interrupted by failure, all effects are undone

consistent results
The effects of a transaction preserve invariant properties
isolated
Intermediate states are not visible to other transactions
Transactions appear to execute serially, even if they are performed concurrently.

durable;
The effects of a completed transaction are persistent
They are never lost (except in a catastrophic failure)
A transaction can be terminated in two ways:
committed
rolled back

Supports flat (single) or nested transactions

Doc 29, CORBAServices Slide # 11

Concurrency Control Service


Concurrent access is controlled by using locks on shared resources

A client can hold multiple locks on a single object
Lock Modes
read (R)
Allows multiple readers on same object, no writers

write (W)
Allows only one writer, no readers

upgrade (U)
A read lock that conflicts with itself
Allows only one reader
Used to avoid the deadlock situation:
If more than one client holds a read lock on the resource, a deadlock will occur as soon as one of the clients requests a write lock on the resource. If each client requests a single upgrade lock followed by a write lock, this deadlock will not occur.
Intention Read and Intention Write Locks
Used on hierarchical structures
Obtain intention lock on parent structures then obtain normal lock on item of interest to insure that another process does not modify structure improperly while you have lock on individual item


Doc 29, CORBAServices Slide # 12

Information Management

Property Service


Provides the ability to dynamically associate named values with objects outside the static IDL-type system.

Defines operations to create and manipulate sets of name-value pairs or name-value- mode tuples.

Provides "batch" operations to deal with sets of properties as a whole.

Provides client access and control of constraints and property modes.

Does not rely on any other object services.

Doc 29, CORBAServices Slide # 13

Relationship Service


The Relationship Service allows entities and relationships to be explicitly represented.

Role
A role represents a CORBA object in an relationship.

Relationship
Relationships between object or roles are represented by a separate relationship object



Type
Relationships have types, as they are CORBA objects
Objects in the relationship have types
Relationships can restrict the types of objects that can be in the relationship

Degree
The number of roles required in a relationship
Cardinality
For each role in a relationship type, the maximum cardinality specifies the maximum number of relationships that may involve that role.


Doc 29, CORBAServices Slide # 14

The Relationship Service defines three levels of service:
base
graph
specific

Base level defines relationships and roles.

Base level operations
Create role and relationship objects
Navigate relationships
Destroy roles and relationships
Iterate over the relationships in which a role participates

Graph level supports traversals of graphs of relationships and adding/removing roles and relationships

Doc 29, CORBAServices Slide # 15
The Life Cycle Service defines operations to copy, move, and remove graphs of related objects, while the Relationship Service allows graphs of related objects to be traversed without activating the related objects


Level Three: Specific Relationships
Two relationships are so common they are explicitly defined in level three

Containment is a one-to-many relationship
A container can contain many containees
A containee is contained by one container

Reference is a many-to-many relationship
An object can reference many objects
An object can be referenced by many objects


Doc 29, CORBAServices Slide # 16

Query Service


Provides query operations on collections of objects

Query
Includes selection, insertion, updating and deletion on collections of objects

Collections
Objects, with methods for adding and removing members
They may map directly to collections managed by native query systems (Databases)
May include arbitrary CORBA objects.

Query Service is independent of any specific query languages

A Query Service must support either
SQL - Structured Query Language
OQL - Object Query Language
A superset of SQL


Doc 29, CORBAServices Slide # 17

Externalization Service


The Externalization Service defines protocols and conventions for externalizing and internalizing objects. Externalizing an object is to record the object state in a stream of data (in memory, on a disk file, across the network, and so forth) and then be internalized into a new object in the same or a different process. The externalized object can exist for arbitrary amounts of time, be transported by means outside of the ORB, and be internalized in a different, disconnected ORB. For portability, clients can request that externalized data be stored in a file whose format is defined with the Externalization Service Specification.



Doc 29, CORBAServices Slide # 18

Persistent Object Service


The Persistent Object Service (POS) provides a set of common interfaces to the mechanisms used for retaining and managing the persistent state of objects

The object ultimately has the responsibility of managing its state, but can use or delegate to the Persistent Object Service for the actual work

Doc 29, CORBAServices Slide # 19

Object Collections Service


Collection is a way of grouping elements together like Java's Vector and Hashtable

Collection services has a rich set of collections than Java JDK 1.1.x or C++ STL

The collection contains the following types of items:
Collection interfaces and collection factories
Iterator interfaces
Function interfaces

Each concrete collection has a Factory which is used to create instances of the collection

Collection Interfaces

Abstract interfaces
CollectionEqualitySequentialCollection
OrderedCollectionEqualityKeyCollection
KeyCollectionKeySortedCollection
EqualityCollectionEqualitySortedCollection
SortedCollectionEqualityKeySortedCollection
SequentialCollection


Doc 29, CORBAServices Slide # 20
Concrete collections
CollectionFactoryKeySortedBag
KeySetSortedMap
KeyBagSortedRelation
MapSortedSet
RelationSortedBag
SetSequence
BagEqualitySequence
KeySortedSetHeap
Restricted access collections
RestrictedAccessCollection
StackDeque
QueuePriorityQueue
Iterator interfaces
IteratorEqualityKeyIterator
OrderedIteratorKeySortedIterator
SequentialIteratorEqualitySortedIterator
SortedIteratorEqualitySequentialIterator
KeyIteratorEqualityKeySortedIterator
EqualityIterator
Function interfaces
Operations
Command
Comparator

Doc 29, CORBAServices Slide # 21

Infrastructure Services

Time Service


Enables the user to obtain current time together with an error estimate associated with it.

Ascertains the order in which "events" occurred.

Generates time-based events based on timers and alarms.

Computes the interval between two events.

Consists of two services, hence defines two service interfaces:

Time Service manages Universal Time Objects (UTOs) and Time Interval Objects (TIOs), and is represented by the TimeService interface.

Timer Event Service manages Timer Event Handler objects, and is represented by the TimerEventService interface.

Timer Event Service Interface

module CosTimerEvent{
   enum TimeType {
      TTAbsolute,
      TTRelative,
      TTPeriodic
   };

Doc 29, CORBAServices Slide # 22
    enum EventStatus {
      ESTimeSet,
      ESTimeCleared,
      ESTriggered,
      ESFailedTrigger
      };

   struct TimerEventT {
      TimeBase::UtcT utc;
      any event_data;
   };

   interface TimerEventHandler {
      readonly attribute EventStatus status;
      boolean time_set( out CosTime::UTO uto );

      void SetTimer(
         in TimeType time_type,
         in CosTime::UTO trigger_time
      );
      boolean cancel_timer();
      void set_data( in any event_data );
   };

   interface TimerEventService {
      TimerEventHandler register(
         in CosEventComm::PushConsumer event_interface,
         in any data
      );
   void unregister( in TimerEventHandler timer_event_handle);
   CosTime::UTO event_time( in TimerEventT timer_event);
   };
};

Doc 29, CORBAServices Slide # 23

Security Service


Security service addresses the following:

Identification and authentication of principals to verify they are who they claim to be.

Authorization and access control - deciding whether a principal can access an object

Security auditing to make users accountable for their security related actions.

Security of communication between objects

Non-repudiation provides irrefutable evidence of actions such as proof of origin of data to the recipient, or proof of receipt of data to the sender to protect against subsequent attempts to falsely deny the receiving or sending of the data

Administration of security information


visitors since 16-Apr-98