The Ultimate Guide to Choosing WordPress Pros and Cons
Case Study: SRM 2.0 - A next generation shared resource management system built on SpringSource dm Server
1. Case Study: SRM 2.0 - A next
generation shared resource
management system built on !
SpringSource dm Server
Matt Stine - St. Jude Children’s Research Hospital
2. Agenda
• Introduction to St. Jude
• Introduction to the SRM Domain
• SRM 1.x
• The Crossroads
• SRM 2.0
• Spring DM / OSGi Benefits
• Demo
• SRM 2.0 Data Bus
• Spring DM / OSGi Benefits
• Demo
• Q&A
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
3. St. Jude Mission
To advance cures, and means of
prevention, for pediatric catastrophic
diseases through research and
treatment. Consistent with the vision
of our founder Danny Thomas, no
child is denied treatment based on
race, religion or a family’s ability to
pay.
3
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
4. About St. Jude
• Founded by entertainer Danny Thomas and opened in 1962
• Supported primarily by funds from volunteer contributions
raised by ALSAC, the fund-raising arm of St. Jude
• 500 new patients each year
– Must be referred by physician
– Generally 18 years old or younger
– Must have disease currently studied at St. Jude
• 4,300 “active” patients
• 58 inpatient beds
• 60,000 outpatient visits per year
• 500,000 appointments per year
• Average patient: 7-9 appointments per day
• 75 staff physicians and 3,300 employees
4
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
5. Research and Treatment
• Known for advances in treatment of childhood
leukemia
• Other catastrophic diseases researched & treated
at St. Jude:
– Genetic diseases such as sickle cell disease,
osteogenesis imperfecta
(brittle bone disease)
– Infectious diseases such as tuberculosis and HIV/
AIDS
– Childhood cancers including tumors of the bone,
brain and soft tissue
5
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
7. Research Landscape
• 16 Academic Departments
• 5 Academic Divisions
• Cancer Center
– First and only NCI-designated Comprehensive
Cancer Center solely focused on pediatric cancer
– 6 Programs:
• Cancer Prevention and Control
• Developmental Therapeutics for Solid Malignancies
• Hematological Malignancies
• Molecular Oncology
• Neurobiology and Brain Tumor
• Signal Transduction
7
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
8. Shared Resources
• Centralized facilities providing services and access
to specialized equipment for research activities
• Often centered around technology too expensive
for individual research programs to maintain their
own infrastructure
• Examples:
– High-throughput DNA Sequencing
– Gene Expression Array Technology
– Electron Microscopy
• St. Jude currently has 41 shared resources
8
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
12. Shared Resource Operational
Issues
Service Sample
Request Check In
9
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
13. Shared Resource Operational
Issues
Service Sample
Request Check In
Process1
...
Processn
9
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
14. Shared Resource Operational
Issues
Service Sample
Request Check In
Process1
...
Processn
Sample
Check
Out
9
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
15. Shared Resource Operational
Issues
Service Sample
Request Check In
Process1
...
Processn
Generate
Sample
Bill
Check
Out
9
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
16. Shared Resource
Management (SRM) 1.x
• Web-based application providing a single,
integrated portal for management of shared
resource facility activities.
• Currently supports 11 St. Jude facilities offering
more than 20 distinct services.
• Available under the GNU Lesser General Public
License (LGPL) v3.0 at http://stjude-
srm.sourceforge.net.
10
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
17. SRM 1.x Development
Process
• Requirements for 5 laboratories
• Extract common requirements
• Build Core Domain Model/Database Schema
• Build Core Services Platform
• Build Web Portal
• Build laboratory specific extensions to:
– DB Schema
– Domain Model
– Services Platform
• Build laboratory specific Web UI
11
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
18. SRM 1.x Development
Process
• Requirements for 5 laboratories
• Extract common requirements
• Build Core Domain Model/Database Schema
• Build Core Services Platform
• Build Web Portal
• Build laboratory specific extensions to:
– DB Schema
– Domain Model ITERATE
– Services Platform
• Build laboratory specific Web UI
11
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
19. SRM 1.x Domain Model
Order
Sample
Workflow
Workflow
Detail
Test Sample
Data Group
12
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
20. SRM 1.x Domain Model
Order
Sample
Sample
Extension
Workflow
Workflow
Detail
Sample
Test Data Test Sample
Group
Extension Data Group Extension
12
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
21. SRM 1.x Technology Stack
• Java 2 Standard Edition 1.4
• Java 2 Enterprise Edition 1.3
– Enterprise JavaBeans 2.0
• CMP Entity Beans
• Stateless Session Beans
– Servlet 2.3
– JSP 1.2
• Oracle 10g
• JBoss AS 4.2
13
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
22. SRM 1.x Services Platform
SRM Architecture
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
14
23. SRM 1.x Issues
15
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
24. SRM 1.x Issues
• Explosive System Growth
– Per deployed service:
• 3 new tables
• 3 new entity beans (remote, local interfaces,
implementation class, modified descriptors, ...)
• 1 new stateless session bean
• 1 new business delegate
• Multiple new servlets, JSP’s
15
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
25. SRM 1.x Issues
• Explosive System Growth
– Per deployed service:
• 3 new tables
• 3 new entity beans (remote, local interfaces,
implementation class, modified descriptors, ...)
• 1 new stateless session bean
• 1 new business delegate
• Multiple new servlets, JSP’s
• Monolithic Deployment
– Tightly coupled services
– Tightly coupled layers
15
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
26. SRM 1.x Issues
16
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
27. SRM 1.x Issues
• Isolated Defects => “Distributed Suffering”
16
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
28. SRM 1.x Issues
• Isolated Defects => “Distributed Suffering”
• Implementation inconsistent across services
– Data integrity issues
– Inconsistent technology stack
– Knowledge transfer burden
16
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
29. SRM 1.x Issues
• Isolated Defects => “Distributed Suffering”
• Implementation inconsistent across services
– Data integrity issues
– Inconsistent technology stack
– Knowledge transfer burden
• Modularity Impossible
– Tried at the web layer
– Dependency versioning made things worse!
16
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
30. The Crossroads
• Information Sciences FY ‘09 – ’13 Strategic Plan
– Develop ordering and billing functionality for ~10
additional lab-based shared resources
– Develop SRM LIMS for those shared resources
requiring such infrastructure
– Develop links to other databases on campus as
required
17
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
31. The Crossroads
• SRM 1.x is at this point roughly five years old
• Core technology stack (EJB 2.0) is about eight
years old
• Architecture/development model mandates
database schema and source code changes for any
new facilities/services
• 3-6 month delivery time for new facilities/services
with 2-3 developers engaged
• Can we do better?
18
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
32. SRM 2.0 Key Goals
19
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
33. SRM 2.0 Key Goals
• Limit System Growth
– Extend primarily by configuration
– Extend secondarily by new/modified code
19
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
34. SRM 2.0 Key Goals
• Limit System Growth
– Extend primarily by configuration
– Extend secondarily by new/modified code
• True Modularity
– Across System Components
– Across Services
– Isolate risk, complexity
19
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
35. SRM 2.0 Key Goals
• Limit System Growth
– Extend primarily by configuration
– Extend secondarily by new/modified code
• True Modularity
– Across System Components
– Across Services
– Isolate risk, complexity
• Upgrade Technology Stack
– Spring
– Hibernate/iBATIS
19
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
36. SRM 2.0 Architectural
Concepts
Entity-Attribute-Value (EAV) Data Model
20
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
37. SRM 2.0 Architectural
Concepts
Entity-Attribute-Value (EAV) Data Model
• Discrete set of tables used for core model
extensions
20
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
38. SRM 2.0 Architectural
Concepts
Entity-Attribute-Value (EAV) Data Model
• Discrete set of tables used for core model
extensions
• Tables => rows in Entity table
20
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
39. SRM 2.0 Architectural
Concepts
Entity-Attribute-Value (EAV) Data Model
• Discrete set of tables used for core model
extensions
• Tables => rows in Entity table
• Table Columns => rows in Attribute table
20
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
40. SRM 2.0 Architectural
Concepts
Entity-Attribute-Value (EAV) Data Model
• Discrete set of tables used for core model
extensions
• Tables => rows in Entity table
• Table Columns => rows in Attribute table
• Table Row-Column Values => rows in Value
table(s)
20
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
41. Conventional Data Model
Source: http://jpodb.alik.ch/twiki/bin/view/Main/DataModel
21
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
42. EAV Data Model
Source: http://
jpodb.alik.ch/twiki/
bin/view/Main/
DataModel
22
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
43. SRM 2.x Domain Model
Order
Sample
Worklog
Task Task Set
23
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
44. SRM 2.x Domain Model
Order
Sample
EAV
Worklog
Task Task Set
23
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
45. SRM 2.0 Architectural
Concepts
Plug-in Architecture
24
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
46. SRM 2.0 Architectural
Concepts
Plug-in Architecture
• System framework supports core business features
24
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
47. SRM 2.0 Architectural
Concepts
Plug-in Architecture
• System framework supports core business features
• Features are implemented via pluggable “Business
Activity Sources”
24
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
48. SRM 2.0 Architectural
Concepts
Plug-in Architecture
• System framework supports core business features
• Features are implemented via pluggable “Business
Activity Sources”
• Data, layout, behavior bound via configurable
“Business Activities”
24
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
49. Plug-in Architecture
Fe
at
ur
e
25
SRM Kernel
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
50. Plug-in Architecture
Bu ur
So
si ce
Fe
ne
at
ss
ur
e
Ac SRM Kernel
tiv
25
ity
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
51. Plug-in Architecture
Bu ur
Bu
So
si
Fe
si
ne
at
ne
ss
ce
ur
ss
e
Ac
Ac
25
tiv SRM Kernel
tiv
ity
ity
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
52. SRM Kernel
SRM Kernel
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
53. SRM Kernel
EAV DAO
Core Dynamic EAV
Hybrid
Services Services Engine
Data
Core DAO Generic
Source
Functions
Handlers
Core Platform SRM Kernel
Dynamic Platform
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
54. SRM Kernel
Business Business
Activity Activity
Source Source
EAV DAO
Core Dynamic EAV
Hybrid
Services Services Engine
Data
Core DAO Generic
Source
Functions
Handlers
Core Platform SRM Kernel
Dynamic Platform
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
55. SRM 2.0 Technology Stack
• Java SE 6
• Spring Framework 2.5.6
• Freemarker 2.3.15
• Prototype 1.6.1
• Hibernate 3.2.6
• iBATIS 2.3.4
• SpringSource dm Server 1.0.2
• PostgresPlus Advanced Server 8.3
27
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
56. DM/OSGi Benefits
• Modularization
• Isolation
• Plugability
28
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
57. Modularization
29
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
58. Modularization
• Clear separation of responsibility
29
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
59. Modularization
• Clear separation of responsibility
• Strict enforcement of module boundaries
29
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
60. Modularization
• Clear separation of responsibility
• Strict enforcement of module boundaries
• “Intraapplication SOA”
29
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
61. Modularization
• Clear separation of responsibility
• Strict enforcement of module boundaries
• “Intraapplication SOA”
• Enables DRY
29
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
62. Modularization
• Clear separation of responsibility
• Strict enforcement of module boundaries
• “Intraapplication SOA”
• Enables DRY
– Especially with Web Slices!
29
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
63. Isolation
30
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
66. Isolation
• Architectural Risk
• Change
• Technology
30
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
67. Isolation
• Architectural Risk
• Change
• Technology
• Dependencies
30
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
68. Isolation
• Architectural Risk
• Change
• Technology
• Dependencies
• Developer Responsibility
30
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
69. Plugability
31
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
70. Plugability
• Services
31
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
72. SRM 2.0 Demo
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
73. Shared Resource Operational
Issues
• Data Management/Retrieval
• Reporting
– Usage Statistics
– Turnaround Time
– Service Request History
33
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
74. Data Management (SRM 1.x)
SRM Pickup Location
SRM App Server Clustered Mass Storage
Research Archives
34
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
75. Data Management (SRM 1.x)
SRM Pickup Location
SRM App Server Clustered Mass Storage
Research Archives
34
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
76. Data Management (SRM 1.x)
SRM Pickup Location
SRM App Server Clustered Mass Storage
Research Archives
34
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
77. Data Management (SRM 1.x)
SRM Pickup Location
2004 Largest File Size:
< 10 MB
SRM App Server Clustered Mass Storage
Research Archives
34
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
78. Data Management (SRM 1.x)
SRM Pickup Location
2004 Largest File Size:
< 10 MB
SRM App Server 2009 Largest File Size: Clustered Mass Storage
Approaching 100 GB!!!
Research Archives
34
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
79. Data Management
• Need a event-based, distributed solution
• Need to provide Data as a Service (DaaS)
– Downstream Analytics Platforms
35
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
80. Reporting
• EAV Schema
– Data/relationships too abstract for report writers
– Performance bottleneck
• Data Mart
– Must be near real-time
– Proper data partitioning
• DaaS
– Participate in other data warehouses
36
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
81. SRM Data Bus
SRM
37
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
82. SRM Data Bus
Data Bus
SRM Broker
37
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
83. SRM Data Bus
Data Bus
Worker
Data Bus
SRM Broker
37
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
84. SRM Data Bus
Data Bus
Worker
Data Mart
Processor
Pipeline
Data Bus
SRM Broker
37
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
85. SRM Data Bus
Data Bus
Worker
Data Mart
Processor
Pipeline
Data Bus
SRM Broker
SRM Data Mart
37
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
86. SRM Data Bus
External
Warehouse
Processor
Pipeline
Data Bus
Worker
Data Mart
Processor
Pipeline
Data Bus
SRM Broker
SRM Data Mart
37
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
87. SRM Data Bus
External
Warehouse
Processor
Pipeline External Warehouse
Data Bus
Worker
Data Mart
Processor
Pipeline
Data Bus
SRM Broker
SRM Data Mart
37
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
88. SRM Data Bus
External
Warehouse
Processor
Pipeline External Warehouse
Data Bus
Worker
Data Mart
Processor
Pipeline
Data Bus
SRM Broker
SRM Data Mart
Data Bus
Worker
37
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
89. SRM Data Bus
External
Warehouse
Processor
Pipeline External Warehouse
Data Bus
Worker
Data Mart
Processor
Pipeline
Data Bus
SRM Broker
SRM Data Mart
Lab Y Data
Archival
Pipeline
Data Bus
Worker
37
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
90. SRM Data Bus
External
Warehouse
Processor
Pipeline External Warehouse
Data Bus
Worker
Data Mart
Processor
Pipeline
Data Bus
SRM Broker
SRM Data Mart
Lab Y Data
Archival
Pipeline
Research Archive
Data Bus
Worker
37
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
91. SRM Data Bus
External
Warehouse
Processor
Pipeline External Warehouse
Data Bus
Worker
Data Mart
Processor
Pipeline
Data Bus
SRM Broker
SRM Data Mart
Lab Y Data
Archival
Pipeline
Research Archive
Data Bus
Worker
Lab X Data
Archival
Pipeline
37
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
92. SRM Data Bus
External
Warehouse
Processor
Pipeline External Warehouse
Data Bus
Worker
Data Mart
Processor
Pipeline
Data Bus
SRM Broker
SRM Data Mart
Lab Y Data
Archival
Pipeline
Research Archive
Data Bus
Worker
Lab X Data
Analytics
Archival
Platform
Pipeline
37
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
93. SRM Data Bus Technology
Stack
• Java SE 6
• Spring Framework 2.5.6
• Spring Integration 1.0.3
• Apache ActiveMQ 5.2
• SpringSource dm Server 1.0.2
• PostgresPlus Advanced Server 8.3
38
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
94. DM/OSGi Benefits
• Modularization
• Isolation
• Plugability
39
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
95. SRM Data Bus
Demo
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
96. Acknowledgements
• SRM 2 Team • QA
– Rama Gundapaneni – Asmita Vaidya
– Simon Hagstroem • Business Analysts
– Roshan Shrestha – Ashish Pagare
– Bhagavathy Krishna – Sundeep Shakya
– Kiran Putcha • OPS
– JP Davaleswarapu – Scott Malone
– Dinesh Devasagayam – Bill Pappas
• Management
• SRM Data Bus Team
– Charles Hurmiz
– Swetha Mandava
– Clayton Naeve
– Raghuver Kontham
• SpringSource
– Wei Cai
– Keith Donald
– Yingliang Du
– Oleg Zhurakousky
– Mark Fisher
41
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
97. Feedback
• Please send me your feedback about the
presentation/presenter:
matt.stine@stjude.org
Twitter: mstine
42
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
98. Q&A
SpringOne 2GX 2009. All rights reserved. Do not distribute without permission.
Hinweis der Redaktion
So the audience for this presentation is primarily going to be software developers that use the Spring framework, probably several who are interested in leveraging OSGi by way of Spring Dynamic Modules, which is the Java modularity runtime provided by SpringSource dm Server, the application server on which SRM 2.0 will reside. In that interest I'm going to provide them with a brief introduction to what St. Jude is, followed by an overview of our research landscape and the concept of shared resources. We'll then step through SRM 1.x, how it was developed, its architecture, technology stack, and data model, and then look at many of the issues with SRM 1.x. We'll then discuss the crossroads provided by the IS strategic plan that called for the massive expansion of SRM and prompted the development of SRM 2.0. We'll look at the key goals for SRM 2, it's architecture, data model, and tech stack, and the describe the many benefits that we've realized from our adoption of Spring DM and OSGi. I'll follow up this discussion with a brief demo of SRM 2.0 and add functionality to the application by way of our OSGi-based plugin system. Next we'll look at SRM 2.0's partner system, the SRM Data Bus, which provides integration between SRM 2.0 and its own Data Mart, the upcoming Pediatric Cancer Genome Project data warehouse, our Pallas data analysis workflow engine, and our research archives. Finally we'll have a brief demo of the Data Bus and take Q&A
St. Jude represents the marriage of life sciences research and clinical care, rallied around our mission, &#x201C;to advance cures, and means of prevention, for pediatric catastrophic diseases through research and treatment. Consistent with the vision of our founder Danny Thomas, no child is denied treatment based on race, religion or a family&#x2019;s ability to pay.
Our founder, Danny Thomas, was a struggling entertainer that one day offered up a simple prayer to St. Jude, the patron saint of hopeless causes, that if he would help Danny find his way in life, Danny would build him a shrine. Danny went on to a fruitful entertainment career, perhaps best known for his starring role in the TV sitcom, &#x201C;Make Room for Daddy.&#x201D; St. Jude Children&#x2019;s Research Hospital is the promised shrine. We are supported primarily by funds from volunteer contributions raised by ALSAC, the fund-raising arm of St. Jude. Some basic information about St. Jude is here for you in the slides.
St. Jude is best known for advancing the treatment of childhood leukemia, though we also research and treat many other catastrophic diseases, including sickle cell, influenza, HIV/AIDS, and other childhood cancers.
And the fruits of our labor over the past 47 years show a massive increase in the national average survival rate for multiple cancers, including an ALL survival rate increase from 4% in 1962 to 94% in 2006.
Part of what has made all of these discoveries possible is a very vibrant research community, both in basic sciences and clinical sciences spaces. Just to give you a cross section of the research landscape at St. Jude, we have 16 academic departments and 5 academic divisions, ranging from Biochemistry to Tumor Cell Biology. We also have the first and only National Cancer Institute designated Comprehensive Cancer Center solely focused on pediatric cancer, consisting of the six programs listed here. Supporting all of this research is our ecosystem of...
...shared resources, which are centralized facilities providing services and access to specialized equipment for research activities. These are very often centered around technology too expensive for individual research programs to maintain their on infrastructure. Some examples of these are our High-throughout DNA Sequencing facility, our Functional Genomics facility providing gene expression array technology, and our Electron Microscopy facility. St. Jude currently has 41 shared resources, of which a little more than half are laboratory-based.
These shared resources all have a common set of operational issues, a few of which include ordering or requisition for services. These can be a simple as a basic form process for service requests to sophisticated scheduling systems for shared instrumentation. Nearly all of these facilities require some form of workflow or process management, where by they track the flow of samples or other items through their facilities, collecting and generating data, (TODO: work on the flow here)...all of this is describe by the umbrella term of &#x201C;LIMS&#x201D; or Lab Information Management System. Finally, most of these facilities operate on a chargeback basis, where by they recover costs by charging investigators grants and other centers of funding for services.
These shared resources all have a common set of operational issues, a few of which include ordering or requisition for services. These can be a simple as a basic form process for service requests to sophisticated scheduling systems for shared instrumentation. Nearly all of these facilities require some form of workflow or process management, where by they track the flow of samples or other items through their facilities, collecting and generating data, (TODO: work on the flow here)...all of this is describe by the umbrella term of &#x201C;LIMS&#x201D; or Lab Information Management System. Finally, most of these facilities operate on a chargeback basis, where by they recover costs by charging investigators grants and other centers of funding for services.
These shared resources all have a common set of operational issues, a few of which include ordering or requisition for services. These can be a simple as a basic form process for service requests to sophisticated scheduling systems for shared instrumentation. Nearly all of these facilities require some form of workflow or process management, where by they track the flow of samples or other items through their facilities, collecting and generating data, (TODO: work on the flow here)...all of this is describe by the umbrella term of &#x201C;LIMS&#x201D; or Lab Information Management System. Finally, most of these facilities operate on a chargeback basis, where by they recover costs by charging investigators grants and other centers of funding for services.
These shared resources all have a common set of operational issues, a few of which include ordering or requisition for services. These can be a simple as a basic form process for service requests to sophisticated scheduling systems for shared instrumentation. Nearly all of these facilities require some form of workflow or process management, where by they track the flow of samples or other items through their facilities, collecting and generating data, (TODO: work on the flow here)...all of this is describe by the umbrella term of &#x201C;LIMS&#x201D; or Lab Information Management System. Finally, most of these facilities operate on a chargeback basis, where by they recover costs by charging investigators grants and other centers of funding for services.
These shared resources all have a common set of operational issues, a few of which include ordering or requisition for services. These can be a simple as a basic form process for service requests to sophisticated scheduling systems for shared instrumentation. Nearly all of these facilities require some form of workflow or process management, where by they track the flow of samples or other items through their facilities, collecting and generating data, (TODO: work on the flow here)...all of this is describe by the umbrella term of &#x201C;LIMS&#x201D; or Lab Information Management System. Finally, most of these facilities operate on a chargeback basis, where by they recover costs by charging investigators grants and other centers of funding for services.
These shared resources all have a common set of operational issues, a few of which include ordering or requisition for services. These can be a simple as a basic form process for service requests to sophisticated scheduling systems for shared instrumentation. Nearly all of these facilities require some form of workflow or process management, where by they track the flow of samples or other items through their facilities, collecting and generating data, (TODO: work on the flow here)...all of this is describe by the umbrella term of &#x201C;LIMS&#x201D; or Lab Information Management System. Finally, most of these facilities operate on a chargeback basis, where by they recover costs by charging investigators grants and other centers of funding for services.
Monolithic Deployment - our core service components and laboratory specific components resided in the same source tree. While we always intended to maintain a degree of separation between these, the lack of a true inheritance model in EJB 2.0 made this extremely difficult. Where a straightforward application of the Strategy pattern in a POJO model would have solved many problems, the inability to do this with EJB would often result in hack solutions where laboratory-specific code would slowly creep into the common components. Another problem occurred when a useful &#x201C;utility&#x201D; class present in the web layer would find an application in the service layer. Rather than factoring out into a common package, the shared source tree facilliated the creation of a circular dependency. Of course neither of these issues is insurmountable with proper discipline, but the programming model did little to prevent it.
Monolithic Deployment - our core service components and laboratory specific components resided in the same source tree. While we always intended to maintain a degree of separation between these, the lack of a true inheritance model in EJB 2.0 made this extremely difficult. Where a straightforward application of the Strategy pattern in a POJO model would have solved many problems, the inability to do this with EJB would often result in hack solutions where laboratory-specific code would slowly creep into the common components. Another problem occurred when a useful &#x201C;utility&#x201D; class present in the web layer would find an application in the service layer. Rather than factoring out into a common package, the shared source tree facilliated the creation of a circular dependency. Of course neither of these issues is insurmountable with proper discipline, but the programming model did little to prevent it.
That said, the core services platform eventually became fairly stable. As we were constantly developing new laboratory-specific extensions, that&#x2019;s here the bugs were. Unfortunately, the monolithic model also led to an isolated defect creating distributed suffering. In this case, we&#x2019;d often need to create downtime for all facilities served by the application to deploy a work stopping fix during the business day. Not good.
The &#x201C;resistance to rapid development&#x201D; created by EJB inspired the use of alternative solutions - i.e. go around the service layer with direct DB access - within the web layer to simply &#x201C;get things done.&#x201D; This inevitably resulted in data integrity issues, as different services were working with the data differently.
That said, the core services platform eventually became fairly stable. As we were constantly developing new laboratory-specific extensions, that&#x2019;s here the bugs were. Unfortunately, the monolithic model also led to an isolated defect creating distributed suffering. In this case, we&#x2019;d often need to create downtime for all facilities served by the application to deploy a work stopping fix during the business day. Not good.
The &#x201C;resistance to rapid development&#x201D; created by EJB inspired the use of alternative solutions - i.e. go around the service layer with direct DB access - within the web layer to simply &#x201C;get things done.&#x201D; This inevitably resulted in data integrity issues, as different services were working with the data differently.
That said, the core services platform eventually became fairly stable. As we were constantly developing new laboratory-specific extensions, that&#x2019;s here the bugs were. Unfortunately, the monolithic model also led to an isolated defect creating distributed suffering. In this case, we&#x2019;d often need to create downtime for all facilities served by the application to deploy a work stopping fix during the business day. Not good.
The &#x201C;resistance to rapid development&#x201D; created by EJB inspired the use of alternative solutions - i.e. go around the service layer with direct DB access - within the web layer to simply &#x201C;get things done.&#x201D; This inevitably resulted in data integrity issues, as different services were working with the data differently.
Going back to our original problem of isolated defects creating distributed suffering, OSGi provides us with a way to circumvent this problem. Now that we can implement our highly-specific, and thus more volatile components as plugins, we have the ability to truly isolate that functionality. OSGi and Spring DM provide us with the ability to expose our core API as OSGi services and then consume those services from the plugins. Further more, as the Spring programming model now ties in nicely with the OSGi lifecycle, it becomes absolutely trivial to register our plugins with the SRM core platform using Spring lifecycle callbacks such as @PostConstruct. And of course, in the event our plugins become more generally useful, nothing whatsoever prevents us from sharing these plugins amongst multiple laboratories.
Going back to our original problem of isolated defects creating distributed suffering, OSGi provides us with a way to circumvent this problem. Now that we can implement our highly-specific, and thus more volatile components as plugins, we have the ability to truly isolate that functionality. OSGi and Spring DM provide us with the ability to expose our core API as OSGi services and then consume those services from the plugins. Further more, as the Spring programming model now ties in nicely with the OSGi lifecycle, it becomes absolutely trivial to register our plugins with the SRM core platform using Spring lifecycle callbacks such as @PostConstruct. And of course, in the event our plugins become more generally useful, nothing whatsoever prevents us from sharing these plugins amongst multiple laboratories.
1. Tour of the metadata editor and downstream user facing functionality
2. Look at 3 Lims Home Screens
3. Do a quick plugin of Lims Home
4. Show the functional lims home dashboard
Demonstrate the round trip stuff:
1) Deploy the Lims Home Client
2) Deploy the Databus Plugin
3) Demonstrate round trip functionality