e-Framework Services Knowledgebase

On Monday 12 February I attended the JISC e-Framework Modelling Workshop. From one of the presentations, about 'Using and Contributing to the e-Framework' (http://www.e-framework.org/) I learnt that the e-Framework activities include developing a knowledge base of Services. The e-Framework is based on a service oriented architecture (SOA), advocating this approach to save development costs by promoting re-use of existing solutions. This does not mean a restriction to SOAP Web Services, many other service protocols that are designed to share data being recognised such as RSS and Z39.50.

Projects are encouraged to register their services in the knowledgebase, both non technical information about what a service does and technical information about how to write such a service. Benefits of this knowledgebase are that developers and institutions can see what others have already done and can possibly re-use contributed software and intelligence, though there is no exclusivity about a particular solution. This knowledgebase should be of value to developers, both as an information source and as a channel through which to distribute their work, if it contains: information on coding with interoperable standards, such as what others have done and specfics such as message sizes; information on data semantics; and links to actual projects and services.

Service details are submitted via a template - a Word document (maybe they need some SOA here...) - and there is a QA process before publication. Services are classified by a genre taken from a vocabulary defined by the e-Framework. The genre essentially describes broadly what the service does, eg Search. Also captured is a 'service expression'. This is a specialisation of a service genre, binding to a particular service, ie. a specified way of doing something. These expressions are standards-based but with more detail for an implementer than the standard may provide, and possibly covering more than one standard (eg. Z39.50 and CQL). The template asks for details about implementation, eg. toolkit used, and also service instances (concrete usable services) and interfaces (eg. WSDL).

The knowledgebase also registers Service Usage Models (SUMs), which are composite services, composed of more basic services. The description of these will include details of process modelling, choreography and workflows, possibly using a business process modelling language, or possibly by UML diagrams. Registration of these SUMs within the e-Framework shoud assist in identifying commonly recurring processes that could be re-used, known as Core SUMs.

I came away from this event wondering how this relates to IESR and service registries generally. They seem to be registering services as details of their software components, rather than how to call and use them. And what is recorded is documentation not actual software for downloading. But the registration of service interfaces and of service instances, even if these are just examples, seems to overlap somewhat with IESR's remit and content. It seems to me that there should be at least some conversation to discuss commonality. Maybe there could be some data sharing to some extent. Of course a big difference is that the e-Framework knowledgebase appears to be aimed at human readers - those who want to develop a service, or those looking for a service to re-use. Whereas the primary purpose of IESR is to provide details to machines as a middleware service.

I considered the e-Framework service genre list when thinking about such a list for IESR a couple of weeks ago. But it seemed to me to be too fine-grained in places and very e-learning biased. In fact some of the finer-grained terms do not seem to fit with the aim of the service genre being the 'big picture' of a service's functionality.

At the start of the workshop we were treated to a showing of an animation that has been developed to demonstrate the benefits of the SOA approach.
See http://www.jisc.ac.uk/whatwedo/programmes/programme_eframework/soa. Enjoy...