Le traitement réparti ouvert Modèle de référence Open

Le traitement réparti ouvert: Modèle de référence Open Distributed Processing: Reference Model By Kazi Farooqui and Luigi Logrippo 1

RM-ODP: Guided Tour of RM-ODP. ……. . 1. Background. 2. Standardisation History. 3. A Generic Architecture. 4. Document Structure. 5. Component Based Engineering. 6. Distributed Object Technology. 7. Framework of Viewpoints. 8. Enterprise Model. 9. Information Model. 10. Computational Model. 11. Engineering Model. 12. Technology Model. 13. ODP Functions. 14. Comparison of Viewpoints. 15. System Design Process -1. 16. System Design Process -2. 17. System Design Process -3. 18. System Design Process -4. 19. Conformance. 20. Current standardisation Status. 21. Vision. 22. User Benefits. 23. Related Standards. 2

1. RM-ODP: Background Existence of Frameworks For Application “INTERCONNECTION” = TCP/IP, OSI, etc. = Ability to Interconnect Computer Systems. the Problem of Organizing Application Components that run on Still Networked-Computers. - which objects provides the services I need - where is the service I need - how do I obtain (interact with) the service - how do I organize (configure) services to work as a single integrated distributed application. - what support (distributed platform) is available for distributed system components to interact and execute. 3

1. RM-ODP: Background Need to express Distributed Application Component “INTERACTION” Issues within a Common Model. & “OPENNESS” is required in all aspects of distributed computing: - Application Programming Interfaces - Man Machine Interface ODP = An Object-Oriented Framework to express (“application-interaction” + “distributed platform” services) 4

2. RM-ODP: standardisation History Work on the Reference Model of ODP started within ISO: 1987. Parallel work initiated within ITU-T (former CCITT) on “DISTRIBUTED APPLICATIONS FRAMEWORK (DAF)” with a similar scope. RM-ODP: In 1991, Joint standardisation Initiative of ISO and ITU-T being developed under ISO/IEC/JTC 1/SC 21/WG 7. to develop A Standardised Logical Architecture for the design of OBJECT-BASED DISTRIBUTED COMPUTING SYSTEMS Spanning Heterogeneous Environments. 5

Continuation jusqu’à aujourd’hui • L’activité de normalisation continue jusqu’à ces jours dans l’ISO et ITU • Ces sujets d’étude furent aussi assumés par l’Object Management Group OMG www. omg. org – Un groupe industriel dédié à la définition de normes pour interopérabilité des applications – Orientation objet • L’OMG avait déjà produit la norme CORBA: Common Object Request Broker Architecture qui fut ensuite influencée par RM-ODP 6

Other related developments • TINA: Telecommunications Information Networking Architecture – Une architecture télécom basée sur les concepts de ODP. • Parlay: multi-vendor consortium formed to develop open, technology-independent application programming interfaces (APIs) that enable the development of applications that operate across multiple, networkingplatform environments 7

3. RM-ODP: A Generic Architecture RM-ODP: “GENERIC ARCHITECTURAL FRAMEWORK” for the integrated support of: - Multi-vendor - Multi-domain - Heterogeneous - Networked-Computing. Heterogeneity includes: - equipment heterogeneity, - operating system heterogeneity, - computational (programming or database) language heterogeneity, - authority heterogeneity (interaction between autonomous ownership domains). 8

3. RM-ODP: A Generic Architecture RM-ODP: A “META-STANDARD” to coordinate and guide the development of “Application-Specific ODP Standards” in different application domains such as: - Telecommunications TINA: an Intelligent Network Architecture based on ODP. Parlay: a set of standardized APIs for telecom services - Network Management (ODMA: Open Distributed Management Architecture) - Office Systems. - Management Information Systems. 9

Figure 1. Inheriting and Specializing ODP Architecture RM-ODP (Generic Concepts, Functions, and Architectural Principles) Domain-Specific Specialisation Domain-Specific ODP Architecture RM-ODP: An “Architectural Document” and not “Design Document” RM-ODP: A Framework within which different “Distributed Computing Environments” can be realised. RM-ODP: A set of Concepts, Rules, and Recipes for different aspects of the system. 10

4. RM-ODP: Structure RM-ODP is a Four-Part Standard: 1. ISO 10746 -1/ ITU-T X. 901 PART-1 OVERVIEW and USER GUIDE: - motivational overview of ODP. - scope of ODP and explanation of key definitions. 2. ISO 10746 -2/ ITU-T X. 902 PART-2 DESCRIPTIVE MODEL: - definition of concepts and relationships capable of specifying open distributed systems. - a vocabulary of ODP concepts used in PART-3 11

