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

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.