1. UKOLN is supported by: Distributed Service Registry Workshop Andy Powell, UKOLN, University of Bath a.powell@ukoln.ac.uk Distributed Service Registry Workshop, Warwick, 2005 www.bath.ac.uk a centre of expertise in digital information management www.ukoln.ac.uk

2. 2 House keeping notes Mobiles - please can all mobiles be switched off whilst in the meeting Smoking - is only permitted in the designated areas of the conference centre Internet - wireless access in lounge (wired in bedrooms) – or Internet Cafe Meals - lunch will be served at the times stated on the programme in the restaurant on both Thursday and Friday. The workshop dinner will take place in the restaurant at 7.30 pm. Breakfast – 7.30 to 8.30 Accommodation - all extras (newspapers/drinks) should be paid for on departure by delegates. Any questions regarding accommodation please speak to the Reception Desk All other questions - please speak to Natasha who will be at the registration desk

3. 3 What are we here to do? share knowledge of current approaches in the area of service registries consider the policies, IPR and data ownership issues, metadata schema(s) and protocol(s) necessary to achieve global interoperability of distributed DL service registries agree future work, funding sources and partnerships in this area

4. 4 Why are we here to do it? growing availability of online digital collections and their associated services trend towards Service Oriented Architecture –JISC Information Environment and eFramework, GRID Services, DLF Frameworks activity, VIEWS, … trend towards use of SOAP and Web Services generally trend(?) towards use of portlets (WSRP, etc.)

5. 5 What does this mean significant growth in number of m2m services with which applications can interact requirement to disclose/discover services –in m2m ways –(and in human-oriented ways sometimes!) –on a global basis tempting to see service registries as being like the DNS but how do we do this and what are the issues? –technical (UDDI, OAI-PMH, ZeeRex, metadata), policy, business, IPR, operational, etc., etc.

6. 6

7. 7

8. 8 the University of… err… Warwick

9. 9 Registry distribution UDDI JISC IE SR Institutional SR EDINA SR Grid SR ExLibris SR UDDI Pure UDDI… UDDI

10. 10 Registry distribution (2) UDDI JISC IE SR Institutional SR EDINA SR Grid SR ExLibris SR UDDI Hybrid UDDI… UDDI UDDI/OAI-PMH/SRW/Z39.50 UDDI/OAI-PMH/SRW

11. 11 Registry distribution (3) OAI-PMH JISC IE SR Institutional SR EDINA SR Grid SR ExLibris SR UDDI Hybrid digital library… UDDI UDDI/OAI-PMH/SRW/Z39.50 UDDI/OAI-PMH/SRW

12. 12 JISC IE set the original scope of the IESR to describe collections and services in the JISC IE but what does in mean? e.g. are the Nature and ingenta RSS feeds in or out?

13. 13 Grid/eScience the Grid Engineering Task Force is currently building a network of service registries one per eScience Centre based on UDDI jUDDI (Java-based software platform) focus on services rather than collections? Cambridge Newcastle Edinburgh Oxford Glasgow Manchester Cardiff Southampton London Belfast DL RAL Hinxton

14. 14 NISO Metasearch (see Pete Johnstons presentation) library portal vendors often already offer and maintain a service registry in the form of a configuration database or knowledge base part of the package – i.e. youve already paid for it! what is the vendor view of the IESR –a useful source of info? –a chance to off-load a maintenance headache? –a competing product in the market-place?

15. 15 Web services/eCommerce integration of Web services in eBusiness/eCommerce sector seems to be the main driving force behind UDDI but… public registries at www.uddi.org still completely unusablewww.uddi.org perception that UDDI spec is highly complex tool availability largely limited to Java note that simpler use of WSDL (e.g. see www.xmethods.com) is more successful www.xmethods.com

16. 16 ELF and VRE the JISC E-Learning Framework and Virtual Research Environments attempts to develop service-oriented approach (SOA) to learning management systems and research tools break monolithic systems into smaller service components typically instantiated using SOAP or REST potentially leading to big increase in number of services requiring registration

17. 17 Portals and portlets gradual increase in use of portal frameworks like uPortal for delivering institutional portals integration of multiple portlets within single personalised framework many portlets delivered within the institution (i.e. intranet services) in combination with internal ELF and VRE related activity leads to pressure to deliver institutional (i.e. closed) service registry

18. 18 Distributing the IESR conclusion of all this is that the IESR cannot be seen as monolithic service need to approach it more like the DNS than like Athens! need to think about approaches for distributing the IESR across multiple (probably many!) players –UDDI –digital library technologies like OAI-PMH –P2P approaches?

19. 19 Re-using existing data also need to take advantage of existing sources of service and collection descriptions –Z39.50 Explain –Z39.50/SRW ZeeRex –OAI-PMH friends and neighbours Identify response –RSS channel lists using OPML (Outline Processor Markup Language) i.e. need to populate service registries with existing work whenever possible - rather than causing new work

20. 20 Other shared services also need to think about the interfaces between a distributed SR and other shared services? e.g. who answers the question which services expose metadata that conforms to the UK LOM Core? –the IESR (which holds details about services)? –the IEMSR (which holds information about metadata usage)? –or some combination of both? If so how? choreography of multiple services still an issue

21. 21 Conclusion and issues only one real conclusion… that the future must be distributed rather than centralised but, if so, do issues of –ownership –workflow –terminology –quality assurance get harder or easier (I think they get easier!)

22. 22 Questions…