Davide Rizzo

1
Open Distributed Processing

• Davide Rizzo

2
Summary

• Why ODP?
• What is ODP?
• Reference Model for ODP
• Consistency of Viewpoint Specifications

3
Why ODP?

• Open
• Distributed
• Processing

4
Characteristics of Distributed Sytems

• Remoteness components of a distributed system
  may be spread across space
• Concurrency any component of a distributed
  system can execute in parallel with any other
  components
• Lack of global state the global state of a
  distributed system cannot be precisely determined
• Partial failures any component of a distributed
  system may fail independently of any other
  components
• Asynchrony communication and processing
  activities are not driven by a single global clock

5
Characteristics of Open Distributed Sytems (ODS)

• Heterogeneity components built using different
  technologies and the set of various technologies
  will certainly change over time
• Autonomy several autonomous management or
  control authorities without any single control
• Evolution during its working life, many changes
  (caused by technical progress, strategic
  decisions about new goals, new types of
  applications)
• Mobility the sources of information, processing
  nodes, and services may be logically mobile

6
Problems relating Open Distributed Systems

• ODS are important because there is a need to
  interconnect information processing systems
• The organizational trends demands the exchange of
  information both inside the organization and
  between co-operating organizations
• The distribution of information processing
  services is realized in an environment of
  heterogeneous resources and multiple
  organizational domains

7
Integration among services and resources

8
A possible solution

• Capture the representation form of data, the
  transport protocol for that data, the location
  algorithm of a service provider etc.
• Common services by grouping together the
  properties of different services and gaining an
  agreement on these, the amount of heterogeneity
  in a distributed systems can be structured in a
  controllable way
• A framework for system specification is needed
  that supports such a structuring of the features
  of distributed systems into common services this
  is provided by ODP standardization

9
What is ODP?

• Is a standardization activity by ISO providing an
  object oriented reference model for open
  distributed system
• Its objective is to enable the construction of
  distributed systems in a multi-vendor environment
  through the provision of a general architectural
  framework that such systems must conform to
• Describes systems that support heterogeneous
  distributing processing both within and between
  organizations through the use of a common
  interaction model (Reference Model of ODP - 1995)

An architectural framework describes a method for
designing an information system in terms of a set
of building blocks, and for showing how the
building blocks fit together. It should provide a
common vocabulary
10
Properties of ODP systems

• ODP standardization enables the building of
  distributed systems with the following
  properties
• Openess
• Integration
• Flexibility
• Modularity
• Federation
• Manageability
• Provision of quality of service
• Security
• Transparency

• portability i.e., the ability to execute
  different components on different processing
  nodes without modification
• interworking i.e., the ability to support
  meaningful interactions between components,
  possibly residing in different systems

11
Properties of ODP systems

• ODP standardization enables the building of
  distributed systems with the following
  properties
• Openess
• Integration
• Flexibility
• Modularity
• Federation
• Manageability
• Provision of quality of service
• Security
• Transparency

• Incorporating various systems and resources into
  a whole without costly ad-hoc developments
• It covers, for example, integration of systems
  with different architectures, different resources
  of different performance.
• Helps to deal with heterogeneity.

12
Properties of ODP systems

• ODP standardization enables the building of
  distributed systems with the following
  properties
• Openess
• Integration
• Flexibility
• Modularity
• Federation
• Manageability
• Provision of quality of service
• Security
• Transparency

• Supporting a systems evolution, including the
  existence and continued operation of legacy
  systems
• An open distributed system should be capable of
  being dynamically reconfigured to accommodate
  changing circumstances.
• Helps to deal with mobility.

13
Properties of ODP systems

• ODP standardization enables the building of
  distributed systems with the following
  properties
• Openess
• Integration
• Flexibility
• Modularity
• Federation
• Manageability
• Provision of quality of service
• Security
• Transparency

• Parts of a system are autonomous, but
  interrelated
• It is the basis for flexibility

14
Properties of ODP systems

• ODP standardization enables the building of
  distributed systems with the following
  properties
• Openess
• Integration
• Flexibility
• Modularity
• Federation
• Manageability
• Provision of quality of service
• Security
• Transparency

• Combining systems from different administrative
  or technical domains to achieve a single objective

15
Properties of ODP systems

• ODP standardization enables the building of
  distributed systems with the following
  properties
• Openess
• Integration
• Flexibility
• Modularity
• Federation
• Manageability
• Provision of quality of service
• Security
• Transparency

