Sensor Alert Service (SAS)

---

Introduction

Here we document the development of the 52°North Sensor Alert Service (52N-SAS).

Things to keep in mind:

1. English is our primary language for communicating but is not necessarily the first language of all participants. Please be mindful that English idioms may not be understood.
2. Use of graphics within Twiki pages is highly encouraged! To embed a graphic, attach a JPEG/PNG file to the page then edit the page to place the link in the proper place.
3. Please prefix all twiki pages concerning SAS with the "SweSas" moniker (e.g., SweSasTelecons). This naming convention will allow us to find relevant pages and weed-out unrelated pages using the twiki search facility (see "SWE SAS Pages" heading below).

OGC Specification

The specification implemented by SAS 2.0 is the one documented in OGC document number 06-028r5. This document unfortunately never became public. It is available to OGC members in the pending docs area at http://portal.opengeospatial.org/files/?artifact_id=24780&version=1.

The service interface of SAS 2.0 will likely not make it to an approved OGC standard. To get an idea of what the OGC developments in the area of event processing will probably look like in the future, see OGC documents number 08-132 and 08-133, available on the OGC homepage.

Snapshot releases

From time to time, we provide snapshot releases. Mostly, when we fixed all known bugs.

• sas-2.0-SNAPSHOT.war: current sas development snapshot
• 52nWNS.war: compatible WNS release

SWE SAS Pages

(List of SweSas pages auto-generated below)

Results from SensorWeb web retrieved at 11:32 (GMT)

Contributor Telecons

During the developments we performed some telecons, see this site.

Lifecycle

Documentation

checkout from svn

1. You optionally need: Maven, Eclipse, Subclipse You can install it later if you want to proceed with the checkout
2. To check out the whole sas project, you should checkout the entire sas tree:
   svn co https://incubator-52n.svn.sourceforge.net/svnroot/incubator-52n/swe/sas/trunk/. However it is not advisable to do it within eclipse. Instead, use the commandline or any other tool to checkout the sas into a seperate directory. This must not be the eclipse workspace!
3. If this is your first maven project from 52north and you want to use maven and or eclipse proceed with the maven instructions
4. run mvn eclipse:eclipse in the sas top-level directory (this is for example swe/sas/trunk/. This will create the necessary project files.
5. Import the submodules into eclipse using import->into workspace. Make shure that copy into workspace is not selected.

Deploy

Build

Test

Implement

• FAQ
• Milestones

svn::ignore

Do not commit the target directories! Set target and .* in svn:ignore! With eclipse click on Team -> Edit properties and select svn:ignore. Fill in:

.*
target

eclipse && maven integration

Read: Maven eclipse documentation You don't need to run mvn on the commandline once you created the eclipse projects. Open Run -> External Tools -> ...

You should the following dialog:

Create multiple entries for all the goals you need. The location is always the project + "../" because the operation shall affect the whole project (sas), not just the submodule (sas-core).

Design

UML Diagram

• Libraries
  • logging
    • java 1.6 logging?
    • log4j?
  • persitence
    • db4o?
    • hibernate?
    • exist?
  • Filtering: event filtering is based on comparison filters only ... at least for this version of SAS. Our design shall support multiple solutions for filtering incoming data. Possible solutions include:
    • Our own implementation. Because we do not have to cope with (too) sophisticated filter conditions, this should be doable.
    • Esper - Esper is a component for CEP and ESP applications, available for Java.
  • Communication: SAS uses XMPP as the underlying protocol for receiving and delivering sensor data / alerts. HTTP is used for service requests and responses. Alerts may also be delivered via SMS, Phone, Fax, SMTP, WS-Addressing and WNS (the SAS specification supports these protocols - our SAS would make use of the WNS to manage communication over these protocols if applicable). Nevertheless, our design is trying to lift the restriction for certain transport protocols, so that at least the design of our services core is transport protocol independent.
    • smack api
• testing framework
  • junit testing - we should give it a try ... at least for black-box-testing. Cactus may be helpful, there is even an article on Cactus Integration in WTP (maybe outdated, I did not try it yet)
• maven
• subversion (sourceforge)

• link to specification
• link to bugtracking system
• link to subversion
• link to mailinglist