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