| GISdevelopment.net ---> GITA 2003 ---> System Architecture |
Designing open GIS conformant system architectures for the enterprise
Christopher Tucker
President/CEO, IONIC Enterprise
PO Box 2635
Alexandria, VA 22301
Christopher Tucker
President/CEO, IONIC Enterprise
PO Box 2635
Alexandria, VA 22301
Abstract
This paper provides a review of the state of the art in utilizing specifications from the Open GIS Consortium (OGC) to develop openly architected enterprise GIS/AM/FM systems that leverage legacy enterprise spatial data against third party spatial data and services. This session will offer a practical overview of the value of OGC specifications, and discuss their use in the development of flexible, multi-tiered, scaleable solutions.
How did we live before interoperability?
In prior years, states and localities have struggled with the requirement to securely publish their spatial data on the web so that authorized regional and federal authorities could dynamically access this data on the fly, in their own web applications. Utilities have had to FME data nightly from one system to another in order to do analysis.
Enterprises have had to convert entire GIS systems over after mergers, in order to achieve a basic level of data compatibility. Organizations with spatial data in multiple environments have had to build applications against proprietary APIs, requiring intimate knowledge of the underlying computational environments and causing combinatorial development problems (e.g., n- clients against n-resources). Data has been replicated continuously, undermining the quality and integrity of spatial data resources. And, system stove-pipes have become a way of life.
Prior to interoperability, most people in GIS viewed this situation simply as the way GIS worked. No talk of ‘interoperability’ could possibly have swayed them from making enterprise GIS decisions that re-enforced these limitations. Yet, with the maturation of standard interoperability (interface and encoding) specifications for distributed geoprocessing, and their support in many commercial products, these same people are now seeking to eliminate the costly data and system redundancy, constant system reengineering, stilted data exchange, and limited functionality offered by traditional GIS.
How did we live before interoperability? Well, we managed just fine, like the drunk under the lightpost. But, only with the deployment of interoperable products will people be able to grasp the new functionality and efficiency gains offered by the new frontier of interoperable distributed geo-processing.
OGC web services: The 'Dial-tone' of the spatial internet
Web services offer a method for publishing your computational capabilities in such a way that others might dynamically find them and bind to them – enabling the easy construction of “service chains” comprising modular, plug-and-play components. This plug-and-play capability cannot be under-emphasized in what it offers architects of new systems. Yet, it is arguably more important in what it can offer enterprise architects who seek to “open-up” and leverage their legacy data and services as their enterprise progresses. The promise of the ‘web services’ vision, as championed by industry leaders such as IBM, Microsoft, Sun and others, is revolutionary. Its realization within the realm of spatial data and distributed geo-processing has been led by the Open GIS Consortium.
The sponsors and members of the OGC have been working over the past several years to specify how various “web-mapping” functions can be implemented in an interoperable, vendor-neutral manner through the use of web services. In consultation and harmonization with ISO TC211, OGC must now be considered the sole source of implementation-level web services specifications for interoperable, distributed geoprocessing. In truth, the OGC pioneered the Web Map Service interface before “web services” became a term of common use. At this stage, the OGC and its 230+ members have developed a comprehensive set of interface specifications and encodings that enable powerful webbased access to map data (Web Map Service), vector data (Web Feature Service and Geography Mark-up Language – GML), and coverage data (Web Coverage Service). And, OGC and its members have worked extensively on perhaps the biggest challenge faced by those seeking to implement web services – how to describe the capabilities of a spatial web service so that they (and the data that they host) might be published and discovered in a Web Registry Service. Without machine-readable capabilities, the integration of various components continues to be an arduous, “man-in-the-loop” process.
Frome dumb maps to spatial applications
Much of the deployed base of OGC services is centered around the Web Map Service, enabling easy, standards-based access to raster map data or portrayed vector data (for instance, Shapefiles). This has been a huge leap forward for many enterprises, freeing them to point applications against any WMS conformant server, without prior knowledge of its API. Some companies have implemented middleware products with the WMS interface (often called a ‘cascading’ Web Map Service), providing an application dynamic access to distributed web map servers. While this has offered organizations unheard of flexibility, they have aspired for more powerful applications offering feature-level access and computation. In support of this business requirement, the Open GIS Consortium membership later developed the Web Feature Service (WFS) specification.
The WFS enables sophisticated, webbased geo-processing. A WFS responds to requests (queries) with ‘feature collections’ encoded in GML (Geography Mark-up Language), which is based on the W3C’s XML specification, enabling the exchange of only the feature information requested about a particular area. Yet, due to various portrayal engines, a user needn’t necessarily deal with anything more complex than the userinterface offered by basic webmapping (WMS) applications. They can merely navigate portrayed views of underlying feature data, as returned from sophisticated WFS queries.
Some OGC member companies have chosen not only to implement the WFS interface specification in their products, in order to enable feature level access to some data set. They have also built powerful middleware products with the WFS interface that can provide direct, simultaneous access to multiple, underlying engines such as Oracle Spatial, ArcSDE, and more. Such OGC conformant infrastructure enables enterprises to provide unprecedented applications over thin clients.
Marrying web services to other DIS Distributed Computing Platforms
TRIBUTED While many enterprises want to deploy web-mapping applications, they would like these applications to take advantage of live enterprise applications deployed on other distributed computing platforms (DCPs) such as J2EE, COM, or CORBA.
Imagine a Telecom operator who needs to serve location-based information or maps every second to thousands of mobile phone subscribers, mixing real-time traffic control information, yellow pages databases and entertainment information from the Web, taking into account subscriber’s preferences stored in their CRM database (Location- Based Services). Imagine a governmental organization which aims to facilitate access to public information for all its population through a map-based interactive page on the Web, accessing simultaneously many of its distributed databases and controlling administrative transactions (e-Government). Imagine a company offering a value-added service on the Web that requires a map result or a map presentation combined with other value-added information from its corporate data warehouse that has to be accounted for and charged online to its customers (e-Business).
Each of these scenarios likely requires integration through an enterprise API that is more flexible and robust than what http:// can provide as a protocol. The OGC recognizes this and is taking steps to develop interfaces such as WMS and WFS as platform independent specifications that could be implemented as JAVA APIs, COM APIs, or CORBA IDLs. Indeed, for the WFS, the OGC has already developed the ‘Simple Features for CORBA’ specification that can serve as the basis for such enterprise API’s – and at least one vendor offers such APIs in its products.
The same products (e.g., WMS, WFS, etc.) can support both OGC Web Service interfaces and enterprise API’s. This enables enterprises to integrate all of their spatial data and services into a common, loosely-coupled environment.
This means that the combinatorial problem posed by such integrations can be solved, with many applications being designed against a common standard interface, with underlying data and services brokered by OGC conformant middleware. New applications, data sources, or services could be added over time with minimal impact to the overall system architecture!
Powerful, Flexible portrayal
One of the most powerful aspects of OGC Web Services is that the underlying data can be separated from the way in which it is portrayed. This is particularly important when one Web Feature Service is accessing multiple legacy databases or remote Web Feature Services – since the application owner would not necessarily own the underlying data. The OGC has followed one of the principle axioms of XML in its web services architecture – the separation of structure, style and content. The OGC standard Style Layer Descriptor (SLD) has made it possible to style underlying data on the fly, much as a cascading style sheet does for any other XML data. And, even more powerful portrayal engines can be applied to enable access to remote symbol libraries, advanced portrayal rules, utilization of SVG graphics, and even 3-D portrayal.
The power of the WFS specification along with a sophisticated portrayal capability lets enterprises do things they never considered possible, over the web and to mobile devices. And, as real-time, spatially-enabled data resources come online, the limits of distributed geo-processing seem endless.
Design strategies for becoming OGC conformant
The OGC’s 230+ members are making great progress in providing OGC “connectors” and patches for their existing products. And, in many cases, the membership is deploying OGC interfaces such as WMS and WFS in their new releases. As such, the first strategy system owners should take advantage of is upgrading their legacy to OGC conformance, without changing vendors. Depending on their system needs, a WMS connector will enable them the access they need. However, some aspects of their systems will require, for instance, a transactional WFS interface on certain resources.
Since different OGC members are on different development schedules, they may not support the interface you need on the schedule you want. In this case, other OGC members can offer direct access to the underlying database, such as Oracle Spatial or ArcSDE. While this would require a new vendor, it would OGC enable the base components of your system so that they could participate in an n-tiered OGC conformant architecture.
Second, a system owner needs to figure out how (s)he will take advantage of all of these OGC conformant sources, and broker them. How will a variety of applications take advantage of a variety of spatial resources? In order to accomplish this, you will need to find those OGC members with appropriate middleware products that offer the brokering capabilities, data enhancement facilities, and portrayal services necessary for effectively bridging this divide.
Third, a system owner needs to decide on the enterprise modules that will require integration with these OGC Web Services, and program against the enterprise API’s (e.g., JAVA, COM, CORBA) also offered by OGC conformant products.
Taking advantage of the ROI inherent in OGC web services
No comprehensive study has been done on the return on investment (ROI) achieved with OGC Web Services. By merely exposing underlying spatial resources as OGC Web Services, a system architect can for the first time in history, potentially solve the combinatorial integration problem posed by the mixing and matching of many different spatial applications against many legacy spatial resources. And, this new ability fundamentally launches you into a world where there is:
- No off-line data conversion required
- No redundancy or duplication of geospatial data needed
- No conflict between multiple GIS servers from multiple vendors
- Easily developed cross-department/organization applications
- Native web access to your spatial resources
- E-business enabled, and secure access to your spatial resources
- A higher level of data integrity, with the same information available for everyone
At this point, it isn’t a question of when your organization could become OGC conformant, and deploy your data within an OGC web services architecture. It is merely a question of which vendor will provide you software products with the OGC web services you need (like, WFS!), a cascading architecture (for those accessing remote OGC services), advanced portrayal, powerful OGC client toolkits, scalability, enterprise deployability (for instance, as EJBs, with JAVA APIs), and support for your particular legacy infrastructure.
Architects now must decide whether they will be responsible for massive investments in yesterday’s technologies, causing them only more headaches and costing them even more money.