4. RM-ODP: Structure RM-ODP is a Four-Part Standard (Cont’d): 3. ISO 10746 -3/ ITU-T X. 903 PART-3 PRESCRIPTIVE MODEL: - description of “ODP Framework of Viewpoints” for the specification of ODP Systems. - specification of characteristics that are required for open distributed systems expressed as concepts, structures, rules, and functions (building blocks) in each “Viewpoint-Specification” 4. ISO 10746 -4/ ITU-T X. 904 PART-4 ARCHITECTURAL SEMANTICS: - modeling the architectural concepts of PART-2 and viewpoint languages of PART-3 using Formal Description Techniques to allow uniform interpretation. 12

5. RM-ODP: Component-Based Engineering Emphasis of ODP is on: - COMPONENTS: Components of Distributed Systems. - INTERFACES: Specification of Component Interfaces - INTERACTION: Application-level communication between distributed components at their interfaces. - PORTABILITY: Availability of standardized distributed platforms. - TRANSPARENCY: Masking distribution details from applications - TRADING: Trading of Services based upon Interface Specifications. - BINDING: Based upon Type Checking. - MULTIMEDIA: Voice, Video, and Data Applications are modelled in a consistent framework. RM-ODP: A Model for the Development of Complex Distributed Systems. vs. A specific protocol or communications architecture (TCP/IP, OSI…) 13

6. RM-ODP: Distributed Object Technology ODP Architecture is based on Object-Oriented Paradigm: 1. OBJECTS as units of DISTRIBUTION and MANAGEMENT. 2. OBJECTS can have multiple INTERFACES. 3. INTERFACES are points of provision and use of SERVICE. 4. INTERFACES are TYPES, BINDING is dynamic and TYPE-CHECKED. ODP Architecture…. . - a “big picture” of “object-oriented distributed systems”. - based on a “distributed object model”. - encourages object-oriented methodology in the design and development of distributed systems. - object-oriented basis of “viewpoint specifications”. - interaction via interfaces: service-oriented approach. - generic notions of templates, types, classes, instantiation, composition, and inheritance. - emphasis on type-checked late binding. - promotes “client-server” architecture. 14

6. RM-ODP: Distributed Object Technology Object-Technology simplifies distributed systems design - objects are good for dealing with complexity. - objects with multiple interfaces: a fundamental notion of distributed systems (strong concept of boundary). - three keys to object-orientation (encapsulation, polymorphism and inheritance): well geared to distributed systems. - promotes “plug-n-playing” with components. 15

www. lcc. uma. es/~av/Publicaciones/04/EDOC 2004. ppt ODP Viewpoints Enterprise Information ODP System Technology Computation Engineering 16

7. RM-ODP: Framework of Viewpoints enterprise information computation engineering technology SYSTEM 17

7. RM-ODP: Framework of Viewpoints Distributed System Specification: A ‘monolithic specification” of the System would be: - Quite Large and Unmanageable. - Difficult to Analyze and Design. - Difficult to separate concerns and assign development roles. - Quite contrary to Software Engineering Principles. Introducing VIEWPOINTS…. (Divide and Conquer) - To deal with full complexity of the system. - Structure system specification by separating concerns. - Different Players are involved in distributed system design and development each with separate concerns. - Viewpoints are specification concepts, not design concepts - Although they have specification implications 18

7. RM-ODP: Framework of Viewpoints WHY VIEWPOINTS (Cont’d) - For any information processing system there are different “roles” that have an interest in the same system. Each has a different view on the same system: 1. Members of the enterprise who use the system (Enterprise), 2. Architects that design the system (Information and Computation), 3. Programmers that implement the system (Engineering), 4. Technicians that install the system (Technology). - Each “role” sees different issues, have different requirements, and use different vocabularies (languages) when describing the system. 19

7. RM-ODP: Framework of Viewpoints What is a VIEWPOINT: - Representation of a system with emphasis on a specific (set of ) concern(s). - “Projection” of particular aspects of the system. - Corresponds to a Particular Abstraction of the System which emphasizes certain aspects and ignores others - Based on experience in system design. - All the viewpoints on a system completely describe different facets of the system. 20

7. RM-ODP: Framework of Viewpoints ODP Framework of Viewpoints: Five VIEWPOINTS as necessary and sufficient projections on the system: 1. ENTERPRISE VIEWPOINT: Purpose, Scope and Policies of the system. 2. INFORMATION VIEWPOINT: Kinds of information handled by the system and constraints on the use and interpretation of that information 3. COMPUTATION VIEWPOINT: Functional decomposition of the system into objects suitable for distribution. Identification of interfaces of objects and interactions between their interfaces. 4. ENGINEERING VIEWPOINT: The infrastructure required to support distribution. 5. TECHNOLOGY VIEWPOINT: The technology artefacts (software and hardware) required to realize system components identified in the other viewpoint specifications. 21

