“Open distributed processing and multimedia” Blair & Stefani

1. “Open distributed processing and multimedia”Blair & Stefani Chapter 2 presented by Andrea Gruber Standards and platforms for open distributed processing

2. Standardization attempts: • Reference Model for Open Distributed Processing (RM-ODP)  ISO • Common Object Request Broker Architecture (CORBA)  Object Management Group • Distributed Computing Environment (DCE)  Open Group • More: TINA and IMA’s Multimedia System Services de jure standard de facto standard

3. ISO RM-ODP • Framework that enables the development of standards • Does not prescribe a standard • Meta-standards for open distributed processing: sufficiently generic to achieve 1)

4. Basic characteristics of RM-ODP: • Object-oriented approach for the specification of distributed systems • Viewpoints concept (5 VP) • Distribution transparency • Functions

5. Object-oriented approach for the specification of distributed systems Arguments in favour • Encapsulation: natural approach for distributed applications • Data abstraction: separate specification and implementation • Evolution: replacement of objects, the interface stays the same • Extensible: new classes and objects can be added at any time • Implementation and interface inheritance: reuse of code • Subtyping: flexibility in selecting services

6. Object-oriented approach for the specification of distributed systems Drawbacks • There must be some, none reported! • Example: If a class is modified, all code depending on that class must be retested and potentially modified to support the changes

7. Major concepts in RM-ODP (1) Objects are accessed by one or more interfaces: • Original and important feature in RM-ODP • Behaviour of an object divided in separate services accessed by different interfaces Templates: • description of an object at a given level of abstraction (e.g. Class) • Deliberate general definition (enables a number of realization of the concept) Type (intention) and Class (extension): • Subtype and subclass hierarchies • Incremental inheritance: difficulties in resolving behaviour at run-time Composite objects: • configurations of interacting objects that offer a composite behaviour

8. Major concepts in RM-ODP (2) Problem in open distributed processing: • Wide scope and inherent complexity Attempt toward a (analytical) solution: • “Viewpoints concept”  partition a system specification into a number of different, complete and self-contained components 5 viewpoints: • Enterprise (contract specifications: agents, roles, communities) • Information (content  schemata: invariant, static, dynamic) • Computational (interaction of entitiesinterfacesbindings) • Engineering (infrastructure: channels, nodes, capsules, clusters) • Technology (particular hardware or software technologies) what is required how is achieved

9. RM-ODP: distribution transparency (1) “The programmer need not be aware of the distributed nature of the system” Sometimes is better if he/she is!  When concerned on real-time behaviour, mobile environments, etc. • RM-ODP implements selective transparency • The programmer can choose the level of transparency (Computational Model environment) • The Engineering Model is responsible for meeting the desired level of transparency

10. RM-ODP: distribution transparency (2) • Access  masks differences in access methods • Location  hides the physical location of an object • Failure  hides the occurrence of failure from other objects • Migration  hides moving of an object to another location • Relocation  handles the movement of an object “in use” • Replication  hides the redundancy of an object (consistency!) • Persistence  the state of an object survives a number of interactions (?) • Transaction  maintain consistency in spite of concurrent access and failure

11. RM-ODP: functions Functions are defined to support RM-ODP: • node management • capsule management • cluster management • security Trading functions (separate document ISO/IEC, 1997): • acts as a broker for services in the distributed environment • enables objects to make interfaces available by exporting a service offer to a trader Management in Engineering Viewpoint

12. RM-ODP conformance Conformance: • Relationship between specification and implementation. • The relationship holds when specifications are met by the implementation • RM-ODP provides a framework to enable such conformance to take place • Conformance points to test (each viewpoint!) • Viewpoints complicate the conformance

13. CORBA • Part of an initiative (by Object Management Group) to develop a comprehensive Object Management Architecture for object-oriented computing • OMA Standards: Request for Proposal in given areas • CORBA: provides mechanisms by which objects transparently make requests and receive responses • Object: an identifiable, incapsulated entity that provides one or more services that can be requested by a client

14. Object model in CORBA • Request for a service: • target object • operation name • parameters • optional request context • Interface inheritance: • derived interface from base interface • similar capability as multiple interfaces in RM-ODP: gives a single derived interface

15. Interfaces in CORBA Interface Definition Language: • IDL is a language-independent, declarative definition of an object’s interface (resembles C++ with distribution feat.) • one or more interface declarations • header • body • Operations carried out (by default) with at-most-once semantics  result is obtained from an operation executed exactly once.

16. CORBA Overall CORBA architecture: • Object Request Broker: logical “heart” of the architecture • Object Services: basic services to the platform • Common Facilities: higher level services, including management • Application Objects: objects developed by outside vendors

