The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences. Vol. XXXVII. Part Bl. Beijing 2008 
infrastructure. GeoSWIFT 2.0 uses Pastry 1 (Rowstron and 
Druschel, 2001) as its underlying DHT infrastructure. Each 
SLN owns a Pastry node instance. This provides the DHT 
putney, value), remove(fey), get (key), and updat e(key, value) 
APIs. The SLN’s DHT APIs allow us to implement P2PSAM’s 
spatial query mechanisms. Finally, on top of the DHT APIs and 
P2PSAM APIs, we can then implement the SLN Layer 
Management APIs to build, maintain, update, and query the 
SSW Layer. Next, we describe how the SLNs using P2PSAM, 
as the spatial query framework, to offer a P2P-based SSW 
service. 
4.2.3 SLN’s P2P-based SSW Service 
The SSW service provided by the SLNs can be described using 
the following sample spatial query statement. For illustration 
purposes, we will use this sample query as an example 
throughout this section. 
Given a rectangle W, find all observations of phenomenon X 
within W 
In our P2P-based SSW service architecture, the client can 
choose any SLN from the system and send the above request to 
the chosen SLN. After an SLN receive the query, it uses 
P2PSAM to process the query. Therefore, the SLNs process the 
query in three P2PSAM steps: (1) Filter Step, (2) Forward Step, 
and (3) Refinement Step (Figure 2). 
mfihwSiM 
P2P SAW tayw 
B*«*B«**i* 
;G«tOti8*t»alén 
'request Wo s 
P2PLOT 
ioitJettoSMPte 
<GetObservations> 
1 
OGC SWE Interfaces 
SIN P2PSAM layer 
"1 
WindowOueryQ 
P2PLQT Layer 
n—I Î r 
put() remove!) get() update!) 
\ 1 \ J 
tflEanastSfeo 
AaosAKAgtotiMtra&xne» 
troni she «Ser «8p. kvwKd the 
<5e(OiS*»vation «Quest » the 
esnsWBäsSUte 
DHT layer 
An SIN 
A Pastry DHT overlay network 
formed by all SLNs 
Figure 2 A diagram of how the SLNs offer a P2P-based SSW service 
using P2PSAM as the spatial query framework 
1. Filter Step: The filter step finds the candidate nodes. 
The candidate nodes are the SLNs that can potentially 
contribute to the query, i.e., the nodes whose mbbox 
intersects rectangle W in the query. The filter step is 
cooperatively performed by the SLNs, because the 
SLNs are also Pastry DHT nodes running P2PSAM 
application software. The final result of the filter step 
is a list of endpoints of the candidate nodes. 
2. Forward Step: After the initial SLN gets the 
endpoints of the candidate nodes, according to the 
1 P2PSAM is not coupled with any DHT infrastructure. 
Therefore, SLNs can be easily implemented with other DHT 
infrastructures, such as Tapestry or CAN. 
endpoints it can then forward the query message to 
the candidate nodes. 
3. Refinement Step: Upon receiving the queries the 
candidate SLNs independently process the queries. 
Each candidate SLN executes the query against the 
spatial properties (e.g., locations) of their hosting 
SSNs. This step is required because of the fact that 
the sensing area of the SLN (i.e., the SLN’s mbbox) 
overlaps the query does not mean that all of the 
SLN’s sensor observations overlap the query. After 
finishing local query processing, each candidate node 
returns its own results to the SLN that initiated the 
query message. The SLN then streams the refinement 
results from the multiple candidate nodes back to the 
client that issued the query message. 
5. CONCLUSION 
In this paper, we presented the GeoSWIFT 2.0, a new P2P 
based interoperable SSW architecture. GeoSWIFT 2.0 
integrates the interoperable OGC SWE architecture (i.e., open 
standards-based GIService for the SSW) with the scalable 
P2PSAM architecture in order to realize an interoperable and 
scalable SSW service. 
GeoSWIFT’s design improves existing Internet GIService’s 
scalability by removing their centralized topologies. As we 
discussed in section 2, the centralized topologies are not 
suitable for large-scale and highly dynamic data sources. 
GeoSWIFT 2.0’s P2P model removes the potential single point 
of failure and the system performance bottleneck. A GeoSWIFT 
2.0 client can choose any SLN from the system and send 
requests to the chosen node. This means that any single SLN 
can be the access point of the service, and can accept client 
requests. This unique P2P design differentiates the GeoSWIFT 
2.0 from other GIService systems or SSW service systems, such 
as the Univerity of Minnesota’s MapServer 
(http://mapserver.gis.umn.edu/), Universität Minister's 52North 
SOS (http://52north.org/), or GeoSWIFT 1.0 (Liang et al., 2005; 
Liang and Tao, 2005; Tao et al., 2003). 
REFERENCES 
Androutsellis-Theotokis, S. and Spinellis, D., 2004. A Survey 
of Peer-to-Peer Content Distribution Technologies. ACM 
Comput. Surv., 36(4): 335-371. 
Balazinska, M. et al., 2007. Data Management in the 
Worldwide Sensor Web. IEEE Pervasive Computing, 6(2): 30- 
40. 
Botts, M., Robin, A., Davidson, J. and Simonis, L, 2006. 
OpenGIS Sensor Web Enablement Architecture Document, 
Open Geospatial Consortium, Inc. 
Guha, S., Daswani, N. and Jain, R., 2006. An Experimental 
Study of the Skype Peer-to-Peer VoIP System, The 5th 
International Workshop on Peer-to-Peer Systems, Santa Barbara, 
CA. 
Liang, S.H.L., 2008. A New Fully Decentralized Scalable Peer- 
to-Peer GIS Architecture, ISPRS XXIth Congress, Beijing. 
1012