- Количество слайдов: 22
Distributed Service Registry Workshop Andy Powell, UKOLN, University of Bath a. [email protected] ac. uk Distributed Service Registry Workshop, Warwick, 2005 UKOLN is supported by: www. ukoln. ac. uk a centre of expertise in digital information management www. bath. ac. uk
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
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
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 e. Framework, GRID Services, DLF Frameworks activity, VIEWS, … • trend towards use of SOAP and Web Services generally • trend(? ) towards use of ‘portlets’ (WSRP, etc. )
What does this mean • significant growth in number of m 2 m services with which applications can interact • requirement to disclose/discover services – in m 2 m 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, Zee. Rex, metadata), policy, business, IPR, operational, etc.
the University of… err… Warwick 8
Registry distribution UDDI EDINA SR Institutional SR UDDI Grid SR UDDI JISC IE SR Ex. Libris SR UDDI Pure UDDI… UDDI 9
Registry distribution (2) UDDI/OAI-PMH/SRW UDDI EDINA SR Institutional SR JISC IE SR UDDI/OAI-PMH/SRW/Z 39. 50 UDDI Grid SR UDDI Ex. Libris SR Hybrid UDDI… UDDI 10
Registry distribution (3) UDDI/OAI-PMH/SRW UDDI Institutional SR JISC IE SR UDDI/OAI-PMH/SRW/Z 39. 50 EDINA SR UDDI Grid SR OAI-PMH Ex. Libris SR Hybrid ‘digital library’… UDDI 11
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?
Grid/e. Science • the Grid Engineering Task Force is currently building a network of ‘service registries’ • one per e. Science Glasgow Edinburgh Centre Newcastle • based on UDDI Belfast Manchester • j. UDDI (Java-based DL software platform) Cambridge Oxford • focus on ‘services’ Hinxton Cardiff RAL rather than London ‘collections’? Southampton
NISO Metasearch • (see Pete Johnston’s 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. you’ve 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?
Web services/e. Commerce • integration of Web services in e. Business/e. Commerce sector seems to be the main driving force behind UDDI • but… public registries at www. uddi. org still completely unusable • 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
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
Portals and portlets • gradual increase in use of portal frameworks like u. Portal 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
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 – P 2 P approaches?
Re-using existing data • also need to take advantage of existing sources of ‘service’ and ‘collection’ descriptions – Z 39. 50 Explain – Z 39. 50/SRW Zee. Rex – 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
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
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!)