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

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