The Web-Interfacing Repository Manager

1. The Web-Interfacing Repository Manager A Perl-Based Application Server Rex Jakobovits, PhD rex@workhost.com WIRM.org July 20, 2000

2. Application Server: A class of Middleware

3. Roles of a Repository Manager

4. Outline of Talk • Requirements Analysis • Architecture • Model & Methodology • Evaluation

5. Requirements Analysis1) Systems Integration • “Wrapper” around heterogeneous applications • insulate user from idiosyncrasies of interfaces • Hide details of control flow • Automatically launch programs • Transparently handle format translations

6. Requirements Analysis2) Data Integration • Uniform interface for querying & browsing application data • Two basic strategies: • Data warehousing • Query mediation

7. Requirements Analysis:3) Workflow Support • Monitor data acquisition • Manage stages of processing • Tools for defining and evolving workflow

9. Requirements Analysis:4) Collaboration Support • Share data across facilities • Access programs remotely • Publish files on web • Groupware features • annotations, etc.

12. Requirements Analysis:5) Advanced Data Types • Allow arbitrary user-defined types • Built-in Multimedia Support • Metadata management • Image conversions • Visualization • Evolving domain model

14. Requirements Analysis:6) Effective Navigation System • Consistent, predictable interface • Hierarchical data traversal • e.g. List of patients  single patient  MR exam  series  slice

15. Requirements Analysis:7) Dynamic Schema Evolution

16. Requirements Analysis:8) User Session Support

17. Requirements Analysis:9) Adaptive User Interface • Customizable for distinct user classes • Selective labels • Reorganize data according to anticipated interest • Access regulation • Privacy (e.g. public, collaborator, privileged) • Proprietary data (published vs. unpublished)

19. Class Defs WIRM Architecture WIRM Server Wirmlet Web Server Client Browser Web View DB Server RDB File Data Viz Cache

20. Class Defs WIRM Server Components Wirmlet Web View WIRM Server Gateway Repository Object Interface HTML Generator Table Manipulator FSA Controller VCM DBI Image Magick CGI.pm RDB File Data Viz Cache

21. The Query-By-Context Design Methodology • An approach to developing information systems using hierarchical, context-sensitive views over domain data, based on… • The Repository Object Model • Abstraction for modeling the structure and behavior of experiment objects • The Wirmlet Process Model • Abstraction for modeling the events that control a user’s interaction with experiment objects

22. Repository Object Model • Allows EMS designer to model domain knowledge as Object-Relational Classes • Each Class Definition consists of: • Schemas(modeling structural properties of objects) • Methods (modeling behavior of the objects)

23. Repository Object Model:Schema Definition • Each Schema is designed using graphical Schema Definition Tool • A Schema consists of a list of Attribute Definitions (Name-Type pairs) • Attribute Types can be: • Atomic (string, int, real, date) • Composite (reference to a class instance) • Aggregate (list or set)

24. ROM Schemas continued… • Built-in (domain-independent) composite types: • File • User • Annotation • Every Schema must include Object ID to uniquely identify instances

25. Repository Object Model:Object Instances • Domain data is organized as instances of values matching a schema structure • Implemented as rows in a Relational table • Programmer can access attributes by name using object-oriented abstraction, as opposed to ordered tuples(e.g. $patientage instead of $p[4][2])

26. ROM Data Abstraction REPO API File System RDBMS

27. Repository Object Model:Defining Methods • Each method is a procedure encoding some behavior of the class, invoked through any instance of the class. • Methods are written in the ROM Procedure Language, which provides access to: • Repository State(SQL queries + persistent instance variables) • Context State (user identity, etc.) • User I/O (GUI elements)

28. ROM Procedure Language show(Patients, “sex = M”); GATEWAY API

29. Methods of the Repository Object Superclass • All Repository classes inherit a set of methods from a prototype superclass • Can be specialized (overridden) by EMS designer • Inherited methods are: • Make, Update, Delete, • View-Label, View-Row, View-Row-Header, View-Page