7. RM-ODP: Framework of Viewpoints ODP VIEWPOINTS. …. - are NOT architectural layers. - NO specific ordering is implied between viewpoints. - one viewpoint is NOT necessarliy an abstraction of another. All of them are abstractions or projections on the same system. - meant to become practical design tools and NOT merely as theoretical abstractions. - can be applied at all levels of granularity: system or its components. Figure 2. VIEWPOINTS: Different Projections on System. enterprise information computation engineering technology SYSTEM 22

7. RM-ODP: Framework of Viewpoints VIEWPOINTS…… - Cultivate a systematic design culture. - Facilitate automated design techniques. - Promotes the use of specialized languages and techniques that can better handle the concerns and tasks of that viewpoint. VIEWPOINTS LANGUAGE: - Each Viewpoint has an associated “Viewpoint Language”. - Viewpoint Language: A set of Concepts, Rules, and Recipes. Concepts: Vocabulary for the description of distributed systems. an Ontology to describe the relationship between the concepts Rules: Grammar for the composition of system specification from that viewpoint using its concepts. Recipes: Some useful and generic system configurations. - Viewpoint Specification (of a system): Uses the concepts of that viewpoint and satisfies the structuring rules of that viewpoint. (E. g. : Computational Specification is based on the concepts of computational object, computational interface, activity, operations, environment constraints, etc. and satisfies the structuring rules such as interface binding rules, 23 interface subtyping rules, invocation rules, portability rules, etc. )

7. RM-ODP: Framework of Viewpoints Technology Mapping of Viewpoint Language: Any existing language can be used for system specification from a viewpoint provided that formal syntax and semantics of the language can express the viewpoint concepts and rules. (Java, C++, Small. Talk, Most OO Languages): Computational Language, Engineering Language. (Z, GDMO, UML): Information Language. Architecture ODP = Concepts + Rules + Recipes = Set of Viewpoint Specifications. 24

8. RM-ODP: ENTERPRISE MODEL OVERALL OBJECTIVE OF DISTRIBUTED SYSTEM ENTERPRISE VIEWPOINT: - Source of Design Requirements. - Directed to the needs of the users of an information system. - what is the system required to do for the enterprise. ENTERPRISE: USERS (People) and RESOURCES (Information System) with BOUNDARY. - Spans single or multiple organizations or part of it. 25

8. RM-ODP: ENTERPRISE MODEL OVERALL OBJECTIVE OF DISTRIBUTED SYSTEM ENTERPRISE MODEL ELEMENTS: Enterprise Model is defined in terms of: 1. Agents: active objects which perform actions (e. g. airlines managers, travel agents, customers). 2. Artefacts: passive objects which do not initiate action (passenger database, passenger tickets, et. ) 3. Communities: grouping of agents and artifacts (e. g. an airline company consists of managers, travel agents, passenger databases, etc. ) formed to meet an objective (contract). 4. Roles: of agents, artifacts, and communities, established for the purpose of achieving an objective, expressed in terms of policies (service provider, service, user, agent role, artifact role, etc. ) 26

8. RM-ODP: ENTERPRISE MODEL OVERALL OBJECTIVE OF DISTRIBUTED SYSTEM ENTERPRISE MODEL ELEMENTS (Cont’d) 5. Policies: (For example, objectives, security, management policies) expressed in terms of permission: what can be done (a vacant seat can be booked). prohibition: what cannot be done (a booked seat cannot be allotted to another passenger). obligations: what must be done (a seat shall be booked against a charge). object-oriented flavor to enterprise language. An These are generic enterprise model concepts. Domain-Specific enterprises may specialize these terms or add new terms resulting in a “domain-specific-enterprise model”, such as a “Telecom-Enterprise Model”. 27

8. RM-ODP: ENTERPRISE MODEL OVERALL OBJECTIVE OF DISTRIBUTED SYSTEM enterprise specification is composed of the combination of the following The statements: ER 1: What is the purpose of the system (or its components) in the enterprise. ER 2: What is the scope of the system (or its components) in the enterprise. ER 3: What is the role of the system (or its components) in the enterprise. ER 4: What policies are applicable to the system (or its components) in the enterprise. ER 5: Who uses which information and for what purpose. ER 6: What are the distribution requirements of the sytem (or its components). (Where various types of processing can be done in the organization). ER 7: What are the interactions between the system and its environment. Enterprise requirements justify and impact system design. 28

