Software Architecture Document

brazilianchubbySoftware and s/w Development

Jun 8, 2012 (5 years and 9 days ago)

991 views




















Software Architecture Document


for the
SOLA Development Snapshot




FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
2

of
70


Revision History


Date

Version

Description

Author

10 Feb 2011

0.1

Initial Draft

A
ndrew

McDowell

15 Feb 2011

0.2

Second Draft

A
ndrew

McDowell

16 Feb 2011

0.3

Internal Release

A
ndrew McDowell

6

Mar 2011

1.0

Release

Andrew McDowell

15 Aug 2011

1.1

Revised for the
Development Snapshot

Andrew McDowell



FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
3

of
70


Table of Contents

1.

Introduction

5

1.1

Scope

5

1.2

Intended Audience

5

1.3

Architectural Representation

5

1.4

References

5

1.5

Acknowledgements

6

2.

Overview

7

2.1

Presentation Layer

8

2.2

Services Layer

8

2.3

Da
ta Layer

8

2.4

External Systems

8

3.

Architectural Drivers

9

3.1

Requirements

9

3.2

Constraints

15

3.3

Principles

15

4.

Architectural Mechanisms

18

4.1

Analysis Mechanisms

18

4.2

Analysis Mechanism Mappings

19

5.

Use Case View

21

5.1

Architecturally Significant Use Cases

21

5.2

Use
-
Case Realisations

23

6.

Logical View

34

6.1

Overview

34

6.2

Presentation Layer

35

6.3

SOLA Desktop

35

6.4

SOLA GIS and GeoTools UI

38

6.5

Services Layer

40

6.6

Boundary

41

6.7

EJBs

43

6.8

Application EJB

44

6.9

Services Common

45

6.10

Common

47

6.11

Data Layer

47

6.12

External Systems

48

7.

Deployment View

49

7.1

Deployment Models

49

7.2

Deployment Artefacts

49

7.3

SOLA Test

50

7.4

SOLA Development Snapshot

51

7.5

SOLA Developers Package

52

8.

Data View

53

8.1

SOLA Data Model

53

9.

Size and Performance

54


FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
4

of
70


9.1

Use Case Points

54

9.2

Database Size

54

9.3

Code Metrics

54

9.4

Performance

54

10.

Security

55

10.1

SOLA Security Model

55

10.2

Authentication

55

10.3

Authorization

56

10.4

Confidentiality and Integrity

56

10.5

Auditing and Logging

57

10.6

Exception Management

57

10.7

Map Viewer Navigation

58

11.

Appendix 1


Definitions, Acronyms and Abbreviations

59

12.

Appendix 2


UML Notation

62

12.1

Component Model Notation

62

12.2

Use Case Model Notation

62

12.3

Logical View Notation

63

12.4

Deployment Model Notation

64

13.

Appendix 3


Architectural Risks

66

14.

Appendix 4


Additional Information

68

14.1

Workflow Engine Evaluation

68

14.2

Enterprise Service Bus

70


FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
5

of
70


Software Architecture Document

1.

Introduction

This document provides an architectural description of
the
Solutions for Open Land
Administration (SOLA)

system
using a
number

of different architectural views to depict
different aspects of the system. It is intended to capture and convey the architectura
l
decisions that have been made

and elaborates on aspects of the system that are considered
to be architecturall
y significant.


The views include use case view, logical view, deployment view and data view. Also
described are the drivers that have shaped the architecture of the system,

the architec
tural
mechanisms applying to SOLA

and its size, performance and
security characteristics.

1.1

Scope

This

Softwar
e Architecture Document
(SAD)
represents the “as
-
is” architecture of
the
SOLA
Development Snapshot
.
The Development Snapshot is a branch of the SOLA source code
and
new
areas currently under development
in the ma
in branch
are also
discussed and
represented i
n this document with light fill.



The
SOLA

project is using
the

Agile

Scrum
development methodology.
This document
will
evolve during
project Sprints

and

additional detail
(generally marked as “To be completed
”)
will be included as appropriate to reflect decisions

and outputs

arising from design and
implementation activities.

1.2

Intended Audience

This is a
technical document intended for
developer and related
technical resources.

1.3

Architectural Representation

The

Unified Modelling Language (UML) is an industry standard software system modelling
notation administered by the Object Management Group.


This document describes the architecture of
SOLA

using standard UML diagrams, including
use case, component, package,

and deployment diagrams. Readers of this document need
to be familiar with the UML notation. For further information on the UML see
http://www.uml.org/
. Note that a brief description of the UML notation used
in this docum
ent

is provided
in Appendix 2



UML Notation to
assist the reader.

1.4

References

Document Name

Date

Author

FLOSS SOLA Data Dictionary v1.0

26 Jul 2011

SOLA Development
Team

Statement of Requirements


Initial Solutions for Open Land
Administration (SOLA)
Software

v1.1

14

Jan

201
1

Neil Pullar

Technology Options for SOLA

Jan 2011

A McDowell

SOLA LADM v0.3 Enterprise Architect Model

8 Feb 2011

Neil Pullar

FAO SOLA Way of Working Document v1.1

10 Feb 2011

Alexander
Lokhman and Imed
Hammouda

The Java EE 6
Tutorial
(
http://download.oracle.com/javaee/6/tutorial/doc/docinfo.html
)

Nov
2010

Oracle

Corporation


FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
6

of
70


Document Name

Date

Author

PostgreSQL Site (
http://www.postgres
ql.org/
)

2011

PostgreSQL User
Community

Metro Users Guide (
http://metro.java.net/guide/
)

01 Feb 2011

Metro User
Community

Real World Java Patterns


剥瑨i湫i湧⁢敳琠tr慣tic敳

g畮攠e〰9

A摡m⁂ien

l扪散瑄t

gmA⁒敦敲敮e攠
E
桴h瀺pL睷眮w扪散瑤t⹣潭⽡Li⽪av愯a灡
F


l扪散瑄t

b湴nr灲楳攠Arc桩瑥tt畲攠u慴a敲湳
E
桴瑰㨯⽭慲瑩湦潷汥o⹣潭⽥L慄avL
F

g畬y ㈰0S

䵡r瑩渠䙯睬敲

乥瑢e慮s⁄潣畭敮瑡ti潮ⰠTr慩湩湧 慮搠pu灰潲琠
E
桴h瀺pL湥瑢敡湳.潲术o戯b湤ex⹨.ml
F

㈰ㄱ

lr慣l攠䍯rp潲慴o潮

p畮 䑥vel潰敲⁎整睯wk⁊av愠a湴nrn慴a潮aliza瑩o渠
E
桴瑰㨯⽪av愮au渮n潭⽪慶慳支瑥e桮hl潧i敳⽣潲支扡bicLi湴lL
F

㈰㄰

lr慣l攠䍯rp潲慴o潮

d敯T潯ls⁤ c畭敮瑡ti潮

E
桴h瀺pL摯cs⹧.o瑯tls⹯牧.
F

㈰ㄱ

d敯T潯ls

1.5

Acknowledgements


The following people have
provided information or feedback that has contributed to the
content of this document




Neil Pullar



Geoff Hay



Elton Manoku



Alexander Solovov



Rafiq DounNaah



Matthew Boafo



Paola Rizzo



FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
7

of
70


2.

Overview

The archit
ecture of SOLA
has been designed using the l
ayered

architectural pattern. A two
dimensional layering approach has been used to structure the software firstly by
responsibility and
secondly for reuse.
The following
Component Model
diagram illustrates
the

layers of SOLA
and the

main components
within each l
ayer

along with
their
key
dependencies.


Figure
1

-

SOLA

Overview

SOLA Services Host (Glassfish / Metro)
SOLA Database (PostgreSQL)
Data Layer
External Systems
Presentati on Layer
Servi ces Layer
Cadastre
Case Management
Print Server
Scanner
Search
PostGIS Database
Reference Data
Digital Archive
«arti fact»
Scanned Image
SOLA Desktop
Administrative
Enterpri se Java Beans (EJBs)
SOLA Web Servi ces
Application EJB
Party EJB
Address EJB
Cadastre EJB
System EJB
Search EJB
User EJB
Administrative EJB
Digital Archive EJB
Spatial
Security
Scheduler EJB
Source EJB
Source Schema
Party Schema
Administrative
Schema
Cadastre Schema
Application Schema
Address Schema
System Schema
Document Schema
Email Server
SOLA GIS

FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
8

of
70


2.1

Presentation Layer

The SOLA
Desktop

is

a
Java Swing

desktop

application
delivered to end users via
Java
Web Start technology

to ensure minimal deployment and configuration overhead
. The
Development Snapshot version of the SOLA Desktop supports basic front office case
management tasks including
application
lodgement
,

digital document
preview and
attachment
, application search, a
pplication assignment

and a

custom

spatial
map viewer

(SOLA GIS)
.

The SOLA Desktop
provides

translatio
ns
for both
the
English and Italian
languages
and
can be configured to support additional
languages.


The SOLA Desktop will continue to be extended to
sup
port the Generic Land Administration
Process
1
. Given each land administration agency will have different workflow requirements
specific to their jurisdiction, it is expected that the SOLA
Desktop

