Notes about MDService and MDBrowser Implementation

MDService

MDService is a REST-style webservice implemented in Java currently based on the ​apache.Struts2 framework (Build around the MVC design pattern). Later migration to Spring is an option. Wrt to the current processing model, which is just passing around xml-streams a look on ​apache.cocoon (Spring-based since last version (2.2)) could be also worthwhile.

MDService serves primarily as a Proxy - passing the (possibly recoded) request to the appropriate Repositories or Registries (source services) and passing back the result. Current implementation even directly passes the incoming result stream back to the user, without any further processing (i.e. also uninformed about the content).

The default response-format is the "raw" xml received from the source service. The request can contain a format-parameter. If the server recognizes this as a valid parameter it performs the appropriate XSLT-transformation upon the original XML and returns back a HTML-snippet. This is meant to be primarily used by the MDBrowser.

Although primary competence of MDService is to serve information from MDRepository, especially user's interaction with MDBrowser (query formulation) requires information from other services as well. These are: ComponentRegistry, VirtualCollectionRegistry, DataCategoryRegistry? and RelationRegistry.

MDBrowser

The image on the right is a snapshot of the current version of the MDBrowser (work in progress).

MDBrowser is the user-interface to the MDService, served currently by the same web-application. It is actually only a boilerplate index.jsp dynamically filled using AJAX (using ​jQuery library). Although this approach is seems very efficient and easy to work with, we have to stay beware of the distinction and try to hold the functionalities cleanly separated (modularization) within the application, allowing for easy refactoring at later stage.

The basic interaction pattern is, that the client (javascript in client's browser) requests during initialization or upon user's interaction a XHTML-snippet from the server and places it in a block on the page. For this it uses the REST-interface of the Webservice with the format-parameter set appropriately (it accepts values like: htmllist, htmldiv, htmltable), which returns the same information (as the default xml-based REST-interface) just transformed into XHTML-snippets.

Four phases can be distinguished in the interaction between MDBrowser and MDService:

1. populating the user interface on initialization
2. contextual help during query building
3. submit query and retrieve the resulting MDCollection
4. retrieve one MDRecord

As stated before MDBrowser needs information also from other sources than just MDRepository. For the sake of uniform interaction patterns, and also due to javascript's security restrictions on cross-site scripting, all the information the browser needs, is provided by the MDService acting as proxy. So be it information from ComponentRegistry or VirtualCollectionRegistry, the browser asks for it via dedicated REST-interfaces of the MDService, which then passes these through to appropriate services, optionally caches the received information, applies the transformations and returns the result back to the MDBrowser.

Current status of implemented functionality

(This chapter is UNDER CONSTRUCTION as of 2010-07-12!)

MDService currently connects to / provides information from ComponentRegistry, DataCategoryRegistry? and mainly MetadataRepository?, all this information is available by default as XML or as an HTML-snippet which is used by the MDBrowser to display these peaces of information to the user. In detail it's following:

collections

this is currently still served from a cached snapshot see #1 for details

elements/terms

this compiled list of elements used in all the profiles with the information on usage in the profiles (think inverted-index) Currently this is for the user to search by just one element irrespective of the various contexts it is used in.

profiles/components/elements

Select one profile, you get all the components and elements listed.

data categories

DataCats? (currently |218|) listed from the Metadata-profile#5 from isocat

A basic search functionality is implemented. Example queries:

 Peter  
 Title any the 

We try out various mechanisms of interaction, so the handling is a bit chaotic or "diverse":

• clicks on a DatCat? => detail information about that DatCat?
• Click on [cmd_filter] copies the name of the Term into the Query field
• Autocomplete in query - lists the available elements.

MDService also implements a primitive cache, so any of the information (from ComponentRegistry, DCR) may not be perfectly up to date.

The whole application is very unstable yet, so you have to expect everything, if you dare to try...

Next steps

• feed collections live from MDRepository #1
• connect to VCR to read and register virtual collections