Enterprise viewpoint language • Possiblement basé sur UML ? • Voici des docs intéressants: http: //www. iso. org/iso/home/store/catalogue_tc/catalogue_det ail. htm? csnumber=68642 (date: 2015) Ou recherche Google sur: ISO/IEC 15414: 2015 ODP X. 911 enterprise viewpoint language 29

9. RM-ODP: INFORMATION MODEL Information Elements, Semantics, Relationships, Flows INFORMATION VIEWPOINT: Focus on the “information content” of the enterprise. Identify: - information elements of the system. - processing that can be performed on information elements. - quality attributes of information elements. - relationship between information elements. - constraints on information manipulation. - information flows between sources and sinks in the system. - information semantics: the meaning that a human would ascribe to the information stored or exchanged between system components. Donc ce point de vue est surtout basé sur des concepts de bases de données 30

9. RM-ODP: INFORMATION MODEL Information Elements, Semantics, Relationships, Flows INFORMATION MODEL ELEMENTS 1. Schemas: state and structure of an information object. {reservation_db_status = [seats_booked, seats_available]} 2. Static Schema: state and structure of an information object at some point in time. {reservation_status_at_midnight = 250 booked-seats} 3. Invariant Schema: restricts the state and structure of information objects at all times (object behavior is constrained by invariant schema). {seats_booked_anyday = unbooked_seats - reserved seats} 4. Dynamic Schema: permitted changes in state and structure of an object subject to the constraints of an invariant schema. {seats_booked_today = 5; seats_booked = increases by 5; seats_available = decreases by 5}. 5. Relation: association between information objects. {record is-associated with a passenger in reservation database} 6. Integrity Rule: assertion about a schema {In an airline company, every passenger has a record in a reservation database, every record in a reservation database is owned by a passenger or an agent } 7. Information Object Template: Static Schema + Invariant Schema + Dynamic 31 Schema.

9. RM-ODP: INFORMATION MODEL Information Elements, Semantics, Relationships, Flows object-oriented flavor to information language. An Behavior of Information System = Transition from one static schema to another. Object’s behavior (an its state changes) are governed by its Invariant and Dynamic Schema. information specification is composed of the combination of following statements: The IN 1: What are the information objects of the system. IN 2: What are the quality attributes of the information objects of the system. IN 3: What manipulations/processing can be performed on the information objects of the system. IN 4: What are the rules and constraints for information manipulation. IN 5: What is the relationship between information objects. IN 6: What semantics a human would associate with the information stored in and exchanged between information objects. IN 7: What are the sources, sinks, and information flows in the system. 32

10. RM-ODP: COMPUTATIONAL MODEL Application structuring, Interaction, Programming COMPUTATIONAL VIEWPOINT: - Representation of distributed application as seen by application designers and programmers. - Functional analysis - Functional decomposition of system into components suitable for distribution. - Identification of interfaces of components. - Distribution-transparent interactions between the interfaces of the application components. - An abstract framework of a distributed programming model. - A Type Model (Interface Typing Rules). - An Interaction Model (Interaction Rules). - A Binding Model (Binding Rules). Global, end-to-end in nature: IN’s Global Functional Plane belongs here, SIBs belong here, no similar concepts have been encountered for Web services. . . 33

10. RM-ODP: COMPUTATIONAL MODEL ELEMENTS: The computational model defines concepts needed to describe distributed computation. 1. Computational Objects: Components of distributed application. Units of structure and distribution. Computational Object Template: a. Set of computational Interface Templates, b. Action template of initializing the state of new object. c. Environment Constraints applicable to the object. Computational Objects can perform following activities: a. create objects and interfaces. b. destroy objects and interfaces. c. trade for an interface. d. bind to an interface. e. read and write the state of the object. f. invoke (or accept) operations and information flows on other computational objects. 34

10. RM-ODP: COMPUTATIONAL MODEL Application structuring, Interaction, Programming Figure 5. ODP COMPUTATIONAL MODEL: An object world supported by distributed platform (engineering model). CO 2 CO 1 CO 3 CO 4 CO 5 CO 6 ODP DISTRIBUTED PLATFORM 35

10. RM-ODP: COMPUTATIONAL MODEL Application structuring, Interaction, Programming 2. Computational Interface: Units of provision of service. Computational objects may possess multiple interfaces. Figure 3. ODP Computational Model Concepts Computational Interface Template (Projection of partial object behavior) Computational Object __________________ Computational Interface Computational Object = Composition of Computational Interface Templates + Actions performed by object + Environment Constraints applicable to object. 36

