CodelistManagerDesign
Context
Architecture
The core defines a basic user interface, the core services, core daos and the core domain objects. The core UI definitions define probably also the Menu. The core implements the core usecases.
Another starting point could be to say that the core has only domain objects, daos and services, so no UI definitions. This is still to be discussed and to be decided.
Every plugin covers 1 or more use cases. A plugin has usually a lot of UI definitions, and may add services, daos and domain objects.
Package Diagram
Dozer is a utility to define mappings between object graphs. It has been explicitly modeled here in order to express that very responsibility.
Requirements
- DAO pattern is necessary in order to abstract from persistence implementations
- Identified persistence implementations are Oracle, Postgres, D4ScienceTreeManager, D4ScienceTabularDataManager
Questions
- Do the VOs in the Service interfaces need to interfaces or classes?
- Will the DAO have VOVirtual Organization;'s as wel in the interface, or domain objects? If yes, Dozer will need to be positioned differently in the diagram.
DAO Pattern
The UI uses services. There can also be services which are not used by the UI. The services have the business logic and use DAO interfaces in order to read and write. The DAO implementations are pluggable. This means that it is possible to configure a Cotrix with an Oracle backend, providing that an Oracle DAO implementation is written. Same for SemanticTurkey, Treemanager etc.
Plugin Architecture
An instance of a CodelistManager can be deployed on a Java application server. A plugin can be packaged in a Custom, Porlet of WebFragment way.
Proprietary
The CodelistManager will have its own definitions of the notion of a plugin. Geoserver has done something similair. Every plugin is a jar file, can be dropped on the classpath and will add definitions to the UI menu. Geoserver has used intensively the Spring framework in order to implement its modularity.
Portlet
Packaging as portlet means complying with the Java Portlet Specification 2.0 (JSR 286). The portlets can be deployed on a portal server like http://www.liferay.com
WebFragment
Servlet 3.0 introduces web fragments. Every plugin can be packaged as a webfragement. http://java.sun.com/developer/technicalArticles/JavaEE/JavaEE6Overview_Part2.html
WebFramework
D4ScienceAn e-Infrastructure operated by the D4Science.org initiative., VocBench and TechCDR are using GWT and this is the way forward. GWT has 2 patterns called MVP and Activity. These two patterns seem to have great added value and are therefore proposed to be used.
Do we use GWTP? They offer Dependency Injection through GIN and Guice. This discussion will needs to be discussed taken into account the eventual use of Spring.
Dependency Injection
The options are Spring and Java 6 EE CDI[1].
Pros and cons
- The team is familiar with Spring.
- Fact is that CDI is having equal DI features as Spring and therefore Spring could be considered as a burden?
- Can caching be done as easy as in Spring through @Cacheable annotations?
- Can authentication be done as as easy as in Spring?
Publish & Subscribe for the Menu
In terms of literature, you can read more about the publish-subscribe design pattern as opposed to simple Observer. This is the principle. Now regarding the specific way it is realized, this is a personal approach. The idea is that:
- You can have a topic, e.g. : owl:class-focus-operations, and specify an interface for them (e.g. “here what is needed as mandatory is only the name of the selected owl:class”)
- You have UI widgets, registering themselves on a topic
- A set of operations are associated to the topic
- thus operations are published on the UI registered on that topic
If you define them well, you may (at least in some cases) have operations which can be specified without requiring any further UI development , because basic elements, such as menus, options etc. will be automatically attached to the proper UI element.
So, for instance, both a class tree and a graph view of an ontology could register to the same owl:class-focus-operations, and, when the user focuses on an owl:class (either shown on the tree or on the graph) they get the operations. Nice thing is that a third party developer could create a new operation, plug it through OSGi, and get it published on all the interested widgets. Even nicer, another third party developer cound instead provide a new UI widget, register it to a topic, and that UI widget would get all the operations for that topic (even third-party ones like the one before!). So nobody needs to know anybody, and u get everything wired up
Then you may have compound topics, which contain the sum of all operations related to different topics, or we could define some inheritance in a similar way.
