2006-04-04 - rutgers_escience_v04

1. Collaborative eScience:
Evolving Approaches
Charles Severance
Rutgers CyberInfrastructure Meeting
April 4, 2006
www.dr-chuck.com

2. Outline
• A look back at the past 15 years
• Putting the “collab” in Collaborative eScience
• The current tools of Collaborative eScience
– Collaboration
– Portals
– Repository
• Reflecting on 15 years of Experience
– What is wrong with Middleware?
– Authorization and Authentication - Are we there yet?
• A “future” eScience Case Study

3. The Founding Concepts
• Scientific Domain
• Groups of People
• Common User Interface
• Data Sharing
– In the moment
– Long-term
• Experimental Equipment
• Compute
• Visualization

4. Over 15 Years of Collaborative eScience
SCIGate ?
OGCE Grid Portal
NEESGrid NEESIT
Worktools CHEF Sakai
Globus Tool Kit
UARC/SPARC
1991 - 1999 2000 2001 2002 2003 2004 2005 2006 2007

5. What was SPARC?
Before
UARC..

6. What was SPARC?
UARC/
SPARC

7. SPARC
2/2001 600 users 800 data sources

8. SPARC Software
• Written from scratch
– No Middleware
– No Portal Technology
• Three rewrites over 10 years
– NextStep
– Java Applets with server support
– Browser based - kind of like a portal
• At the end, in 2001 - it was ready for another
rewrite

9. Keys to SPARC Success
• Ten years of solid funding
– Team consistency
– Long enough to learn from “mistakes”
• Long term relationship between IT folks and
scientists - evolved over time - relationship
was “grey”
• Software rewritten several times over life of
project based on evolving user needs and
experience with each version of the program
• Portion of effort was invested in evaluation of
usability - feedback to developers

10. After SPARC: Now What?
• Getting people together is an important part of
collaborative eScience
– WorkTools - Based on Lotus Notes
– CHEF - Collaborative framework - Based on Java and
Jetspeed
– Sakai - Collaboration and Learning Environment - Java
• Critical point: Collaborative software is only one
component of eScience
• UM Focus: Building reusable user interface
technologies for the people part of collaborative
eScience

11. WorkTools
WorkTools - The “organic”
single-server approach - if
you build it (and give away
free acounts), they will
come…
Over 9000 users (2000 active) at the end of 2003

12. CompreHensive CollaborativE
Framework (CHEF)
• Fall 2001: CHEF Development begins
– Generalized extensible framework for building
collaboratories
• Funded internally at UM
• All JAVA - Open Source
– Jakarta Jetspeed Portal
– Jakarta Tomcat Servlet Container
– Jakarta Turbine Service Container
• Build community of developers through workshops
and outreach

13. CHEF Applications
• CourseTools Next Generation
• WorkTools Next Generation
• NEESGrid
• NSF National Middleware Grid Portal

14. NEESGrid - The Equipment
Network for
Earthquake
Engineering
Simulation
NSF Funded.
NCSA, ANL, USC/ISI, UM, USC, Berkeley, MSU

15. CHEF-Based NEESGrid
Software

16. Overall Data Modeling Efforts
NEES
Site
Specifications Site A Site B Site C
Database
Equipment Equipment People
People
Project Trials
Experiments
Description Experiments Trials
Domain
Tsnumai Shake Table Geotech Centrifuge
Specific
Specimen Specimen Specimen Specimen
models
Common
Elements Units Sensors Descriptions
Data / Data Data Data
Observations

17. Capturing Video and Data
PTZ/ Still Camera Control
USB Capture Gateway
DT Client
Video DT Main System
BT848
Frames
DT Client
Data
DAQ
Capture
DT Client
Simulation
Coordinator Site B
Site A

18. Data Monitoring Tools
Still Image / Camera Control
Camera Control Still image
Gateway camera
control
^
< >
^
DT Main System ~ < >
Thumb-
nail
Creare
viewers

19. What’s in a name?
Sakai is named after
Hiroyuki Sakai of the Food
Channel Television
program “Iron Chef”.
Hiroyuki is renowned for his
fusion of French and
Japanese cuisine.

