Server-Side Components

1
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

2
Object Implementation Structure

• Objects are not always active and running -
  requires transparent activation/deactivation
• Maintaining, saving and restoring object state,
  checkpointing
• No mandatory enforcement

3
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

4
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.

5
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

6
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 objects 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

7
OMGs 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

8
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

9
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.

10
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

11
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

12
Event Service

• Defines generic interfaces for passing
  information among multiple sources and consumers
• Sources and consumers dont 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

13
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

14
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)

15
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

16
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

17
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

18
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

19
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

20
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)

21
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

22
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

23
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

24
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)

25
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

26
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