Project: Component Registry

The Component Registry stores CMDI metadata components and profiles and offers a service to list and retrieve them. The BrowserGui is a web application displaying available components in the component registry in the correct context: application domain, creator, creation date, version, etc. The registry offers a hierarchical structure for browsing the components.

The Component Registry has means to keep itself coherent and consistent: check all offered components and keep an administration of the added and removed components. All components get a unique identifier wherewith other applications can identify it to the registry.

Components and profiles are specified and stored in a format specified by the general component schema. The registry offers profile schema's in the XSD format, which get generated from the profile specifications on the fly using the comp2schema XSLT.

---

Subpages

• REST service describes the Component Registry rest service
• BrowserGui describes the Component Registry Flex UI for browsing and editing
  • To get started working on the Flex code, please read these instructions.
• ManagingGroups describes how to manage user groups

Contents

1. Project: Component Registry
   1. Subpages
   2. Contents
   3. People
   4. Getting code
   5. System Requirements
   6. Development process
   7. Milestones and Planning
   8. Building and Deploying
      1. Building
      2. Deployment
      3. Dependencies
   9. Management
      1. Administration interface
      2. Managing user groups
   10. Design
   11. Tickets
   12. History
       1. Historical pages

---

People

• Project owner: Twan Goosen
• Developer: George Georgovassilis
• Developer: Olha Shkaravska

People who have worked on the Component Registry and Editor in the past:

• Patrick Duin (original developer)
• Jean-Charles Ferrières

---

Getting code

The source is available from the Clarin SVN repository (ComponentRegistry/trunk).

---

System Requirements

To serve:

• Java 1.6
• Tomcat 6
• PostgreSQL server

To run the Flex client:

• Web browser
• Adobe Flash Player

To build:

• Java 1.6
• Maven 2
• Flex SDK 3.6

---

Development process

• Feature implementations and fixes are assigned to milestones; one milestone per minor version
  • Features are decided on by MPI-PL (primary contacts: Daan Broeder, Dieter van Uytvanck) in consultation with the taskforces (see ​this presentation) and the CLARIN development community (mailing list: ​dev@lists.clarin.eu)
  • Issues get reported through ​cmdi@clarin.eu (as mentioned ​here)
• Active development happens in trunk
• As soon as the items on the version milestone have been reached, a branch is created (e.g. 1.15.0) and minor version number in trunk is bumped
• The branched version gets deployed to a testing server (lux16) and is tested internally at MPI-PL (by Corpus Management) according to a test plan. For this, create a testing ticket on the MPI TRAC.
• Once testing has completed successfully, the new version gets deployed to the production server (catalog.clarin.eu, see ServerConfig? for info and contacts). For this, create a deployment ticket on the MPI TRAC.
• The deployed version gets tagged
• Development for the next minor version continues in the trunk
• Maintenance releases may be done to the current production branch (leading to e.g. 1.15.1)

---

Milestones and Planning

There are 3 milestones to go:

• ComponentRegistry-1.14, due the end of July 2014. In this release the group management and concurrent-service issues must be fixed (see the tickets).
• ComponentRegistry-1.15, due the end of September 2014. In this release support of public visibility of development ('private') components must be fixed (see the tickets).
• ComponentRegistry-1.16, due the end of December 2014, depending on CMDI 1.2 readiness. On top of adjusting to CMDI 1.2, it consists of a number of tickets to fix, under which the most critical are Component and profile versioning/deprecation and adding of persistent_id to authorization part of SHHAA configuration.

---

Building and Deploying

For specific information about building and deploying the separate modules, see their respective pages:

• Building and deploying the REST service
• Building and deploying the Flex UI

Building

There is a modular Maven project (pom) that contains both the REST service and the Flex UI.

Deployment

To deploy the REST service including the Flex UI and its HTML wrapper, deploy the build output (WAR file) of the REST service to a Tomcat instance.

For details, see deploying Component Registry REST service.

Currently Deployed Locations

• Production: ​http://catalog.clarin.eu/ds/ComponentRegistry/rest/
• Testing: ​http://lux16.mpi.nl/ds/ComponentRegistry/rest/ (MPI internal)

Dependencies

Internal dependency: the REST service depends on the Flex UI because it contains an html wrapper for the SWF.

External dependencies: see REST service dependencies.

The Component Registry as a whole also depends on the metadata toolkit, specifically the general component schema and the comp2schema XSLT.

Management

Administration interface

An administration interface that allows for inspection and modification of all public and private components is available at the path /admin.

E.g. for production: ​http://catalog.clarin.eu/ds/ComponentRegistry/admin].

Which accounts have administration rights is configured in the context parameter eu.clarin.cmdi.componentregistry.adminUsers.

Managing user groups

As of version 1.14.0 of the Component Registry, group functionality is available. Groups can be managed through a JMX interface as described in ComponentRegistryAndEditor/ManagingGroups.

---

Design

For design details of the modules of this project, see their respective pages:

• REST service design
• Flex UI design

There is a description of the high level architecture (picture below).

---

Tickets

List of all open tickets for this project:

Ticket	Summary	Priority	Owner	Milestone
#130	Importing component/profile should strip out components with componentId attributes.	major	Twan Goosen
#155	error message when not enough attributes to login	major	Twan Goosen
#164	Copy data category properties into component/element	major	Twan Goosen
#186	Transfer ownership of components	major	Dieter Van Uytvanck
#379	Throw exceptions from update method of ComponentRegistry interface	major	Twan Goosen
#428	Examine why ConcurrentRestServiceTest does not fail	major	Twan Goosen
#735	Data category should be searchable in the CCR	major	menzo.windhouwer@di.huc.knaw.nl
#147	Add a parameter to link to the components/profiles tab	minor	Twan Goosen
#221	add a favicon for the component registry	minor	Twan Goosen

---

History

The Component Registry has been developed as part of the CLARIN project.

People who have worked on this project include (in chronological order) Patrick Duin (original author), Twan Goosen, Jean-Charles Ferrières, Olha Shkaravska and George Georgovassilis

The original implementation of the backend (REST service) was using file system storage for the users and their registries. As of ComponentRegistry-1.8 this was replaced by a database based implementation. The code still reflects the original, more hierarchical storage model (e.g. a registry per user even though all components are stored in the same table).

For a detailed version history, see the changelog.

Historical pages

• ​ Some early designs