31. Default Make method for Book

32. View Methods: Drill-Down Visualization • View-Label • Visualize in context of string • Self-hyperlink that leads to Page View • Default: “classname OID” • View-Row • Visualize in context of group (table) • List of attributes (possibly subset) • First item should be Label View • Default: Label view + every attribute

33. Drill-Down VisualizationContinued… • View-Page • Visualize in context of full page • Object becomes current “focus subject” • Should use Label View in title • Default: List every attribute (same as Row View)

34. Writing Custom Views • EMS Designer overrides default views by writing specially-named methods using ROM Procedure Language • Make View-Label more descriptive than “classname OID” (e.g. patient name) • Make View-Row a summary (omit some details) • Make Page-View more interesting (presentation style, reorder information, etc.)

35. Default Row View for Book

36. Custom Views for Book sub Book_view_label { my($b) = @_; return href($b->{title}, vlink($b)); } sub Book_view_row { my($b) = @_; return [ Book_view_label($b), “ $b->{author_first_name} $b->{author_last_name} ”, File_view_icon($b->{cover}) ]; }

38. Context-Sensitive Views • Views have access to global context variables • Key to building context-sensitive web site is to implement context-switching at view granularity • E.g. Patient-Label-View: if (USER == $PRIVILEDGED) { show($patient{name});} else { show($patient{number}); }

39. The Wirmlet Process Model • Abstraction for modeling the system as a set of discrete event-handlers • Wirmlet: a script which encapsulates a simple web-based interaction with the user, emitting a Web View (HTML document) • Divide and conquer: break down problem of designing information system into small, coherent steps at the granularity of a form submission or hyperlink traversal

40. Defining & Executing Wirmlets • Each Wirmlet has a URL, a handle by which it can be executed… • Directly by naming the URL • Through a hyperlink that encodes the URL • By submitting a form tied to the URL • Wirmlets are written in the ROM Procedure Language, so they have access to repository state, session state, and user I/O.

41. Basic structure of a Wirmlet • Display document header information (banner, title, navigation bar) • Possibly display a prompt which includes a submit button • Process results (query database, possibly update database) • Display confirmation

42. Built-In Wirmlets • Domain-independent Wirmlets for executing common operations • Use inherited methods of ROM superclass • Facilities for: • User maintenance • Querying & browsing • Creating & editing instances (Workflow) • Schema management (defining, evolving, etc.)

44. Distributing System Logic: Wirmlets or Methods? • WIS Designer only needs to build a few “entry point” Wirmlets • The majority of the system logic can be relegated to the Class Methods, making use of built-in Wirmlets • All data visualization goes through Object Viewer Wirmlet • Workflow can be encapsulated in Make & Edit methods, which are activated through Create Object and Edit Object Wirmlets

45. Example: Encapsulating Workflow in Make Method • Consider WIS that keeps track of which lab books are checked out. • Two classes: Book & Loan • Borrowing a Book can be implemented as the Make method of the Loan class

47. Customizing Loan-Make sub Loan_make_prompt { $display .= h3("Borrowing a Book"); $display .= em("Which Book are you borrowing?");  $avail_books = repo_query("Book", "availability = 'IN LAB'"); $display .= repo_choice($avail_books, "book_choice"); $display .= submit("Borrow This Book"); return $display; }

49. Evaluation of Benefits:Programmer’s Perspective • Comprehensive, adaptive drill-down navigation system “emerges” from simple modeling steps • Hierarchical workflow management easy to implement using stepwise refinement • Changes are instantly realized • New data immediately accessible anywhere • Two-step updates (save buffer, refresh browser) • New schemas are “ready to use” • On-the-fly schema evolution

50. Evaluation of Benefits:Programmer Perspective (continued) • Object manipulation much less bug-prone than relational manip. • Hi-level abstractions = rapid prototyping • easy to test interface design proposals • Easy to refine system as programmer’s understanding of domain evolves • Perl is POWER! • Regular expression parser is crucial • Huge leverage from existing module archives