© OGC 2003
– All rights reserved
6 Role and Definition of Common Architecture
OpenGIS Web Services OWS are individual components of dynamic geospatial computing applications; they are also parts of an overall paradigm for building solutions
to geospatial “problems”. This paradigm - the Spatial Web - imposes both conceptual and implementation constraints on how OWS works. Conceptual constraints include service
orientation, n-tier distribution capability, self-description, and stateless operation; these constraints generally address functionality.
Implementation constraints include use of common XML encodings, HTTP transports, tightly defined interface syntax, specific information models for service descriptions and
other metadata; these constraints generally address interoperability. Taken together, these constraints form a common basis or architectural framework to guide the successful and
interoperable implementation of OWS instances. From a practical viewpoint, the more of these common constraints can be satisfied once for all services, the less work it will be
either to implement existing service types or to define new ones. As with any functional web, this should lead more quickly to the efficiencies of both scale and diversity many
nodes of many different capabilities which give the Web much of its value.The OWS Common Architecture defines a framework of guiding concepts, terminology,
fundamental patterns and organizing principles for implementation and deployment. The OWS Common Architecture establishes common interfaces, exchange protocols, and
services that can be utilized by any application. OpenGIS® Implementation Specifications provide guidance to application developers on how to build their
applications to comply with the OWS Architecture. OpenGIS® Services are implementations of services that conform to OpenGIS® Implementation Specifications.
Compliant applications, called OpenGIS® Applications, can then plug into the framework to join the enterprise operational environment. This loosely coupled approach
to enterprise development results in very agile systems.
By building applications to common interfaces, each application can be built without build-time or run-time dependencies on other applications. New applications and
services can be added, modified, or replaced without impacting any other applications. In addition, operational workflows can be changed dynamically, allowing rapid response to
crises conditions.
The following subclauses present useful and recognized patterns for OpenGIS Web Services and their interactions.
6.1 Open Distributed Processing
The concept of distributing computing functions across a network in a dynamic fashion has been addressed by the Reference Model for Open Distributed Processing RM-
ODP, an international standard for architecting open, distributed processing systems.
© OGC 2003
– All rights reserved
RM-ODP provides both a conceptual framework for such systems, and implementation patterns or rules.
The RM-ODP model identifies the top priorities for architectural specifications and provides a minimal set of requirements—plus an object model—to ensure system
integrity. Five standard viewpoints are defined; the viewpoints address different aspects of the system and enable the ‘separation of concerns’:
Enterprise viewpoint: articulates a “business model” that should be
understandable by all stakeholders; focuses on purpose, operational objectives, policies, enterprise objects, etc.
Information viewpoint: focuses on information content and system behaviour
i.e. data models, semantics, schemas
Computational viewpoint: captures component and interface details without
regard to distribution
Engineering viewpoint: exposes the distributed nature of the system and provides
standard definitions to describe engineering constraints
Technology viewpoint: describes where to apply the technologiesproducts of
choice and allows for conformance testing against the architectural specification There are a number of documents associated with the OWS1.2 initiative which express
various components of these viewpoints. The present document serves both as an overview to those documents and to fill in those common aspects of architecture that are
not covered in more specific discussions.
The Enterprise Viewpoint is addressed by a combination of the OGC mission and the business requirements articulated in Section 7 and Annex A as well as the other
individual requirements and scope documents developed as part of OWS1.2.
The Information Viewpoint is addressed specifically in OGC 03-026 Service Information Model IPR, OGC 03-024 Registry IPR, and other information model metadata
documents.
The Computational Viewpoint forms the core of the present report, by providing an object model for the implementation-independent definition of OWS interfaces.
The Engineering Viewpoint is also covered in this report, as well as by other documents. It focuses on the requirements for mechanisms by which interfaces are knit together into
a processing network such as the Spatial Web. These include encodings serializations, messaging frameworks, transactions, exception-handling, persistence, etc. These
mechanisms are described in as platform-neutral a manner as possible.
The Technology Viewpoint is distinguished from the Engineering Viewpoint only to the extent that the above engineering mechanisms can be defined separately from technology.
A common architectural framework should in principle be defined in a technology – neutral fashion. In practice, such a framework can only enhance interoperability by
© OGC 2003
– All rights reserved
recommending the best presently available common technologies for achieving this purpose, so discussions of specific technology do enter necessarily into portions of the
present document.
6.2 Service Oriented Architecture