• monitoring, controlling and managing systems
  resources in order to support configuration, QoS
  and accounting policies.

16
Properties of ODP systems

• ODP standardization enables the building of
  distributed systems with the following
  properties
• Openess
• Integration
• Flexibility
• Modularity
• Federation
• Manageability
• Provision of quality of service
• Security
• Transparency

• Meeting a set of quality requirements on the
  systems behaviour

17
Properties of ODP systems

• ODP standardization enables the building of
  distributed systems with the following
  properties
• Openess
• Integration
• Flexibility
• Modularity
• Federation
• Manageability
• Provision of quality of service
• Security
• Transparency

• Ensuring that system facilities and data are
  protected against unauthorised access.
• The security requirements are made more
  difficult to meet by the remoteness of
  interactions and the potential mobility of parts
  of the system and of the system users.

18
Properties of ODP systems

• ODP standardization enables the building of
  distributed systems with the following
  properties
• Openess
• Integration
• Flexibility
• Modularity
• Federation
• Manageability
• Provision of quality of service
• Security
• Transparency

• Masking from applications the details and the
  differences in mechanisms used to overcome
  problems caused by distribution.
• This is a central requirement that arises from
  the need to facilitate the construction of
  distributed applications.

19
Realization of ODP

• There cannot be an single, common infrastructure
  that provides all of the properties that
  distributed systems require
• There is also a need for a framework describing
  infrastructure components and showing how they
  fit together
• The development of a framework for system
  specification and the corresponding
  infrastructure components is the general goal of
  the ODP standardization

20
Principals Concepts of the ODP

• Transparencies determine how the end users see
  the system, or more precisely, what they dont
  see of the system
• Viewpoints a division of system specification in
  order to simplify the description of complex
  systems
• Functions mask the complexity of a distributed
  system both user and programmers and connect
  processes and services

Implement
Use
21
Transparencies general concepts

• The programmers and end users should not need to
  be concerned with the nature and means of
  distribution
• Programming and use of a distributed application
  appears exactly the same as if the application
  were not distributed at all
• Uniform view of a system for the end users
• Its ODPs abstraction mechanism
• Presents a view of what is happening, but hides
  the how it is happening

22
ODP Transparencies

• Are implemented by ODP functions
• The ODP transparencies are
• access transparency
• failure transparency
• location transparency
• migration transparency
• persistence transparency
• relocation transparency
• replication transparency
• transaction transparency

• Masks the differences between two or more
  communicating objects
• The differences could be in the data
  representation or in the invocation mechanism
  between the objects.
• Is provided by an ODP engineering channel

23
ODP Transparencies

• Are implemented by ODP functions
• The ODP transparencies are
• access transparency
• failure transparency
• location transparency
• migration transparency
• persistence transparency
• relocation transparency
• replication transparency
• transaction transparency

• Enables fault tolerance in an object or shields
  an object from failures in the objects
  environment.
• Can be implemented by several functions. One
  such function is the replication function wich
  replicates an object

24
ODP Transparencies

• Are implemented by ODP functions
• The ODP transparencies are
• access transparency
• failure transparency
• location transparency
• migration transparency
• persistence transparency
• relocation transparency
• replication transparency
• transaction transparency

• Masks the location of an object in space.
• Depends on chosing a location independent naming
  scheme.
• Enables the named entities to be moved, without
  notifying all parties who carry a reference to
  the entity of the changed reference

25
ODP Transparencies

• Are implemented by ODP functions
• The ODP transparencies are
• access transparency
• failure transparency
• location transparency
• migration transparency
• persistence transparency
• relocation transparency
• replication transparency
• transaction transparency

• Masks changes of location of an object
• Depends on the migration function
• Before migration, an object will be
  checkpointed, and deleted from its original
  location
• Once the object is moved, other objects depend
  on the relocation transparency to find the object
  again

26
ODP Transparencies

• Are implemented by ODP functions
• The ODP transparencies are
• access transparency
• failure transparency
• location transparency
• migration transparency
• persistence transparency
• relocation transparency
• replication transparency
• transaction transparency

• Mask from an object the deactivation an
  reactivation of objects including itself
• An object does not need to be concerned with
  loading an object from persistent store before
  using it
• Depends on the deactivation and reactivation
  function

27
ODP Transparencies

• Are implemented by ODP functions
• The ODP transparencies are
• access transparency
• failure transparency
• location transparency
• migration transparency
• persistence transparency
• relocation transparency
• replication transparency
• transaction transparency

