ukoln is supported by: distributed service registry workshop andy powell, ukoln, university of bath...
TRANSCRIPT
UKOLN is supported by:
Distributed Service Registry Workshop
Andy Powell, UKOLN, University of Bath
Distributed Service Registry Workshop, Warwick, 2005
www.bath.ac.uk
a centre of expertise in digital information management
www.ukoln.ac.uk
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
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
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
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
7
8
the University of… err… Warwick
9
Registry distribution
UDDI
JISC IESR
InstitutionalSR
EDINASR
GridSR
ExLibrisSR
UDDI
UDDI
UDDI
UDDI
Pure UDDI…
UDDI
10
Registry distribution (2)
UDDI
JISC IESR
InstitutionalSR
EDINASR
GridSR
ExLibrisSR
UDDI
UDDI
Hybrid UDDI…
UDDI
UDDI/OAI-PMH/SRW/Z39.50
UDDI/OAI-PMH/SRW
11
Registry distribution (3)
OAI-PMH
JISC IESR
InstitutionalSR
EDINASR
GridSR
ExLibrisSR
UDDI
UDDIHybrid ‘digitallibrary’…
UDDI
UDDI/OAI-PMH/SRW/Z39.50
UDDI/OAI-PMH/SRW
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
Grid/eScience
• the Grid Engineering Task Force is currently building a networkof ‘service registries’
• one per eScienceCentre
• 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
RALHinxton
14
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?
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 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
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
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
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
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
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
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
Questions…