10. RM-ODP: COMPUTATIONAL MODEL Application structuring, Interaction, Programming Two Types of Computational Interfaces: 1. Operational Interfaces (e. g. to information processing objects). 2. Stream Interfaces (e. g. , to multimedia and telecommunications objects). Interface specification: Contract between the Service User (Client) and Service Provider (Server) Object. This contract must include the following information: 1. The way in which the service is invoked (the operations, information flows, etc. ) 2. What naming conventions are used. 3. What properties are associated with the service (Quality of service, ownership, location). 4. In what order the operations (methods) of the service can be invoked). 37

10. RM-ODP: COMPUTATIONAL MODEL Application structuring, Interaction, Programming computational object is normally distributed, but is regarded as an entity A It could be an enterprise or a system within an enterprise For example, the airplane reservation system of Air Canada 38

10. RM-ODP: COMPUTATIONAL MODEL Application structuring, Interaction, Programming Figure 4. Computational Interface Template COMPUTATIONAL INTERFACE SIGNATURE (Operation Typing + Computational Behavior) + ENVIRONMENT CONSTRAINTS on: 1. Computational Interface (or its object) 2. Operations Invocations 1. Assertions from Enterprise Viewpoint 2. Assertions from Information Viewpoint 3. Assertions from Engineering Viewpoint 4. Assertions from Technology Viewpoint + ROLE 39

10. RM-ODP: COMPUTATIONAL MODEL Application structuring, Interaction, Programming Environment Constraint: 1. Distribution transparency requirements on operation invocation. 2. Quality of service attributes associated with operations/stream flows (throughput, delay, jitter, etc. ). 3. Temporal constraints on operations (e. g. deadlines). 4. Dependability constraints (e. g. , availability, reliability, security, fault-tolerance, etc. ). 5. Location constraints on objects. Role: Client, Server or Producer, Consumer. Types of Operations: Two 1. Interrogations: Request-Response Style (RPC). 2. Announcements: Request-Only Style. 40

10. RM-ODP: COMPUTATIONAL MODEL Application structuring, Interaction, Programming Computational Activity: - Activity is the agency through which computations make progress. - Unit of concurrency of computational object. - Multiple activities within a computational object. - Activities pass from one object to other when an operation (interrogation) is invoked. - Activities may split into parallel subactivities and later recombine. Binding Object: - To cater for special “multi-party” binding requirements (e. g. , distributed cooperative working environment). - May express configuration and quality of service controls on the multiparty binding. 41

10. RM-ODP: COMPUTATIONAL MODEL Application structuring, Interaction, Programming An object-oriented flavor to computational language. Computational modeling of a distributed application consists of structuring the application into computational objects, identification and specification of computational interfaces, identification of application-level communication between computational interfaces called computational interactions, and the association of environment constraints with objects, interfaces, and interactions. 42

10. RM-ODP: COMPUTATIONAL MODEL Application structuring, Interaction, Programming The computational modeling activity consists of the fllowing concerns: CO 1: What are the computational objects of the system. CO 2: What activities occur within the computational objects of the system. CO 3: What are the interfaces of computational objects of the system. CO 4: What operations can be invoked to/from the computational interfaces. CO 5: What behavior is observable at the computational interfaces. CO 6: What is the role of the computational interface. CO 7: What environment constraints are associated with the computational objects and their interfaces. CO 8: What interactions are possible between computational objects (interfaces). Computational Model = An “Object World” populated with concurrent computational objects interacting with each other in a distribution-transparent manner by invoking operations (or information flows) at their interfaces. It hides the details of the underlying abstract machine (engineering model) that supports it. Engineering Model = Animates the computational Model. 43

10. RM-ODP: COMPUTATIONAL MODEL Application structuring, Interaction, Programming Figure 5. ODP COMPUTATIONAL MODEL: An object world supported by distributed platform (engineering model). Noter la similarité avec le Platform Independent Model du Chapitre 9 CO 2 CO 1 CO 3 CO 4 CO 5 CO 6 ODP DISTRIBUTED PLATFORM 44

10. RM-ODP: COMPUTATIONAL MODEL A Programming Model of Distributed Computation HIGHLIGHTS: 1. Distributed Object Model. 2. Distributed Applications Programming. 3. Programming Concepts and Structures. 4. Distribution-Transparent Interaction Model. 5. Strong Typing Model supporting Late Binding Computational Model offers (embodies) facilities required of a “distributed programming environment”: 1. Remote Interactions + 2. Concurrent Access + 3. Heterogeneous Environments + 4. Mobile Objects + 5. Multiple Copies of Objects + 6. Asynchronous Events + 7. No Global Memory + 8. Partial Failures + 9. Late Binding + Multi-Party Binding = Abstract Distributed Programming Environment 45

