Well architected. It needs documentation and could be a little more configurable. The services themselves have some performance issues on the Win2K platform. The portlet could be a little more navigable.
I evaluated this software as a suite of products and not as individual components with the main emphasis on the portlet and the services needed to get this working. As a whole, I was very impressed with the software, it looks well architected.
I am assuming the target audience for this software will be portal administrators (although in my experience these also tend to have some development experience).
I experienced several issues with the system but I feel these issues could be easily addressed. I hope any negative criticisms below are constructive and taken in the spirit in which it is offered, as a genuine effort to help identify the weak points. I hope my comments are useful.
I have been a portal developer with 5 years experience of work with portals (primarily uPortal). Primarily I work with Java and XML technologies and have created several JSR168 portlets.
The installation bundle is currently very large download (118Mb). It contains over 90 Mb of JAR library files (not including those inside War files). IMHO, I feel the distribution size could be significantly reduced by the use of Maven2 for dependency management. There is a Maven2 ant library which I feel would work very well in this distribution.
I had access to a working installation of the portlet, it would be good to maintain this demo (or at least provide some screenshots in the documentation) so that the user knows what to expect from the working portlet.
I think the distribution would benefit from some descriptions of what the software is for and how it does it. It needs to explain the terminology used and what they apply to in this context (e.g. OAI Repositories, Data Sources, etc). It should include some architecture diagrams. It should explain where each part of the data in the system is located and how it is accessed (databases, remote site etc).
The distribution contained some subfolders that included the source code (spp-alerting-delivery) and some that didn't (e.g. spp-clients). If this is open source software I would expect that all the source code is clearly available such that modifications (e.g branding) can be made if required.
The instructions for starting the services using Ant were clear and easy to follow.
Either some kind of status check ant target or some explanation of what to look for in the log files needs to be added so that the user can confirm that everything is working as it should. Also some indication of the timescales that a harvest takes would be useful.
Since this system is written using the Spring Framework, a key feature should be that it can be easily user configured. More detailed user documentation could easily highlight this.
Configuration options such as the job time for harvesting needs to be in the documentation otherwise PubMed could get very busy at 35 minutes past the hour! Alternatively this could be specified as a configuration option at build time. Essentially, it would be better if a user creating an installation at 10:40 didn't have to wait until 11:35 to check if it works.
Other hidden configuration settings such as the location of any database used needs ellaboration. Instructions for porting to other databases would be helpful (Oracle, MySQL, SQLServer etc). I also noticed that the service using 2 different 100% Java database, Derby (activemx) and HSQLDB (portlet) - the same database could be used for both to reduce confusion.
Email configuration as the only alerting option is liable to be slightly problematic. It would be good if there were an alternative to email (such as RSS) as SMTP servers, due to the obvious security implications, can be tricky to integrate with. A quick start could even include a sample email server (such as the 100% Java Dwarf Mail Server).
I did experience severe performance related issues with the service (requiring several reboots). Initially, I thought this was due to memory use but once memory limits were included there were still considerable issues with CPU and bandwidth usage.
The services could be extremely CPU intensive and bandwidth resource hungry on my test machine. Whilst the services are running, at some points the CPU utilisation of the Java processes services was 100% for a significant duration (at least one of these processes was the HSQLDB instance). Also, the services utilisation of bandwidth was nearly total to extent where it was impossible to surf the internet at the same time.
It would benefit from being able to stop the services from an ant target as I don't think re-booting windows is an ideal solution.
It would be good if there were an ant clean target to return the installation to a factory install state.
Both portlet and admin web application were easy to install. Although the portlet identifier (sppuserpref.sppprefs) may be a little error prone for portal configuration.
When both applications are located on the same server the admin web application will not start. It gives a SEVERE: Error listenerStart. On Tomcat this is due to the use of Spring's Log4jConfigListener. This can be fixed by adding the following to the respective web.xmls.
<context-param>
<param-name>webAppRootKey</param-name>
<param-value>SppAdmin.root</param-value>
</context-param>
<context-param>
<param-name>webAppRootKey</param-name>
<param-value>sppusepref.root</param-value>
</context-param>
Warning on startup of Admin web application. Need to add something like the following to the web.xml to avoid the warning WARNING: Security role name tomcat used in an <auth-constraint> without being defined in a <security-role>.
<security-role>
<description>Tomcat administrator</description>
<role-name>tomcat</role-name>
</security-role>
The portlet GUI looks clean and professional.
Identity. It would be good if the portlet could identify the user from the portals authentication but I am not sure that the mechanism for this is clear in the standards. Certainly, on uPortal something like a request.getRemoteUser() should obtain the userid.
For wider appeal it might be better to avoid the use of terminology in the portlet. Specifically any mention of datasources or repositories unless it is very clear as the precise meaning of these terms. Also using an ambiguous jargon word such as subscription should probably be avoided.
I appreciate that this is still in development but the portlet currently echoes a lot of hibernate information to standard output.
A navigation bar would probably be useful to navigate around the portlet. On the "Your Subscriptions" page the only option are "Edit, Delete, Create Subscription". In this situation a "Home" link taking you to the "Subscription Details/Datasources" 2-panel page would be good (otherwise it feels like you are at a dead end).
For choosing the journals, further navigation mechanisms would make it more usable [such as "A-Z links", search box, go to page (page X of Y)].
An idea is that unobtrusive AJAX refresh could be employed in the Journal navigation to prevent unnecessary portal page refreshes.