eReSS: e-Research Standards and
Specifications
I. Dolphin, R. Sherratt, C. Awre, S. Jeyes
and R.J. Allan
Support for JISC VRE Programme
•eReSS was funded by JISC to support the VRE Programme and
related activities from 2006-2009.
•It is an international consortium including experts in a variety of
technical and standards fields. It is lead by University of Hull.
•It will undertake an assessment and review of and provide advice
on the use of specifications and standards within the VRE
Programme and wider e-Research communities.
– Currently we are visiting projects to gain input and requirements
•eReSS uses a Confluence Wiki at:
http://www.hull.ac.uk/esig/eress.html
•There is an introduction and related material at an older Twiki
Wiki:
http://www.grids.ac.uk/eResearch
eReSS Consortium
–
–
–
–
–
–
–
–
–
–
Ian Dolphin, Robert Sherratt, Chris Awre (U. Hull)
Rob Allan, Xiaobo Wang (STFC Daresbury Laboratory)
Rob Crouchley (U. Lancaster)
Mark Baker (U. Reading)
Peter Burnhill, Christine Rees, James Reid, Tim Stickland
(EDINA)
Joseph Hardin (U. Michigan)
Shoji Kajita (Nagoya University)
Steve Jeyes (Edexcel)
Jim Farmer (im+m and Georgetown)
Jon Allen (im+m)
eReSS Activities
• Review on an ongoing basis interoperability standards,
frameworks and technology platforms (tools) and identify their
applicability to VRE development activities.
– It is recognised that these might have their origin within the eResearch arena or have been developed by other sectors and have
potential applicability to e-Research.
• Review current VRE development work and identify
requirements for interoperability. This task will provide a basis
upon which the pragmatic implementation of appropriate
interoperability recommendations can be made.
• Propose suitable interoperability solutions where there are any
and provide guidance to current and future JISC VRE projects as
to their implementation.
– The proposed solution will provide an easy-to-use reference guide
backed up by the expertise of consortium members. This task
could also be used as a vehicle to form feedback on the usability
of international ICT standards for e-Research and propose
changes
or enhancements if required for
future versions.
Related Activities in the UK
In our paper for this workshop we listed a number of related UK
activities to which we will refer:
• JISC VRE 1 e-Research Wiki
• CETIS: Centre for Educational Technology and Interoperability
Standards http://www.cetis.ac.uk
• UKOLN http://www.ukoln.ac.uk
• JISC Standards Catalogue http://standardscatalogue.ukoln.ac.uk/index/JISC_Standards_Catalogue
• E-Framework for Education and Research http://ww.eframework.org
• UK Grid Engineering Task Force
• AHRC ICT Guides http://ahds.ac.uk/ictguides
Standards become more useful as more people use them. We
should encourage all these groups to share experiences.
Why do we need Standards?
• If you’re working on your own, maybe you don’t need any.
• Big organisations might have their own.
• But if you’re working openly with other people, you need to
communicate with them, exchange and use data, information or
software – interoperability.
• Standards are necessary to promote re-usability,
understandability and longevity.
• In software development, standards can help with the vision of
a Service Oriented Architecture of plug-and-play components.
• Agile development?
• Many areas of standards are important, for instance from data
curation to knowledge management.
• But, specifications and standards can be complex, hard to
understand and don’t always fit the use case.
• Standards evolve and new ones arise over periods of several
years.
• We are not the Standards Police!
International Standards Bodies
Just a few:
• W3C: the World Wide Web Consortium http://www.w3c.org
• IETF: the Internet Engineering Task Force http://www.ietf.org
• OASIS: Organization for the Advancement of Structured
Information Standards http://www.oasis-open.org
• ANSI: American National Standards Institute
http://www.ansi.org
• ISO: International Standards Organization http://www.iso.org
• OGF: Open Grid Forum http://www.org.org
Some companies set up their own.
The good thing about standards is there is always more than
one to choose from.
Agreed Standard or Folksonomy?
• We can list and reference agreed standards, but
• What do we do about “de facto” standards?
• Some standards are “bent” to fit the purpose – should we lobby to
encourage changes in later versions?
• Of course there is also Wikipedia http://www.wikipedia.org
Wikipedia defines ``standard'‘ to mean: Typically Standards are
produced by many organization (or groups of cooperating entities),
some for internal usage only, others for use by groups of people,
groups of companies, or an entire industry. They form interest
groups, that obtain mutual gains in coordinated action if they
ensure a "group-wide" uniformity in measure (for comparative
evaluations), or in a technical reference level of quality or
attainment. Different classes of standard are defined and many
individual ICT standards are listed. Many tools are also listed,
for instance Sakai and uPortal.
So, how do I become a Standard?
Potted history of WSRP Standard
Apache JetSpeed Portal
JCP - Java Portlet API
JSR 168
OASIS TC
Web Service for Remote Portals
WebServices
OASIS TC
WSIA Family
WSRP as the initial spec.
Web Service User Interface
OASIS TC
Web Service for Interactive Applications
uPortal
WebService channel
1999 2000
2001
Very rough timeline…
2002
2003
eReSS: the First Year
The project started in March 2006 with an initial six-month
phase to capture current usage of standards, specifications, tools
and technologies within the JISC VRE 1 programme and document
this in the Wiki. This work formed both the baseline for
subsequent activities within the study and also fed into the
development of the current VRE 2 Programme.
The Wiki now has three sections:
• Overview - a categorisation of standards used and details of
technologies used in e-Research;
• Details of each specification and standard;
• Contextual use of the standard.
eReSS Wiki Home Page
Screenshots of Confluence
Current Areas of Interest
•User Facing
Integration,
Customisation and
Personalisation
•Extensibility
•Documentation
•Security
•Workflow
•Lifecycle
•Compliance
Standards for:
• Accessibility
• Business
• Communications
•Standards and
specifications
•Categories
•Technologies
•Architectures
•Context of use
• Data
• DRM/ Licenses
• Frameworks
• Information
• Presentation
• Security
The eReSS Wiki
New additions
Project categories
VRE 1 Projects
Use of standards, by VRE project
Specifications and standards
Categories of Standards
Category of Technologies
A Good Example
Personally I believe portals tell a good story of how standards
can help with both interoperability and uptake.
• We held our “Portals and Portlets 2003” workshop in July 2003,
a month before two significant Java standards, JSR-168 (Java
Portlet Specification) and WSRP (Web Services for Remote Portlets)
were ratified.
• It is now possible to develop and re-use portlets in many
compliant frameworks: eXo Platform, GridSphere, LifeRay,
StringBeans, Pluto, WebSphere, BEA Portal, …
• Even Sakai now has a JSR-168 native interface and WSRP
producer/ consumer [winks offline to Chuck…]
• We can combine: educational tools, collaboration and group
working tools, research tools, audio-visual conferencing, Grid
computing and data analysis, data and information cross
searching and retrieval…
For Portals, we want to do This:
JSR-168, WSRP
Portlet
Portlet
Portlet
Portlet
Portlet
Service
SOAP, WSDL, UDDI
Service
Service
Common Services
Service
Service
Some remaining Problems
• Remaining problems are often to do with older “stovepipe”
software.
• These mostly integrated, in one package and without using
open standards, security, authentication and authorisation,
access control, search, model, view, control.
• Extending or re-factoring such software is extremely difficult.
• Internal role-based access mechanisms of two packages will be
different and often have incompatible definitions.
• Security standards such as Shibboleth are hard to integrate into
this environment.
• Moving data between packages is extremely difficult.
• Take Wiki tools as an example: there are many of them, each
has a different internal structure, access control mechanism, Wiki
language and data format. They are not inter-operable, cannot be
integrated with other software and cause lock-in. We faced this
problem with Sakai, initially looked at Xwiki, but eventually the
CARET group in Cambridge developed Rwiki. A case of reinventing the wheel,