Server-Side Components

• Recap: (fig 5.2)

– Thin clients, fat servers

– ORB handles transparent communication

– Object adapter provides interfaces between ORB and object implementation & represents implementation of object model

• To client, server always there, always available and always in consistent state

• Object implementation must support the realization of this client-side simplicity

Object Implementation Structure

• Objects are not always active and running - requires transparent activation/deactivation

• Maintaining, saving and restoring object state, checkpointing

• No mandatory enforcement

Object Adapters

• Responsible for:

– registering object implementations

– generating and interpreting object references

– mapping references to corresponding implementations

– activating and deactivating objects

– invoking methods, via skeleton or DSI

– coordinating interaction security

Different Object Adapters

• BOA designed primarily for servers that reside in their own processes separate from client and ORB

• Library OA would be specialized for objects that coreside with clients in a single process; could be designed and tuned for fast performance and small footprint

• OODB Adapter uses a connection to OODB to access the objects stored in it. Since OODB provides the methods and persistent storage, objects maybe registered implicitly, and no state required.

BOA

• Supports object implementations constructed from one or more “programs”

• Differentiates between a server (an execution unit) and an object (implements a method or interface) - server may contain multiple objects

• Supports four activation policies (fig 5.4)

• Shared server - activated by the BOA encompassing multiple active objects

• Persistent server policy - like shared server except that the server is activated outside of the BOA

• Unshared server - one object active per server

• Server-by-method - a separate server for each method invocation

Dynamic Skeleton Interface (DSI)

• Important means to realize interoperability

• It allows two ORBs to construct a bridge that communicates a communicates an invocation to the remote object’s ORB

• Crucial to dynamic, reconfigurable complex distributed systems

• Implemented via Dynamic Implementation Routine (DIR) - ORB invoke the same routine DIR for every DSI request it makes

OMG’s vision on component technology

• OMA embodies the vision

• Supported by CORBAservices and CORBAfacilities

• Standardized interface definition for each service and facility

• Open competing ground & market for component venders

• CORBAservices provide basic functionalities

• Horizontal CORBAfacilities add application-level functionality

• Vertical CORBAfacilities provide domain/industry specific functionalities

CORBAservices

• CORBAservices architecture (Fig. 4.1 Morbray)

• Services grouping (Table 4.1., Morbray)

• Bases for component-based software development

• Real savings for end-user companies adopting OMG technology

• Representing basic functions needed by most application developments

• Declared in IDL

• Explicit operation sequencing dependencies

• No implementation descriptions

Relationship Service

• Provide standard way for establishing linkages and relationships among objects that would replace ad hoc or custom approaches

• Relationship is characterized by:

– Type (of relation), e.g. owns, contains, employed-by, etc

– Roles: the role an object play in a relationship, e.g. owner, container, employer, etc.

– Degree: the number of required roles, which are needed to characterize the relationship, e.g. Employment has two: employer and employee

– Cardinality: the max number of relationships that may involve a particular role, e.g. employer role may have one-to-many relationship with employees

– Semantics: may define relationship-specific attributes and operations, e.g. job-title may be an attribute of the employment relationship.

Three Levels of Relationship Service

• Basic relationship service: defines only roles and relationships (figure 10.2)

• Second level: graphs of related objects (fig 10.3)

– Adds support for graphs of related objects through the Node and Traversal interfaces

– Node interface collects all of the roles a related object is involved in

– Traversal interface provides an operation to traverse the graph

• Third level: Specific relationships containment and reference

Other Information Management Services

• Property Service - to access and manipulate dynamic properties of application objects

• Query Service - provides a general-purpose interface for query objects, used mostly with various database products

• Externalization Service - Converting program data structures and other object states into a form that can be stored and transmitted. E.g., removing pointers and binary data into flat byte streams

• Persistent Object Service - Provides a set of interfaces used by a persistent object to access and store its persistent state; applications’ interface to DBMS

• Collection Service - provides interface definitions for common groupings of objects structured in various ways, e.g. list, stack, queue

Event Service

• Defines generic interfaces for passing information among multiple sources and consumers

• Sources and consumers don’t need to have direct knowledge of each other, thus de-coupling consumers from event sources with grouping and delivery mechanism managed by the Service

• Can be used as multicast mechanism without direct connection between sender and receivers

