1

Q: How to create this output?

<Stack> <Stack_-Entry obj-name="head" data="Macchiato"> <Stack_-Entry obj-name="next" data="Cappuccino"> <Stack_-Entry obj-name="next" data="Latte"> <null obj-name="next"/> </Stack_-Entry> </Stack_-Entry> </Stack_-Entry></Stack>

2

Stack stack = new Stack();stack.push("Latte");stack.push("Cappuccino");stack.push("Macchiato");new JSX.ObjOut().writeObject(stack);

class Stack { private Entry head;private static class Entry {

String data;Entry next;

}} // push() inserts at head (omitted)

3

Orthogonal Data Access

A new paradigm for object oriented programming

4

Goals

• To import/export data from programs– Simple– Ease of use– Correctness– To test out these ideas on you – comments

are most welcome

• Generalizing from– Java programming language– XML exchange format

5

Overview

• Part I: Data Access– Importance of data access– OOP

• Part II: Instance Evolution• Part III: Back-compatibility• Part IV: Apply to Java

6

Part I: Data Access

• Data is important– Data is the focus of most real-world

applications– Oracle made $10.8 billion in bad times

7

Reasons to access data

Export/import data:

• Persistence

• Communication– across space– across language– across module or subsystem

• Data processing

• Data input/output

8

Databases & Data Access

• Databases provide data access– For data-processing– For communication between components– For communication between programming

languages– To switch operating systems & hardware

• Databases provide persistence– CLAIM: not the primary use of databases!

9

Impedance mismatch problem

• Database problem: impedance mismatch– Need to map data between programming

languages and the database

10

Database problem

objectschema store

DatabaseProgram Environment

11

Impedance mismatch

• Solutions to impedance mismatch– Object Oriented Databases– O/R mapping– Persistent Programming Languages

• O/R is a band-aid solution

• OODB and PPL aim at providing persistence, but import/export of data as a secondary goal

12

PPL solution

object

store

Program Environment

13

PPL & data access

• By getting rid of the schema, PPL also lose the ability to provide data access

• The mapping layer is important

14

Distributed computing - RPC

object

Program Environment A

object

Program Environment B

15

Distributed computing

• CORBA and SOAP provide cross-language compatibility

• The focus is communication, not persistence– The data is not long-lived, and so evolution is

not a primary concern

• RPC use marshalling to export/import data – a form of serialization

16

class BankAccount { String name; int accountNumber; int balance;}<?jsx version="1"?><BankAccount name=“Arthur Weasley" accountNumber="11223344" balance="20000"/>

Serialization example

17

Serialization

object

schema

Program Environment

object

schema

store

18

Serialization

• Serializing an object graph represents it as a stream of data, which can be deserialized to form a copy of the graph, that could replace the original

• It preserves structure

• The stream can be saved as a file, transmitted over the network or inspected/manipulated in memory.

19

Ways of accessing data

• Databases, Object DB, O/R mapping

• Persistent Programming Languages

• RPC: CORBA, SOAP, web services

Serialization can be used for all the above

20

Data Access & OOP

• Wait! Doesn’t serialization break the data hiding of objects?

• Data is important

• But OOP hides data

• Orthogonal data access resolves this

21

OOP and data

• Object oriented programming focuses on the behaviour of objects, rather than their state (or data)

• This is at odds with the predominate use of computers for dealing with data

• Thus, we focus on object state (instances, values), rather than object code

22

Serialization

• Serialization directly accesses the fields of objects, to automatically construct a file format or wire protocol

• Must this break encapsulation?

23

OOP and data hiding

• “object oriented = data abstractions + object types + type inheritance”

• “It supports objects that are data abstractions with an interface of named operations and a hidden local state.”– Cardelli & Wegner, ACM Survey, 1985

24

“On the Criteria to Be Used in Decomposing Systems into Modules”

• Back to the source: Parnas paper -> ADT -> OO

• OO hides data, for modularity– Managerial: Divide the task up– Flexibility: can change modules independently– Comprehensibility: one module at a time

• But it only needs to hide information about the implementation of the data to accomplish these aims

25

Objects

• Object = code + data

• “Information hiding” is thought to mean to hide the fields of objects, and only allow access through methods (behaviour)

• But access to state is still needed: hence, getter and setter methods

• But the real purpose is to hide information about the implementation

26

Expose “data implementation”

<Stack> <Stack_-Entry obj-name="head" data="Macchiato"> <Stack_-Entry obj-name="next" data="Cappuccino"> <Stack_-Entry obj-name="next" data="Latte"> <null obj-name="next"/> </Stack_-Entry> </Stack_-Entry> </Stack_-Entry></Stack>

27

Hide “data implementation”

<Stack_-Memento> <ArrayOf-java.lang.String obj-name="array" length="3">

