Enterprise Modeling of Business Objects in the realm of Geographical Information System Development 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. |