• Masks the relocation of an object from other
  objects that are referring to it
• If objects are connected via a channel, and one
  object is relocated, the channel is reconfigured
  to the new location of the object
• Is provided by the relocation function

28
ODP Transparencies

• Are implemented by ODP functions
• The ODP transparencies are
• access transparency
• failure transparency
• location transparency
• migration transparency
• persistence transparency
• relocation transparency
• replication transparency
• transaction transparency

• Replicates objects in different locations to
  provide fault tolerance and enhanced performance
  by better access of data
• Is provided by the replication function

29
ODP Transparencies

• Are implemented by ODP functions
• The ODP transparencies are
• access transparency
• failure transparency
• location transparency
• migration transparency
• persistence transparency
• relocation transparency
• replication transparency
• transaction transparency

• masks the coordination between a set of objects
  required to achieve consistency properties of the
  objects
• Is provided by the transaction function

30
ODP Viewpoints

• Provide a framework for specifying ODP systems
• They are not of concern to end users (viewpoint
  have nothing to do with the end users view of a
  system transparencies provide this)
• Are not independent, but partial view of the
  complete system specification
• Distributed system are viewed to be so complex
  that a process of separation of concerns must be
  employed when describing such system (Divide and
  conquer)
• Multiple viewpoint enables different partecipants
  each to observe a system from a suitable
  prospective and a suitable level of abstraction

31
Viewpoints Languages

• Are associated with a viewpoint
• They may utilises a different notation, that is
  best suited for describing a particular area
• They consist of
• a set of definitions
• a set of rules, wich constrain the ways in wich
  the definition can be related

32
Development by viewpoints

• Embraces all techniques that involve adding more
  detail to the specification
• For example, by including more requirements or
  by resolving implementation choices

33
Development by viewpoints

• A specification in one viewpoint may need to be
  translated into a specification in another
  viewpoint.
• This is because each viewpoint may utilises a
  different notation or language, that is best
  suited for describing a particular area

34
Development by viewpoints

• Is a relation between specification at the same
  level of abstraction.
• Two specifications are equivalent in case they
  capture precisely same requirements

35
Development by viewpoints

• A collection of viewpoint specifications may be
  integrated into one specification
• Each viewpoint presents a partial description of
  the implementation
• The ultimate aim is to develop an implementation
  that satisfies all viewpoints

36
Development by viewpoints

• Is a relation between any number of
  specifications, not necessarily at the same level
  of abstraction
• Specifications are consistent with each other,
  whenever it is possible to find at least one
  implementation that satisfies them simultaneously

37
The RM-ODP framework
38
ODP Viewpoints

• enterprise viewpoint concerned with the business
  activities of the specified system
• information viewpoint concerned with the
  information that needs to be stored and processed
  in the system
• computational viewpoint concerned with the
  description of the system as a set of objects
  that interact at interfaces enabling system
  distribution
• engineering viewpoint concerned with the
  mechanism supporting system distribution
• technology viewpoint concerned with the
  components from which the distributed system is
  constructed

39
Enterprise viewpoint

• Is used to organisational requirements and
  structure.
• Social and organizational policies can be defined
  in terms of
• Objects
• active objects, e.g. bank managers, tellers,
  customers
• passiveobjects, e.g. bank accounts, money
  communities
• groupings of objects e.g. a bank branch consists
  of a bank manager, some tellers, and some bank
  accounts the branch provides banking services to
  a geographical area
• Roles of the objects within communities,
  expressed in terms of policies
• permission what can be done, e.g. money can be
  deposited into an open account
• prohibition what must not be done, e.g.
  customers must not withdraw more than 500 per
  day
• obligations what must be done, e.g. the bank
  manager must advise customers whenthe interest
  rate changes

40
Enterprise Language

• Is specifically concerned with performative
  actions that change policy, such as creating an
  obligation or revoking permission
• E.g.
• In a bank, the changing of interest rates is a
  performative action as it creates obligations on
  the bank manager to inform the customers
• However, obtaining an account balance is not a
  performative action as obligations, permissions,
  and prohibitions are not affected
• Thus, an enterprise specification of a bank need
  not include the obtaining of account balances
  such functionality will be identified in the
  computational specification

41
Information viewpoint

• Defines the semantics of information and
  semantics of processing on information in the
  system
