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 e-Research 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 UKIn 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://standards-

catalogue.ukoln.ac.uk/index/JISC_Standards_Catalogue •E-Framework for Education and Research http://ww.e-

framework.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 BodiesJust 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?

Apache JetSpeed Portal

WebServices

Web Service User Interface

JCP - Java Portlet APIJSR 168

OASIS TCWeb Service for Remote Portals

1999 2000 2001 2002 2003Very rough timeline…

OASIS TCWeb Service for Interactive Applications

OASIS TCWSIA Family

WSRP as the initial spec.

uPortal WebService channel

Potted history of WSRP Standard

eReSS: the First YearThe 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.

Screenshots of ConfluenceeR

eSS

Wik

i Hom

e P

age

Current Areas of Interest

•User Facing Integration, Customisation and Personalisation

•Extensibility•Documentation•Security•Workflow•Lifecycle•Compliance

Standards for:

•Accessibility

•Business

•Communications

•Data

•DRM/ Licenses

•Frameworks

•Information

•Presentation

•Security

•Standards and specifications•Categories•Technologies•Architectures•Context of use

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 ExamplePersonally 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…

Common Services

SOAP, WSDL, UDDI

Portlet

Portlet

Portlet

Portlet

Portlet

Service ServiceService

Service

Service

JSR-168, WSRP

For Portals, we want to do This:

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 re-inventing the wheel, or a necessary pain?