<java.lang.String valueOf="Macchiato"/> <java.lang.String valueOf="Cappuccino"/> <java.lang.String valueOf="Latte"/> </ArrayOf-java.lang.String></Stack_-Memento>

28

Hide “data implementation”

private static class Memento {String[] array;private Memento(Stack s) {

array = new String[size];int i = 0;for (Entry e=s.head; e!=null; e=e.next)

array[i++] = e.data;}

}

29

Hide “data implementation”

private Object writeReplace() throws ObjectStreamException {

return new Memento(this);

}

30

Mapping local to the object

• Evolution is necessarily tightly coupled with implementation, so that is where the mapping should be

• We map from the object’s internal representation, into a “memento”, which is the object’s external representation

• Internal representation is implementation

• External representation is interface

31

Does this break encapsulation?

• “Information hiding” means(1). data hiding?(2). implementation hiding?

• SUBMIT: (2), as this gives the benefits of its raison d'être (Parnas)

• It transcends encapsulation

32

The way was lost…

• The real issue is not behaviour vs state, but implementation vs interface

• The problem with automatic serialization is not that it records state, but that it records it in terms of the implementation of that state – it should hide this information

• We can solve this with a layer, to structure access to state

33

Memento

• The idea is simple– A data object to represent the state of another

object

• This allows the implementation to evolve, without affecting the interface

• …but what if the implementation evolves to augment or diminish its capacity?

34

Part II: Evolution

• Evolution is important

• Implementation vs. interface evolution– Evolution of implementation should be local

• Forward vs backward propagation of instances– Evolution of interface should be extendable

35

Context in literature

• Instance evolution (not schema/type/class evolution) – Banerjee

• Within class evolution (not inheritance or class) – Banerjee

• Filtering/screening (not conversion) - Casais

36

Evolution

• Evolution– Implementation evolution– Interface evolution (of external representation)

• Terminology– In Databases – “schema evolution”– In Object databases - “class evolution”– In RPC – “type/class evolution”– In PPL – “type/class evolution”

37

Part III: Back-compatibility

• Forward propagation– old -> new

(we can read the old version)

• Backward propagation– old <- new

(we can write to the old version)

38

Read/write self.

Where the interface never changes.

Read/write self, and read old.

Back compatible read (eg persistence)

Read/write self, and write old.

Back compatible write(eg publish to old clients)

Read/write self, and read/write old.

Bi-directional compatibility.

39

• Partial versioning (Roddick survey)– can read old and new, but only write new

• Full versioning (Roddick survey)– Can write both old and new versions

• Backward and forward compatibility – Monk– Dynamic instance conversion

40

Back-compatibility

• Extending schema– Use inheritance to explicitly extend– We exploit the inheritance of fields/attributes– The semantics work for back-compatibility– The semantics are familiar to developers

• CLAIM: using inheritance for back-compatible evolution is novel

41

Inheritance for back compatibility

• Where the evolution is capacity augmenting (or additive), we can “extend” the Memento, and provide a backchain to update and backdate

• In the Java data model, inheritance is always additive

42

Part IV: Apply to Java

• Java is– strongly typed– robust– high-level– object oriented

• but its evolution mechanisms for serialization are not

43

Evolution Mechanisms

• Custom serial format (write/readObject)– Untyped, unparsed, not named, cannot retrofit

• Serializable Field API (Put/GetField)– Runtime type-checking, parsed, named, can

retrofit

• Memento (writeReplace/readResolve)– Static typing, parsed, named, can retrofit

(JSX) + version naming, encapsulation

44

Memento – external type

• The Memento idea is simple– A data object to represent the state of another

object

• This is an external type, to represent the state (or data) of an internal type

45

Memento Summary

• Memento – external type– Name of the Memento is a version name– Extending a Memento gives back-

compatibility semantics (as for method interfaces), for bi-directional instance propagation

– Compile-time type checking– Able to retrofit (in JSX)

• CLAIM: back-compatible Memento is new

46

Orthogonal Data Access

A new paradigm for object oriented programming?

47

Goals – comments, please

• To import/export data from programs– Simple– Ease of use– Correctness– To test out these ideas on you – comments are most

welcome

• Generalizing from– Java programming language– XML exchange format

• Email: bren@csse.monash.edu.au

48

Comments so far…

• 16 Dec 2002– Bi-directional (slide 38, rightmost) When an old version reads an

extended memento, it discards the data it can’t read. But it’s useful to pass it on when writing, despite not understanding it itself. Useful in a chained pipe/database context. Mail readers do this. COBOL has “filler” for this (thanks John, Michael & Peter)

• Implement: store the Memento read in an instance field. Update the fields of this with the new state, instead of creating a new one.

– Object identity is an issue for PPL and distributed systems; however, the technique of copying works fine, provided there is no concurrent access. For large databases, with concurrent access, more sophisticated solutions are needed than this. The memento addresses simpler problems that don’t require all that overhead (thanks John)