will be the primary SOLA
component requiring customisation t
o satisfy the needs of the agencies. This may extend to
replacement of the SOLA
Desktop

with a custom client application. Where heavy
customisation or replacement is required, the SOLA
Desktop

will act as a reference
implementation providing working exampl
es of the design and implementation patterns best
suited for use with SOLA.

2.2

Services Layer

SOLA implements a web services based architect
ure that is consistent with the princip
l
e
s of
Serv
ice Oriented Architecture (SOA)
2
.
It

includes eight

SOAP based
web
services
implemented using the Java JAX
-
WS technology
backed by

eleven Enterprise Java Beans
(EJBs)
hosted using

Glassfish and Metro
.


The
SOLA
Desktop

can use

the
SOLA
Web
S
ervices independently or combined in order to
support
land administration

busine
ss processes. All of the services are designed to be
interoperable and availa
ble for reuse by other systems. Of note, Metro provides support for
WS
-
* standards and is interoperable with .NET Windows Communication Foundation (WCF)
technology.


The EJBs enca
psulate the main business logic

for SOLA

and have been implemented using

the EJB 3.1 specification. This specification provides several
improvements
3

over

earlier
EJB specifications and is intended to be light weight and functional.


2.3

Da
ta Layer

The Data
Layer persist
s

SOLA
data into a PostgreSQL database
.
The structure of the SOLA
Database is based on the data storage requirements implied by the Land Administration
Domain Model (LADM
-

draft ISO standard 19152
) although extensions and adjustments
have been included to support the function requirements of SOLA. The database
contain
s

multiple schemas

with the data in each schema
managed and maintained by
a primary

SOLA
EJB
.
The PostGIS Database provides support f
or storage and manipulation of spatial
data
.

2.4

External Systems

External Systems identifies the systems
SOLA integrate
s

with
.
The
SOLA Desktop

can
direct

print jobs through
to print s
ervers
on
the
land administration
agent’s

network.

Email
notifications wi
ll be sent via the land administration agent’s email server.
Scanners
can

be
configured to place imaged documents on
the

network
or local
file
location

so they may be
picke
d

up and linked
to the relevant
application
.




1

See section 4.1 in the SOLA Statement of Requirements

2

http://en.wikipedia.org/wiki/Service
-
oriented_architecture#Principles

3

Convention over Configuration (CoC), Context and Dependency Injection (CDI), Portable Global
JNDI Names, etc


FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
9

of
70


3.

Architectural Drivers

This section discusses the architectural drivers that have been identified for
SOLA
. The
architectural drivers include
the
requirements

that have architectural

significance, constraints
the system must comply with and

architectural
principles
. The drivers
provide rationale for
key
aspects

of the
SOLA

architecture.

3.1

Requirements

3.1.1

Functional Requirements

The following table identifies and discusses the functional requirements of
SOLA

that have
architectural significance.



Requirement

Description

Significanc
e

Case
Management

The system will
provide

case
management
facilities
for client
initiated app
lications and
requests. (FN


1 to 3, 13 to 15,
17, 18, 21, 24
,
25, 32 to 35, 38,
50 to 58, 64, 78, 80 to 82
).

Each
land administration agency

will have its own procedures and
processes for
managing

land
administration
. The procedures
and processes may involve
multiple parties.
(
Generic Land
Administration Process, FN


49,
54, 78
).

SOLA to implement a Case Management
Service that will
support

t
he generic
workflows for maintaining and managing
case details and associated data.

SOLA to extend the Land Admini
stration
Domain Model (LADM) as
necessary to
capture associations between the elements
that comprise a case.

SOLA
Desktop

to support
the Gene
ric
Land
Administration

Process.

C
ustomisation
of
the SOLA
Desktop

by each land
administration agency

is to be expected
.

Search

The system will provide facilities
to search
and display
land
administration records. (
FN


4 to
8, 19, 46, 47, 65 to 67
, QL


24
,
36, 37
).

Limited requirement
for full text searching
as
data
will be
held as tabulated / structured
text
or in scanned
image form
.

SOLA to implement a Search Service
to
perform
structured text searches or
combined
structured text

and geospatial
searches

using PostgreSQL / PostGIS
database queries
.

Spatial
Capability

The system
will

provide a spatial
capability sufficient to
search,
view, create and modify spatially
defined cadastral objects
.

(
FN


4,
10 to 12
, 36, 37, 39, 40, 42 to
45, 65 to
68, 71 to 74
).

The system will also support
relevant technical standards for
geographic information. (
QL


28
).

SOLA to use a s
patial
ly enabled d
atabase

(PostgreSQL / PostGIS)
,
spatial library
(Geotools) and a customized
d
esktop GIS
component

to deliver ri
ch spatial
functionality.

SOLA can also optionally accommodate a
spatial map server (e.g. GeoServer).

Support for Geographic Information
standards (e.g. GML, WFS, LADM, etc).


FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
10

of
70


Requirement

Description

Significanc
e

Rights

Management

Each
land administration agency

