Using COM to develop universal GIS applications
Michael Hamsa Programmer/Analyst Cook-Hurlbert, Inc. 5222 Thundercreek Road Austin, Texas 78613 Telephone: (512) 338-1711 Fax: (512) 338-9794 Email : mike.hamsa@cook-hurlbert.com
A New Breed of GIS Applications
Motivation What started as a data repository for graphical and tabular information representing everything from environmental research to utility assets has become an organizational tool for planning futures as well as an information source for critical network topology. Geographical Information Systems are becoming a wide spread device for mass deployment of spatial data. The world of energy generation and distribution has started to see that this technology can be used throughout the enterprise for robust data collection and circulation, job design, new business and planning, as well as mission critical systems like outage management and network restoration. Organizations are starting to plan for lightweight devices that can use GIS technology in the field to perform the same types of jobs that it is used for in the office. What problems does this present? What are the limitations of each GIS? Are they scalable enough for hundreds of users, yet portable enough to be used in a distributed or disconnected environment? Many people are discovering that one GIS solution may not be the answer. There are probably terabytes of historical and legacy data existing today in GIS data repositories that is still up to date and usable, but because of re-organization and re-engineering new GIS platforms have been installed and implemented. Along with these new systems comes a new suite of products and applications that have to be taught. The old applications are no longer used because the GIS they were originally written for has been replaced by newer technology. As corporations currently using competing GIS technologies merge, decision about standards have to be answered, and a complete translation from one GIS to another may not be the right answer. These issues are providing today’s IT departments with new and interesting problems to solve. What is more than likely the case is that a single GIS platform may not be the best answer to these questions. A GIS that can be used easily in the office may not be the most efficient tool to use on a pen based machine in the field. Two different companies that merge, may agree that they are happy with the GIS each is using and decide not to go with only one. How do these companies continue developing a single add-on application that can be used on multiple GIS platforms? A Solution New technology has given a new answer. It is now possible to develop integrated applications that can run with different GIS platforms. Microsoft introduced the Component Object Model (COM) as a solution to problems like this, different environments communicating directly with one another. This technology does not come without a price, and that price is in the form of increased design and development time. Each GIS being targeted should be reviewed for required application functionality, and this functionality should be abstracted at the lowest possible level and partitioned correctly. The payoff is a uniform tool that can be used throughout the organization for everything from job design to outage management, regardless of what GIS system the user has access to. What is COM A Foundation COM is a programming architecture that provides a generic way to distribute reusable interfaces in binary format. It allows different programming languages and environments to communicate with one another using an Open Software Foundation standard called Remote Procedure Call, simply referred to as OSF RPC. RPC is a wire protocol that uses low level operating system calls to allow different process spaces to communicate with one another. These process spaces can be running on the same computer, or on separate computers connected together with standard network protocols. COM has a standard API that supplies developers with a common way to create and destroy COM components. The COM API is contained within a DLL (dynamic link library) that is loaded in the process space that the COM application is running in. Problems One the biggest advancements brought to the Windows developer was the concept of the DLL. DLLs allowed applications to reuse common functions simply by dynamically loading a file and making use of the functions that it exposes. As DLLs became widely used, a concept referred to as ‘DLL hell’ was coined because of the trouble caused by these DLLs. When applications were upgraded, modified, and extended, it became very troublesome to maintain these DLLs. The DLL had to be referred to by an exact file system path and physically loaded into the application process space. The application expected the DLL to contain the same functions and look the same way every time it was loaded. A simple change to a DLL function made by one developer could easily affect every developer on the team stopping development for days. Something had to be done. Reusability? Internally, Microsoft’s application development division fought through this problem and developed a specification for reusing DLLs efficiently. Using something called a COCLASS to expose interfaces instead of functions, applications now have to ask for interfaces instead of expecting them to be there. This way they can gracefully handle cases when an interface is not exposed. DLLs are still used to house these COCLASSes, but they can also be distributed in exe format. Using the windows registry, the DLL location, as well as other attributes about the COM components, are stored and accessed. Each COCLASS and interface is referred to using something called a GUID (Globally Unique Identifier) which is guaranteed to be unique across the world. Using GUIDs to name interfaces and COCLASSes eliminates the threat of naming collision between components. Generally, COM is a written contract that states what interfaces and methods a component exposes, how they are used, and what they return. This contract should never be broken. Method syntax should never change because it would break any clients currently using the method. The implementation of the method can change so long as the same results are returned. If a new syntax is needed, to offer additional parameters for instance, a new method should be added to the interface instead of changing the signature of the existing one. This guarantee allows clients to freely use a components interfaces and methods without fear of losing them. GIS Applications and COM Customizing GIS Functionality Every IT department is faced with the same types of problems when they implement a GIS, users requesting new functionality. As the GIS platform becomes more of a tool to plan networks, analyze voltage loss, or predict outages, these functionality requests become more like applications and require large efforts to complete. The initial problem is that the new application is usually targeted for a single GIS platform because it depends on the primitives exposed by the GIS. This is a very limiting factor because sometimes it is not possible to use a single GIS platform. As the application is moved from one GIS to another, it is usually rewritten because of these dependencies on the GIS. GIS Access Component GIS vendors have been slowly exposing their primitives and APIs using COM and this is making the task of building add-on applications for a GIS easier. It is now possible to use mainstream development environments like Visual Basic and Visual C++ to build new functionality and user interfaces on top of the GIS. The underlying problem still exists because the COM interfaces exposed by a GIS are vendor specific and exposed differently by each GIS system. When you build an application that directly uses the interfaces exposed by one GIS, it is only usable with that GIS. The specific primitives and functions exposed by the GIS need to be hidden from the application being built. By building a layer that abstracts the GIS primitives and exposes a new set of COM interfaces, a certain amount of GIS independence can be gained. This new GIS access layer takes the form of a COM component that is built specifically for a GIS, using the primitives and APIs made available by the GIS system, while exposing a common set of interfaces to the add-on application. Architecture With minimal effort, a new access component can be written for each target GIS. An imaginary line can be drawn horizontally through the GIS access component, dividing it in two. The bottom half of the layer is built specifically for the target GIS while the top half exposes the interfaces used by the application. The interfaces exposed by the top half of the component are carefully specified and documented to be used directly by the add-on application. These interfaces hide the GIS from the application and allow it to be developed without specific GIS interfaces and methods. This component is unique because is it both a client and a server. A client in the context of the GIS and a server in the context of the add-on application. Functionality Abstraction It is very important to partition the functionality of the GIS access component appropriately. Logical partitions should be introduced to promote ease of application development. There is usually only a small number of GIS functions that are actually used. Actions such as creating or updating features, getting items selected by the user or items at a specific coordinate, or panning to a feature or coordinate are all very commonly needed functions exposed by the GIS and used by an application. By closely reviewing the application requirements and matching them up with each GIS, an abstraction suitable to the development effort can be accomplished. This will improve maintenance, extendibility, and reuse of various implementations. Conclusions COM is a programming architecture and specification that has made it possible for several different environments to communicate with one another. Using COM, many GIS vendors have been able to successfully expose interfaces that allow third parties to build applications on top of the GIS that provide useful tools to the organizations using them. As the future of the GIS industry progresses, a heterogeneous GIS environment may result and applications will have to be built that can run on several different GIS systems with changing the application code. The benefits of this are reduced training costs because regardless of what GIS system the user is on, he is assure that the add-on application he is using to perform outage management or network analysis will always be the same. People using a lightweight GIS in the field that is different from the GIS they use in the office can now use the same job design tool in both places. This does place additional work on the shoulders of the IT departments developing add-on applications, but the result is a uniform tool that does not require a specific GIS system to run. As re-engineering occurs and new GIS system are brought in, the application can be reused without changing the code. Additional costs are minimized because the application is not dependent on the GIS and can be ported much easier. Plan carefully and you will have an application that will be used with future GIS systems. References
| ||
| © GISdevelopment.net. All rights reserved. |