1 / 48

Q: How to create this output?

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>

wkitchen
Download Presentation

Q: How to create this output?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. Program Environment Database schema store object Database problem

  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. Program Environment store object PPL solution

  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. Program Environment A Program Environment B object object Distributed computing - RPC

  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. Serialization example class BankAccount { String name; int accountNumber; int balance; } <?jsx version="1"?> <BankAccount name=“Arthur Weasley" accountNumber="11223344" balance="20000"/>

  17. Program Environment store object object schema schema Serialization

  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)

More Related