1
The Web-Interfacing Repository Manager
A Perl-Based Application Server
Rex Jakobovits, PhD
WIRM.org
July 20, 2000
2
Application Server: A class of Middleware
3
Roles of a Repository Manager
4
Outline of Talk
1. Requirements Analysis2. Architecture3. Model & Methodology4. 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
8
9
Requirements Analysis:4) Collaboration Support
Share data across facilities Access programs remotely Publish files on web Groupware features
annotations, etc.
10
11
12
Requirements Analysis:5) Advanced Data Types
Allow arbitrary user-defined types Built-in Multimedia Support
Metadata management Image conversions Visualization
Evolving domain model
13
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)
18
19
WIRM Architecture
ClassDefs
WIRMServer
WirmletClient
Browser
DBServer
RDBRDB File DataFile Data Viz Cache
Viz Cache
WebServer
Web View
20
WIRM Server Components
HTML Generator
FSA Controller
Gateway
Repository Object Interface
Table Manipulator
DBI
VCM
Image Magick CGI.pm
ClassDefs
ClassDefs
WirmletWirmlet
RDBRDB File DataFile Data Viz CacheViz Cache
WIRM Server
WebView
WebView
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. $patientage 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
GATEWAY API
show(Patients, “sex = M”);
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
30
31Default 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.)
35Default 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}) ]; }
37
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
1. Display document header information (banner, title, navigation bar)
2. Possibly display a prompt which includes a submit button
3. Process results (query database, possibly update database)
4. 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.)
43
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
46
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;}
48
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
51
Evaluation of Benefits:End-User Perspective Uniform Web GUI much easier to
use for non-unix gurus Centralized, automated file
management pays off Annotation feature highly used Multi-context is key
52
Lines of code in WIRM API’s
Interface Lines
Table Manipulator 419
FSA Controller 251
Gateway 1270
HTML Generator 500
Repository Object API 854
Visualization Cache Manager 348
53WIRM.org