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

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

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

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