Web Services

This is one of the sessions I’ve been looking forward to most. Firstly Mark Ellingsen is talking about web services, and their relation to library technologies and Ex Libris products.

Web services are technologies which enable inter-application communication. They are based around the exchange of information in XML format, using standard protocols (usually http)

One key component of web services is XSD – the XML Schema Definition language. This provides structure, validation rules, data type constraints and inter-element relationships – i.e. they define what the information can be put into the xml document, and how the information is structured.

There are two approaches to constructing web services – one based around SOAP, and the other based on REST.

The first approach uses three components:

  • SOAP (Simple Object Access Protocol) is a standard messaging format
  • WDSL is the Web Services Description Services Langugage – it defines web services
  • UDDI – Universal Description, Discovery and Integration – allows for the registration of web services to make them finable and usable by other applications.

Second architectural style is REST – Representational State Transfer – in this style the URI is a representation of a resource, the clien then moves (transfers) from stat to stat based on a transition from one URI to another. HTTP methods like GET and PUT are used to changes states.

SOAP is supported by many major players – including IBM, Sun and Microsoft. REST is easier to implement but is restricted to http transport.

In the library world – Fedora, Amazon and ZING all support SOAP and REST (or REST like) approaches.

Also in this area is WSRP – Web Services for Remote Portlets – which allows the integration of a portlet (or ‘channel’) into a portal environment. This is aimed at ‘plug and play’ approach to portals, which are currently often built by hand. For example, we supply Aleph patron data in the RHUL portal – but it is all specially coded, and had to be re-coded when we upgraded from one version of Aleph to another.

Aleph X-Services are a step in the right direction, but are not currently web services, which makes them difficult to utilise in a practical situation.

However, you need to approach the problem from both sides – web services don’t make a useful environment – they just enable integration and communication between systems. We need to understand what we are trying to do – what systems need to talk to each other, and what they need to be able to say – then we need web services to support these interactions.

Mark is now mentioning the DLF Service Framework – something I obviously need to look at. The Working Group report indicates that we need to understand what services we need to provide, and that the abscence of common models stop us developing useful services.

The DLF defines a service as ‘a functional componenet which it is useful to talk about as a unit’. Mark adds to this, but I didn’t get down his additions in time – slow down Mark!

The DLF asked ‘At what level of granularity and aggregation should service be designed?’ – that is to say, should we look at a ‘library service’ or a ‘loan renewal’ service – what level should we look at. I suspect that we need to group services together somewhere between these levels – so ‘library patron services’, ‘search and retrieval services’. I also suspect that librarians (myself included) tend to be too granular when we think about the services we supply.

Going onto Mark’s next slide – before we can define the services, we need to think about our business processes – until we understand this, we cannot define the services we need, and then develop APIs and build useful applications.

Finally Mark is mentioning VIEWS – Vendor Initiative for Enabling Web Services – this is a vendor initiative. However Mark sees them focussing on the wrong things initially – Gateway searching and Authentication and Authorisation – these are things that are already being worked on by other organisations. It would be more interesting, Mark suggests, to focus on things such as financial transactions and interactions with e-learning systems.

So – Mark’s tasks for the library community:

We need to understand library processes
Need to understand how they interface with other processes with the organisation

Mark says he hasn’t ever seen a diagram which shows the interactions between the library business process and the rest of the institution.

and tasks for Ex Libris:

Integrate web services into the x-service API, and provice a more functionally rich x-services environment.

4 thoughts on “Web Services

  1. Painting a moving train

    Blogged conference reports can be somewhat telegraphese – but are often interesting to scan. Here are a couple – followed by an observation. Richard Akerman blogs the Info-grid conference over several entries beginning here. A while ago, Overdue Ideas …

  2. Painting a moving train

    Blogged conference reports can be somewhat telegraphese – but are often interesting to scan. Here are a couple – followed by an observation. Richard Akerman blogs the Info-grid conference over several entries beginning here. A while ago, Overdue Ideas …

  3. Web Services

    Je n’étais pas le seul bloggueur à la conférence ICAU ’05. Il y avait aussi Owen Stephens, qui a posté plus complétement que moi, et en direct: je ne savais pas qu’il était là, dommage, je serais allé lui faire

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.