 |
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
- References
- System Management
- Naming Service
- Life Cycle Service
- Licensing Service
- Object Trader Service
- Task Management
- Event Service
- Transaction Service
- Concurrency Control Service
- Information Management
- Property Service
- Relationship Service
- Query Service
- Externalization Service
- Persistent Object Service
- Object Collections Service
- Collection Interfaces
- Infrastructure Services
- Time Service
- Timer Event Service Interface
- Security Service
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
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.
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
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
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
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: (, )
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
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
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.
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
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
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.
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.
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
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
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
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.
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
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
Abstract interfaces
| Collection | EqualitySequentialCollection |
| OrderedCollection | EqualityKeyCollection |
| KeyCollection | KeySortedCollection |
| EqualityCollection | EqualitySortedCollection |
| SortedCollection | EqualityKeySortedCollection |
| SequentialCollection | |
Concrete collections
| CollectionFactory | KeySortedBag |
| KeySet | SortedMap |
| KeyBag | SortedRelation |
| Map | SortedSet |
| Relation | SortedBag |
| Set | Sequence |
| Bag | EqualitySequence |
| KeySortedSet | Heap |
Restricted access collections
| RestrictedAccessCollection | |
| Stack | Deque |
| Queue | PriorityQueue |
Iterator interfaces
| Iterator | EqualityKeyIterator |
| OrderedIterator | KeySortedIterator |
| SequentialIterator | EqualitySortedIterator |
| SortedIterator | EqualitySequentialIterator |
| KeyIterator | EqualityKeySortedIterator |
| EqualityIterator | |
Function interfaces
Operations
Command
Comparator
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.
module CosTimerEvent{
enum TimeType {
TTAbsolute,
TTRelative,
TTPeriodic
};
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);
};
};
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