Srikrishna Pothukuchi
Navionics Technologies Pvt Ltd
Road No 3, Banjara Hills, Hyderabad 500034, India
Tel: +91-40-661 8251 (Off) +91-40-714 3599 (Res)
Email : [email protected]
Introduction
Application of geographics to business systems is emerging rapidly as the quest for predicting future businesses over well-known spatial phenomenon intensifies. Matured spatial systems escalate such need in leveraging spatial information in formulating business strategies. May it be a risk evaluation for the insurance aspirants or identification of outlets for the retail chain, the usage of geographics is well established. However in some cases, the GIS is limited to producing reports that enable the decision maker, but might fail often in occupying prominent place in the enterprise information system architecture.
Business systems those exhibit predominantly spatial characteristics are often proprietary and closed, whereas systems that are compatible to open standards have well defined interfaces but very much limited in exhibiting the spatial characteristics throughout the lifecycle. Former systems are built carefully to satisfy the requirements at the time of definition and tend to become legacy systems. We have plenty of examples in this area, where the developer often builds his own component libraries and use, or better still reuse third party mapping components like ActiveX controls or Java Beans while developing the enterprise system. Latter systems have their main information system intact and a popular third party GIS Viewer or Analysis software tool supplements; one example being ERP as a candidate system, with third party GIS Tools supplementing it.
Organizations from the non-professional GIS segment that join bandwagon of spatially enabled services lack commitment to the usage of spatial information. Such failures cannot only be attributed to the lack of awareness on GIS on behalf of executives, but it should also be equally attributed to the systems architect, who had delivered the spatial solution loosely coupled to the core information system. Higher the degree of coupling does not necessarily mean moving towards proprietary systems, as long as interfaces provided comply with the open standards.
Current Scenario
Developments in relational database technologies and distributed component services caused many enterprises to exploit these technologies to develop their information systems accordingly. Contribution of the ISO TC-211 and the Open GIS Consortium are to be acknowledged duly in this regard. Keeping meticulous details aside, the most popular and simple way of spatially enabling a business solution is to attach business attributes to the spatial primitive. If there are more tiers for the system in entirety, at the data tier it is the spatial table that holds these extra attribute columns, and at the business logic tier, a compound object or a GML document that holds the corresponding schema. The presentation layer, usually being a map browser, parses the GML dataset and presents the information. Architect is still having the choice of building better system, as he is having access to the objects in the GML document.
At the database level, spatial objects are stored in relational tables often with huge binary large object types. With the advent of SQL MM specification, abstract data types were introduced for storing spatial data. Irrespective of the storage mechanism, the spatial record can be accessed by its unique identification number. This record represents either a primitive spatial element or a derived element. Again it’s the same record that is going to be presented by the application visually, and along with its graphical depiction a standard identification tool fetches attribute details about this element, thus serving the base functionality. Analytical operations on this element are to be limited only to the attributes predefined. If the user has more information processing requirements than assumed earlier, either he has to change the definitions of his datasets by adding or removing more attribute columns in the database. This situation is really pitiful on behalf of the spatial objects, because the requirements for change are often applicable only to the business objects, i.e. information represented by aspatial columns or simply the attributes.
A workaround solution could be produced, if the GIS Client software provides a macro language of its own. One typical example is writing a macro program that temporarily brings data from aspatial tables linked by the unique ID of spatial tables and creating a theme for further analysis operations on the temporary dataset.
While the later approach is immediately appealing (as it were today), still the information processing needs are not addressed completely. Information processing involves not only the spatial data, rather it involves usage of business data extensively. There are enterprise systems where GIS is merely a part, making the system spatially enabled partially. But the term spatially enabled system implies that the business system is partly complying to bring forth the usage of spatial data, whereas the amount of spatial enabling is not quantified at large. Good example in this case is of a popular ERP package was referred by this term, when the ERP package made by one vendor has plug-in to a popular GIS tool made by another vendor sold as a total solution; data interchange between these two systems were maintained at a sub-system level.
Another option left to the architect is to build an information processing system either by using off-the-shelf map components or by developing his own. Whatever choice he make, the system evolved would remain as proprietary, despite of the flexibility it offers.
Approach
While limitations in implementation of business geographic systems are widening the gap between core business information processing requirements and spatial information usage, newest trends in technology should drive the approach of building and deploying the GIS software. This section proposes an approach where various services augment the usage of built-in capabilities of the existing GIS tool.
As per the proposed approach, there would be some auxiliary software services like simple Windows NT processes or UNIX daemons compliant to certain distributed object services like DCOM or CORBA. These modular services utilize several inputs before presenting the information content. They are auxiliary services and do not form parts of the base GIS Engine or the enterprise system. They do assume the content of pure spatial dataset and capable of building a model at the runtime as per the requirements of the enterprise and give back the outputs to the core GIS Engine, there by presenting the content in the modeled format.
In simpler terms, these set of services steal the inputs from GIS Engine, Information System and/or from any other relevant services at appropriate places and serve back the outputs to the relevant application. This concept is straightforward more obviously when we work with GML documents. Document produced at the middle-tier can be used by the local GIS Engine or a Map Browser for presentation. Objects retrieved from the GML documents could also be utilized to suit the requirements of the current context.
In order to provide flexibility in putting the Information System to respond for various events, modular software processes are to be deployed. These additional services could transform the original presentation intended by the GIS Engine to suit the requirements of the Information System.
Above diagram depicts interaction among sub-systems and services. Interfacing Services form a middle-layer between the core Information System and GIS System, translating the needs of each other. To interact with the component sub-systems, Service Access Points are provided. Under careful observation, organization of Service Access Points is visibly different from the left side sub-system to the right side sub-system. This pattern exists because of the fact that the Information System tends to give multiple inputs and also in need of similar outputs in comparison with the standard nature of GIS sub-system of the subject. Whereas the standard nature of a GIS subsystem requires minimum number of Service Access Points, where it could be coupled with a flexible Business System.
Architectural Framework
Architectural framework for the subject is built around two core components, namely, the Information System and the GIS Engine. It also takes into account other supporting components like the data stores, repositories and applications. Following schematic depicts arrangement and interaction of these components and services.
Current enterprise subsystems are assumed to occupy to prominent locations in the tiered architecture, namely the Core Systems Layer and the Data Stores Layer. Proposed framework services are placed at the Interface Services layer.
At the Data Stores Layer, the two stores namely, the Business Data Store and Spatial Data Store are generic in their occupancy, i.e. these two stores may reside typically at the data tier in the traditional client/server architecture or still occupy server side of the web tiers in case of an n-tier architecture. It is more important that despite of the physical location, these two stores represent data stores always. Functionality of the Business Store is to safe storage of enterprise information and the functionality of the Spatial Store is restricted only to maintain geographic information. This separation is only logical, whereas in some systems, certain business tables reserve a column for storing spatial information within them.
As usual data stores serve data to core systems. Uniqueness of the new approach is to introduce a middle layer in between the Core Systems Layer and the Data Store Layer. The middle layer should not be mistaken for a business logic layer in traditional web-based systems; rather uniqueness of this layer is of various interfacing services that it is composed of. This middle layer known as the Interface Services Layer would serve upper layers for the purpose of presentation. The Interface Services Layer contains Interface Kernel represented by the dotted rectangle and two supporting services augmenting the Interface Kernel, namely, Programmable Interface and Dynamic Object Relation Builder.
Interface Kernel encapsulates core functionality of object translation and it is assisted by separate component services that would be able to change behavior of the kernel to suit the information flow between various systems. The four component services are Process Listener, Process Translator, Business Feature Service and the Spatial Object Service.
The Process Listener / Translator couple occupies the heart of the Interface Kernel. Responsibility of the Process Listener is to capture information emanating from data stores to the core systems. It captures information as per the Programmable Interface Specification and looks for specific patterns and identification of objects before serving filtered information to other processes. Process Translator converts captured information into conceivable objects and provides translated data to the two upward services. The whole cycle is like stealing specific information intended for the core systems; processing the filtered information; formatting the information; and serving the processed information to upward services. While serving information to upward layers, the Process Translator parses information content readable by Business Feature Service and Spatial Object Service. Communication from these two services to the translator is bi-directional because all the temporal information from these services should be translated and stored again in the Dynamic Repository. These temporal services could be specialized geocoding or addressing services programmed especially for the information requirement by the end user. In such cases, Business Feature Service sends address information to the Process Translator with relevant Spatial Object IDs and using the service of Dynamic Repository, Process Translator sends back the geocoded information to the Spatial Object Service. Translation described here could also happen in a reverse direction from Spatial Object Service to Business Feature Service through the Process Translator. However it depends on how well the Interface Kernel is programmed.
Dynamic Repository keeps all dynamic relation information. It contains relational information among business and spatial objects. Process Translator consults Dynamic Repository for processing and formatting retrieved information. It can also store these relational objects using industry standard Document Object Model there by reducing the programming efforts.
Programmable Interface is the main entry point for customizing the Interface Kernel. Interface Definition Language could be embedded within the solution, thereby making the interface compliant to open standards. Dynamic Object Relation Builder can be accessed either by the Programmable Interface through the latter’s native language or directly through its own Object Query Language. Accessibility through OQL is maintained to keep the interface simple yet powerful.
Standardization
Standardization would take place on three major fronts, independently. One is specification of GIS development where the OGC recommendations could be driving implementation of Business Feature Services and Spatial Object Services. On the other front OMG’s CORBA specifications could be driving entire implementation of the Interface Kernel. An optional choice could be reserved for implementing ODMG’s Object Oriented Database standard for implementing the dynamic repository and usage of Object Query Language for its Relation Builder. Irrespective of third party implementation standards, the Interface Service Layer could be standardized for its framework and specifications on yet another front, leveraging existing well-established standards of geographics and computing.
Conclusions
An equilibrium state in coupling would balance the system between proprietary to open and to that of a matured system and henceforth increases the average life span. Despite of the standards, and maturity in technology, it is the direction or vision that sustains the life of an application. Openness in this framework calls for more effort and refinement in formalizing and delivering specifications that utilize the considerable effort already made by several organizations in the fields of geographics and computing. Output of this approach is wide analytical usage of geographic data and seamless integration of geographic tools with the existing enterprise information system with an open and identical framework, which is matured and non-proprietary.
References
- The OpenGIS Abstract Specifications, Revision 4, 1999, Open GIS Consortium
- The OpenGIS Simple Feature Specification for CORBA, Revision 1.0, 1998, Open GIS Consortium
- The OpenGIS Geography Markup Language Implementation Specifications, Revision 2.0, 2001, Open GIS Consortium
- The Common Object Request Broker – Architecture and Specification, Revision 2.6.1, 2002, Object Management Group