• This is done using three schema
• invariant schema defines conditions that must
  always be true on a set of information (state of
  an object)
• static schema that defines conditions that will
  hold after certain events have occurred
• dynamic schema defines transformations (state
  changes) that can occur on the state of an object
  in the course of the normal processing, in
  contrast to a static schema, wich forces an
  object into certain schema

42
Information viewpoint - Example

• Static schema at midnight, the
  amount-withdrawn-today is 0
• Invariant schema the amount-withdrawn-today is
  less than or equal to 500
• Dynamic schema a withdrawal of X from an
  account decreases the balance by X and increases
  the amount-withdrawn-today by X
• A dynamic schema is always constrained by the
  invariant schemas
• Thus, 400 could be withdrawn in the morning but
  an additional 200 could not be withdrawn in the
  afternoon as the amount-withdrawn-today cannot
  exceed 500

43
Computational viewpoint

• Is used to specify the functionality of an ODP
  application in a distribution-transparent manner
• Is object-based, that is
• objects encapsulate data and processing (i.e.
  behaviour)
• objects offer interfaces for interaction with
  other objects
• objects can offer multiple interfaces
• Defines the objects within an ODP system, the
  activities within those objects, and the
  interactions that occur among objects
• Most objects describe application functionality,
  and these objects are linked by bindings through
  which interactions occur
• Binding objects are used to describe complex
  interaction between objects (Computational
  interaction)

44
Computational viewpoint - Example
Action
Interface provided by Bank Branch Object
Application objects
45
Computational ViewpointInterface Subtyping -
Example

• The concept of interface type is particularly
  important in RM-ODP.
• Interfaces in the computational model are
  strongly typed and inheritance of an interface
  type (usually) creates a subtype relationship.
  Subtypes of an interface type are substitutable
  for the parent type (or any supertype).

46
Computational Interaction - Example

• BankTeller Interface Type
• operation Deposit (c Customer, a Account, d
  Dollars)
• returns OK (new_balance Dollars)
• returns Error (reason Text)
• operation Withdraw(c Customer, a Account, d
  Dollars)
• returns OK (new_balance Dollars)
• returns NotToday(todayDollars,daily_limit
  Dollars)
• returns Error (reason Text)
• The notation used in the example above is merely
  illustrative. RM-ODP does not prescribe any
  particular notation for defining operational
  interface types

47
Engineering viewpoint

• Is used to describe the design of
  distribution-oriented aspects of an ODP system
• Defines a model for distributed system
  infrastructure
• Its language defines a number of functional
  building blocks wich can be combined together to
  provide the requested transparencies
• The fundamental entities described in the
  engineering viewpoint are objects and channels

48
Engineering viewpointObjects and Channel

• Objects in the engineering viewpoint can be
  divided into two categories
• Basic engineering objects, corresponding to
  objects in the computational specification
• Infrastructure objects, e.g. a protocol object
• A Channel corresponds to a binding or binding
  object in the computational specification

49
Engineering viewpointExample of channel
Supporting Object
Supporting Object
Supporting Object
A channel provides the communication mechanism
and contains or controls the transparency
functions required by the basic engineering
objects
50
Technology viewpoint

• Is concerned with the hardware and software
  components form wich the distributed system is
  constructed
• Its language is primarily concerned with
  referencing appropriate standards and
  techonologies to use in order to realize the
  specifications of the other viewpoints

51
ODP Functions

• Provide some building blocks to assemble ODP
  systems
• They are a collection of functions expected to be
  required in ODP systems to support the needs of
  the computational language (e.g. trading
  function) and engineering language (e.g. the
  relocator)
• There is not a simple mapping between
  transparencies and functions
• For example, the relocation transparency is
  exactly what tje relocation function provides,
  but some transparencies are more implicit in an
  ODP system, and do not require the support of a
  function
• Similarly, many functions provide functionality
  that is not necessarily a transparency

52
ODP functions

• The ODP functions are categorised into four
  groups
• management functions
• coordination functions
• repository functions
• security functions

53
ODP functions

• The ODP functions are categorised into four
  groups
• management functions
• Node management function
• Capsule management function
• Cluster management function
• Object management function
• coordination functions
• repository functions
• security functions

54
ODP functions

• The ODP functions are categorised into four
  groups
• management functions
• coordination functions
• Event notification function
• Checkpoint and recovery function
• Deactivation and reactivatin function
• Group function
• Replication function
• Migration function
• Engineering interface reference tracking function
• Transaction function
• ACID transaction function
• repository functions
• security functions