20. Sakai General Collaborative Tools
• Announcements
• Assignments
• Chat Room
• Threaded Discussion
• Drop Box
• Email Archive
• Message Of The Day
• News/RSS
• Preferences
• Resources
• Schedule
• Web Content
• Worksite Setup
• WebDAV

21. Requirements Overlap
Grid Computing
Quizzes Physics
Visualization
Grading Tools Research
Syllabus Collaboration
SCORM
Teaching
and Data Repository
Learning
Chat
Discussion Earthquake
Resources Research Large Data
Collaboration Libraries

22. Sakai: Product Placement
Teaching
and
Learning
Collaboration and eResearch

23. Additional General Collaboration
Tools Under Development
• Wiki based on
Radeox
• Blog
• Shared Display
• Shared
Whiteboard
• Multicast Audio
• Multicast Video
These are works-in-progress by members of the Sakai eResearch community. There are no dates for release.

24. NMI / OGCE
www.ogce.org
NSF National Middleware Initiative
Indiana, UTexas, ANL, UM, NCSA

25. Chalk Talk:School of Portals (2004)
NEES 1.1 NEES 3.0
CHEF OGCE 1.2 ?
Jetspeed OGCE 1.1
OGCE 2
Sakai
GridPort 2
GridPort 3
GridPort
Alliance uPortal GridSphere
XCAT
Competition Collaboration Convergence

26. Chalk Talk:School of eScience Portals (2006)
NEES 1.1 GridSphere
CHEF OGCE 1.1
OGCE 2
Jetspeed SciGate ?
Sakai
GridPort 2 GridPort 3
SciDoc
uPortal
GridPort
Alliance
XCAT
Competition Collaboration Convergence

27. Integration and Applications
Atlas ITER CMS
Administration and Users
Configure: Atlas Portal
Experiment Gateway
Process Portal Gateway Desktop Gateway Technologies
Control
Knowledge Store
…
Sakai
SRB
KnowledgeStore
Opal Management
Clarens Experiment Components
Simulation
Process
Metadata
Control
…
…
Configure: ITER Portal
Experiment
Process Services and
BlueGene
MetaData
Control
Security
Clarens
Components
Identity
Globus
ORNL
Sakai
Knowledge Store
Opal
SRB
Sakai
…
SRB
Opal
Clarens
Metadata SciGate Petascale Petascale Resources
Production Compute Data

28. The Ecology of Collaborative
eScience

29. Scope of Collaborative E-Science
“..composing and orchestrating “..interoperability is key…”
many technologies…”
Portal
Technology
Data
Collaborative Sources
Tools
Identity
ACL Shared Data
Repository Knowledge
Compute
Tools

30. Portals are an excellent
technology for building a
User Interface for federated user interface
Collaborative E- across these disparate
components using
Science standards like JSR-168.
Portal
Technology
Data
Collaborative Sources
Tools
Identity
ACL Shared Data
Repository Knowledge
Compute
Tools

31. Portals may only
be an intermediate
step in the
Desktop
Applications
process..
Portal
Technology
Data
Collaborative Sources
Tools
Identity
ACL Shared Data
Repository Knowledge
Compute
Tools

32. Sakai is focused primarily
Focus of Sakai on integration with portals
Activity in eScience and working closely with
data repositories.
Dis
cus
sF
irst
Portal
Technology
Data
Collaborative Sources
Tools
Identity
ACL Shared Data
Repository Knowledge
Compute
Tools

33. Collaboration .vs. Portal
• Basic organization is about the • Basic organization is about the
shape of the people and groups thing it represents - Teragrid,
• Customization based on the “group NVO
leaders” • Site customization is based on
• New groups form quickly and the resource owners
organically
• Sometimes there is an
• Doing one thing at a time - chat,
upload - perhaps multiple active individual customization aspect
windows on a desktop • Many small rectangles to
• Very interactive provide a great deal of
• Think of navigation as picking a tool information on a single screen
or switching from one class to • Portals think of rectangles
another operating independently - like
• Think “Application” windows
• Think “Dashboard”

