Post on 14-Jan-2016
description
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