10. RM-ODP: COMPUTATIONAL MODEL A Programming Model of Distributed Computational language abstracts over a wide choice of implementation mechanisms (i. e. , programming languages). Interface Typing Model INTERFACE TYPE CHECKING: “no-surprise” principle INTERFACE SUBTYPING = One interface to be substituted by other. Server must support at least the operations required by client. Clients must accept all possible terminations from the server. NO-SURPRISE Rule: Permits Servers to evolve without having to change clients. Minimum: Subtyping based on operation signature compatibility. Extensions: Behavior compatibility and environment constraint compatibility. 46

10. RM-ODP: COMPUTATIONAL MODEL Interface Typing Model Figure 6. Typing Model: Interactions Based on Interface Matching CO 1 CO 2 CO 3 47

10. RM-ODP: COMPUTATIONAL MODEL Interface Subtyping Example Figure 7. Interface Subtyping Travel Agent make_reservation (); cancel_reservation (); subtyping make_reservation (); cancel_flight (); Airlines Manager make_reservation (); cancel_reservation (); add_flight (); delete_flight (); Company Director Airlines Manager or a Company Director Interface can substitute for a Travel An Agent Interface. 48

Trader Concept Part of the Computational Model (Broker in CORBA, directory services, Kijiji, yellow pages …) Trader 1 2 Client 1. 2. 3. 4. 5. 3 4 Server advertises capabilities with Trader (interface type info) Client looks for specific capabilities (trader providing interface of specific type), asks trader Trader informs client of available server 2 and 3 could be repeated until Client has found a satisfactory match Client binds with server 49

11. RM-ODP: ENGINEERING MODEL Distribution Support Platform ENGINEERING VIEWPOINT: - System-Support for distributed applications. - Structures and mechanisms which enable and regulate distribution. - Infrastructure objects and their configurations required to support distributed applications and their interactions (specified in the computational model). - Infrastructure Objects: Distribution Transparency support mechanisms, communication mechanisms, etc. - Machine-independent execution and interaction-support environment for distributed applications. - A Model of an “Object-Based Distributed Platform”. - A Model of an extended “Operating System of Networked-Computers”. - Animates the Computational Model: how an application specified in the computational model, can be engineered onto the distributed platform. Distributed in nature 50

11. RM-ODP: ENGINEERING MODEL ODP Engineering Model consists of a set of interconnected autonomous computer systems, called nodes which supports a nucleus object and multiple capsules. The nucleus encapsulates computing, storage, and communication resources of a node which are shared by the objects in the node. A capsule consists of multiple clusters of basic engineering objects which are engineering (run time) representations of the computational objects. The basic engineering objects between two nodes communicate through channels. A channel is a configuration of stubs, binders, and protocol objects. The channel supports inter-object communication and corresponds to a binding between two computational interfaces. 51

Figure 8. ODP ENGINEERING MODEL T Transparency Object CAPSULE B Cluster B B Channel Node Cluster B B B T 1 CHANNEL Capsule Cluster B NODE-1 Cluster T 2 T 3 P 1 P 3 CHANNEL BEO P Protocol Object CHANNEL B P 2 NUCLEUS NODE-2 NUCLEUS TRANSPORT NETWORK 52

11. RM-ODP: ENGINEERING MODEL Table 1: System Abstractions in Engineering Model 53

11. RM-ODP: ENGINEERING MODEL DISTRIBUTION TRANSPARENCIES Distribution Transparencies: They hide distribution-related details from the application programmer/designer. Selective Transparencies: The ODP application designer/programmer can select the level of transparency needed in the design and have control over aspects of distribution by turning off some transparencies. Table 2: ODP Distribution Transparencies 54

Table 2: ODP Distribution Transparencies (Cont’d) Transparency Central Issue Result of Transparency Location of object in the distributed system Clients are unaware of the physical location of the server. Migration Dynamic re-location of objects during the “bind-session”. Clients are unaware of the dynamic migration of the server. Replication Resource Failure Multiple invocations on replicated Client invokes a replicated server objects, multiple responses, and group as if it were a single server. consistency of replicated data. Distribution of requests, collation of responses, consistency of data, and membership changes are hidden. Resource management policies of Client unaware of the node (deactivation and reactivation of objects). the server. Partial failure of object in the node. Client unaware of the failure of the server and its subsequent reactivation (possibly at another node). 55

Table 2: ODP Distribution Transparencies (Cont’d) ACID: Atomicity, Consistency, Isolation, Durability 56

