Notional Architecture Executive Summary
Version
Date
1.1
16 February 2005
Author:
R.M.Horton
Table of Contents
1
Introduction.................................................................................................................... 3
1.1
Notional Architecture Document Lifecycle........................................................... 4
1.2
How to Use This Document................................................................................. 4
2
The SIDP......................................................................................................................... 4
2.1
Purpose of the SIDP............................................................................................ 4
2.2
SIDP Scenarios ................................................................................................... 5
2.3
SIDP Technical Architecture ............................................................................... 5
3
Notional Architecture Background .............................................................................. 6
3.1
What is the Notional Architecture? ...................................................................... 6
3.2
Why Have a Notional Architecture? .................................................................... 6
3.3
Relationship with Australian Government Spatial Infrastructure Initiatives ......... 8
4
Underlying Standards to the Notional Architecture ................................................... 9
4.1
Australian Spatial Data Infrastructure.................................................................. 9
4.2
OGC Reference Model...................................................................................... 10
4.3
ISO Reference Model for Open Distributed Processing.................................... 11
5
Notional Architecture Premises ................................................................................. 12
6
Notional Architecture Service Component Overview .............................................. 13
7
Notional Architecture Portal Platform ....................................................................... 14
8
Conclusion ................................................................................................................... 16
9
References ................................................................................................................... 17
9.1
Acronyms .......................................................................................................... 17
9.2
Glossary ............................................................................................................ 18
9.3
Bibliography....................................................................................................... 20
Page 2 of 20
SIDP Notional Architecture Executive Summary
1 Introduction
This Executive Summary provides a high level overview of the SIDP Notional Architecture. It
is an introduction to the key concepts in the Notional Architecture document, as well as a
reference to other related documents or information sources.
This summary
• discusses the conceptual background of and requirements for a Notional Architecture
• describes the relationships between the SIDP Notional Architecture and other
Australian public spatial infrastructure systems
• describes the key underlying standards of the Notional Architecture
• describes the basic premises of the Architecture
• provides an overview of the service components of the Architecture
• provides a brief description of an idealised geo-enabled enterprise information portal
The SIDP commissioned the Open Geospatial consortium – Australasia (OGC-A) to develop
a Notional Architecture building on earlier work by OGC-A for the Western Australia
Department of Land Information (DLI) and the Queensland Spatial Information Infrastructure
Council (QSIIC). The Notional Architecture is to provide a roadmap for the SIDP,
government agencies, corporations and other bodies implementing interoperable systems
using technology supporting open geospatial standards. The Notional Architecture is an
idealised description of the services and standards, following the ISO Reference Model for
Open Distributed Processing and OGC Open Reference Model, required to produce an
interoperable spatial infrastructure. The Notional Architecture articulates the broad range of
specifications required for a geo-enabled portal which meets the requirements for the
Australian Spatial Data Infrastructure.
The SIDP Notional Architecture comprises five volumes
SIDP Notional Architecture Volume 1 – Summary
SIDP Notional Architecture Volume 2 – Technical Considerations: Viewpoints, part 1
SIDP Notional Architecture Volume 3 – Technical Considerations: Viewpoints, part 2
SIDP Notional Architecture Volume 4 – Appendices
SIDP Notional Architecture Volume 5 – Model to assist in the preparation of scenarios
Executive Summary
Notional Architecture
Notional Architecture
Volume 1
Summary
Notional Architecture
Volume 2
Notional Architecture
Enterprise and
Information
Viewpoints
Volume 3
Notional Architecture
Computational
Viewpoint
Appendices
Volume 4
Notional Architecture
Volume 5
Scenario Model
SIDP Notional Architecture Documents
Page 3 of 20
SIDP Notional Architecture Executive Summary
1.1
Notional Architecture Document Lifecycle
The Notional Architecture is a dynamic model. The standards and specifications referred to
are evolving. Many projects are being undertaken around the world which test the varied
aspects of interoperability. There is also an increasing interest in alignment between
business processes, workflows and information, product manufacturing and delivery,
especially within the context of the e-Government Interoperability Frameworks. The SIDP will
monitor developments in the public arena.
OGC-A will review the Notional Architecture at six monthly intervals to ensure that the
Architecture is kept current with the information generated by the SIDP and by other relevant
projects worldwide. Special reviews of the Architecture may be initiated if the Technical
Committee of the Open Geospatial Consortium updates any of the underlying standards on
which the Architecture is based.
All documentation updates will be posted on the SIDP web site (www.sidp.com.au).
1.2
How to Use This Document
A Volume Guide is provided at the start of each section of this Summary (see example
below). The highlighted part of the Guide indicates the volume of the Notional Architecture
document containing more detail on the topics discussed in the section.
Volume 1
Notional Architecture Volume Guide
Volume 2
Volume 3
Volume 4
Volume 5
Section 9 of this document contains a list of acronyms and a glossary of technical terms
used in this summary.
2 The SIDP
2.1
Purpose of the SIDP
The Spatial Interoperability Demonstration Project (SIDP) is a collaborative initiative between
the Australian Spatial Information Business Association (ASIBA) and the Open Geospatial
Consortium – Australasia (OGC-A). The project is funded under the AusIndustry Innovation
Access Program with additional in-kind support provided by private sector companies and
government agencies.
The SIDP’s purpose is to demonstrate the benefits of linking business processes and
sharing spatial and other information resources across organisational lines. The linking is
independent of where the data, information and processing tools, accessible over the
internet, are physically located and what type of computer system is used.
For a full overview of the SIDP and its deliverables consult the Project Overview on the SIDP
website.
Page 4 of 20
SIDP Notional Architecture Executive Summary
2.2
SIDP Scenarios
Volume 1
Notional Architecture Volume Guide
Volume 2
Volume 3
Volume 4
Volume 5
In order to produce some “real world” systems for demonstration, the SIDP defines and
implements three scenarios in the areas of Emergency Management and Insurance. The
demonstration scenarios are being defined and refined by a series of workshops held in July
and August 2004.
These scenarios
• identify opportunities for shared, distributed Web Services for accessing data,
geoprocessing and business services over the internet
• align with components of the Notional Architecture
• provide a gap analysis between existing and required capabilities
• consider the custodial arrangements by which Web Services could evolve from
design concept through prototype demonstrator to operational stability
The Notional Architecture presents a scenario based on the Regional Reports created by the
Queensland Treasury as a means of briefing the Department of Premier and Cabinet, as a
sample. The regional reporting process also provides, for example, an economic report on a
geographic region, or information about a region affected by an emergency incident.
The SIDP scenarios reflect further real world business requirements. The SIDP Project
Management Team models the outcomes of the workshops, workflows for the SIDP
scenarios and identifies specific Web Services for implementation. Modelling the scenarios
provides additional examples of how the Notional Architecture and the modelling process
can generate systems to realise actual business outcomes.
Series 1 workshops were conducted around Australia during July and August 2004. The
Executive Workshop Briefing, the Operational Workshop Presentations and the Outcomes
Report are available on the SIDP website.
Series 2 workshops are scheduled for April and May 2005. The SIDP Website has more
details.
2.3
SIDP Technical Architecture
The SIDP Technical Architecture is derived from the SIDP Notional Architecture. The ISO
Reference Model for Open Distributed Processing (ISO RM-ODP) and OGC Open Reference
Model define five Viewpoints. The Notional Architecture addresses the Enterprise,
Information and Computational Viewpoints.
The Technical Architecture, commissioned from CSIRO (ARRC) details the Engineering
Viewpoint for those services to be implemented in the SIDP. When the project is completed
the final Viewpoint, the Technology Viewpoint, will be documented in the form of the
“Implementation Architecture”. An explanation of the different viewpoints of the ISO RMODP is provided in section 4.3.
Page 5 of 20
SIDP Notional Architecture Executive Summary
Notional Architecture
Enterprise, Information, and Computational Viewpoints of Complete Spatial
Infrastructure System
Technical
Architecture
Engineering Viewpoint of
SIDP specific services
Relationship between the Notional Architecture and the Technical Architecture
The SIDP Technical Architecture contains detailed components, services and interfaces that
are specific to the SIDP scenarios. The Technical Architecture also identifies components to
be integrated as part of the SIDP, which may form the foundation of the Australian Spatial
Data Infrastructure (ASDI) once the SIDP is completed. References to the SIDP Technical
Architecture are found in section 6.
3 Notional Architecture Background
3.1
What is the Notional Architecture?
Volume 1
Notional Architecture Volume Guide
Volume 2
Volume 3
Volume 4
Volume 5
The SIDP Notional Architecture is an idealised description of the services and interfaces
required to construct interoperable spatial infrastructure systems. The architecture is
notional in that it makes no assumptions about physical implementation and the only
assumption made about vendors and institutions is that they accept and support open,
non-proprietary standards.
The Notional Architecture is concerned with spatially located data, discovery services,
geospatial processing services and related business process services such as
authentication, authorisation, auditing, digital rights management and pricing. It is based on
Australian and international spatial data and data processing standards as discussed in
section 4.
3.2
Why Have a Notional Architecture?
Volume 1
Notional Architecture Volume Guide
Volume 4
Volume 2
Volume 3
Volume 5
Ad hoc interoperability between different spatial systems is difficult and expensive, requiring
each system to construct individual interfaces to each other system. Even when the same
supporting standards are used, different interpretations of the syntax and the models can
restrict interoperability.
Page 6 of 20
SIDP Notional Architecture Executive Summary
Many of the standards do not address the issue of the semantics, or contextual meaning, of
the data. Consider a user querying a road network information system. If their query refers
to a route into Melbourne, are they referring to a road designation (eg Route 1) or a path
from where they are now to Melbourne? One road may carry several designators (eg
Princes Highway, Route 1 etc) and for systems to interoperate successfully they need to
have a common understanding of the context in which these designators apply.
OGC
Reference
Model
ISO
Development
Model
WWW Consortium
Standards
Supporting
Standards
OASIS e-business
Standards
ISO Geospatial
Standards
ANZLIC Metadata
Standards
Each architecture
interprets supporting
standards models and
syntax in their own way
Geoscience
Australia
ASDD
Architecture
SIDP
Implementation
Architecture
QLD
Government
Information
Architecture
WA SLIP
Architecture
NSW CANRI
Architecture
Implementation
Architectures
Interoperability
All systems require separate interfaces for all other systems owing to lack of
common semantics and component definition
Multiple implementations of standards without common semantics or component definition
The Notional Architecture describes a framework in which those semantics can be managed
and also defines common components that provide a unifying, and simplifying approach to
sustainable and cost-effective interoperability. With the Notional Architecture as the
reference, systems will require only a single interface that conforms to the specifications in
order to gain interoperability with all other systems that meet the same specifications.
A widespread adoption of the Notional Architecture will help ensure interoperability between
systems at all levels of government (federal, state, and local), academia, industry, and other
agencies. It will also help stimulate the market for spatial information services by providing a
unified means of accessing data and processing services with a reduction in development
costs for specialist service providers and end-users.
Page 7 of 20
SIDP Notional Architecture Executive Summary
OGC
Reference
Model
ISO
Development
Model
WWW Consortium
Standards
Supporting
Standards
OASIS e-business
Standards
ISO Geospatial
Standards
ANZLIC Metadata
Standards
SIDP Notional Architecture provides common semantics and components
Geoscience
Australia
ASDD
Architecture
SIDP
Implementation
Architecture
QLD
Government
Information
Architecture
WA SLIP
Architecture
NSW CANRI
Architecture
Single interface gives access to all other systems
Implementation
Architectures
Interoperability
Notional Architecture provides common component definitions and semantic framework
When complete, the SIDP demonstrators, based on the Notional Architecture, will also
provide the Australian community with demonstration capabilities consistent with those of the
more than fifty nations that are developing interoperable national spatial data infrastructures.
These national activities are supported by regional collaborative efforts in Asia and the
Pacific, Europe, the Americas and Africa as well as an emerging Global Spatial Data
Infrastructure effort.
3.3 Relationship with Australian Government Spatial
Infrastructure Initiatives
Volume 1
Notional Architecture Volume Guide
Volume 2
Volume 3
Volume 4
Volume 5
The custodian for the Australian Spatial Data Infrastructure is the Australia and New Zealand
land Information Council (ANZLIC)
The SIDP Notional Architecture contains a superset of the components and interface
definitions from current Australian spatial infrastructure initiatives. These initiatives include
the Australian Spatial Data Directory, the Western Australia Shared Land Information
Platform, the Queensland Government Information Architecture and the New South Wales
Community Access to Natural Resources Information.
The SIDP Notional Architecture has been offered to, and accepted by, the Spatial Data
Infrastructure Committee of ANZLIC (December 2004).
Page 8 of 20
SIDP Notional Architecture Executive Summary
4 Underlying Standards to the Notional Architecture
Volume 1
Notional Architecture Volume Guide
Volume 2
Volume 3
Volume 4
Volume 5
The SIDP Notional Architecture is based on a large suite of national and international
standards. A complete list of supporting references for these standards can be found in the
bibliographies in Volumes 2 and 3.
Key standards for the Notional Architecture are
• Australian Spatial Data Infrastructure (ASDI)
• Open Geospatial Consortium Reference Model (OGC-RM)
• International Standards Organisation Reference Model for Open Distributed
Processing (ISO RM-ODP)
An overview of each of these standards is provided in sub-sections 4.1, 4.2 and 4.3.
A brief description of the World Wide Web Consortium Web Services is given in the sidebar
in section 5.
Specific implementation and technology standards such as Microsoft .NET or J2EE are
outside the scope of the SIDP Notional Architecture.
4.1
Australian Spatial Data Infrastructure
Volume 1
Notional Architecture Volume Guide
Volume 2
Volume 3
Volume 4
Volume 5
The Australian Spatial Data Infrastructure is an initiative of ANZLIC. It is a national
framework for linking users with providers of spatial information. The ASDI comprises the
people, policies and technologies necessary to enable the use of spatially referenced data
through all levels of government, the private sector, non-profit organisations and academia.
Key components of the ASDI are the
• Australian Spatial Data Directory
• Standards
• Spatial metadata
Read more about the Australian Spatial Data Infrastructure on the Geoscience Australia
website.
Page 9 of 20
SIDP Notional Architecture Executive Summary
4.2
OGC Reference Model
Volume 1
Notional Architecture Volume Guide
Volume 2
Volume 3
Volume 4
The OGC Reference Model provides a
framework in which to deliver spatial interface
and encoding specifications. The OGC-RM
provides a foundation for the OGC Technical
Baseline (the currently approved OpenGIS
Specifications as well as a number of candidate
specifications that are in progress), describes the
OGC requirements baseline for geospatial
interoperability, describes the OGC architecture
framework through a series of non-overlapping
viewpoints and regularises the development of
domain-specific interoperability architectures.
Volume 5
What is the OGC?
OGC is an international not-for-profit trade
association dedicated to promoting new
technical and commercial approaches to
interoperable geoprocessing. The OGC was
founded in response to widespread recognition
of the problem of non-interoperability in the
geospatial industry with its many negative
ramifications for industry, government and
academia. With greater than 80% of business
and government information having some
reference to location, the vision of OGC
includes a national and global infrastructure in
which geospatial or location referenced data
and geoprocessing resources are accessible to
everyone. The OGC vision also includes geoenabling a wide variety of activities currently
outside the domain of geoprocessing, opening
new markets and giving rise to new kinds of
businesses and new benefits to the public.
The benefits of interoperability can be seen in the
Geospatial Information Value Chain diagram,
which illustrates an information value chain for
geospatial information within an enterprise or
information community. The value chain starts
with geospatial information sources entering an
The core mission of OGC is to deliver spatial
interoperable environment. These then pass
interface and encoding specifications that are
through geoprocessing chains, creating
openly available for global use. The OGC
Reference model focuses on the technology
intermediate value-added geospatial-based
aspects of the OGC mission.
products along the way. The diagram shows
several examples of such value-added products
including fusion (combining, correlating, annotating, and interrelating geospatial information
from many sources into a single structure) and analysis (operating on geospatial information
for the purpose of deriving new information, extracting results or understanding its nature
and significance).
Geospatial Information Value Chain.
Page 10 of 20
From the OGC Reference Model
SIDP Notional Architecture Executive Summary
The last step in the value chain involves creating for both internal customers and external
customers finished products that either contain geospatial information, or are derived from
geospatial information. Typical products provide functions such as visualisation and
portrayal, reporting, analysis or information transfer and dissemination.
The Notional Architecture provides a unified approach for projects implementing the OGCRM as part of the ASDI. It provides specific interpretations of the information semantics and
computational components required to build spatial infrastructure. These include the
geographic general feature model, standard conceptual schemas for spatial-temporal
geometry and topology, the Publish-Find-Bind pattern for service discovery and the OGC
Web Services Framework.
4.3
ISO Reference Model for Open Distributed Processing
Volume 1
Notional Architecture Volume Guide
Volume 2
Volume 3
Volume 4
The ISO RM-ODP defines a structural
framework for system specifications. The
main structuring approach used in ISO
RM-ODP architecture is the definition of
viewpoints (see sidebar “What are the ISO
RM-ODP Viewpoints?”)
The Notional Architecture details only the
enterprise, information and computational
viewpoints of a hypothetical, fully featured,
spatial infrastructure system.
The engineering and technology
viewpoints are not considered in the
Notional Architecture because each
requires the detailing of specific hardware,
software and communications
technologies and the identification of their
roles in implementation. The SIDP
Technical Architecture embodies the
engineering viewpoint which establishes
the model that will be the basis for the
implementation of specific SIDP services.
When the services are available the
Technology Viewpoint will be documented
in the form of the Implementation
Architecture.
Page 11 of 20
Volume 5
What are the ISO RM-ODP Viewpoints?
A viewpoint is a subdivision of the specification of a
complete system, established to bring together those
particular pieces of information relevant to some particular
area of concern during the design of the system.
Viewpoints are not completely independent as key items in
each are identified as related to items in the other
viewpoints. However, the viewpoints are sufficiently
independent to simplify reasoning about the complete
specification. Each viewpoint in the set can be related to
all the others. They do not form a fixed sequence like a set
of protocol layers, nor are they created in a fixed order
according to some design methodology. An architecture is
expressed in terms of the complete set of related
viewpoints, without laying down how a complete
specification is to be constructed for any given system.
The ISO RM-ODP defines five viewpoints of the system
and its environment. These are
•
the enterprise viewpoint focuses on the purpose,
scope and policies for the system
•
the information viewpoint focuses on the semantics of
the information and information processing performed
•
the computational viewpoint enables distribution
through functional decomposition of the system into
objects which interact at interfaces
•
the engineering viewpoint focuses on the
mechanisms and functions required to support
distributed interaction between objects in the system.
•
the technology viewpoint focuses on the choice of
technology in the system
SIDP Notional Architecture Executive Summary
5 Notional Architecture Premises
Volume 1
Notional Architecture Volume Guide
Volume 2
Volume 4
Volume 3
Volume 5
The Notional Architecture is based on the following premises:
• a number of resources exist as Web Services (see sidebar)
• resources include:
o Data sets
o Services that access, manipulate, or portray data sets
o Processes that ‘chain’ services
• all resources are accessible only as services accessed by web agents such as
browsers or applications
• users can only use web agents to access these resources to create information
products
• providers of resources may need to account for, and possibly charge for, their use
• resources are offered in a distributed manner by a variety of custodians
The Web Services that provide the
various resources are defined using an
ISO/OSI three tier model. This model
requires that the presentation
capabilities, the processing capabilities
that embody business rules and the data
access capabilities are all defined and
implemented as separate services. The
groups of services defined in the Notional
Architecture are covered in section 6.
Web agents or clients can be browsers
(“thin” clients), applications (“thick”
clients) or plug-ins (“chubby” clients).
Clients are discussed in section 7.
Users may be people using a “thick”,
“thin”, or “chubby” client to access
resources or they may be automated
processes.
What are Web Services?
The term Web Services describes a standardised way of
integrating Web-based applications using open
standards over an Internet protocol backbone. Popular
examples of standards used by Web Services are as
follows: XML is used to encode the data, SOAP or GML
is used to transfer the data, UDDI is used for listing what
services are available and WSDL and CS/W can be used
for describing the available services. Used primarily as a
means for businesses to communicate with each other
and with clients, Web Services allow organisations to
communicate data without intimate knowledge of each
other's IT systems behind the firewall.
Unlike traditional client/server models, such as a Web
server/Web page system, Web Services do not provide
the user with a graphical user interface (GUI). Web
Services instead share business logic, data and
processes through a programmatic interface across a
network. The applications interface with each other, not
with users. Developers can add the Web service to a
GUI (such as a Web page or an executable program) to
offer specific functionality to users.
Providers of resources are government agencies, corporations or other organisations that
provides spatial services complying with the ASDI standards. In the context of the SIDP,
providers of resources will be ASIBA and OGC members and participating Australian
government agencies.
Custodians are responsible for managing the products that users receive, the services that
generate them and the data that are employed. The ASDI is underpinned by integrated
spatially related information services that are federated. The term “federated” is used
throughout this project in the sense used by the Queensland Government Information
Architecture (1999) i.e. “agencies are independent and have their own accountability. They
operate according to the principle of “mutual best interest” by collaborating to provide
efficient, accountable, auditable delivery of authoritative information products, services and
data to Executive Government, within government, to businesses and to the public.”
Page 12 of 20
SIDP Notional Architecture Executive Summary
6 Notional Architecture Service Component Overview
Volume 1
Notional Architecture Volume Guide
Volume 3
Volume 2
Volume 4
Volume 5
Seven broad groups of capabilities required for spatial infrastructure platforms are identified
in the Notional Architecture. Each of these capabilities has a group of Web Services defined
to meet those capabilities. The seven SIDP capability groups are
•
•
•
•
•
•
•
provide applications to users
interrogate registries and catalogues
generate data portrayals
access data
carry out geographic processing
authenticate, authorise and account for users
store and manage spatial data, statistical tables, accounting records, catalogue and
registry entries, etc. in various repositories
Within each group, capabilities are implemented as specific content and service
components. Each component operates as a web service communicating on a transactional
basis with other components, user agents and remote applications via the internet.
Component services are provided and accessed through the internet from many different
physical locations. The internet provides the backbone by which these services
communicate both between themselves and with people using browsers and other tools.
Standard internet messaging protocols and mark up languages define the rules by which
messages are created and interpreted. A wide variety of information products can be
generated using “just in time” processing, dynamically assembling and combining
components from one or many service providers.
The functions of each group of services are
•
Application Services provide server-side client generators for accessing
business and data access services. These link to browsers or other applications
to provide the services to the users.
•
Authentication, Authorisation and Accounting Services manage and account
for spatial data infrastructure and processing resources.
•
Data Repository Services provide permanent storage of geographic objects,
temporal events, associated geolinkable non-spatial data, user audit and
management records, registry and catalogue metadata, and articulated service
and data use policies. There are three types of data repositories and their
associated services – datastores (dynamic content), libraries (reference
information) and registers (metadata).
•
Data Access Services are used by web agents (including automated processes)
and other Web Services to acquire copies of data in either original or processed
form. This encompasses simple existing facilities for downloading copies of entire
data elements such as GML files, shapefiles, raster images or database records,
as well as more sophisticated services delivering data through Geodata
Processing Services. Additionally, transactions (creation, replace, update, delete)
to existing data stores can be accommodated through the use of transactional
interfaces, such as the OGC Web Feature Service. This capability is very useful,
for example, when users collect new information in the field via a mobile device
and wish to send the new transactions to the server.
Page 13 of 20
SIDP Notional Architecture Executive Summary
•
Geodata Processing Services are the tools that operate on geospatial data and
provide services that add value to the final information product. Geodata
Processing Services conduct transformations of data originating from Data
Repositories or other Geodata Processing Services and may deliver their outputs
to Portrayal Services, Data Services or other processing services.
•
Portrayal Services prepare visualisations and representations of data originating
from Data Repositories and Geodata Processing Services. Web agents receive
images representing the data, not the actual data values. These images may be
maps, statistical charts, choropleth depictions, VRML animations or narrative
packages such as summaries delivered in PDF format. A common existing
Portrayal Service required for the SIDP platform is the Web Mapping Service.
•
Registry and Catalogue Services provide a common mechanism to search and
access information about resources available on a network. Registries support
“search and discovery” by providing reference pointers to largely static
descriptions services, their interfaces and their components. Catalogues support
“search and discovery” by providing reference pointers to more volatile
descriptions of geodata set contents. Resources are network addressable
instances of typed data or services. These services also provide tools enabling
authorised Web Agents to classify, register, describe and maintain resource
metadata according to their assigned authority type. “Search and discovery” is
implemented using the Publish-Find-Bind model (see Volume 4).
A detailed view of the service components is described in Volume 3. While not definitive ,
these components are indicative of the types of components required by the SIDP platform.
Further detail on the specific components that will be part of the SIDP demonstration
scenarios are in the SIDP Technical Architecture.
7 Notional Architecture Portal Platform
Volume 1
Notional Architecture Volume Guide
Volume 2
Volume 3
Volume 4
Volume 5
The Notional Architecture Portal Platform presents a high level service component view of
the SIDP Notional Architecture. The salient points for SIDP are that:
•
“thin” clients are web browsers for people accessing services through the World Wide
Web
•
“thick” clients are remote applications acting as their own web agents and able to
invoke services according to agreed message standards and protocols. “Thick”
clients can be remote GIS desktop applications used directly by people or they can
be autonomous tasks such as statistical analysis and modelling engines
•
enterprise Partners configure the Web Services to conduct business processes such
as analysis, data manipulation, presentation of products according to designated
symbologies and layouts, and may also to provide interactive help to users
•
catalogue services support the publication of service and data characteristics
(metadata) and provide a means for their discovery by appropriate agents.
Catalogues also provide information about the language structures and interface
capabilities supported by each service. All services to be accessed in the SIDP
require catalogue references
Page 14 of 20
SIDP Notional Architecture Executive Summary
•
gazetteer services support searches and other applications (such as portrayal)
requiring the names of locations and features
•
web feature services (WFS) abstract data as topographic features encoded in
geographic mark-up language (GML) that are amenable to further analytical or
representational processing, such as may be done with “thick” clients. WFS deliver
vector data content and attributes but can also handle content such as point data
from gazetteer services
•
web coverage services (WCS) similarly abstract coverage data (including raster data)
to “thick” clients or for portrayal through WMS
•
web mapping services (WMS) provide pictorial portrayals of data as maps which are
readily visualised and manipulated in “thin” clients but are not suitable for further
processing. WMS may stream and portray content from WFS
SIDP Portal Platform
When completed, the SIDP Portal will expose data stores to the SDI via OpenGIS compliant
service interfaces. The services used to access the data stores are, in many cases, existing
legacy systems adapted with appropriate wrappers or middleware to translate from their
internal proprietary formats and interfaces to the external open standard mechanisms
required for interoperability within and between SDIs. The SIDP Portal will enable Australian
geospatial community data services with appropriate interoperability interfaces, to exchange
services and data with other SDI participants at State, Commonwealth and international
levels. International connectivity options include image repositories maintained by US NASA
and EROS Data Center3, the Asian- Pacific regional SDI, the United Nations SDI-based
interoperability framework, services operated by the World Bank and OECD, and numerous
non-governmental institutions such as the World Conservational Monitoring Centre and the
World Resources Institute.
Page 15 of 20
SIDP Notional Architecture Executive Summary
8 Conclusion
The SIDP Notional Architecture is a framework for building interoperable regional and
national systems and services to use spatial information in more effective and efficient ways.
The Architecture is
• focussed on user-driven product, process and service, not data
• vendor, content, technology, and institution neutral
• based on a distributed architecture
• designed to allow agencies and custodians to retain control over their data and
internal processes
• evolutionary, building on existing systems rather than replacing them
• incremental and component based.
The main benefits of adopting and using the Notional Architecture are that it provides
• a standard way of interpreting the underlying models and their syntax
• a guideline for building standard components of a spatial infrastructure architecture
• a guideline for implementation where there are no existing spatial systems
• an assurance that systems developed are interoperable between all levels,
irrespective of whether the scope of the system is local government, state
government, federal government, industry specific, academic etc.
Page 16 of 20
SIDP Notional Architecture Executive Summary
9 References
9.1
Acronyms
ANZLIC
ASDD
ASDI
ASIBA
CANRI
CSDGM
DLI
FGDC
GA
GIA
GIF
GML
ISO
ISO RM-ODP
J2EE
JPEG
OASIS
OGC
OGC-A
OGC-RM
OSI
PDF
PNG
SDI
SIDP
SLIP
SOAP
UDDI
VRML
W3C
WCS
WFS
WMS
WSDL
XML
Page 17 of 20
Australian New Zealand Land Information Council http://www.anzlic.org.au/
Australian Spatial Data Directory http://asdd.ga.gov.au/asdd/
Australian Spatial Data Infrastructure
Australian Spatial Information Business Association http://www.asiba.com.au/
Community Access to Natural Resource Information (NSW) http://www.canri.nsw.gov.au/
Content Standard for Digital Geospatial Metadata (USA FGDC)
Department of Land Information (Western Australia) http://www.dli.wa.gov.au/
Federal Geographic Data Committee (USA) http://www.fgdc.gov/
Geoscience Australia (Australian Government) http://www.ga.gov.au/
Government Information Architecture (Queensland) http://www.iie.qld.gov.au/comminfo/gia/
Graphic Interchange Format (Unisys)
Geography Mark-up Language (OGC) http://www.opengis.org/docs/02-023r4.pdf
International Organisation for Standardisation http://www.iso.org/
International Organisation for Standardisation Reference Model for Open Distributed Processing
Java 2 Enterprise Edition
Joint Photographic Expert Group format (including JPEG2000)
Organisation for the Advancement of Structured Information Standards
http://www.oasis-open.org/who/
Open Geospatial Consortium http://www.opengis.org/
Open Geospatial Consortium – AustralAsia
Open Geospatial Consortium Reference Model
Open Source Initiative http://opensource.mirrors.ilisys.com.au/
Adobe Portable Document Format
Portable Network Graphics (W3C) http://www.w3.org/Graphics/PNG/
Spatial Data Infrastructure
Spatial Interoperability Demonstration Project
Shared Land Information Platform (DLI and WALIS, WA)
Simple Object Access Protocol (W3C) http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
Universal Discovery Description and Integration (OASIS) http://www.uddi.org/
Virtual Reality Markup Language
World-Wide Web Consortium http://www.w3.org
Web Coverage Service (OGC) – see Glossary
Web Feature Service (OGC) – see Glossary
Web Mapping Service (OGC) – see Glossary
Web Services Description Language (W3C) http://www.w3.org/TR/wsdl
Extensible Mark-up Language (W3C) http://www.w3.org/XML/
SIDP Notional Architecture Executive Summary
9.2
Glossary
Application
Architecture
Binding
Catalogue
Client
Component
Conceptual
Architecture
Coverage
Custodian
Datastore
Gazetteer
Geodata
Geospatial
Data
Library
Map
Metadata
Standard
Notional
Architecture
Portal
Services
Process
Page 18 of 20
A program that performs a specific function directly for a user. Applications can make use of
SDI.
The organisational structure and operating environment of the SDI, including the relationships
between its parts, and the principles and guidelines governing their design and evolution over
time.
Specific syntax and parameter values used by a client to invoke a specific server operation
A registry that, in the SDI context, is usually used to describe spatial data sets.
A software component or an application that accesses a service. Clients may be categorised
in three ways
•
Thin clients where the client supports only human-interface code, such as a web
browser or a minimal PDA or WiFi handset, and must also support non-proprietary
standards. They typically lack long-term memory such as disk drives. Application
code and data access both run remotely and are entirely dependent on an external
network connection.
•
Thick clients where the client supports all the human interface and application code,
may support some or all data access code, and may support long-term data memory.
Human interface code may be entirely customised and not conform to non-proprietary
standards. May not even support human interfaces i.e. may be entirely automated
remote processes. May operate at times without network connection.
•
Chubby clients have capabilities somewhere on the spectrum between thick and thin
clients i.e. may support some application and data code, and may store limited
amounts of data. Will usually but not necessarily support human interfaces. May
operate well for limited time without network connection.
Software that packages the client or server implementation of a service and can provide the
realisation of a set of interfaces. A component consists of software code (source, binary or
executable) or other equivalents such as scripts or command files.
An overview of the services, data, technology and institutional environment of SDI. It
describes, in general terms, both what the SDI will include and how it will operate.
A continuous representation of a portion of the earth's surface. A coverage may be a collection
of features (like a vector dataset) or it may be a raster or gridded surface representing one or
more attributes.
The authoritative manager of an SDI resource, whether data set, service or component, who is
responsible for the declaration of the policies regarding use and accounting for the resource.
Any type of persistent storage for components and data. Content may be static or dynamic.
May include database systems, file systems, structured text storage, XML repositories etc.
A dictionary of geographical names. May encompass locations, cultural and landscape
features and may embody various naming conventions including official name, names in
common usage, traditional and community-based names. Attributes of gazetteer entries may
include geographic coordinates, extent and topology. May be implemented through Web
Feature Service for SDI applications such as user interfaces.
Georeferenced spatial data such as a road network or a satellite image. Geodata explicitly
describes the spatial extent of a set of features or describes a measurable surface. It includes
both geospatial data and geolinked data.
Geodata with explicit geographic positioning information included, such as a road network
from a GIS, or a georeferenced satellite image. Geospatial data may include attribute data that
describe the features in the dataset.
A type of registry intended for recording references to entity types (as distinct from recording
instances) i.e. a look-up. Content is generally static once instantiated.
A pictorial representation or portrayal of geographic data.
Data will be documented according to the FGDC Content Standard for Digital Geospatial
Metadata (CSDGM) and/or the ISO 19115.
A design framework based on vendor-neutral, open standards.
Provides "one-stop" access to Provider Services. An online access point to a collection of
geospatial data -- more precisely, to a collection of services that provide data or relevant
functionality. A portal does not store or maintain the data and its associated services; rather,
these are distributed in many computers nationwide and maintained by the agency or
organisation that is responsible for its data and services. Portals shall be based on open
standards and specifications that are defined collaboratively by various interested parties, are
freely published, and are able to be implemented by any vendor or organisation.
A system offering a single interface for the execution of a single task creating one or more
products. Processes may be grouped to provide a service.
SIDP Notional Architecture Executive Summary
Registry
Resource
Schema
Server
Service
SIDP
Site
System
Web Agent
Web Coverage
Service
Web Feature
Service
Web Map
Service
Web Service
Page 19 of 20
A listing of the specific, individual services, components, datasets or other entities that
comprise the SDI or are relevant to its users. Instance registries are used to identify, locate,
and describe individual instances. Many registries refer to associated Type Libraries that
record the allowed types within registry classes e.g. types of services, types of user
authorities.
Data, services and components that are published and underlie the creation of all useful
products. Resources are presented to the internet as Web Services.
A schema is an expression of the Type using a particular data modelling language. Types can
be described as classification taxonomy for a set of schema definitions. The OGC application
data modelling language is GML and each schema fragment corresponding to a given type is
defined in GML.
(a) A software component that delivers a service. (b) A physical implementation of such a
component that provides the realisation of its operations.
A collection of operations, accessible through one or more interfaces, that allows a user to
evoke behaviour of value to that user. A server delivers each service. A service may
encapsulate many processes. A "service instance" is another name for a server (b).
The AusIndustry Interoperability Demonstration Project.
A location (e.g. URL) at which a system is accessed.
Servers and data organised to accomplish one or more Services. A system may be accessible
at more than one site.
People or software that act on the web information space. Software agents include browsers,
servers, proxies, spiders and multimedia players mediating interactions on behalf of a person,
entity or process.
Supports electronic interchange of geospatial data as "coverages" – that is, digital geospatial
information representing space-varying phenomena. A WCS provides access to potentially
detailed and rich sets of geospatial information, in forms that are useful for client-side
rendering, multi-valued coverages and input into scientific models and other clients. The WCS
may be compared to the OGC Web Map Service (WMS) and the OGC Web Feature Service
(WFS); like them it allows clients to choose portions of a server's information holdings based
on spatial constraints and other criteria. Unlike WMS (OGC document 01-068r3), which filters
and portrays spatial data to return static maps (rendered as pictures by the server), the Web
Coverage Service provides available data together with their detailed descriptions; allows
complex queries against these data; and returns data with its original semantics (instead of
pictures) which can be interpreted, extrapolated, etc. -- and not just portrayed. Unlike WFS
(OGC Document 02-058), which returns discrete geospatial features, the Web Coverage
Service returns representations of space-varying phenomena that relate a spatio-temporal
domain to a (possibly multidimensional) range of properties.
Serves vector data (points, lines and polygons) to the web for use by applications on remote
websites. Provides interfaces for describing data manipulation operations on geographic
features using http as the distributed computing platform. A Web Feature Service request
consists of a description of query or data transformation operations that are to be applied to
one or more features. The request is generated on the client and is posted to a web feature
server via http. The web feature server then reads and (in a sense) executes the request. The
OGC Web Map Service (WMS) allows a client to overlay map images for display served from
multiple Web Map Services on the Internet. In a similar fashion, the OGC Web Feature
Service allows a client to retrieve geospatial data encoded in Geography Markup Language
(GML) from multiple Web Feature Services
Produces maps of georeferenced data. A "map" is a visual representation of geodata; a map is
not the data itself. These map views are rendered in a 2D pictorial format such as PNG, GIF or
JPEG. The WMS specification thus enables the creation of a network of distributed Map
Servers from which clients can build customised maps. A particular WMS provider in a
distributed WMS network need only be the steward of its own data collection. This stands in
contrast to vertically integrated web mapping sites that gather in one place all of the data to be
made accessible by their own private interface.
Application logic accessible across a network using standard Internet protocols. Web Services
combine the best aspects of component-based development and the Web. Like components,
Web Services represent functionality that can be easily reused without knowing how the
service is implemented. Unlike current component technologies that are accessed via
proprietary protocols, Web Services are accessed via ubiquitous Web protocols (e.g. http)
using universally accepted data formats (e.g. XML).
SIDP Notional Architecture Executive Summary
9.3
Bibliography
ANZLIC Metadata Guidelines (v2 – February 2001), see
http://www.anzlic.org.au/download.html?oid=2358011755
ISO 10746, Information technology -- Open Distributed Processing – Reference model, see
http://www.iso.ch/iso/en/ittf/PubliclyAvailableStandards/c020696e.zip for overview
OASIS ebXML see http://www.ebxml.org/
OASIS Universal Discovery Description and Integration, see http://www.uddi.org/
OpenGIS Geography Markup Language (GML) Implementation Specification, version 3.0, see
http://www.opengis.org/docs/02-023r4.pdf
OpenGIS Reference Model (ORM), see http://www.opengis.org/docs/03-040.pdf
OpenGIS Web Coverage Server (WCS) Implementation Specification, version 1.0, see
http://www.opengis.org/docs/03-065r6.pdf
OpenGIS Web Feature Server (WFS) Implementation Specification, version 1.0, see
http://www.opengis.org/docs/02-058.pdf
OpenGIS Web Mapping Server (WMS) Implementation Specification, version 1.1.1, see
http://www.opengis.org/docs/01-068r2.pdf
OpenGIS Web Registry Service (WRS) Discussion Paper, version 0.0.2, see
http://www.opengis.org/docs/01-024r1.pdf
OpenGIS Web Services Architecture (OWS) Discussion Paper, see http://www.opengis.org/docs/03025.pdf
Queensland Government Information Architecture, see
http://www.governmentict.qld.gov.au/02_infostand/gia.htm
SIDP Technical Architecture, see
http://www.sidp.com.au/index.cfm?Fuseaction=extrainfonew&Return=showtrolley&ProductID
=7&categoryID=1
World Wide Web Consortium Extensible Markup Language (XML) 1.0, see
http://www.w3.org/XML/Core/#Publications
World Wide Web Consortium Simple Object Access Protocol (SOAP) 1.1, see
http://www.w3.org/TR/SOAP/
World Wide Web Consortium Web Services Choreography Requirements (Working Draft 11 March
2004), see http://www.w3.org/TR/2004/WD-ws-chor-reqs-20040311/
World Wide Web Consortium Web Services Description Language (WSDL) 1.1, see
http://www.w3.org/TR/2001/NOTE-wsdl-20010315
Page 20 of 20
SIDP Notional Architecture Executive Summary