Multi-tiers for OWS Services Framework (OSF)
Multi-tiers for OWS Services Framework (OSF)
The OpenGIS Web Services (OWS) and Open Location Services (OLS) initiatives also defined server-side client applications, as "the main server-side components of client applications". The OWS Services Framework (cross ref to Computational Viewpoint that was section 4.3.2 of ORM 03-040) describes how these components run on the server side of the network, drawing on "user application logic" (business logic) to invoke Registry, Processing, Portrayal, and Data services, and to interact with client-side components through a Web/Portal Server. These components generalize the "viewer client generators" of Web mapping to support thin (small, simple) clients running on mobile devices such as cell phones. Server-side client applications fit into a larger architecture of services, depicted below.
[excerpt from 2.2 OpenGIS Service Framework - CICE 03-055r1]
The Publish-Find-Bind service framework is the foundation of the OpenGIS Service Framework (OSF) that is employed in the OGC Web Services architecture. In the OSF, the role of broker is implemented with a set of registry services. The role of provider is accomplished by a collection of service types; 1) data services; 2) portrayal services; and 3) processing services. The role of requestor is typically provided by a set of client applications. The OSF is depicted in the Figure below.
In addition to providing the clients and services needed to support the requestor, provider and broker roles, the OSF also contains a set of encoding methods that are used as the foundational data structures in the message communications that implement the Publish, Find and Bind operations.
The structure of the OSF shown in Figure above might tend to imply that an instance of the OSF is self- contained on a single platform. While this approach could be realized, generally this is rarely the case at all. The OSF is architected to operate on the Internet over the World Wide Web (WWW). Any client (requestor) on the WWW can potentially find registered services (or data) from any OGC registry (broker) on the WWW and bind to any OGC service provider (provider) on the WWW. The distributed operations in the architecture are supported by the instantiations of OGC interface specifications that are implemented using OGC Web Services. This architecture provides a distributed operating environment that enables the sharing of geospatial information that fosters an environment of collaboration.
[end of insert from OpenGIS Service Framework - CICE 03-055r1, para. 2.2]
OpenGIS Services are accessible from Application Services operating on user terminals (e.g., desktop, notebook, handset, etc.) or servers that have network connectivity and that utilize OpenGIS service interfaces and encoding specifications (Figure 24). Users may use Application Services to access Registry, Portrayal, Processing and Data Services, depending upon the requirements and designed implementation of the application. Application Services commonly, but not necessarily, provide user-oriented displays of geospatial content and support user interaction at the user terminal. Application Services may be realized as marked-up text (e.g., HTML or XML) transferred across a network from a server, software modules (e.g., Java classes or ActiveX components) transferred across a network and executed on a local system, or as executable code resident on a local system. OpenGIS® Application Services may also support privacy and access controls based on authenticated user identity, however, such controls will typically be provided by an authentication server or some other access control mechanism.
Figure?? (24) illustrates the distinction between client-side and server-side Application Services.
Figure ?? -Application Services and the OWS Services Framework Client-side Application Services should:
- Provide the means to find geospatial-based services and data resources through search and discovery mechanisms of Registry Services;
- Provide access to geospatial data (e.g., geographic features and images) and other geospatial-based Application Services and Data Services;
- Integrate with a range of deployment platforms from Web browser-based to desktop to wireless handsets;
- Portray geospatial information in graphic, image, and/or text form;
- Support user interaction via keyboard, cursor or other human-machine interfaces
Application Services should be able to execute not only on the user's desktop (or handset), but also on a server on the network. Examples of server-side Application Services include compute-intensive (and/or I/O-intensive), server-based applications like those required for Image Processing or Route Determination. Server-side Application Services should:
- Implement user application logic (business logic) that utilizes supporting OpenGIS Framework Services such as Registry, Processing, Portrayal, and Data Services.
- Interact with client-side Application Services through an appropriate network protocol depending on the platform being used.
- May be deployed as components of Web Portals and web-accessible business services that add-value to underlying OpenGIS Framework Services.
The above discussion of client-side and server-side Application Services notwithstanding, the OPS Services Framework does not distinguish the myriad options for deploying applications on a network. Instead, any user-facing software component that performs a service that satisfies user-requirements, whether it executes on the client or on the server side of a network connection, is simply an Application Service. The Application Services described below categorize applications by logical function and not physical deployment. Implementations of OpenGIS Application Services are, through standardized interfaces and encodings, freely able to mix and match the capabilities of OpenGIS Services Framework into physical implementations to meet market or application-specific requirements
Specifying tiers independently
Regardless of how exactly one defines thin vs. thick clients, the multi-tier view afforded by the Engineering viewpoint allows a large specification to be broken into different parts, each addressing a different part of a total system specification (user interface, service invocation, and data/metadata transfer), which can each be mapped into specific technologies as shown in Figure ??(25)).
Figure ??(25) - Mapping from platform independent UML models