Hello all
One part of Hao's and Chinh's work in the Google Summer of Code is to
create a prototype of OGC Catalog Service on the Web (CSW) and OGC Web
Coverage Service (WCS). Given the short time allocated to those parts
(only a few weeks), those web services can only be prototypes. For
example the WCS will not perform any cropping or subsampling operation
at this time. More advanced CSW and WCS already exist in other projects
(Geotk + Constellation) that we propose to port to Apache SIS, but
before starting a port we would like to take the "clear room" state of
Apache SIS as an opportunity for reconsidering the foundations. The
following points are my understanding of current state. Since I'm not an
expert on web services, I will appreciate if anyone could correct any
false statements I may do:
* Java Servlet (package javax.servlet) is the foundation of the Java
server-side technology. JSP, JSF, Struts, Spring and others, are
extensions of the servlet technology.
* Apache SIS already provides a small web service (not an OGC one) in
its application/sis-webapp module.
* The existing web service in SIS extends only the standard
javax.servlet.http.HttpServlet class. It does not depends on any
particular framework (Spring, etc.).
* Apache SIS uses Jersey only for executing the JUnit tests.
>From discussion I had today with other peoples involved in web
development, it is important that we allow SIS to be easily used
together with Spring. It does not necessarily means that we have to use
Spring in SIS, since - if I'm understanding right - Spring also use
parts of JavaEE standard (e.g. some standard annotations for dependency
injections, or [2]).
So it seems to me that creating a web server on top of
javax.servlet.http.HttpServlet is safe even for peoples who would want
to use SIS with Spring - is that right?
Assuming that the above is right, I would suggest to Hao and Chinh to
create a new "CatalogService" class in application/sis-webapp module
(not yet on Subversion - we use a Git clone for now). CatalogService
would extend HttpServlet, taking inspiration from the existing
LocationServlet class. To start with something simple, we could override
only the doGet(HttpServletRequest, HttpServletResponse) method for now.
The CSW specification is there:
http://docs.opengeospatial.org/is/12-176r7/12-176r7.html
Since we would support only the HTTP GET operation for this prototype,
requests would be encoded using Keyword-Value Pairs (KVP) in the
requests. The request XML encodings in above specification can be
ignored for now.
To start with something simple, we would do only the "GetRecords"
operation (section 7.3). The filter operations (7.3.4.10) would be only
simple searches by bounding boxes, time, physical parameters or satellite.
The response can be Dublin core or ISO 19115. For this prototype we
would answer only ISO 19115 documents.
Does it seem okay?
Martin
[1] http://docs.oracle.com/javaee/7/api/javax/servlet/package-summary.html
[2]
http://docs.spring.io/spring-framework/docs/4.3.x/javadoc-api/org/springframework/web/servlet/HttpServletBean.html