34. Sakai Portlet Version 0.2
Announcements (sakai.announcements)
Assignments (sakai.assignment)
• Tree View Chat Room (sakai.chat)
Discussion (sakai.discussion)
• Gallery View Gradebook (sakai.gradebook.tool)
Email Archive (sakai.mailbox)
• Proxy portlets Membership (sakai.membership)
Message Forums (sakai.messageforums)
• Source in SVN Preferences Tool (sakai.preferences)
Presentation (sakai.presentation)
• Configurable via Profile (sakai.profile)
Resources (sakai.resources)
properties file Wiki (sakai.rwiki)
Tests & Quizzes (sakai.samigo)
Roster (sakai.site.roster)
Schedule (sakai.schedule)
Site Info (sakai.siteinfo)
Syllabus (sakai.syllabus)

35. Sakai JSR-168 Portlet
• Web Services are used to login to Sakai
establish a session and retrieve a list of
Sakai Sites, Pages, and Tools
• The portlet is 100% stock JSR-168
– Works in Pluto, uPortal, and GridSphere

36. Three Variations
• Display the Sakai gallery - all of Sakai
except for the login and branding.
• Retrieve the hierarchy of sites, pages
and tools display in a tree view with the
portlet and show selected tools/pages in
an iframe within the portlet
• Proxy tool placement for a particular
Sakai tool such as sakai.preferences

37. Sakai Gallery View

38. uPortal, Pluto, or GridSphere
Sakai
Portlet
Login
/portal/gallery
Charon
How Gallery Works
Web Svcs
Portal
Sakai

39. Sakai Tree View

40. uPortal, Pluto, or GridSphere
Sakai
Portlet
Login
ToolList
/portal/page/FF96
Charon
Web Svcs
Portal
How Tree View Works
Sakai

41. Sakai Proxy Tool

42. Proxy Tool Selection

43. 1
uPortal, Pluto, or GridSphere2
Sakai
Portlet
Login
SiteList
/portal/page/FF96
Charon
Web Svcs
How Proxy Portlet Works
Portal
Sakai

44. SakaiSite.getToolsDom
<sites>
<portal>http://localhost:8080/portal</portal>
<server>http://localhost:8080</server>
<gallery>http://localhost:8080/gallery</gallery>
<site>
<title>My Workspace</title>
<id>~csev</id>
<url>http://localhost:8080/portal/worksite/~csev</url>
<pages>
<page>
<id>af54f077-42d8-4922-80e3-59c158af2a9a</id>
<title>Home</title>
<url>http://localhost:8080/portal/page/af54f077-42d8-4922-80e3-59c158af2a9a</url>
<tools>
<tool>
<id>b7b19ad1-9053-4826-00f0-3a964cd20f77</id>
<title>Message of the Day</title>
<toolid>sakai.motd</toolid>
<url>http://localhost:8080/portal/tool/b7b19ad1-9053-4826-00f0-3a964cd20f77</url>
</tool>
<tool>
<id>85971b6b-e74e-40eb-80cb-93058368813c</id>
<title>My Workspace Information</title>
<toolid>sakai.iframe.myworkspace</toolid>
<url>http://localhost:8080/portal/tool/85971b6b-e74e-40eb-80cb-93058368813c</url>
</tool>
</tools>
</page>
</pages>
</site>
</sites>
New WS method is upwards compatible with

45. Sakai Repository Integration
Approach

46. Sakai is focused primarily
Focus of Sakai on integration with portals
Activity in eScience and working closely with
data repositories.
Portal
Technology
Data
Collaborative Sources
Tools
N ow
c us s
Di s
Identity
ACL Shared Data
Repository Knowledge
Compute
Tools

47. Collaboration .vs. Repository
• Many different systems may be • Generally one system for the
active at the same time area
• Systems evolve, improve, and • Long term strategic choice for
are often replaced every few institution
years • System focused on accessing,
• Systems focused on the indexing, curation, and storage
dynamic needs of users and • Millions of high quality objects
applications properly indexed
• Thousands of simultaneous • Data and metadata quality
online users • Must enforce standards and
• Performance tuning workflow to insure data quality
• Must be very easy to use; • Most use is very purposeful:
almost unnoticeable search, publish, add value
• Used informally hundreds of • Think “Library”
times per day per user
• Think “E-Mail”