Transaction transparency: ACID properties Implements the basic properties of a database transaction in a distributed env’t: • Atomicity - The entire sequence of actions must be either completed or aborted. The transaction cannot be partially successful. • Consistency - The transaction takes the resources from one consistent state to another • Isolation - A transaction's effect is not visible to other transactions until the transaction is committed • Durability - Changes made by the committed transaction are permanent and must survive system failure. The ACID properties of a DBMS allow safe sharing of data. Imagine more than one person trying to reserve a seat on a flight. Enforcement of the ACID properties allows the safe performance of such transactions. 57

11. RM-ODP: ENGINEERING MODEL Stub objects involve application semantics and add further interactions and/or information to the interactions between basic engineering objects to support distribution transparency Example: access transparency: converting between different representations Binder objects control and maintain the binding between distributed basic engineering objects (in case they are relocated, reactivated or replicated at a different node) contributing to the provision of distribution transparencies. They transport information between BEO. Example: migration transparency: two objects may wish to remain connected in spite of migration. The binder will find the new location, reestablish the link and possibly resend lost information. Protocol objects interact with other protocol objects in the channel to provide communication between basic engineering objects. 58

Figure 9. Simplified Generic Channel Structure BEO Configuration of Transparency Stubs Stub Supporting Objects Configuration of Transparency Stubs Configuration of Transparency Binders Binder Supporting Objects Configuration of Transparency Binders TRANSPARENCY SYSTEM Configuration of Protocol Objects Interceptor CHANNEL 59

Engineering Mechanization of Computational Model Figure 11. Engineering Model Animates Computational Model. Interface Template CO Interface Template Binding Based on Interface Type Checking C S CO ODP-Based Programming Model: Objects and Distribution are Orthogonal Concepts. Engineering Based on Requirements & Constraints in Interface Templates EO BEO C EO EO S BEO EO ODP-Based Distributed Platform Model Legend: CO: Computational Object (Program Object) BEO: Engineering representation of CO EO: Engineering (Distribution-Support) Objects C: Client Interface S: Server Interface 60

Correspondence between Basic Engineering Objects and Computational Objects A CO can also be decomposed as a whole network of BEOs communicating through channels BEOs CO 61

Table 3. Relationship between Computational and Engineering Model 62

Figure 12. Service Machine: Customization of Engineering Model using Components. TELECOM SERVICE Telecom Service Basic Engineering Objects D D D T T T P P P N N N Service Machine Communication Platform N NODE-1 Domain-Specific Distribution Support Components Generic Distribution Support Components (Transparency Objects) Communication Support Components Transport Network Access D D D T T T P P P N NODE-2 TRANSPORT NETWORK N 63

12. RM-ODP: TECHNOLOGY MODEL Technical artifacts to support system components Technology Viewpoint: - A Source of Design Constraint. - Technical Implementation of the ODP System. - Choice of technology artefacts (hardware and software) required for the realization of distributed system components (identified in the information, computational and engineering models). - Specify reference points (interfaces in the engineering and computational models) as conformance points. Example: - Communication Protocols: Protocol stack such as IP or OSI. - Internode communication: Protocols. - Node: Machines running Linux - Java Beans, Enterprise Java Beans 64

13. RM-ODP: ODP FUNCTIONS: Functions that are fundamental and widely applicable to the ODP construction of ODP Systems: 1. Management Functions: - Object Management: Objects manage themselves on advice of cluster managers. - Cluster Management: deactivate, checkpoint, recover, migrate, replicate, terminate. - Capsule Management: cluster instantiation, reactivation, termination. - Node Management: Threads, binding (channel creation), capsule creation. 2. Coordination Functions: - Event Notification: notification of significant events from event producers to consumers. - Group: distributed cooperative computation defined by policies such as distribution, collation, ordering, membership, etc. - Replication: consistency of replicated data. - Migration: migration of object. - Transaction: coordination of activities to achieve transactional properties (e. g. ACIDity). 65

13. RM-ODP: ODP FUNCTIONS (Cont’d): ODP 3. Repository Functions: - Storage: data repository, deactivated cluster repository, etc. - Relocation: directory of locations of interfaces that have been relocated. - Type Repository: repository of types and their relationships. - Trading: advertisement and discovery of interfaces (services) 4. Security Function 66

14. RM-ODP: COMPARISON OF VIEWPOINTS 67

15. RM-ODP: VIEWPOINTS IN SYSTEM DESIGN PROCESS-1 System Design: - Design process may be subdivided into phases related to different viewpoints. - Each viewpoints is used as a problem analysis technique as well as solution space of the relevant issues of the problem domain. - Some Viewpoint(s) play a predominant role (than others) in particular phases of system design. - Particular viewpoint specification(s) capture much detail of certain phase of design trajectory (than others). - System specification in some viewpoints is based on requirements expressed in other viewpoint(s). 68