will have its own data
requi
rements for capturing and
describing the legal rights that
can be
allocated to rights holders.
(
FN


㈷ 瑯tP〬0R㘬SR㤠9o‶


pl䱁⁴ im灬敭敮琠t渠
Admi湩s瑲慴ave

p敲eic攠e潲慩湴ninin朠g湤慮慧i湧 le条l
ri杨瑳⁡湤⁡ s潣i慴a搠da瑡t

pl䱁⁴ 畳攠eh攠
iA䑍

t
漠m潤敬⁣潲攠oa湤
慤mi湩s瑲慴ao渠n潮ce灴p⸠

pl䱁⁴ 畳攠e 扵sin敳s⁲畬敳⁥ gi湥⁴
慬low⁤敦慵l琠t畬敳⁴漠o攠e潤ifi敤 瑯tr敦l散琠
慧敮cy⁲敱畩r敭敮瑳⸠

䥭慧敤⁤ c畭敮瑳
慲攠數p散瑥t⁴漠
c潶敲e
瑨t慪潲楴y ⁤ t愠a慰t畲u⁲敱畩r敭敮瑳
桯wev敲e睨敲攠慤diti潮慬
A
来湣y

s灥cific
摡瑡tre煵ir敭敮瑳
數is琬t
瑨敳攠will

湥e搠do
扥潤敬l敤 數灬ici瑬y i渠n桥⁓liA⁤ 瑡t慳攠
慳⁰ r琠tf⁴ e⁣畳瑯tis慴a潮⁰牯 敳s⸠

䍡摡s瑲攠
䵡湡来m敮t

T桥⁳ys瑥t⁷ ll⁰牯
vi摥⁦慣iliti敳
瑯ts異p潲o

m慩湴ni湩湧⁴桥
c慤慳瑲攠
i湣lu摩n朠gh攠e扩lity 瑯t
c慰瑵牥t
v敲eio湳 ⁣潲攠oa摡s瑲慬
r散潲摳⸠
Ec丠


㌶Ⱐ,TⰠ,9⁴ ‴ Ⱐ
㔸Ⱐ,9



pl䱁⁴ im灬敭敮琠t⁃慤as瑲攠e敲eic攠e潲o
m慩湴nini湧 慮d慮慧in朠c慤慳瑲慬
灲潣敳s敳⁡ 搠慳s潣i慴a搠摡瑡t

pl䱁⁴ 畳攠e⁳p慴a慬ly 敮慢l敤⁤慴a扡s攠
Em潳瑧牥pn䰠i m潳瑇fpFⰠ,灡瑩慬 li扲慲y
Ed敯瑯tlsF⁡ 搠愠a畳瑯tize搠d敳k瑯t⁇䥓
com灯湥湴n瑯t摥liv敲⁲ic栠h
灡瑩慬
f畮c瑩潮ality⸠

pl䱁⁴ 畳攠eh攠eA䑍a瑯tm潤敬⁣潲攠oa湤
慤mi湩s瑲慴ao渠n潮ce灴p⸠.A䑍⁳u灰潲瑳

灳敵摯⁴ m灯r慬
d慴a⁳t潲o来⁵ i湧


m攠
s瑡t灳⁡ 搠d扪散琠t敲ei潮i湧
.

B畳in敳s⁒畬攠
䵡湡来m敮t

b慣栠
l慮搠d摭i湩s瑲慴ao渠n来湣y

睩ll⁨慶攠e瑳 ow渠
laws 慮搠
r敧畬慴a潮s
a灰lic慢l攠e漠la湤
慤mi湩s瑲慴ao渮n
E
c丠


ㄬ1
P
Ⱐㄸ⁴
㈰Ⱐ
P㤬94〬044


Ⱐ,䰠


P


pl䱁

瑯tse灡r慴a⁢ si湥ss⁲畬敳⁦r潭
慰plic慴i潮⁣潤e

vi愠愠創les⁩湴nrf慣攮e

創o敳 i湴敲e慣攠e漠o異p潲琠o桥⁵ 攠潦⁡
䑥al慲慴iv攠B畳in敳s⁒畬敳⁅湧in攠
E
䑲潯ls
bx灥r琩爠pn䰠i瑡t敭敮瑳⁦潲⁲畬攠e敦ini瑩潮
慮搠數散畴u潮
.


A来湣y

s灥cific⁲敱畩r敭e湴n⁡ d⽯爠
c桡湧敳⁴漠oaws⁡ 搠牥d畬a瑩潮s⁣a渠ne
i湣潲灯oa瑥t 睩t桯u琠牥煵iri湧⁳ig湩fic慮t
m潤ific慴a潮s⁴ pliA⸠

䑯a畭敮琠
Arc桩ve

T桥⁳ys瑥t⁷ ll⁰牯vi摥⁦慣
iliti敳
瑯ts瑯牥⁡湤慮慧e⁢ t栠
来湥r慴ad⁡ 搠dm慧敤
摯c畭敮瑳
.

E
c丠


ㄷⰠ㈳⁴o′ Ⱐ
㌲⁴ ″ ,″ ,‴ ,‵ ,‵ ,‵ ,‶ Ⱐ



pl䱁⁴ im灬敭敮琠t⁢ sic⁄潣畭敮琠
Arc桩ve

p敲eic攠e漠o異p潲琠s瑯牡来⁡湤
r整物ev慬 ⁧ n敲慴e搠dn搠dm慧敤
摯c畭敮瑳⁦rom⁴ 攠el䱁 摡瑡扡s攮e



FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
11

of
70


Requirement

Description

Significanc
e

Document
Generation
,
Notification
and
Reporting

The system will support
generation of official extracts and
documents suitable for
reporting
and external
correspondence

(e.g. Case Management
notifications, etc)
.
(FN


1
ⰠP
Ⱐ㤬,
㈳Ⱐ,〬0R㌬PR㜬TS㈬OS㤬9T㘬ST㜬T㠳Ⱐ



T桥⁳ys瑥t⁷ ll⁢ ⁣慰a扬e
敭慩li湧⁧
e湥r慴敤
c潲o敳灯湤e湣攠⡑䰠



F


乯⁲敱kir敭敮琠t潲⁵o敲⁴漠敤it
摯c畭敮瑳

c攠ehey 慲攠
来n敲慴e搠dn搠d潣畭敮瑳
mus琠t攠e潲o慢l攠eh敲敦潲攠摯c畭敮瑳⁴ ⁢
来湥r慴ad⁩n⁐䑆⁦潲o慴a

pl䱁
䑥ak瑯t⁴ ⁵ e⁴ e灥渠no畲u攠
g慳灥r剥灯r瑳⁣潭灯湥湴 瑯t来湥r慴攠e䑆
摯c畭敮瑳

慮搠牥d潲瑳


g慶慍慩l Am䤠瑯tb攠ese搠d潲⁳敮摩湧 敭慩ls⸠

䑯a畭
敮琠
䥭慧i湧

T桥⁳ys瑥t⁷ ll⁰牯vi摥⁦慣iliti敳
瑯t慳sis琠
瑨攠
sc慮ni湧 ⁩m慧in朠gf
摯c畭敮瑳
瑨t琠t異灯rt

l慮搠
慤mi湩s瑲慴ao渠nra湳慣瑩o湳⸠.
c丠


ㄷⰠ,㐬4OR

Pㄠ1o″ ,″ ,‶ ,‹ Ⱐ
n䰠



F⸠

乯⁤ir散琠t湴n杲g瑩o渠n整we敮⁓l䱁 慮d
sc慮湩n朠g慲dw慲攠is⁲敱u
ir敤⸠

䑯a畭敮琠
Arc桩ve

p敲eic攠
瑯t扥⁥ 瑥t摥d
瑯tmak攠es攠ef⁡
im慧攠ea湩p畬a瑩o渠ni扲慲y
E
A灡c桥⁃潭m潮s⁓慮s敬慮
F

慮搠d䑆
li扲慲y
m䑆
J
剥湤敲敲F

瑯t
g敮敲慴攠
瑨tm扮慩l
慮搠
灲pview
ima来
s

扡se搠dn
摯c畭敮瑳⁴ 慴ah慶攠e敥渠sc慮湥搠慮d

灬慣e搠d渠nn
慣c敳si扬e

file syst敭潣慴a潮


mri湴ing

T桥⁳ys瑥t⁷ ll⁰牯vi摥⁦慣iliti敳
瑯ts異p潲琠灲i湴n湧 潦⁢ 瑨t
来湥r慴ad⁡ 搠dm慧敤
摯c畭敮瑳⸠⡆丠


1
Ⱐ,
Ⱐ,Ⱐ1〬0㈳Ⱐ
㌵Ⱐ,〬0R㌬PR㜬TS㌬PS㤬9T〬08R
F⸠

pl䱁⁴
灲潶i摥⁰物n
瑩湧⁦aciliti敳 vi愠ah攠
pl䱁⁄敳k瑯t.

bl散瑲o湩c⁄慴a
䥮f敲e桡n来

T桥⁳ys瑥t⁷ ll⁳異p潲琠瑲a湳f敲e
潦⁤ 瑡tt漠or⁦r潭⁴ 攠e慤慳瑲慬
摡瑡扡se
.

E
c丠


㌹Ⱐ,0Ⱐ,1 瑯t㜳Ⱐ
n䰠



F⸠


pl䱁⁴ 灲潶i摥⁳灡tial⁣a灡bility 瑯t
s異灯r琠t慴a 數瑲慣瑳⁢y Ar敡 ⁉ t敲敳琮t

pl䱁⁴

數瑥td⁴ e⁃慤慳tr攠e敲vic
攠e漠
灲潶i摥⁳異p潲琠o潲⁌慮摘䵌
a湤⁃ps
im灯r琠t湤⁥ p潲琮o

A畤i瑩湧 慮d
䱯杧ing

T桥⁳ys瑥t⁷ ll慩湴ni渠nh攠
i湴n杲楴y ⁡ l⁲散潲摳 慮搠慰ply
慰灲p灲楡t攠e潧gin朠gn搠du慬ity
c潮瑲潬敡s畲敳⸠.
c丠


OⰠ㘬S㠬8
㄰Ⱐ,㘬ST〠0o‷ ,‷ ,‷ ,‷ ,‸


Ⱐ,䰠





pl䱁⁴ 畳攠eo朴g⁴ ⁰牯vi摥⁣潮fig畲慢l攠
l潧杩n朠g灴p潮s

f潲⁳yst敭 摥扵朠
i湦潲o慴a潮⁡ d⁥ c数ti潮s.

pl䱁⁴ 畳攠ep灬ic慴a潮 level⁡ 摩tin朠g潲o
湯mi湡瑥t⁳ys瑥t⁦畮c瑩潮s⽴牡湳慣瑩潮s
畳i湧 䍯湴數琠tn搠䑥灥湤敮cy⁉湪散瑩o渠
E䍄䤩⁉ 瑥牣数t潲o⸠

pl䱁
瑯t畳攠e
rig来r⁢慳敤 慵di琠瑲tils⁡ ⁴ e
䑡瑡 䱡y敲⁴漠瑲慣k
慬l
摡瑡tc桡湧敳
i湣lu摩湧⁴桯s攠
m慤攠eir散tly⁴漠o桥
摡瑡扡s攮e


FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
12

of
70


Requirement

Description

Significanc
e

System
Administration

The system will provide features
to support
system administration
,
security and configuration.
(FN


㄰Ⱐ
T㔠Ro‷
,

㠳,‸ ,‸ 瑯t94
F⸠

pl䱁⁴ im灬敭敮琠t⁓yst敭
p敲eic攠eo
s異灯r琠t摭i湩s瑲慴a潮⁲el慴敤⁵灤慴敳⁡ 搠
c桡湧敳⸠

pl䱁⁴ 灲潶i摥
pliA Admi湩s瑲慴a潮
s散瑩潮 i渠pliA⁄敳k瑯t

f潲⁣潤攠eis琠
c桡湧敳
Ⱐ扵si湥ss⁲畬e慩湴nn慮ce

a湤
r敬慴a搠
sys瑥t
c潮fi杵
r慴io渠n慴愮a

T桥⁓l䱁 p散畲uty 䵯摥l⁩s⁢ s敤⁡牯畮搠
瑨t⁣慰慢ili瑩敳 ⁊bb p散畲楴y

慮搠tp
J

s瑡t摡r摳
⸠.敦敲⁴漠瑨攠e散瑩潮


p散畲ity
f潲⁤整oils.


Acc敳s⁴
mr潰敲ey⁡湤
䍡摡s瑲攠
䥮f潲m慴a潮

T桥⁳ys瑥t⁷ ll⁰牯vi摥⁦慣iliti敳
瑯tallo眠瑨攠eu扬ic⁴

re煵es琠
慮搯潲

潢t慩渠n湦潲m慴a潮渠
la湤
慤mi湩s瑲慴ao渠牥n潲摳.

Eck



瑯‷t
F

pl䱁⁴ im灬敭敮琠
瑨t⁓l䱁

t敢
A灰lic慴io渠no
s異p潲琠摥灬oym敮琠慳

灵blic⁣潵湴nr⁳敲eic攠慶慩l慢l攠
from慮搠
慤mi湩s瑲慴ao渠nffic敳

T桩s⁷敢⁡灰lic慴io渠
c潵l搠慬s漠扥 摥ploye搠dn⁴桥⁩湴nrn整e瑯
s敲e攠e敮敲el⁰畢lic⁥湱uiri敳

3.1.2

System
Qualities

The following table identifies and discusses the qualities of the
SOLA

(i.e. non functional
requirements) that have architectural significance
.


Quality

Description

Significance

Security

The system will include security
measures for user
authentication,
a
uthorization
, confidentiality and
integrity
.

(
QL


31, 32
).

The system will ensure the
integrity of all data stored. (QL


1, 2).

Periodic back
-
up of system data
will be supported to avoid data
loss. (QL


9)

The SOLA Security Model is bas
ed
around the capabilities of JEE Security
and WS
-
* standards. Refer to the
section
10

Security
for details.

SOLA to use the Java Transaction API
(JTA) to support D
istributed
Transactions (a.k.a. 2 Phase Commit).

SOLA database to use the UNICODE
(UTF
-
8) character set to ensure
accurate storage of multi
-
lingual data.

SOLA to use an industry standard
database with online backup capability
(PostgreSQL).

System
Performance

User volumes and performance
targets

for the system (QL


34 to
39
)

Separate Search Service to improve
performance of searches that would
otherwise require coordinating and
managing the output from several
service calls.

Transaction logging to

include start
and end times for performance
reporting.

Refer to the section
9.3

Performance
for details.


FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
13

of
70


Quality

Description

Significance

Maintainability

The system will comply
with
development techniques and
standards that encourage high
quality
, maintainable software (QL


㄰,‱ ,‱ 瑯t1㘬SOP


A摨敲攠瑯⁣潤i湧⁳瑡湤慲摳.

啳攠e潤攠e整物cs
瑯tls
攮g⸠.o湡rF
瑯t
r敧畬慲ay
条畧攠eh攠eys瑥t⁣潭灬數ity⸠

啳攠e啮rt

f潲⁡o瑯t慴a搠dni
琠瑥s瑳⸠

啳攠䙩瑮敳s攠e潲⁡畴om慴a搠dys瑥t
瑥t瑳⸠

啳攠eu扶敲ei潮 潦⁳潵rc攠e潮瑲潬.

啳攠e慶a䑯a⁦潲⁁of⁤ cum敮瑡ti潮.

啳攠e潧㑊⁴ ⁣a灴pr攠數c数瑩o渠
i湦潲o慴a潮⁦潲慴ar⁡湡lysis

慮搠
g慶慍慩l Am䤠瑯tf潲
w慲搠數c数瑩o渠
摥瑡ils vi愠am慩
l


pc慬a扩lity

T桥⁳ys瑥t m畳琠t攠e慰a扬攠ef
扥i湧⁤数loy敤⁩no慤 扡la湣敤
慮搠d潲⁦慩lov敲⁣潮fi杵r慴io湳
n䰠




啳攠ebb 㘠S湤⁇l慳sfis栠h灰lic慴a潮
p敲e敲⁴漠eu灰潲琠摩s瑲i扵te搠
摥ploym敮琠t湤 l潡搠d慬慮ci湧
pl䱁⁓敲vic敳 if⁲敱畩re搮

pl䱁
t敢
p敲eic敳

慮搠bgBs

摥sig湥搠慳⁳瑡tel敳s⁴ ⁳u灰潲琠
sc慬i湧 t ⁳敲eic敳⸠

pl䱁⁴ 畳攠en⁩n摵s瑲y⁳t慮摡r搠
摡瑡扡s攠e散桮ology
m潳t杲敓n䰩i
瑨t琠tu灰潲瑳⁳c慬i湧⁵
,⁲e灬ica瑩o渠
慮搠d慩lv敲⁣o湦i杵r慴i潮s.

䑥灬oyme湴

T桥⁳ys瑥t m畳琠t攠e慰a扬攠

s異灯r瑩湧 愠
c敮瑲aliz敤⁡ 睥wl
慳⁡ 桵b
J
慮d
J
s灯k攠e数loym敮琠
m潤敬
s

En䰠



F

T桥⁳ys瑥t
m畳琠t攠e潲瑡bl攠
慣r潳s
m
慪潲灥r慴an朠gyst敭s⸠
En䰠


ㄹ 瑯tO㈬OO4
F

T桥⁳ys瑥t m畳琠
灲潶i摥
慵瑯t慴a搠d湳瑡lla瑩o渠n慣k慧敳
f潲om慪潲o
sys瑥t⁣om灯湥湴n

E
n䰠



F

啳攠䝬eb慬 啮r煵攠ed敮tifiers
d啉䑳F
f潲⁲散潲搠䥤o⁴ ⁡voi搠i搠dl慳桥s w桥渠
畳i湧
re灬ic慴i潮.

啳攠el潮y
J
䤠f潲⁥湴敲灲is攠l敶el
r数lic慴a潮.

pl潮y
J
䤠f異p潲os⁍ s瑥t
J
plave⁲数lic慴i潮Ⱐ,畴umay 湯琠t異灯r琠
䡵e
J
慮d
J
s灯k攠m潤敬 i湤ic慴a搠by⁑䰠


ㄹ.⁆畲瑨tr

inv敳ti条tio渠牥煵ir敤⸠

啳攠e慶a⁡ ⁴ 攠eevelo灭敮琠
l慮杵a来

t漠o異p潲琠o潲瑡oility
r敱畩r敭敮瑳.


b湴nr灲楳攠Arc桩v攠⡅A利⁵s敤⁦潲o
摥ploym敮琠tf⁓liA p敲vic敳⁡ 搠
bgBs⁩湴n⁴桥 p敲vice
s

䡯e琮

g慶愠t敢⁓瑡牴⁵te搠d潲⁤o灬oym敮琠潦
瑨t pl䱁⁄敳k瑯t⁴ i
湩mis攠
i湳瑡lla瑩o渠n湤⁣o湦i杵r慴io渠
r敱畩r敭敮瑳 敮d⁵ 敲e com灵瑥牳⸠


FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
14

of
70


Quality

Description

Significance

Data Migration

The database to support ETL
tools to
assist

dat
a migration
activities. (QL



F

pl䱁⁴ 畳攠en⁩n摵s瑲y⁳t慮摡r搠
摡瑡扡s攠⡐潳瑧牥pn䰩iwhic栠hs
s異灯r瑥搠dy
a⁲慮g
攠ef
潰敮⁳潵rce
4

as well as commercial ETL tools.

The Land Administration Data Model
(LADM) to be used as the basis for the
SOLA database and support
compatibility with other LADM based
products.

Localization

The system will be capable of
supporting
multiple languages
(QL




啳攠ef⁊慶愠䱯c慬攠eo⁩d敮tify 瑨t
l潣慬iz慴i潮 灡r慭整ers.

啳攠

g慶愠a敳潵rc攠B畮摬敳⁴漠
灲潶i摥 l潣alize搠dra湳l慴io湳⁦潲⁓佌o
䑥ak瑯t⁳cr敥渠n慢敬s

a湤 s瑡tic⁴ xt
.

䵥ss慧i湧⁕瑩l
ity
t漠
c敮瑲alize

mess慧攠er潣敳si湧 慮搠dr潶i摥
l潣慬iz敤 瑲慮sl慴a潮s⁦潲⁓l䱁
来湥r慴ad
m敳s慧敳

vi愠aav愠
剥o潵rc攠e畮dl敳⸠

pl䱁⁲敦敲敮e攠ea瑡tdis灬ay val略s
c慰慢le


s
異p潲o
i湧畬瑩灬攠
瑲慮sl慴io湳⁦潲⁤os灬ay⁴漠oh攠es敲e

p異灯r琠t潲⁣慬e湤慲al潣aliz慴ao渠no⁢
i
nv敳瑩条瑥搮d

䱯w

mo睥w

pu灰ly

bnviro湭敮瑳

p潭攠e慮d⁡ mi湩s瑲慴i潮
慧敮ci敳 敲慴e⁩n⁥ viro湭敮瑳
睨敲攠wow敲⁳u灰ly is 琠
杵慲a湴ne搠d湤⁰ow敲e潵瑡来s
慲攠愠a潭m潮 c畲u敮c攮

En䰠


㈵O

䡡edw慲攠ao湦i杵r慴io渠n漠i湣l畤攠

啮rn瑥牲異t慢l攠mow敲e
pup灬y
啐pF

瑯tallo眠
s畦fici敮琠瑩m攠e潲o
c潮瑲潬le搠
s桵瑤t睮f⁳ys瑥ts.

m敲e潲m慮c攠e敳瑩湧 ⁓l䱁⁴漠oe
畮摥rt慫敮⁴ ⁥湳畲攠
Cm唠
慮搠牥l慴敤
r敳潵rc攠es慧e

is
mi湩mis敤⸠

pl䱁⁴ i湣潲灯o慴a a
n

aler琠tyst敭
瑨t琠湯tifi敳⁵ 敲e w桥渠nig湩fic慮琠
慣瑩潮s
潣c畲⁳畣栠hs⁴牡湳i瑩潮⁴漠
啐p⁰ 睥w

T桩s⁩s⁡ 灲潰ps敤⁦敡瑵牥t
瑨t琠牥煵ir敳⁦畲瑨敲⁩nv敳ti条瑩潮⸠







4

Example open source ETL tools supporting PostgreSQL include; Pentaho Kettle, GeoKettle, Talend
Open Studio and Talend Spatial Data Integrator.


FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
15

of
70


3.2

C
onstraints

The following table identifies and discusses the main architectural constraints that
SOLA

must comply with.


Constraint

Description

Open Source

To achieve the goals of the
SOLA

project, the software must be free/libre and
open source. Any software
components or

standards
used for
SOLA

(e.g.
database,
GIS software
, etc) must be non
-
proprietary

and compatible with the
Modified
BSD

licens
e
5
.
(QL


18
)

Portability

SOLA

must be fully transferable to a wide
range of major hardware
or
operating system platforms
. The development language and supporting
components used for SOLA must all comply with the po
rtability requirements.
(QL


19 to 22,
24
).

3.3

Principles

Architectural principles are used to guide architectural and high level design decisions to
ensure the architecture is consistent. Each architectural principle is described via a standard
pat
tern as follows




Principle name



Description



Rationale

/ Benefits



Implications


From consideration of the architectural r
equirements and constraints
the following

architectural p
rinciples have been established

for

SOLA
.




Leverage open source components and non proprietary industry standards



Use
modular loosely coupled components where possible



Use and Enterprise Application Framework


Leverage
open source components
and

non proprietary
industry
s
tandard
s

Description:

Technology and infrastructure selection decisions
will

be

based upon
the
availability of proven open source components and
non proprietary

industry
standards
.

Custom solutions

should only be used when
open source components and/or
non proprietary
industry
standard
s

are unavailable
, unproven

or insufficient to
satisfy project requirements.

Proprietary
components and standards should be avoided unless
the
y

are
ubiquitous (e.g. Windows operating system)
.




5

Open Source License selected for the SOLA Development Snapshot
.


FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
16

of
70


Leverage
open source components
and

non proprietary
industry
s
tandard
s

Rationale /
Benefits:

Compliance with
standards
avoids a dependence on the skills to

b
uild or
customiz
e and maintain
a

custom solution. Such skills tend

to be in short
supply.

Facilitates and simplifies interoperability (technical and functional) between
differing systems.

Proprietary components and standards will limit the flexibility of
SOLA

and
likely impose technical and financial constraints on the
land administration
agencies

wishing to use it.

Complies with the
SOLA

Open Source
architecture
constraint.

Implications:

Use of
open source

compon
ents (e.g. Postgresql, PostGIS,
Glassfish
, Metro,
etc) as well as
compliance with recognised
non proprietary
standards
(e.g.

WS
-
*
, WFS, LADM,

etc
)
.


Use modular loosely coupled and interoperable
components where possible

Description:

IT solutions should be engineered with a bias
towards

using highly discrete,
loosely coupled
and interoperable
components
.

Rationale

/
Benefits
:

Loose coupling reduces the complexity of a system of interacting

components.
It allows making internal changes to one component without

affecting other
com
ponents. It improves availability and stability of the

system since problems
with one component are less likely to impact other

components.

Components can be reliably changed more quickly than otherwise would

be
the case.
Functional scope of the components

is reduced which in turn

reduces
their complexity
.

Interoperability enhances opportunities for reuse, reduces costs by reducing
duplication of effort and reducing integration complexity.

Implications:

Use of layering (Presentation, Services and Data) to decompose the system
into manageable blocks.

Use of
a web services based architecture
and Metro to support WS
-
*
compliant
interfaces
(QL


26
)
minimizing

the barriers for integration with other systems
.

Use of stateless EJBs to encapsulate business logic and Dependency Injection
to allow alternative EJB implementations to be deployed and used in
preference to the default EJB implementations.

Use of rules engine
to separate business rules from applicat
ion code and to
centralise and simplify rule definition and maintenance.

Use
Separated Presentation
design pattern
and
beans
binding
in the
presentation layer to separate the

user interface from model data
and
controlling logic
(i.e. beans)
improving maint
ainability and testability.

Use of Domain and Repository patterns to separate
business

logic from ORM
implementation details.





FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
17

of
70



Use
an

Enterprise Application Framework

(EAF)

Description:

An
EAF

provides services and support for common enterprise system
mechanisms such as persistence, security, messaging, UI presentation, etc.

Rationale /
Benefits:

Typically the
EAF

will comply with recognised standards ensuring
interoperability and significantly reduce the overall coding effort required to
produce reliable, scalable and performant enterprise applications.

EAFs are usually well supported through Integrated Develo
pment Environment
(IDE) tooling.

Removes the need to evaluate and integrate a large range of components
each responsible for achieving specific mechanisms (e.g. persistence
framework, UI framework, etc).

Implications:

Use Java Enterprise Edition 6 as th
e
EAF

for SOLA.
(QL


20 to 22, 24
)

Use Glassfish 3 and Metro as the
application server

platform for SOLA.

Note that
JEE is a mature standard which is portable across a number of
application server vendors and will have the largest vendor support base in
future
.
The JEE standard documentation and learning path is
also
of a higher
quality than alternative languages and other Java based Enterprise Application
Frameworks. Coupled with broad vendor support this will
further
enable the
land administration agenc
ies
that adopt SOLA
to enhance and maintain their
own SOLA implementations.


FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
18

of
70


4.

Architectural Mechanisms

This section presents the architectural mechanisms of the
SOLA

and identifies how these
will be incorporated during design and implementation. Note that architectural mechanisms
represent common solutions to frequently encountered architectural problems and are often
used to realise architectural requirements.

4.1

Analy
sis Mechanisms

The following table describes the analysis mechanisms applicable to
SOLA.


Analysis Mechanism

Description

Persistence

The

means to make an element persistent (i.e. save an object’s state
across multiple executions of the application).

Communication

The means by which distributed processes communicate.

Business Logic Encapsulation

The means by which business logic is encapsulated

in the application
to
enable

consistent
reuse of the logic while
also
remaining
loosely
coupled and
maintainable.

Transaction Management

The means by which ACID transactions are handled.

Security

Protect access to certain resources or information.

Auditing

Provide audit trails of system execution and access to system
managed resources and information
.

Business Rules

The means to manage and execute business rules.

Workflow

The means to manage and control the progress of key items as they
are processed through the systems.

Error Management

Allows errors to be caught, propagated, managed and
reported.

Document Generation

&
Reporting

The means by which the system will generate documents and
reports
.

User Interface

Provide facilities for windows presentation and user interaction.

Electronic Data Interchange

The means by which the system will

exchange data.


Notifications

The means by which the system will generate user notifications.

Printing

The means by which the system will print system generate
documents.

Geographical Information
Systems (GIS)

The means by which the system will
support storage, viewing and
manipulation of GIS dat.

Image Manipulation

The means by which the system will support manipulation of images.

Localization

The means by which the system will support localization of the
product to a specific locale and or provide runtime support for
multiple locales.


FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
19

of
70


4.2

Analysis Mechanism Mappings

The following shows how the analysis mechanisms above have been mapped to design
and
Implementation mechanisms.


Analysis Mechanism

Design Mechanism

Implementation Mechanism

Persistence

Relational Database

PostgreSQL


Object Relational Mapping
(ORM)

Java Persistence
Architecture
API
(JPA)

and Hibernate Java Persistence
Framework


Data Replication

Slony
-
I

Communication

Inter Process Communication
(IPC)

Java API for XML Web Services
(JAX
-
WS), Glassfish Metro

Business Logic
Encapsulation

Business Interfaces

Enterprise Java Beans (EJB)
,
Dependency Injection

Transaction Management

Distributed Transactions

Java Transaction API (JTA)

Security

Authentication

Username Authentication with
Symmetric Key

and Trusted
Subsystem Model, WS
-
*, Glassfish,
Metro


Authorisation

Role Based Access Control (RBAC),
Glassfish Roles and Groups,
Declarative Authorisation


Communication

WS
-
*

protocols
, Symmetric Data
Encryption

Auditing


DB Triggers
, Log4J

Business Rules

Business Rule Service

Declarative Business Rules Engine
(BRE
)


Drools Expert
, SQL Queries

Workflow

State Transition Modelling

Custom s
tate
/status attribute on key
e
ntities

Error Management

Structured Exception Handing
and Logging

Log4J logs
,
Web Services
Fault

Contract

Document Generation &
Reporting

Report Generator/Tool

JasperReports

User

Interface

Desktop Client

Java Swing
, MVC pattern, beans
binding

Electronic Data
Interchange

F
lat file and

XML

C
omma
S
eparated (CS
V
)
, LandXML

Notifications

Email

JavaMail API, Simple Mail Transfer

FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
20

of
70


Analysis Mechanism

Design Mechanism

Implementation Mechanism

Protocol (SMTP)


Document Format

Portable Document
Format (PDF)

Printing

Client

Side Printing

JasperReports Viewer

Geographical Information
System (GIS)

Spatial Data
Persistence

PostGIS extension for PostgreSQL


GIS Library

Geotools


Desktop GIS

Custom Swing component

Image Manipulation

Image
Manipulation Library

Sanselan, PDF
-
Renderer

Localization

Screen Labels

Java Locale,
Swing and
Java
Resource Bundles


User Messages

Java Locale and c
entralized message
processing utility
using

Java
Resource Bundles


Reference Data

Database function
to
obtain
translations for display values


Currency

Java Locale, currency / money utility


Calendar

TBC



FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
21

of
70


5.

Use Case View

This section identifies those use cases or scenarios from the use case model that represent
significant, central functionality of the system,
address architectural risks
or they have a
large architectural coverage


that is they exercise many architectural

elements, or if they
stress or illustrate a specific, important point of the architecture.

5.1

Architecturally Significant Use Cases

The following use case diagram shows those use case
(
s
)

that are considered architecturally
significant.


Figure
2



Architecturally Significant Use Cases

The

uses cases that are part of

the
SOLA

but

are not identified above are considered
simpler and more straightforward examples of the architecturally significant use cases and
are not repre
sented explicitly in the Software Architecture Document. However the
architectural approach and mechanisms will be the same for the simpler use case as for the
complex use cases explicitly described
here
.


The following sections briefly describe the archit
ecturally significant features for each of the
use cases identified and include references to the architectural risks
6

addressed by each
feature.

5.1.1

UC01 Service Enquiry

An enquiry made by a land office client concerning the status of an existing service
application or a general enquiry about the services provided by the land office and the
requirements and fees pertaining to the service.





6

Refer to Appendix 3



Architectural Risks for details.

UC01 Service
Enquiry
UC03 Lodge
Application
UC04 Review Quality
UC05 Register or
Approve
UC06 Ceate New
Property
Land Office Client
Public Counter Officer
Notification Service
Quality Reviewer
Registrar or Approving
Officer
Land Officer Specialist
Archivist

FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
22

of
70


Architecturally significant a
spects of this use case include




Search Records

(FN 4)



Uses the Search Service to impr
ove cross service search
performance
(Risk 4

& 7
).



View Cadastral Map

(FN 10)


Uses the
SOLA Map Viewer

and
Spatial

Service
to
display the cadastral map
(Risk
3
, 4, & 6
)

5.1.2

UC03 Lodge Application

The receipt and the recording of a land office service request details
and any changes to
rights or property definitions arising from the application. I
nitially
this is completed
by a land
officer serving at a public counter in the land office and subseque
ntly by a land officer
working in the “back office

.


Architecturally significant aspects of this use case include




Lodge New Application (FN 21)


Coordinates

multiple EJB’s to save
application details

(Risk
s 4 &

7).



Lodge Notice (FN 23)


Uses Jasper Re
ports to generate the Lodgement Notice (Risk 3)



A
pplication Main Documents (FN 24
)


Uses the
Digital Archive

Service to support
linking of imaged documents to the application (Risk
2
).



Link New Boundary Nodes t
o Existing Cadastre Nodes (FN 43
)


Illustrat
es using the
SOLA Map Viewer

for spatial editing tasks (Risk
s

3

& 6
)

5.1.3

UC04 Quality Review

The review of the recording of the application and any changes to rights or property
definitions to ensure their correctness, that all required supporting documents
have been
provided and that these are consistent with the application. The “back office” land officer will
conclude this review with a recommendation as to whether the application can proceed.


Architecturally significant aspects of this use case include




C
omplete Quality Checklist (FN 48
)


Uses the
business rules engine to automatically
verify the quality of the data supporting the application
(Risk

3
)

5.1.4

UC05 Register or Approve

The duly delegated land officer (typically registrar or approving surveyor) will further review
an application and, if satisfied, will approve (a change to the cadastre) or register (an
application for registration). At that time the proposed changes to ri
ghts or property
definitions
take the status of “current” and any former rights or property definitions take the
status of “historic”.


Architecturally significant aspects of this use case include




Register Transaction

(FN
55
)


Uses the
Administrative

Ser
vice
and the Cadastre
Service
to apply
status

changes to land administration records
that must be managed as
one transaction
(Risk
s

5

& 7
).

5.1.5

UC06 Create New Property

Where an application is received to create a new property, details concerning the new
prop
erty must be recorded, any existing rights either cancelled or transferred to the new
property and the existing property records to be
superseded

identified
. A new certificate is
then issued for the new property (a certificate of title in jurisdictions whe
re title registration is
practised).



FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
23

of
70


Architecturally significant aspects of this use case include




Verify
Draft Title Details (FN 59
)


Uses the Cadastre Services to effect changes to
spatially defined
land administration records (Risk 3)

5.2

Use
-
Case
Realisations

This section illustrates how the software will work by giving the use case (or scenario)
realisations of the architecturally significant use cases

and features
. These use case
realisations consist of sequence diagrams which model how the vario
us design model
elements of the system will interact to achieve the required behaviour.



FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
24

of
70


5.2.1

UC01 Service Enquiry



Search Records (FN 4)

The Public Counter Officer enters search criteria into the Application Search Form, which may include application details as
well as agent or
contact person (i.e. party) information. The Search EJB executes a s
earch using

its entity m
anager
7

a
nd

a
JPA Named Query
8

across both the
Application and Party schemas. The results are returned to the Application Summary Bean which notifies the Application Search

Form to
refresh via a Property Changed event.



Figure
3



UC01 Service Enquiry


Search Records (FN 4)

Sequence Diagram

A





7

http://www.objectdb.com/api/java/jpa/EntityManager

8

http://www.objectdb.com/java/jpa/query/named

TypeConverters
Publ i c Counter Offi cer
Application
Search Form
Application
Summary Bean
Search Service
SOLA Database
Search Client
Search EJB
Generic Translator
[Enter cri teri a and
cl i ck Search]:
searchAppl i cati ons(Cri teri aBean)
fromBean(Cri teri aBean) :
Cri teri aTO
searchAppl i cati ons(Cri teri aTO) :
Li st<Appl i cati onSummaryTO>
searchAppl i cati ons(Cri teri aTO)
:Li st<Appl i cati onSummaryTO>
fromTO(Cri teri aTO) :Cri teri a
searchAppl i cati on(Cri teri a) :
Li st<Appl i cati onSummary>
getResul tLi st("searchAppl i cati ons", Cri teri a) :
Li st<Appl i cati onSummary>
toTO(Li st<Appl i cati onSummary>) :
Li st<Appl i cati onSummaryTO>
toBean(Li st<Appl i cati onSummaryTO>) :
Li st<Appl i cati onSummaryBean>
propertyChanaged()
getAppl i cati onSummaryBeanLi st()
refresh()

FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
25

of
70


The Public Counter Officer can
view the
details of a selected

a
pplication

in the Application Form.
The a
gent,
contact p
erson,
a
ddress
and
source
details associate
d with the
selected a
pplication are lazy loaded
via the appropriate EJB
and translated to equivalent TOs
during the
translation of the a
pplication
i
n the Services Layer.


Figure
4

-

UC01 Service Enquiry


Search R
ecords (FN 4)
Sequence Diagram B

TypeConverters
Publ i c Counter Offi cer
Application
Search Form
Application
Summary Bean
Case
Management
Service
SOLA Database
Case
Management
Client
Party EJB
Application Form
Application EJB
Generic Translator
Address EJB
Source EJB
[Sel ect Resul t]:
getSel ectedAppl i cati on()
create(sel ectedAppId)
open()
getAppl i cati on(appId) :Appl i cati onTO
getAppl i cati on(appId) :
Appl i cati onTO
getAppl i cati on(appId) :
Appl i cati on
fi nd(appId) :Appl i cati on
toTO(Appl i cati on) :Appl i cati onTO
getAgent(agentId) :Party
fi nd(agentId) :Party
getAddress(agentAddrId) :
Address
fi nd(addressId) :
Address
getContactPerson(contactPersonId) :
Party
fi nd(contactPersonId) :Party
getAddress(contactPersonAddrId) :Address
fi nd(addressId) :Address
getSources(appId) :Li st<Source>
fi ndByAppl i cati onId(appId)
:Li st<Source>
toBean(Appl i cati onTO) :Appl i cati onBean
di spl ay()

FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
26

of
70


5.2.2

UC01 Service Enquiry


View Cadastral Map (FN 10
)

The Public Counter Officer selects the Map button to display the SOLA Map Viewer. The Starter is a
S
ingleton that holds a reference to the
Spatial Client
through

the Pojo

Data Access class.
Once the Map is configured, the data for each layer is loaded

from the Spatial Service. The
Result For Navigation entity is exposed by the Spatial Service to avoid the need to translate the navigation data into a TO.



Figure
5

-

UC01 Service Enquiry


View Cadastral Map (FN 10) Sequence Diagram


Publ i c Counter Offi cer
Control Bundle
Main Form
Starter
Spatial Client
SOLA Database
Spatial Service
Poj o Data Access
Map
Search EJB
loop each Poj o Layer
[Cl i ck Map Button]:
getControl Bundl e() :Control Bundl e
create()
create()
setup(Poj oDataAccess)
confi gure()
confi gureLayers(Poj oDataAccess)
zoomToExtent()
l oad(queryName,
boundi ngBox) :l ayerData
getSpati al ForNavi gati on(QueryForNavi gati on) :
Resul tForNavi gati on
getSpati al ForNavi gati on(QueryForNavi gati on) :
Resul tForNavi gati on
getSpati al Resul t(QueryForNavi gati on) :
Resul tForNavi gati on
getResul tLi st(queryName,
boundi ngBox) :
Resul tForNavi gati on
di spl ay(Control Bundl e)

FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
27

of
70


5.2.3

UC03 Lodge Application


Lodge

New Application (FN 21)

Create Application uses the appr
opriate EJB to save
new
party, ad
dress and source details.


Figure
6

-

UC03

Lodge Application



Lodge New Application (FN 21
) Sequence Diagram

A

TypeConverters
Publ i c Counter Offi cer
Application Form
Application Bean
Case
Management
Service
SOLA Database
Case
Management
Client
Party EJB
Report Manager
Application EJB
Generic Translator
Address EJB
Source EJB
loop each Source
[Lodge Appl i cati on]:
l odgeAppl i cati on()
fromBean(Appl i cati onBean) :
Appl i cati onTO
createAppl i cati on(Appl i cati onTO) :
Appl i cati onTO
createAppl i cati on(Appl i cati onTO) :
Appl i cati onTO
fromTO(Appl i cati onTO, nul l ) :
Appl i cati on
createAppl i cati on(Appl i cati on) :Appl i cati on
cal cul ateFeesAndDates()
al l ocateAppNumber()
saveParty(contactPerson) :Party
saveAddress(Address) :Address
persi st(Address)
persi st(Party)
saveSource(Source) :Source
persi st(Source)
persi st(Appl i cati on)
toBean(Appl i cati onTO) :Appl i cati onBean
showLodgementNoti ce(Appl i cati onBean)

FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
28

of
70


Saving an application is similar to creating the application with the main difference that the application is first retrieved

from the database the
data
from the Application

TO is translated into the attached application. This ensures any entity properties that are not exposed through the
Transfer

Objects
remai
n unchanged

during JPA Merge / Persist operations

(also see section
6.9.1

Abstract TOs
)
.


Figure
7

-

UC03 Lodge Application


Lodge New Applicatio
n (FN 21) Sequence Diagram B

TypeConverters
Publ i c Counter Offi cer
Application Form
Application Bean
Case
Management
Service
SOLA Database
Case
Management
Client
Party EJB
Application EJB
Generic Translator
Address EJB
Source EJB
loop each Source
Associ ated enti ti es l azy l oaded duri ng transl ati on.
[Save Appl i cati on]:
saveAppl i cati on()
fromBean(Appl i cati onBean) :
Appl i cati onTO
saveAppl i cati on(Appl i cati onTO) :
Appl i cati onTO
saveAppl i cati on(Appl i cati onTO) :
Appl i cati onTO
getAppl i cati on(appId) :
Appl i cati on
fi nd(appId) :Appl i cati on
fromTO(Appl i cati onTO,
Appl i cati on) :Appl i cati on
saveAppl i cati on(Appl i cati on) :Appl i cati on
cal cul ateFeesAndDates()
saveParty(contactPerson) :Party
saveAddress(Address) :Address
persi st(Address)
persi st(Party)
saveSource(Source) :Source
persi st(Source)
persi st(Appl i cati on)
toBean(Appl i cati onTO) :Appl i cati onBean

FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
29

of
70


5.2.4

UC03 Lodge Application


Lodge Notice (FN 23)

As part of lodging a new application, the lodgement
notice

is generated using Jasper Reports. The Lodgement Notice Template is filled with
data from the Application Bean

and displayed to the Public Counter Officer in the Jasper Viewer. The Public Counter O
fficer can optionally print
the lodgement notice from Jasper Viewer.


Figure
8

-

UC03 Lodg
e Application


Lodge Notice (FN 23) Sequence Diagram



JasperFillManager
Publ i c Counter Offi cer
Application Form
Jasper Viewer
Report Manager
[Lodge Appl i cati on...]:
showLodgementNoti ce(Appl i cati onBean)
getResource(j asperReportName) :
l odgementNoti ceTempl ate
fi l l Report(l odgementNoti ceTempl ate, Appl i cati onBean) :JasperPri nt
create(JasperPri nt)
di spl ay()

FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
30

of
70


5.2.5

UC03 Lodge Application


A
pplication Main Documents (FN 24
)

When attaching a

document, SOLA retrieves the list of files from the default file system location
(an accessible network location)
and displays
basic file information (e.g. file name, etc) to the Public Counter Officer.
The Public Counter Officer can choose t
o view a thumb
nail of one of
tho
se files, or they can browse their local file system to locate the document to attach. This diagram illustrates retrieving th
e file information
from the default file system location.



F
igure
9



UC03 Lodge Application


A
pplication Main Documents (FN 24
) Sequence Diagram

A

Publ i c Counter Offi cer
File System
Digital Archive
Service
Digital Archive
EJB
Application Form
File Browser
Form
Digital Archive
Client
Generic Translator
Type Converters
[Sel ect document, cl i ck Attach]:
create()
di spl ay()
getAl l Fi l es() :
Li st<Fi l eInfoTO>
getAl l Fi l es() :
Li st<Fi l eInfoTO>
getAl l Fi l es() :Li st<Fi l eInfo>
getFi l e(fi l eName) :Fi l e
createFi l eInfo(Fi l e) :
Fi l eInfo
toTO(Li st<Fi l eInfo>) :
Li st<Fi l eInfoTO>
toBean(Li st<Fi l eInfoTO>) :Li st<Fi l eInfoBean>
PropertyChanged()
refresh()

FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
31

of
70


If the Public Counter Officer selects one of the files, a thumbnail is generated so the officer can view the first page of th
e document and confirm
it is the correct document t
o attach. The officer can also choose to open the document to view the full contents of the document (not illustrated
in this diagram).


Figure
10

-

UC03 Lodge Application


Application Main Docu
ments (FN 24) Sequence Diagram B



Publ i c Counter Offi cer
File System
Digital Archive
Service
Digital Archive
EJB
File Browser
Form
Digital Archive
Client
Generic Translator
Type Converters
File Info Bean
[Sel ect fi l e]:
getThumnai l Icon()
getThumbnai l (fi l eName) :Fi l eBi naryTO
getFi l eThumbnai l (fi l ename)
:Fi l eBi naryTO
getFi l eThumbnai l (fi l ename) :Fi l eBi nary
getFi l e(fi l ename) :Fi l e
createThumbnai l (Fi l e) :Fi l eBi nary
toTO(Fi l eBi nary) :Fi l eBi naryTO
toBean(Fi l eBi naryTO) :Fi l eBi nary
createIcon(Fi l eBi nary) :ImageIcon
propertyChanged()
getIcon() :ImageIcon
refresh()

FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
32

of
70


When the Public Counter Officer confirms the document to attach, the document is saved to the SOLA Database.


Figure
11

-

UC03 Lodge Application


Application Main Docu
ments (FN 24) Sequence Diagram C




Publ i c Counter Offi cer
File System
Digital Archive
Service
Digital Archive
EJB
File Browser
Form
Digital Archive
Client
Generic Translator
Type Converters
Document Bean
SOLA Database
[Confi rm Attach]:
createDocumentFromServer(fi l ename) :
DocumentBean
createDocumentFromServer(DocumentTO,
fi l ename) :DocumentTO
createDocumentFromServer(DocumentTO,
fi l ename) :DocumentTO
fromTO(DocumentTO) :Document
createDocument(Document, fi l ename) :
Document
getFi l e(fi l ename) :Fi l e
persi st(Document)
toTO(Document) :DocumentTO
toBean(DocumentTO) :
DocumentBean
propertyChanged()
cl ose()

FAO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
33

of
70


5.2.6

UC03 Lodge Application


Link New Boundary Nodes to Existing Cadastre Nodes (FN 43)

To be completed.

5.2.7

UC04 Quality Review


Complete Quality Checklist (FN
48
)

To be completed.

5.2.8

UC05 Register or Approve


Register Transaction (FN 55)

To be completed.

5.2.9

UC06 Create New Property


Verify Draft Title Details (FN 59)

To be completed.



F
AO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
34

of
70


6.

Logical View

This section
describes the architecturally significant parts of the design and its
decomposition into packages and subsystems. For some significant packages the logical
view is further decomposed into interfaces and classes.

6.1

Overview

The following package diagram shows

the high level package
s and elements that make up
SOLA
.


Figure
12



SOLA

Package

Overview

The architecture of the
SOLA

ha
s been designed using the l
ayered architectural pattern. A
two dimensional layering approach has been used

to structure the software firstly by
responsibility and secondly for reuse.


In the following sections each of the layers and high level packages are briefly described,
along with any si
gnificant classes or components,
their
key

responsibilities

and the
name
spaces used for the packages
.

Note that
all
SOLA package names will stem from
the
base package name of
org.sola
.







F
AO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
35

of
70


6.2

Presentation Layer

The Presentation Layer encapsulates the components that end users will interact with
,
including

the
SOLA
Desktop

an
d the SOLA
Map Viewer (SOLA GIS)
.


Figure
13

-

Presentation Layer

P
ackage names
in the Presentation Layer
stem from
org.sola.clients
.

6.3

SOLA

Desktop



The SOLA Desktop is a Java Swing desktop application delivered to end users via
Java
Web Start technology to ensure minimal deployment and configuration overhead. The
Development Snapshot version of the SOLA Desktop supports basic front office case
management tasks including application lodgement, digital document preview and
attachme
nt, application search, application assignment and a custom spatial map viewer
(SOLA GIS). The SOLA Desktop provides translations for both the English and Italian
languages and can be configured to support additional languages.


The SOLA Desktop will conti
nue to be extended to support the Generic Land Administration
Process
9
. Given each land administration agency will have different workflow requirements
specific to their jurisdiction, it is expected that the SOLA Desktop will be the primary SOLA
component
requiring customisation to satisfy the needs of the agencies. This may extend to



9

See section 4.1 in the SOLA Statement of Requirements


F
AO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
36

of
70


replacement of the SOLA Desktop with a custom client application. Where heavy
customisation or replacement is required, the SOLA Desktop will act as a reference
implementation

providing working examples of the design and implementation patterns best
suited for use with SOLA.


Figure
14

-

SOLA
Desktop

Package names in the SOLA
Desktop

stem from
org.sola.
clients.
desktop
.

6.3.1

Desktop

The Desktop package
includes the main executable class for the SOLA Desktop (Desktop
Application), the Main Form, Web Service Manager (WS Manager)

and related application
classes.

6.3.2

Beans

The SOLA Desktop implements the Separated Presentation
10

UI
p
attern and the classes of
the Beans package
form

the
do
main
l
ayer of
this

pattern
.
Better Beans Binding
11
, which is a
fork of the Beans Binding JSR 295 reference implementation,

is used to notify the
presentation of changes in
the domain layer
.


Note that J
SR 295
was

withdrawn in May 2011
12
,

however the latest versions of the
NetBeans IDE continue to provide
integrated
support for beans binding
13
.




10

http://martinfowler.com/eaaDev/SeparatedPresentation.html

11

http://kenai.com/projects/betterbeansbinding/pages/Home


12

http://jcp.org/en
/jsr/detail?id=295


F
AO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
37

of
70


6.3.3

Forms

The Forms package contains the GUI Form classes of the SOLA Desktop. These classes
are responsible for prese
ntation of SOLA data only, consistent with the Separated
Presentatio
n

UI pattern.

6.3.4

Reports

The Report Manager provides methods to generate and display SOLA reports using the
Jasper Report Viewer. The Jasper templates for the SOLA reports are located in the reports
folder of the Resources package.

6.3.5

Converters

This package provides utilities to tr
anslate data between the Transfer Objects exposed by
the SOLA Web Services with
the beans in the Beans package.

6.3.6

Localization

This package i
ncludes a standardised locale selection control and stores any locale
selection made by the user in the Java Preferen
ces store.

When loading a form for display,
the locale setting is used to determine the correct Java
Resource Bundle
14

to use as the

source for the labels defined i
n the form.

6.3.7

Configuration

The Configuration M
anager determines
the
URLs
to use
to connect

th
e SOLA Web
Services.

The URLs are sourced from system properties in the case of SOLA Desktop Web
Start or
from a configuration file obtained from the
SOLA Desktop JAR (for development)
.

6.3.8

Resources

The Resources package contains
non
-
code resources used by t
he SOLA Desktop such as
images,

property files,

resource bundles

(for localization)
,
and report templates.


6.3.9

Tasks

This package c
ontains classes for
running and monitoring

the progress of background

tasks
.
Background tasks can be used to execute
long running
actio
ns and ensure the UI

remains
responsive to
further

user input.
Currently
background tasks are used to load the
Unassigned and Assigned lists on the Dashboard. The user can choose to navigate to
another screen using the menu options before

these
loading tasks are complete.

6.3.10

Cache

Cache p
rovides
simple
caching facilities for system reference data and code lists.

6.3.11

Renderers and Utilities

These packages contain
classes to assist the rendering of data values in other controls such
as
table cell
s and combo boxes.

They also include

general utility classes available for use
across SOLA Desktop packages.








13

http://netbeans.org/kb/docs/java/gui
-
binding.html

14

http://java.sun.com/developer/techn
icalArticles/Intl/ResourceBundles/


F
AO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
38

of
70


6.4

SOLA

GIS and GeoT
ools UI

The SOLA GIS and GeoT
ools UI packages implement the spatial components used for the
SOLA Desktop
. Following review of existing open source Java based GIS tools
and
component
s
,

GeoT
ools
15

was selected
as

the

basis
for

the
SOLA GIS components.
GeoT
ools is an open source GIS toolkit that consists of a number of libraries covering a
broad range of GIS fun
ctionality.
It provides implementation
s

of Open Geospatial
Consortium
16

(OGC) specifications as they are developed and is
used as the basis for
other
g
eospatial

projects including

GeoServer
17

and uDig
18
.

The original
GeoTools
project was
started in 1996 and
it remains an active project

wit
h the most recent release being
July

2011

(version 8.0 M1)
.


The main GeoTools libraries used by SOLA are




g
t
-
swing



This library contains the basic Swing GUI components including a basic map
control, status bar as well as
action and tool classes to interact with the map control and
map layers.



gt
-
epsg
-
hsql


This library contains routines and classes to define coordinate systems.



gt
-
wms


This library contains calls and routines to load WMS layers.


The SOLA GeoTools UI
package has been implemented to
extend

the basic GUI
components offered by the gt
-
swing library in a generic manner. The SOLA GIS package
builds on the
components in the
GeoTools UI package to satisfy SOLA specific
implementation requirements

and
has no di
rect dependency

on
GeoTools
.


Figure
15

-

SOLA GIS and GeoTools UI




15

http://geotools.org/

16

http://www.opengeospatial.org/

17

http://geoserver.
org/display/GEOS/What+is+GeoServer

18

http://udig.refractions.net/developers/


F
AO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
39

of
70



T
he
initial architecture for SOLA
included
GeoServer
for serving

geospatial data to the SOLA
map v
iewer

which ensured compatibility with geospatial standards such as Web Map
Service (WMS) and Web Feature Service (WFS)
.
Using
GeoTools
ensures SOLA will remain
capable of supporting geospatial standards
and allows

GeoServer to be an optional
component
of

the S
OLA architecture
.


Package names for GeoTools UI stem from
org.sola.
clients.geotools.
Package
names for SOLA GIS stem from
org.sola.
clients.desktop.gis.

6.4.1

UI

The UI packages
include the Map class which extends the GeoTools JMapPane
19

class, the
main
Swing
GUI

component of GeoTools, and the Utility, Messaging and Control Bundle
classes.


The Control Bundles are GUI components that encapsulate
the m
ap control, map tools and
map actions used for a specific instance of the map viewer. They also allow configuration of
the data source
to use
and layers
to display i
n the
map viewer.
The

SOLA Controls Bundle
includes Zoom and P
an tools as well as the Infor
mation Tool

and is the default map v
iewer
for SOLA
. The
Locate

Application Controls Bundle further extends the SOLA Controls
Bundle to include the Locate Application
tool which allows users to identify the
approximate
location of a new Application during t
he lodgement process.

6.4.2

Map Tools

Map Tools require the user to interact directly with the map
control

using their mouse. This
could include clicking on a point, selecting an area on the map
control

using a selection
rectangle or
using

a sequence

of mouse clicks

to draw or edit a feature
.
The Map Tools
currently available in SOLA include

Pan, Zoom In
, Informat
ion and Locate Application.


6.4.3

Map Actions

Map actions are triggered by the user selecting a button, toolbar
item
or menu option and
typically result in changes to the map
control
, but they do not require the user to interac
t
directly with the map viewer. The Map Actions currently available in SOLA include Zoom
Out, Zoom to Full Extent and Locate Application Remove.

6.4.4

Layers

A layer represents a distinct collection of geospatial features for display. Examples include
parcels, roads, road centre
-
lines, survey marks, place names, etc.
The map viewer will
typically display a number of layers concurrently to provide the us
er with the
necessary
location
context and e
ach layer can have its own symbolization and styling to differentiate it
from the geospatial features in other layers. SOLA uses
Styled Layer Descriptors
20

(SLD)

to
describe the s
ymbolization
and styling of layer
features.


The data used for layers can be obtained from different
sources
.

SOLA is able to display
data from W
MS, Shape file and
custom POJO objects
. The SOLA Development Snapshot
uses POJO Layers with data sourced from the SOLA
database via the
Spatial W
eb S
ervice
.

6.4.5

Data

The POJO Data Access feature of
SOLA uses the
Well Known Binary
21

(WKB)

format to
transfer data to
and from the map v
iewer

via the Spati
al Web Service. WKB is the geospatial



19

http://docs.geotools.org/latest/userguide/unsupported/swing/jmappane.html

20

http://www.opengeospatial.org/standards/sld

21

http://en.wikip
edia.org/wiki/Well_known_binary


F
AO FLOSS SOLA

Software Architecture Document



SOLA Development Snapshot


August 15, 2011

v1.1

Page
40

of
70


data storage format used
by
PostGIS

so u
sing WKB removes
translation
between

different
geospatial formats

wh
en sourcing data from the SOLA D
atabase.

6.4.6

GIS

The GIS package provides a Starter class to initialize the SOLA GIS components with the
Spatial Web Service. It also implements a Messaging class that override
s the default
Messaging class in the GeoTools UI package to integrate with the SOLA Message Utility for