1 / 83

PATTERNS FOR AUTOMATIC INTEGRATION OF THE DOMAIN-DATA LAYERS IN ENTERPRISE-SYSTEMS

Ben Gurion University Beer-Sheva, Israel. PATTERNS FOR AUTOMATIC INTEGRATION OF THE DOMAIN-DATA LAYERS IN ENTERPRISE-SYSTEMS. Mira Balaban Joint work with Lior Limonad. Example: an e-Mail client system. Persistency requirements:. Demo. Persistent class Persistent  In-memory

billy
Download Presentation

PATTERNS FOR AUTOMATIC INTEGRATION OF THE DOMAIN-DATA LAYERS IN ENTERPRISE-SYSTEMS

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. Ben Gurion University Beer-Sheva, Israel PATTERNS FOR AUTOMATIC INTEGRATION OF THE DOMAIN-DATA LAYERS IN ENTERPRISE-SYSTEMS Mira Balaban Joint work with Lior Limonad

  2. Example: an e-Mail client system Persistency requirements: IBM Haifa, Oct 06

  3. Demo • Persistent class • Persistent  In-memory • Persistent  Persistent • Persistent collection Domain Layer Data Access Layer Storage IBM Haifa, Oct 06

  4. Modern Systems • Built into layers • Typical layers are: • Presentation • Domain • Data • Grasp changing requirements as a norm • Such as: persistency requirements • Adhering to the MDA spirit View DB as a natural extension of the application IBM Haifa, Oct 06

  5. Persistency Motivation • A strict demand to keep an object state, when its data is important for the continuity of the system. • Objects are too big. • Large amount of objects. • Too much for loading all together to memory (hardware limit). • Need to deal with objects one at the time. • Need to save historical states of the system. • Sharing object states between multiple applications. IBM Haifa, Oct 06

  6. Agenda • Demo • Motivation • The problem of partial persistency • The research goal • Partial solutions • The DAL Patterns solution • Application Example • Evaluation • Correctness proof • Merits and shortages • Conclusions and future work IBM Haifa, Oct 06

  7. Partial Consistency Input: Mapping between application (Domain layer) and storage (Data layer). Based on a semantic linkage between layers. Output: integrated layers. Task: Introduce Partial persistency. Requires system restructuring (refactoring, transformation). Requirements: • Persistency of (only) marked objects • Behavior preservation • Transparency – minimal changes to the domain layer IBM Haifa, Oct 06

  8. Persistencyof (only) marked objects complications (1) Co-existence of storage and in-memory objects • Mixture – ingoing and outgoing references:Ingoing: In-memory  Persistent • Availability Outgoing: Persistent  In-memory • Reference preservation IBM Haifa, Oct 06

  9. Persistencyof (only) marked objects complications (2) • Duplication handling: • Consistency– • Inter-layer – • Duplicated of objects • Duplicated references • Intra-layer – preventing duplication of objects IBM Haifa, Oct 06

  10. Insertion of persistency requirements • Goal: Achieve automatic persistency insertion in a running application • Integration must fulfill Partial persistency • Persistency of (only) marked objects • Behavior preservation • Transparent integration • Domain-layer stays intact IBM Haifa, Oct 06

  11. Agenda • Demo • Motivation • The problem of partial persistency • The research goal • Partial solutions • The DAL Patterns solution • Application Example • Evaluation • Correctness proof • Merits and shortages • Conclusions and future work IBM Haifa, Oct 06

  12. Current Technologies (1)e.g. J2EE / Hibernate • Support: • Mapping: may be generated automatically • Intra-layer Consistency • Availability – handled by the environmente.g. EJB container IBM Haifa, Oct 06

  13. Current Technologies (2)e.g. J2EE / Hibernate • Necessary manual work: • Modification of persistent classes • Adhering to standards (e.g. EntityBean interface) • Mixture handling • Handle ingoing and outgoing references • e.g. serialization • Interlayer consistency • Object consistency • Manual invocation of, e.g., session.save(obj), session.load(class,id), ejbLoad() / ejbStore() / ejbCreate() / db.bind(…) / db.deletePersistent(…) • Reference consistency • e.g. between two stored objects • Still require writing tedious (bug infected…) code! • Domain-Layer is modified – No Transparency! IBM Haifa, Oct 06

  14. Current Technologies (3)e.g. J2EE / Hibernate Missing: An algorithmic, correct, automated solution forintegration of the Domain and the Persistent layers IBM Haifa, Oct 06

  15. Partial solutions:Fowler’s Active Record Pattern • Transparent • Partial persistency • Preserving references between objects • Preservation of objects availability • Behavior preserving • Object structure preservation IBM Haifa, Oct 06

  16. Partial solutions:Fowler’s Data Mapper pattern • Transparent • Partial persistency • Preserving references between objects • Preservation of objects availability • Behavior preserving IBM Haifa, Oct 06

  17. Agenda • Demo • Motivation • The problem of partial persistency • The research goal • Partial solutions • The DAL Patterns solution • Application Example • Evaluation • Correctness proof • Merits and shortages • Conclusions and future work IBM Haifa, Oct 06

  18. The DAL Patterns Solution • A small set of Data-Access Layer (DAL) patterns (refactorings, transformations): • Core pattern: Proxy-Data-Mapper: • Context independent insertion of persistency • ContextPatterns: • Context tailored refactorings of: • Persistent-to-In-Memory interactions • Persistent-to-Persistent interactions • DAL-Insertion algorithm • A combined procedure for pattern application IBM Haifa, Oct 06

  19. Proxy Data Mapper Pattern • Application precondition:message has a factory method • Automatic application: IBM Haifa, Oct 06

  20. Proxy Data Mapper Pattern • Application precondition:message has a factory method • Automatic application: • Extract subclass “MessageImp” IBM Haifa, Oct 06

  21. Proxy Data Mapper Pattern • Application precondition: message has a factory method • Automatic application: • Extract subclass “MessageImp” • Move implementation: Message  MessageImp IBM Haifa, Oct 06

  22. Proxy Data Mapper Pattern • Application precondition: message has a factory method • Automatic application: • Extract subclass “MessageImp” • Move implementation: Message  MessageImp • Add a MessageDataMapper IBM Haifa, Oct 06

  23. Proxy Data Mapper Pattern • Application precondition:message has a factory method • Automatic application: • Extract subclass “MessageImp” • Move implementation: Message  MessageImp • Add a MessageDataMapper • Add a MessageProxy IBM Haifa, Oct 06

  24. Proxy Data Mapper Pattern • Application precondition:message has a factory method • Automatic application: • Extract subclass “MessageImp” • Move implementation: Message  MessageImp • Add a MessageDataMapper • Add a MessageProxy • Turn Message to be abstract • Redirect the factory method IBM Haifa, Oct 06

  25. Example of Proxy Data Mapper Usage IBM Haifa, Oct 06

  26. The Proxy Data Mapper Automatable Refactoring (1) Input: persistentClass, dbSchemaElement 1. Extract the implementation from the persistent class: persistentClassImp = extractSubClass(persistentClass); 2. Construct the data mapper class: dataMapper = addClass(concat(persistentClass.name+''DataMapper'')); addMethod(dataMapper, “load”, constructLoadImpMethod(persistentClassImp, dbSchemaElement)); addMethod(dataMapper, “store”, constructStoreImpMethod(persistentClassImp, dbSchemaElement)); addMethod(dataMapper, “update”, constructUpdateImpMethod(persistentClassImp, dbSchemaElement)); addMethod(dataMapper, “delete”, constructDeleteImpMethod(persistentClassImp, dbSchemaElement)); IBM Haifa, Oct 06

  27. The Proxy Data Mapper Automatable Refactoring (2) 3. Construct the proxy class: proxy = addClass(concat(persistentClass.name+''Proxy'')); addField(proxy, “_idField”, Integer); addField(proxy, “_mapperField”, dataMapper); • Add finalize, load, update methods. • add all constructors: for each constructor c in constructors(persistentClassImp) addMethod(proxy, proxy.name, constructConstructore(dataMapper, persistentClassImp)); • add all delegated methods to the proxy class: for each method m in instance_methods(persistentClassImp) addMethod(proxy, m.name, constructDelegatedMethod(m, persistentClassImp); IBM Haifa, Oct 06

  28. The Proxy Data Mapper Automatable Refactoring (3) 4. Redirect factory methods: for each factoryMethod f in factories(persistentClass) redirectFactoryMethod(proxy); 5. Tag modifications: stereotype(persistentClass, ``abstract''); IBM Haifa, Oct 06

  29. Proxy Data Mapper – Example Applying PDM to the Message class: IBM Haifa, Oct 06

  30. Problems solved by the Proxy Data Mapper Pattern • Persistency of only marked classes • Mixture • Availability • Reference preservation • Duplication • Consistency • Inter layer • Object – handled by the proxy • Reference • Intra layer – factory method uses Fowler’s “Identity Map” • Behavior preservation • Full Transparency IBM Haifa, Oct 06

  31. The DAL Patterns Solution • A small set of Data-Access layer patterns: • Core pattern: Proxy-Data-Mapper: • Context independent insertion of persistency • ContextPatterns: • Context tailored refactoring of: • Persistent-to-In-Memory interactions • Persistent-to-Persistent interactions • DAL-Insertion algorithm • A combined procedure for pattern application IBM Haifa, Oct 06

  32. Context Patterns • Problem parameters: • In/Out associations into/from the persistent class • Cardinality constraints • Persistent/In-memory marking of the Context class • 5 context patterns <<persistent>> Context Class <<persistent>> fooClass 1 1 * * IBM Haifa, Oct 06

  33. DAL Patterns IBM Haifa, Oct 06

  34. I. Persistent Collection Data Mapper • context IBM Haifa, Oct 06

  35. pn:MessageProxy mn:messageImp p3:MessageProxy m3:messageImp p1:MessageProxy m1:messageImp p1:MessageProxy m1:messageImp vs:VirusScan col:MessagesCollection :MessageDataMapper :MessageDataMapper :MessageDataMapper :MessageDataMapper Messagesm1..mn I. Persistent Collection Data Mapper – problems(1) • The in-memory collection realization problem: • The collection of all proxy objects may be too large to fit in-memory IBM Haifa, Oct 06

  36. I. Persistent Collection Data Mapper – problems(1) • Solution to the collection realization problem: • Introduce a collection that loads corresponding proxy objects by demand getMsg(n) vs:VirusScan col:MessagesCollection pn:MessageProxy mn:messageImp col:MessagesCollectionMapper :MessageDataMapper id1..idn Messagesm1..mn IBM Haifa, Oct 06

  37. I. Persistent Collection Data Mapper – problems(2) • The deletion problem: • Collection of IDs  A new implicit reference to persistent objects IBM Haifa, Oct 06

  38. I. Persistent Collection Data Mapper – problems(2) • The deletion problem: • When a proxy is deleted, how to prevent message deletion from storage? getMsg(n) vs:VirusScan col:MessagesCollection pn:MessageProxy mn:messageImp col:MessagesCollectionMapper :MessageDataMapper id1..idn Messagesm1..mn IBM Haifa, Oct 06

  39. I. Persistent Collection Data Mapper– problems (2) • Solution to the deletion problem: • Extend the garbage collector to handle persistent objects. • References to persistent objects = clients holding their ids. So far: • In-memory proxy objects. • Collections of persistent objects. IBM Haifa, Oct 06

  40. :MessageTableManager Increase(id) Decrease(id) I. Persistent Collection Data Mapper– problems (2) • Solution to the deletion problem: • Insert TableManager (object) for the message – guards storage deletion by tracking reference count to it • All clients: proxys/collections, notify itabout reference changes pn:MessageProxy mn:messageImp :MessageDataMapper IBM Haifa, Oct 06

  41. I. Persistent Collection Data Mapper • Solution structure: IBM Haifa, Oct 06

  42. I. Persistent Collection Data Mapper– problems (3) • The collection itself is too large to reside in-memory: <<Persistent>> col:MessagesCollectionMapper id1…………………………………………………………………..idn IBM Haifa, Oct 06

  43. I. Persistent Collection Data Mapper– problems (3) • Extended solution: • Make the collection persistent • Apply the Proxy Data Mapper pattern MessagesCollectionMapper proxy:MessagesCollectionMapperProxy col:MessagesCollectionMapperImp id1…………………………………………………………………..idn mapper:MessagesCollectionMapperMapper IBM Haifa, Oct 06

  44. I. Extended Persistent Collection Data Mapper IBM Haifa, Oct 06

  45. II. Memoization Data Mapper patterns context • Memoization data mapper • Multi memoization data mapper IBM Haifa, Oct 06

  46. II. Memoization Data Mapper patterns problems • The memoization/multi-memoization problems • When a message is stored, how to handle outgoing references to other in-memory objects or in-memory collections? :MessageProxy m:messageImp e:EncryptionKey :MessageDataMapper Messagesm IBM Haifa, Oct 06

  47. II. Memoization Data Mapper patterns problems • Solution: • Extend the proxy with a reference to the outgoing referenced object or collection :MessageProxy e:EncryptionKey m:messageImp :MessageDataMapper Messagesm IBM Haifa, Oct 06

  48. II. Memoization data mapper pattern • Solution structure: IBM Haifa, Oct 06

  49. III. Multi memoization data mapper pattern • Solution structure: IBM Haifa, Oct 06

  50. IV. Persistent to Persistent Patterns– context • Persistent to Persistent • Persistent to multi persistent IBM Haifa, Oct 06

More Related