17. ORB (1) Object Request Broker • enables requests to be carried on in a heterogeneous distributed environment • implements location and access transparency • ORB Core: basic representations of objects, means of communicating • IDL Stubs: marshalling and unmarshalling results • IDL Skeletons: the same services at the receiving end of the request

18. ORB (2) Object Request Broker • Dynamic Invocation Interface: used when no appropriate stubs are accessible in dynamic communication (unknown type) • Object Adapter Interface: services like generation of object references, activations and deactivations of objects • Interface repository: manages collection of object definitions (which operations and what parameters) • Implementation repository: object implementation

19. Object Services • Naming Service: directory service (such X.500) • Event Service: register interest and get notification • Persistence Service: objects outlive the creating thread or process • Transaction Service: allows consistent updates • Relationship Service: allows links between CORBA objects • Externalization Service: record the state of an object on file  transfer on network  reconstruction of object • Life-cycle Management Service: creation, copying, moving, deletion of an object • Concurrency Control Service: enables multiple concurrent access to an object

20. CORBA conformance • CORBA 1.0  implementations required to offer the correct interface only (too weak!) • CORBA 2.0  Improve Interoperability: Interoperability Architecture • General Inter-ORB Protocol • Bridges: • allows ORBs in different domains to interact • mediated vs immediate • full bridges: direct translation between protocols • half-bridges are mediated bridges that agree on a protocol (more flexible, more performance overhead)

21. The Open Group’s DCE • The Distributed Computing Environment is a standardisation activity sponsored by the Open Group • The Open Group promote standards through: • Request for Technology (RFT) • Pre-structured Technology (PST)

22. DCE Architecture: • classical client-server architecture, not Object Oriented • sits between the operating system and the applications • data sharing services (distributed file system, diskless support device) • fundamental services (RPC, threads, time, naming, security...) • management services (DME from Open Group)

23. DCE services (1) The fundamental services: • Threads service (based on Digital Concert MTA): • creation and management of threads at the user level • different scheduling policies (FIFO, Round Robin, Time sliced) • RPC service (+ presentation service): • provides the means of inter-process communication in DCE (realizes access and location transparency) • IDL header  universal unique identifier (UUID from uuidgen) • IDL body  defines each operation on an interface • binding to an interface before invocations can proceed • automated (transparent), implicit (client selects server once) and explicit binding (client selects server each time)

24. DCE services (2) The fundamental services: • Time service • provides a system-wide measure of synchronised time (UTC) • interoperability by Network Time Protocol (accuracy 10ms) • time servers (local/LAN, global/WAN, courier, time provider) • Naming service • Allows servers to advertise services and clients to locate services in the global distributed environment  caching & clerks • Cell Directory Service: name space for local machines • Global Directory Service: name space between cells (Internet interoperability through DNS) • Example: /…/C=UK/O=LANCS/OU=COMP/users/gordon/file.ext • Security service (client+PACprivilege serverservice): • Enables secure access to servers in a DCE environment (Kerberos+DES)

25. DCE services (3) The data-sharing services: • Distributed file service • relies on the naming service • based on Andrew File System (AFS) and whole file caching • provides location and access transparency when accessing files over local and remote systems • uses Episode file server featuring logs on all ops on meta-data (for consistency after failure and restart) • Diskless support • is used to extend the distributed file service to diskless clients • based on BOOTP and TFTP • the diskless client features a cache manager

26. TINA • Telecommunication Information Networking Architecture • Based on CORBA • Provides a uniform platform for the execution of the different distributed applications • Frameworks for three major application classes: • Network (generic network architecture independent of network elements and connections) • Service (user agents, service sessions, access management…) • Management (consists of computing and telecommunication management)

27. IMA MSS • Multimedia System Services is an open distributed processing architecture specially designed to support multimedia • Based on CORBA • Virtual device • abstraction over a physical device (CD player, mic, speaker) • offer a stream interface • format interface (MPEG) • Virtual connection (parameters: media, connection, QoS, stream and sync type) • an object representing an abstract view of media transport from the output of one virtual device to the input port of another

28. Comparison and conclusion • RM-ODP is a meta-standard defining a framework to enable the emergence of more specific object-oriented technologies for open distributed processing • CORBA is a specific object-oriented technology providing interoperability of objects in a heterogeneous environment • DCE is a client-server architecture achieving integration between different services

29. Comparison and conclusion 4. TINA is a specialisation of RM-ODP for the field of telecommunications 5. MSS is a specialisation of CORBA addressing the lack of multimedia support in CORBA by defining a particular class hierarchy for multimedia devices and connections ALL COMPLEMENTARY INITIATIVES POTENTIAL for CONVERGENCE: CORBA interface on top of DCE services  towards RM-ODP