48. Inbound Object Flow
Search
The lens or
View
disseminator
Reuse
understands
Sakai DR the data
model and is
Index Lens capable of
rendering the
objects. The
Store
Prepare for
lens is part of
Create and storage the DR.
use in
Data
native form
Model
Curate, convert,
update and
maintain over
Ingest time
The DR establishes a data model for “site” Preparation for storage may
objects. The CLE hands sites to the DR. The include cleanup, conversion,
DR may have to do “model” or content cleanup copyright clearance, and other
before completing the ingest process. workflow steps.

49. Outbound Object Flow
Sakai can find and
re-use objects in the
Search
repository.
View
View
Sakai
Search Index Lens Lens
Reuse
Reuse Data
Model
Data
DR Model

50. Sakai and Repositories Going
Forward
• Instead of solving the problem by creating a single
DR technology that is a superset - which might take
years
• Focus on data portability between systems - reduce
the impedance mismatch (or needed conversion
between systems)
• RDF enables object portability across systems,
languages, and technologies

51. Sakai Repository Approach
• Move Sakai and other Collaboration systems toward
RDF
– Experiment with using RDF as native storage format
– High Performance RDF - Fedora testing - 180M tuples -
complex queries - 70ms
• Move data repositories toward RDF
– Move from schema-based stovepipe objects to OWL/RDF
based objects with referential integrity
– Explore dimensions of portability of disseminator / lenses -
this is an important research area
• Get started immediately….

52. Fedora Images

53. Some Reflections

54. Where is the Middleware?
“..composing and orchestrating “..interoperability is key…”
many technologies…”
Portal
Technology
Data
Collaborative Sources
Tools
Identity
ACL Shared Data
Repository Knowledge
Compute
Tools

55. Is Middleware The Universal Connector?
Portal
Collaborative
Technology Data
Tools
Sources
Identity
ACL
Middleware
Shared
Data Knowledge
Compute
Repository Tools

56. The Universal Connectors
Portal
Collaborative
Technology Data
Tools
Sources
tcp/ip http/https
Identity
ACL web services
Shared
Data Knowledge
Compute
Repository Tools

57. Is Middleware “inside” each
application?
Portal
Technology
Data
Collaborative Sources
Tools
Identity
ACL Shared Data
Repository Knowledge
Compute
Tools

58. Middleware is simply another component -
used as needed
Portal
Technology
Data
Collaborative Identity Sources
Tools ACL
Middleware
Shared Data
Repository Knowledge
Compute
Tools

59. Identity and Access Control: A very important
function of Middleware
Portal
Technology
Data
Collaborative Identity Sources
ACL
Lets Talk about This
Tools
Middleware
Shared Data
Repository Knowledge
Compute
Tools

60. Chalk Talk:Identity and Access Control
CAS
??
Shibboleth
MyProxy GridShib
Globus
Identity
K.X509 ACL
Kerberos
???
LDAP
Cosign
PubCookie
Competition Collaboration Convergence

61. Identity and ACL: Goal State
• One server - one software distribution
• Virtual Organization Software
• Supports all protocols
– Globus Certificate Authority
– Shibboleth
– LDAP
– MyProxy
– Kerberos
• Who will do this? Who will fund this? Who
can get these competitors to cooperate?

62. AUTHN/AUTHZ Meetings

63. My eScience Fantasy

64. The pre-requisites
• My net worth is $5B (I give myself grants)
• I encounter some tech-savvy scientists in a field who
are using technology to do world-class research…
• They have never been visited by any other computer
scientist…
• They are working in groups of 1-30 geographically
distributed around the world
• They all work on a beach with Internet2 connections
and wide-open wireless and favourable exchange
rates

65. D
A
Experiments
Compute
E
B Remote Observation
Data Models
Vol 4
Vol 3
Vol 2
F Vol 1
C eDocuments
Tutorials

66. Step 1: Visit The Scientists
• Understand what they are doing and how
they are doing it?
• Ask them how they would like to improve it.
• Show each application to other scientists.
Ask the other scientists how they would
improve it.
• Help each group improve their work - help
them using whatever technology they are
currently using