55
ODP functions

• The ODP functions are categorised into four
  groups
• management functions
• coordination functions
• repository functions
• Storage function
• Information organization function
• Relocation function
• Type repository function
• Trading function
• security functions

56
ODP functions

• The ODP functions are categorised into four
  groups
• management functions
• coordination functions
• repository functions
• security functions
• Acces control function
• Security audit function
• Authentication function
• Integrity function
• Confidentiality
• Non-repudation function
• Key management function

57
Software development process in ODP

• The development process is decomposed according
  to viewpoints
• Each viewpoint deals with a particoular area of
  concern and, therefore, focuses on those aspects
  of the system under development that are relevant
  to that area of concern

58
Consistency between viewpoints

• The five viewpoints specifications must be linked
  by defining the relations between key terms in
  them. It is these statements of the relationships
  between veiwpoints that make them specifiy a
  single system, rather than being completely
  independent documents
• Many of the links will be provided implicity by
  the notations used, resulting from correspondence
  between names. However, some of the key
  constraints need to be stated explicitly
• Constraints are placed on the relations between
  terms in the viewpoint language themselves,
  establishing some limits on the mappings which
  can be established
• Most of the constraints placed are between terms
  in the computational and engineering languages

59
Example of consistency between viewpoints
If such correspondence cannot be established,
then the two different description are not
consistent, and should be refined untile a
correspondence can be demonstrated
60
Enterprise viewpoint consistency vs. other
viewpoints

• The enterprise language should serve as the basis
  for specifying enterprise goals which must be
  reflected directly or indirectly in all other
  viewpoint specifications.
• The enterprise viewpoint describes, explicitly,
  the objectives of the system in the context of
  the organization in terms of members, roles,
  actions, purposes, usage and policies.
• Therefore, an information, computational,
  engineering or technology viewpoint specification
  is consistent with an enterprise specification if
  all the roles, activities, and policies described
  in the enterprise specification are correctly
  reflected.
• For instance, dynamic schema defined in an
  information specification must obey the policies
  described in the enterprise specification.
• Different roles identified in the enterprise
  specification may be supported by different
  computational objects, having different
  transparency requirements.
• Thus, transparency needs for each role in the
  enterprise specification should be reflected by
  the use of the corresponding transparency
  mechanism in the engineering specification

61
Correspondence between computational and
engineering viewpoints
62
Other concerns in ODP System

• Formal Descriptions
• Consistency between viewpoints described with
  different notations
• Conformance assessments
• Other ODP projects
• INTAP, which uses UML Profile for EDOC
  (Enterprise Distributed Object Computing) from
  OMG and RM-ODP viewpoints
• ATA, architecture which respect ODP standards

63
INTAP example of enterprise viewpoint
64
INTAP example of enterprise viewpoint
Special icon is used to represent role of the
community in the diagram
65
INTAP example of enterprise viewpoint
The behavioral part of the community could be
specified with UML Collaboration.
66
INTAP example of information viewpoint
Instance model description
67
INTAP example of information viewpoint
Structured class diagrams for instance model
68
INTAP example of information viewpoint
Dinamic schema
69
References

• ODP Reference Model  
• ftp//ftp.dstc.edu.au/DSTC/arch/RM-ODP/PDFdocs/
• Reference Model of Open Distributed Processing
  (RM-ODP) Introduction
• Kerry Raymond - kerry_at_dstc.edu.au 
• http//archive.dstc.edu.au/AU/research_news/odp/r
  ef_model/papers/icodp95.ps
• ODP Unplugged!
• Ian Joyner
• http//homepages.tig.com.au/ijoyner/ODPUnplugged
  .html
• RM-ODP The ISO Reference Model for Open
  Distributed Processing
• Antonio Vallecillo - av_at_lcc.uma.es
• ETSI Informática. Universidad de Málaga
• http//www.enterprise-architecture.info/Images/Do
  cuments/RM-ODP.pdf
• FDTs for ODP
• Howard Bowman, John Derryck, Peter Linington and
  Maarten Steen
• Computing Laboratory, University of Kent,
  Canterbury
• http//www.cs.kent.ac.uk/research/groups/tcs/cons
  istency/talk.ps.gz
• Applying EDOC and MDA to the RM-ODP Engineering
  and Technology Viewpoints
• An Architectural Perspective
• David Frankel Consulting