SIR Development Documentation
An extensive documentation of the class structure is in this Enterprise Architect project file: sir.eap
Some core example diagrams are attached to this page as images:
Package, Class and File Structure
The data structure appears at several places in the service:
- All requests and responses, and their elements have matching Java classes in the service implementation (package
- The data base access is based on a DAO pattern. Java classes are in the package
org.n52.sir.ds, and the currently the only supported implementation is PostgreSQL (package
- The table structure, indices etc. of the data base are defined in the file
Request and Response Handling
The flow of the request through the classes is as follows (italic words refer to components described below): Incoming request is decoded in the request operator
using get and post decoders
. The decoded request is then inserted into the according listener class
, which actually processes the request and create the respective response class
instance. This is then handed through the request operator
back to the servlet
The request and response handling consists of four components:
transform the incoming GET URLs or XML documents into the Java request classes (see next step). The respective interfaces and implemenations are
in the package
The request classes
in the package
mirror all the incoming requests. They hold all required values from the incoming requests and are created in the respective decoder.
The listener classes
in the package
do the actual processing of the request, i.e. they query the database for the definition, validate incoming or outgoing documents, or consult the reasoner for matching definitions, and so forth. They create an according
which is returned into the request operator.
The response classes
in the package
mirror all the outgoing responses.
The transformation of sensor metadata descriptions in SensorML
to ebRIM compatible documents is based on XSLT
The required transformation files (
) are saved in the directory
, but this can be changed using the configuration parameter
. Example files for testing can be found in the directory
The Java classes for transformation can be found in the package
. A factory pattern is used.
Profile Conformity Testing
The document OGC 10-171 also contains an XML profile which defines all elements that shall be present in a SensorML
description. This set can be seen as the minimal useful information which is needed for sensor discovery. These elements can then be used in the transformation. All incoming/inserted documents are checked against the profile and only accepted if they are conform
with it! Users can test their documents beforehand (but only manually) using the test client, but the response contains information about why a document is not accepted, too.
The required XSLT files for transforming the profile into an XSLT file which in turn can be used for validation (check out the various Schematron
resources on the web for details of this process) are in the folder pointed to by the configuration parameter
. The actual profile file is
and is currently saved in the
folder. Of course, these can be changed in the properties file! Example files for testing can be found in the directory
The Java classes for validity testing can be found in the package
. A factory pattern is used.
Tests and Utilities
The Java code contains very rudimentary unit tests in the package
. The can be run using JUnit
very easily in Eclipse: Right click on the file
, then navigate to
Run As... > JUnit Test
to run all tests.
It is important to point out that this test Suite does currently NOT check the content of the received responses, it merely checks for validity of the document (so an exception response does lead do a failed test).
The tests utilize the request examples from the folder
, so the URLs for testing the GET interface are taken from the file
RequestExamples_GET.txt" and the XML documents for testing the POST interface are the respective =...Request.xml
files. In addition, the POST is tested a second time using the client's beans - so a simple test of the client is included in a way as well.
contains a generator for dummy sensor descriptions
that can be directly inserted into a SIR instance. Take a look at
if you want to try it out.
Utility functionality, e.g. common tasks with XML documents, the job handling for catalog connections, clients to other webservices (like SOR), and more are collected in the package
. These are pretty straightforward and well-documented, so a lengthy explanation is abstained from at this point.
The landing page shows a very simple user interface - just one text box to enter a search string into, just like many popular search engines. The response is also rendered in a fashion remotely similar to a popular search engine. This client utilizes an OpenSearch
interface and several response formats such as HTML, XML, KML, or JSON.
The test client is written using [[http://java.sun.com/products/jsp/][Java Server Pages]. It provides a simple interface to comfortably create and send POST requests to the service and inspect the response. In addition to the service operations the client includes a page to transform SensorML
documents into EbRIM
documents using the same method that the service utilizes, and a page to view the log about last pushing events to other catalogs (during runtime only!).
All Java classes for the test client can be found in the package
. These comprise currently only the beans for the respective JSPs and the class
to send the actual requests. The
is in the folder
, the sub-pages for all operations in the subfolder
, one .jsp respectively. The pages include the JSPs
for the images and title,
for the menu, and
contains style information and the folder
contains the logos for the client's header.
The syntax highlighting in the editor relies on CodeMirror
. All codemirror files are in the folder
and the configuration/initialization of the editors is handled for all pages in the file
The simple test client is only a single HTML file,
. It uses codemirror for syntax highlighting and includes a drop-down menu for selecting some request examples. These examples are taken from the folder
. There is one example file for every possible request via POST, and a single text file containing examples of possible GET requests. These example files are also used for testing!
The build process is completely based on Maven. Since several dependencies are not available in public repositories as binaries. Therefore you have to download and install (
) the following projects before being able to build the main project
An Eclipse project
for development is available at
. You can browse the repository here
To check out a working SIR installation into Eclipse follow these steps:
- Check out the following projects with your favourite SVN client for Eclipse (recommended and used for this step-by-step description: Subclipse).
- File > New > Other... > Check out project from SVN
- Repository location: https://svn.52north.org/svn/swe/incubation/
- Navigate to directory SIR >
- One after the other, select one of these directory and click "Next" (Not "Finish". We do not automatically import is as a Maven project since Maven problems will interfere with the checkout.)
- Use "Check out as project in the workspace" and use the suggested name (the name of the component respectively directory).
- Click "Finish".
- Right-click on the newly available project, select Configure > Convert to Maven Project
- If your have errors, right-click on the project and select Maven > Update Project...
- Repeat the process above for the main project
- Optional: Take a look at the project 52n-arsearch to see integration of the SIR with augmented reality browsers.
Please follow the internal guidelines: DeveloperInformation
mvn test on a project on the console, then update the Maven Project in Eclipse - this often solves problems with dependencies!
Requirements for Development
Run Maven configuration with the goal
and the profile
in debug mode in Eclipse.
- Topic created by: DanielNuest
- Topic created on: 2013-01-31