67. Step 2: Add some technology
• Install the super-multi-protocol Virtual
Organization software and provide a NOC for
the VO software - identity and simple
attributes
• Install Sakai - point it at the VO software for
identity add icon at the top of Sakai
• Give each scientist an account in the VO
• Give each effort in the field a site within Sakai

68. Heart Study Collaboratory
Login
My Workspace A B C D E Open Forum
Home
Chat
Resources
Tutorials
Site B
Mail List
Live Meetings

69. Step 2: Use the VO
• For those who want to protect their
information, help them add SSO to their
sites, backed by the VO service
• Since it is multi-protocol - likely there
will be no modification of the underlying
science code - only a server
configuration change Identity
ACL

70. D
A
Experiments
Compute
E
B Remote Observation
Data Models Heart Study Collaboratory
Login Vol 4
My Workspace A B C D E Open Forum Vol 3
Home
Vol 2
F
Chat
Resources Vol 1
Tutorials
Site B
Mail List
C
Live Meetings
Identity eDocuments
ACL
Tutorials

71. Step 4: Unique Identifier
Service
• Come up with a way for any member of the VO to “get” a unique
identifier
• Demand some information (build a little data model)
– Person’s name and organization (implicit from request)
– What kind of thing this will represent (experiment, document, image
series)
– Simple description
– Keyword/value extensions
• Build an simple way request and retrieve these through a simple
web service - capture implicit metadata from request (when, IP
address, etc). Make sure it works from perl!
• Encourage community to start marking “stuff” with these
identifiers in their stovepipes

72. Step 5: Data Models
• Begin to work with subsets of the field to try to
find common data models across stovepipes
• Start simple - use very simple RDF - human
readable
• Broaden / deepen model slowly - explore
variations
• Define simple file-system pattern for storing
metadata associated with a file and/or a
directory

73. Step 6: A Backup-Style Repo
• Build a data repository which will function as
a backup
• Basic idea - each time you get identifier - this
enables backup space - any data and/or
metadata can be uploaded under that
particular identifier and left in the repository
• Make the repo multi-protocol, FTP, DAV,
Web-Service with attachments, GridFTP, etc.
• Make it so there can be a network of
cooperating repositories

74. Local
Central Repo
Repo D
A
Experiments
Compute
E
B Remote Observation
Data Models
GUID Vol 4
Vol 3
Service Vol 2
F Vol 1
Identity C Heart Study Collaboratory
My Workspace A B C D E
Login
Open Forum eDocuments
ACL
Home
Chat
Resources
Tutorials Tutorials
Site B
Mail List
Local
Repo
Live Meetings

75. Year 4 and on…
• Once the basic stovepipes have been “brought in
from the cold” and made part of a community with no
harm, the next steps are to begin to work “cross-
stovepipe”
– Evolve data models to be far richer with many variants
– Build value added tools that are aware of the data models
and are usable across stovepipes
• Teach the community to build and share tools - gently
encourage development standards - Java / JSR-168
perhaps
• Most important: Always listen to the users

76. Science at … start at the center
and work outwards…
the center of New Tools
eScience
Data Models
New Technologies
Connect
Communicate
Repositories Science
Priority
Scientists
Enhance
Data Storage
… apply technology
when the users will New Approaches
see it as a “win” …

77. Conclusion
• Many years ago, eScience had science as its
main focus
• Custom approaches resulted in too many
unique solutions
• Computer scientists began a search for the
“magic bullet” - each group found a different
magic bullet
• Each group now competes for mind share
(and funding) to be the “one true” magic bullet

78. Conclusion (cont)
• One way to solve the “many competing technologies”
solution is to form “super groups” which unify the
technologies
• No single technology gets to claim “they are the one”
(Middleware is not “in the middle”)
• Each technology needs to become a drop-in
service/component which is available for use only
when appropriate
• Once we can get past looking at the technologies as
the main focus, we get back to science as the main
focus

79. Lets remember why we started this
whole field in the first place…
• Scientific Domain
• Groups of People
• Common User Interface
To download
• Data Sharing www.dr-chuck.com
– In the moment “Chuck’s Talks”
– Long-term
• Experimental Equipment
• Compute
• Visualization