eReSS: e-Research Standards and Specifications

1. eReSS: e-Research Standards and Specifications I. Dolphin, R. Sherratt, C. Awre, S. Jeyes and R.J. Allan

2. 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

3. eReSS Consortium • Ian Dolphin, Robert Sherratt, Chris Awre (U. Hull) • Rob Allan, XiaoboWang(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)

4. 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.

5. 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://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.

6. 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!

7. 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.

8. 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.

9. So, how do I become a Standard? JCP - Java Portlet API JSR 168 OASIS TC Web Service for Remote Portals OASIS TC WSIA Family WSRP as the initial spec. OASIS TC Web Service for Interactive Applications Potted history of WSRP Standard Apache JetSpeed Portal WebServices Web Service User Interface uPortal WebService channel 1999 2000 2001 2002 2003 Very rough timeline…

10. 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.

12. Screenshots of Confluence eReSS Wiki Home Page

13. Current Areas of Interest • Standards for: • Accessibility • Business • Communications • Data • DRM/ Licenses • Frameworks • Information • Presentation • Security • User Facing Integration, Customisation and Personalisation • Extensibility • Documentation • Security • Workflow • Lifecycle • Compliance • Standards and specifications • Categories • Technologies • Architectures • Context of use

14. The eReSS Wiki

15. New additions

16. Project categories

17. VRE 1 Projects

18. Use of standards, by VRE project

19. Specifications and standards

20. Categories of Standards

21. Category of Technologies

22. 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…

23. For Portals, we want to do This: JSR-168, WSRP Portlet Portlet Portlet Portlet Portlet SOAP, WSDL, UDDI Service Service Service Service Service Common Services

24. 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?