16. RM-ODP: VIEWPOINTS IN SYSTEM DESIGN PROCESS-2 Figure 14. ODP Viewpoints: Source of Design Requirements and Constraints Information Model Enterprise Model Computational Model Engineering Model Source of Requirements and Constraints Technology Model Design Template 69

17. RM-ODP: VIEWPOINTS IN SYSTEM DESIGN PROCESS-3 Recursive Use of Viewpoints in System Design 1. Viewpoint: Used as a design analysis tool - For identification and refinement of a composite system into its constituent components and - For the application of viewpoint-specific analysis to the constituent components. to - Obtain a complete design of the system consistent from all viewpoints. 70

17. RM-ODP: VIEWPOINTS IN SYSTEM DESIGN PROCESS-3 Recursive Use of Viewpoints in System Design (Cont’d): 2. Objects identified in a given viewpoint may be specified recursively from different other viewpoints to assure a consistent design. For example, engineering objects (which constitute the distribution support environment) can be specified using: a. Enterprise Viewpoint (Objectives) b. Information Viewpoint (Information Flow, source, sinks for that part of the system). c. Computational Viewpoint (Computational activities, interfaces, and interactions associated with the objects in that part of the system). d. Engineering Viewpoint (Supporting objects, if any, required for complete realization of the objects). e. Technology Viewpoint (what technical objects to be used for the realization of the system part). 71

SYSTEM under design Is the System objective 1. Purpose, 2. Scope, 3. Role, 4. Policies, 5. Obligations completely specified. No Enterprise modeling Is the identification of: 1. Information objects (IO) 2. Manipulation of IO, 3. Rules for manipulation of IO. 4. Semantics of IO. 5. Information flows completely specified. No Information modeling Viewpoint Selection (Designer Driven) Is the functional Is the decomposition into: infrastructure 1. Computational objects, required to support 2. Computational (distribution) of Interfaces, system or its 3. Environment components Constraints, completely 4. Interactions specified. completely specified. No Computational modeling Is the technology artifacts for the system (component) identified. No Engineering modeling No Technology modeling Viewpoint modeling using viewpoint specific concepts, structure, and rules. Choose the system, or Yes component, or the composition of components No that need further viewpoint No analysis. Was there any decomposition of the system during this iteration. No Is the system (and its components) completely and consistently specified from all viewpoints. Yes Can the system (and its components) mapped onto to real resources. Yes DONE 72

Viewpoint consistency: a major open problem • How do we know, how do we find out whether – all five viewpoint specs for a given system are mutually coherent – specify the same system 73

18. RM-ODP: VIEWPOINTS IN SYSTEM DESIGN PROCESS-4 Figure 16. Yet Another Organization Enterprise Model Information Model Computational Model Engineering Model Requirement Domain Bridge Gap Solution Domain 74

21. RM-ODP: VISION Object-Based Distributed Systems Architecture standard to guide the development An of domain-specific distributed systems that: - maximizes software portability, interoperability, and reusability. - enables seamless integration of disparate (old and new) applications over multiple dissimilar platforms to solve business problems. FEDERATED INFORMATION SYSTEMS: To bridge TECHNOLOGICAL and ADMINISTRATIVE boundaries between System components respecting ownership and security requirements. (This is essential because real-world enterprises are “federation” of autonomous domains, and therefore information systems should be bridged over technological and administrative boundaries). 75

22. RM-ODP: USER BENEFITS Object-Orientation: - Software Reuse. - No problem of legacy systems. - Controlled System Evolution. - Software Components Market. Interfaces are Standardized: - Maximum choice from multiple vendors. - Lower software cost. - Optimal component integration. Flexible Component Configuration: - Late and Dynamic Binding. - Plug-n-Play with Components based upon interface type-matching. Selective Distribution Transparency: - Distribution transparency under the control of the programmer. Common Reference Model: - Application Portability - System Interoperability. 76

23. RM-ODP: RELATED STANDARDS OMG’s CORBA: Influenced by ODP. (Technology Model of ODP). OSF’s DCE: Influenced by ODP. (Technology Model of ODP). ANSAware: Conforms to Subset of ODP. (Technology Model of ODP). Telecoms TINA: Telecom-Domain Specialization of ODP. Parlay: influenced by ODP ODMA: NM’s Open Distributed Management Architecture. UML and MDA: shares numerous concepts with ODP, is used in the development of ODP concepts OASIS standards (related to XML) OMG: Object Management Group OSF: Open Standards Foundation DCE: Distributed Computing Environmen ANSA: American National Standards Association ODMA: Open Document Management API 77. . .