• Supports multiple styles of interaction (between application and the Service; two principal styles: push and pull

• PUSH - event source makes out call to consumers

• PULL - event source waits for consumer to make a call back in order to receive the next event notification

Event Service

• PULL consists of polled and blocking mode

• Supports different styles of interactions simultaneously all interoperating at the same time through the same event channel

• Example of Event service interface (fig. 4.7. Morbray)

• Event factory object implements the Lifecycle service operations specific to the Event service, and responsible for creating event channel objects

• Event channel object supports several interfaces for event notification and other operations

• A scenario (Fig. 4.8)

• Good thesis topic, e.g. how to take advantage of the flexibility of event service to design real-time, command control, decision support, reliable, dynamic distributed systems

Other Task Management Services

• Concurrency Service - provides general purpose, platform/OS independent service for ensuring atomic access to distributed objects

– Locking, critical sections, mutual exclusion

– Unusual service in that it probably has all the necessary interfaces (functions) for application development which makes specialization unnecessary

– An example (Fig 4.9)

• Transaction Service - one of the most sophisticated, high-level service of the CORBAservices, which alone has sufficient commercial value

– General capability that allows the manipulation of the state of multiple objects in a distributed environment

– Supports ACID properties (atomicity, consistency, isolation and durability)

Naming Service

• A general directory service to be used by most applications, which provide mapping between object name and reference

• Names maybe object names or operation names

• Names maybe well known or private

• Name bindings are always relative to a scope called naming context; names are unique to their naming context

• Name resolution is mapping from name to object within a context

Naming Services

• Key operations: bind and resolve

• Primary objects in the Naming service are naming context objects, (e.g. Fig 4.11)

• Schema that defines the directory trees and the naming conventions used in these trees is an application design choice

• This service can be used as an interface wrapper over existing naming directory services

• Names are represented as a sequence of structures. Each structure is a (name, kind) pair. The intention is that the structure sequence would be converted into path names for use in platform specific environment

Naming Service

• Naming service usually requires following conventions defined

– Definition of the local naming schema

• structure of naming contexts

• rules for extending the context

– Definition of the local naming conventions

• Well-known names

• conventions for new names

• semantics and values for the kind field

Life Cycle Service

• Defines interfaces and conventions for creating, deleting, copying and moving objects

• Principle 1: object creation is an application issue, it is not possible to predetermine all the attributes and properties that must be passed to the object creation function

• Principle 2: All other services, facilities, CORBA domains and applications should define lifecycle operations. Lifecycle service provides the conceptual basis for how all other lifecycle capabilities should be configured

Life Cycle Service

• Key concept: Object Factory

– An object whose purpose is to create other objects, each factory is limited to creating a small set of object types

– An factory is generally not created by other factories, and has a long life so that it can manage the lifecycle of other objects

– Factories should be well-known in other services, e.g. Naming and Trader

– Support lifecycle in distributed environment, and should be language and location transparent

Life Cycle Service

• Introduces the notion that all distributed objects have an abstract location, whose meaning is defined by implementation and installation, usually means a particular processor or set of processors

• At abstract locations, the Lifecycle service define factory finder objects, which maintain a directory of factories at the same location

• By doing object creation with respect to the abstract location of a factory, Life cycle service is an enabling mechanism for managing object location

• Lifecycle interface definition (Fig. 4.13)

Lifecycle Service

• Factory objects for object creation

– determine object location

– assemble resources (memory, permanent storage, system dependent resources, etc) that new object needs

– register with BOA for an object reference and pointer to permanent storage

– create object using resources just located

– signal BOA that the new object is ready for activation

– return object reference

– register the object with Naming or Trading service

Other System Management Services

• Licensing service - provides general-purpose interface for flexible protection of intellectual property. In current applications, licensing is used for control of the allocation of software licenses

• Trader service - provides a registry of all the publicly known services and query service to these services with various service characteristics and qualities through special interfaces

– Fundamental to dynamic and adaptive systems

– Based on ISO ODP Trader protocols

Infrastructure CORBAservices

• Security and time services– Security cannot be thought of as a completely independent service, and

must interact directly with ORB to be effective

– Functions of security service: access control, auditing, authentication, and policy implementation

– Time service supports the retrieval and synchronization of clocks in a distributed system

• Messaging service– Intend to address many important areas of asynchronous processing based

ORB

– IDL interfaces have a synchronous semantics by default

– Provides asynchronous invocation semantics to ordinary IDL operations

– Extend CORBA technology to cover the functionality addressed by MOM

Overview of CORBAdomains and CORBAfacilities

• CORBAdomains address interoperability within vertical-market areas, e.g. healthcare, manufacturing, telecom, financial services, etc.

• CORBAservices address interoperability across vertical markets by providing a set of common facilities, e.g. compound documents and system management facilities, needed by multiple domains

• Higher-level than CORBAservices, but boundary not clear cut

• CORBAservices focus on enabling capabilities, CORBAfacilities and CORBAdomains focus on interoperability issues

• More detailed view of OMA (Fig 5.3)

• Relationship between different pieces (Fig. 5.4)

Horizontal CORBAfacilities

• Distributed Document Component Facility (DDCF) – for transparent manipulation of compound documents in distributed

environment

– Based on OpenDoc specifications

• Common Management Facilities– based on submission from X/Open consortium

– System management automates the handling of computer support services across a distributed enterprise, e.g. remote update & installation, monitoring and maintenance of security policies, etc

Horizontal CORBAfacilities

• Internationalization and Time Operations Facilities– Former supports multinational data types including output formats and

conversions among formats

– Latter defines similar capabilities on time objects and conversions

– E.g. character classification, date/time formats, numeric formatting, monetary formatting, etc.

• Data Interchange Facility– Interpretation, conversion and exchange among different data formats