|
1
|
The v0.3 RESTful interface will be implemented in comformance to the Coordinating Node Application Programming Interface for v.03 as described in REST Interface documenent (http://mule1.dataone.org/ArchitectureDocs/REST_interface.html)
|
|
2
|
|
|
3
|
0.3 CN_query_0_3.getLogRecords() GET /log/
|
|
4
|
0.3 CN_health_0_3.generateReport() GET /log/report
|
|
5
|
0.3 CN_query_0_3.search() GET /object/
|
|
6
|
0.3 CN_crud_0_3.get() GET /object/<guid>
|
|
7
|
0.3 CN_crud_0_3.getSystemMetadata() GET /object/<guid>/meta/
|
|
8
|
0.3 CN_crud_0_3.resolve() GET /object/<guid>/locate/
|
|
9
|
|
|
10
|
Not listed in the above document is the following operation:
|
|
11
|
0.3 CN_crud_0_3.create() POST /object/<guid>
|
|
12
|
|
|
13
|
The supporting Interfaces in the business service layer will implement the following methods in support of the above REST calls as described in the Coordinating Node APIs for V0.3 (http://mule1.dataone.org/ArchitectureDocs/CN_APIs_v0_3.html)
|
|
14
|
|
|
15
|
Query API
|
|
16
|
getLogRecords(token, fromDate, toDate) -> logRecords
|
|
17
|
search(token, query) -> list of GUIDs
|
|
18
|
|
|
19
|
CRUD API
|
|
20
|
getSystemMetadata(token, GUID) -> systemMetadata
|
|
21
|
get(token, GUID) -> metadata
|
|
22
|
resolve(token, GUID) -> systemMetadata???
|
|
23
|
create(systemMetadataGUID, systemMetadata, scienceMetadataGUID, scienceMetadata)
|
|
24
|
|
|
25
|
Health API
|
|
26
|
generateReport(token) -> statusReport
|
|
27
|
|
|
28
|
*token parameter will be ignored for v.03 implementations
|
|
29
|
|
|
30
|
The REST interface will be developed by use of Spring 3 MVC. Dependency injection will take advantage of Springs XML, Annotiation based and Java-based configuration models. Aspects will not fully be implemented during this phase, but should be used in future development to handle logging, validation, authentication/authorization cutpoints.
|
|
31
|
|
|
32
|
Although it would be more uniform to create separate servlets based on the various APIs servicing the calls, due to the REST vocabulary splitting query methods into two separate paths, log and object will be the initial implemented servlets. Upon a request to a servlet, Spring will have mapped the incoming call to the correct controller as indicated by annotations within a POJO (@Controller and @RequestMapping). The controller will have the business layer services injected via @Autowiring annotiation.
|
|
33
|
|
|
34
|
The log servlet will receive the getLogRecords() and generateReport() method calls. These calls will be handled by two separate service implementations representing the query and health service layer APIs respectively. The method getLogRecords() initially will be a simple interface to a function that will read a file as an InputStream. Since the log format is not yet specified, I plan simply to return the local tomcat logs, most likely in wrapper xml, for the date range specified. The method generateReport() will interface to a rest client that iteratively calls MN_health_0_3.heartbeat() on each of the configured MemberNodes and wrap the results in an XML format.
|
|
35
|
|
|
36
|
|
|
37
|
Similar to the log servlet, the object servlet will receive calls for methods in the Query and CRUD APIs. The method search() will interface to a rest client that will return a result set from a call to Solr. The CRUD methods will interface to the Metacat API for persistence.
|
|
38
|
|
|
39
|
The domain model objects will be generated where possible via xsd definitions using Jibx generation tool in maven. These generated objects will be compiled into their own project space, CnDomain, and packaged as a jar to be uploaded into a local maven repository.
|
|
40
|
|
|
41
|
RestClient will most likely be its own project, similar to the CnDomain project, upon which Solr and MnHealth will be dependent.
|
|
42
|
|
|
43
|
The final code base should include two servlets, three service layer interfaces representing the three APIs, three separate service layer implementions of the API, DOA layers and implementations for Solr, MnHealth, Metacat and file based operataions.
|
|
44
|
|
|
45
|
|
|
46
|
Views produced by the servlets will produce XML, JSON or CSV based on the http accept header of the request. Spring's ContentNegotiatingViewResolver will decide whether a quest should be formated by JibX mashaller for XML or Jackson Mapping for JSON. CSV will most likely be implemented as an XSLT view using an stylesheet to trasform content from one type to another. However, Jasper Reporting may replace this functionality in the future given the more expressive nature by Jasper (CSV/PDF/Excel/HTML).
|
|
47
|
|
|
48
|
Framework and Component Technologies Used
|
|
49
|
|
|
50
|
Use of Spring Core, Spring MVC, Spring Web, Spring OXM and Spring AOP for dependency injection and Web interface
|
|
51
|
include Spring OXM for xml bindings
|
|
52
|
include cglib for Jackson dependcy
|
|
53
|
include Jackson core and mapper asl for Json implementation
|
|
54
|
|
|
55
|
Use of SpringIDE (SpringSource Tool Suite) editor for Software editing
|
|
56
|
AntRun plugin
|
|
57
|
Subversive Connector - http://community.polarion.com/projects/subversive/download/eclipse/2.0/galileo-site/
|
|
58
|
SVNKit 1.3.0 Implementation
|
|
59
|
SVN Team Edition
|
|
60
|
|
|
61
|
Use of Subversion repository for software revision control
|
|
62
|
|
|
63
|
Use of Maven repository for dependency management
|
|
64
|
|
|
65
|
Use of Jibx for Xml bindings
|
|
66
|
|
|
67
|
Use of Metacat for storage and Mercury/Solr for indexing
|
|
68
|
|
|
69
|
|
|
70
|
javax.mail mail 1.4.1
|
|
71
|
org.apache.maven.plugins maven-antrun-plugin 1.3
|
|
72
|
org.apache.maven.plugins maven-compiler-plugin 2.0.2
|
|
73
|
org.springframework spring-aop 3.0.0.RELEASE
|
|
74
|
org.springframework spring-webmvc 3.0.0.RELEASE
|
|
75
|
org.springframework spring-oxm 3.0.0.RELEASE
|
|
76
|
|
|
77
|
org.jibx jibx-bind 1.2.1
|
|
78
|
org.jibx jibx-extras 1.2.1
|
|
79
|
org.jibx jibx-run 1.2.1
|
|
80
|
org.jibx jibx-schema 1.2.1
|
|
81
|
org.jibx jibx-tools 1.2.1
|
|
82
|
org.jibx maven-jibx-plugin 1.2.1.1</version>
|
|
83
|
|
|
84
|
cglib cglib-nodep 2.2
|
|
85
|
org.codehaus.jackson jackson-core-asl 1.4.0
|
|
86
|
org.codehaus.jackson jackson-mapper-asl 1.4.0
|
