Successful Development of Multi-Tiered GIS Applications

Successful Development of Multi-Tiered GIS Applications

Michael B. Hamsa
Programmer/Analyst
Cook-Hurlbert, Inc.
5222 Thundercreek
Austin, Tx. 78759
Telephone: (512) 338-1711
Fax: (512) 338-9794
E-mail: mike.hamsa@cook-hurlbert.com

Theory and Background
Today, geospatial information systems are gaining notoriety in many different industries as a way to distribute geographical data to many people, not only within a company to its employees, but also to people outside of the company that may access the data using internet connections. We are also beginning to see many different types of applications using geographical data come to the forefront. Everything from mapping tools that track locations of assets in the field for utility companies to sales force applications that determine and locate clusters of potential customers for mobile sales employees. What used to be static paper map production and maintenance is now becoming on-line real-time geographic data distribution and over multiple types of media. This is driving the mapping technology, the vendors that provide it, and the groups that support it and maintain it to understand and use the latest advances. Software engineers need to constantly be aware of changes and improvements in technology that can be used to provide the software they are responsible for designing. The technology used in many of the software products we use today changes at such a rapid pace that it is becoming almost impossible for one person alone to keep up with it.

Because of this, more pressure is being put on Information Technology and Information Services departments to design and develop applications that use these systems and the data they contain. Requirements for applications that consume geographic data are beginning to include internet distribution technologies because users are requesting undisturbed access to the important information contained in these systems. At the same time, the "industrial strength" users who maintain the data in these systems need the ability to create, update, and delete in an environment that provides a higher level of performance and a larger number of tools that the everyday internet user may not require. Initially it looks like two completely separate applications may have to be developed to meet the requirements of both types of users. This may not be possible because IT departments are also faced with aggressive timelines to design and develop the application and approval of the applications by upper management hinges on short and inexpensive scheduled that roll functionality out to users quickly.

The general concept here is to have the engineers spend as much time up front as possible to gather and analyze requirements for these applications. Based on the analysis of the requirements, a complete software architecture can be designed that provides a maintainable and extendable platform to build future applications within. After the requirements of all the different types of users has been gathered and looked at there is usually some overlap of functionality requested. For instance, web users in the field and at home want to view work requests as well as the geographic and facility data associated with it - so do desktop users in the office. Desktop users in the office need to locate and identify potentially large customers and reference the geographic location of these customers with other customers - so do web based users in the field and at home. The business logic needed to supply this type of functionality is no different for the home or mobile user then it is the office users. The only difference the software engineers find is that the office users expect much better performance and access time and they also need a larger selection of tools than the internet based user. The office users should not be limited to web browser based technology when they can access the data with the same type of Windows based applications that they use every day. Internet based data distribution and maintenance is not the answer for every user and some users will not be satisfied with its performance or limitations.

The answer for IT and IS departments is to make sure that the technology they develop can be used by both types of applications. It is now becoming perfectly possibly for the same business logic software components of an application to be consumed by a full blown client/server application in the office and lightweight browser-based clients in the field or at home. Spending a small amount of time up front to identify these functional overlaps in software requirements may mean the difference between the design and development of a single set of business logic software components or the design and development of two completely separate sets of components used by two separate applications that both provide the exact same functionality.

Software Architecture
An understanding of software architecture is needed to identify the layering strategy that can be exploited. Typically software engineers try to separate the system into distinct areas of functionality. Client/server applications usually implement what is referred to as the Three Tier Architecture. This architecture divides the application into a presentation layer, a business layer, and a data/data access layer, each of which can be replaced without causing or requiring a lot of redesign to the other layers. The presentation layer is usually installed on the computer the user is accessing and it does not contain any business logic - it is only responsible for presenting data to the user. This layer is referred to as the Graphical User Interface (GUI) and it is what the users see and interact with. The business layer is also commonly installed on the computer the user is accessing, but it is not required to be located here. This logic may be installed on a separate computer and accessed by the presentation layer, but this is normally not the case with client/server applications. Keeping the business logic layer on the same computer as the presentation layer increases performance and reduces the amount of network traffic. The business layer is responsible for maintaining user based functionality - it does not provide any type of presentation media. When a user invokes a tool or command from the user interface, the business logic is called upon to perform the operation. The data layer for enterprise based client/server applications is typically accessed from a server running a relational database. This enables every client to access the same data without duplication. Databases provide data to the business and presentation layers. Some business logic may be maintained in the form of stored procedures, triggers, or constraints but it is up to the application designers and developers to understand that it is stored in proprietary database formats and can not be reused with other databases. There is no reason why all three layers of a client/server based application can't be installed and maintained on the same computer, but this is normally exercised only in isolated cases where data is replicated or used only by a single user.

Web based internet applications follow the same layering strategy, only the different layers are commonly distributed on different computers, possibly in remote locations. The client computer is only equipped with a thin web browser used as the presentation media. The user interacts with the browser to perform common actions and view data formatted into a web page. The business logic and the logic that formats the data into a web page is located on a separate computer called the Application Server or Web Server. As the numbers of users on a web based application increases, it may become necessary to add more that one Application Server to balance the load of large numbers of clients. In this case, the same software components that provided the business logic can be installed on each of the Application Servers. The Application Servers access the database server to retrieve, create, update, and delete data. This layering architecture is what is commonly referred to as a thin client or browser based client because the client computer has none of the number crunching, algorithmic based logic and functionality - it is all contained in the business logic software components on the application or web servers. This method of data distribution is becoming more widely used because it requires little, if any, additional software to be installed on the client. It reduces maintenance issues and allows users to access data from different locations. The draw back is that performance is usually less than acceptable for anything more than a few updates or inserts and internet connections may not be available everywhere so IT departments are still forced to deploy applications that rely on the client/server architecture.

Interface Based Programming
Recently, there have been advances in technology that have allowed for the development of reusable components. Microsoft's Component Object Model (COM) is a programming specification that produces a binary set of reusable components. These components expose a set of interfaces that can be called from many different locations, on different computers, using software components developed with different programming languages. An application built with Visual Basic that exposes a COM interface can now communicate with a software application built with Visual C++ or possibly another application developed with straight C. COM ideas follow object oriented programming practices by completely encapsulating the functionality of a particular method and only exposing the interface or entry point for other systems to call upon. The internals of the method may change without notification so long as the same end result is achieved and the signature of the method does not change. If a method accepts two parameters, a long and a double, then the method must always accepts those parameters. This rule forms a written contract between COM applications that should never be broken. If a modification or enhancement to the method is made that results in new parameters added or existing parameters removed from the method then a new interface and a new method should be added to the component instead of disturbing the existing method.

Another interesting specification of the COM model is that it designates a uniform memory management mechanism. When you receive an interface pointer that you want to keep around you must increment the reference count on the interface using a method called AddRef. Each time someone calls this method, an internal reference count is incremented by one. When you are finished with the interface pointer it is the application developers responsibility for decrementing the reference count by calling Release on that interface pointer. When the internal reference count of an interface reaches zero, meaning no one is currently holding a referenced pointer, the component is unloaded from memory. COM also specifies a common creation mechanism called the Class Factory. Each COM component must implement the class factory, which is also a COM component, and this object is responsible for creating instances of the component. A standard COM API named CoCreateInstance is always used by outside applications to create instances of components. CoCreateInstance creates an instance of the component and increments the internal reference count by one.

COM components are not limited to exposing a single interface. Components can expose several interfaces each with its own set of methods. This provides a way of partitioning functional groups of methods within a COM component. You can ask a COM component for any of the interfaces it exposes by using a method called QueryInterface and supplying it the name of the interface that is required. One of the standard interfaces required to be exposed by each component is called IUnknown. The IUnknown interface exposed by all COM components contains the AddRef, Release, and QueryInterface methods. These are the three methods required to be supported by all interfaces of a COM component. Any number of additional methods can be added to the interface after these methods have been implemented.

These are the first basic rules of the COM specification. The model goes into great detail about other such details, but the main advantage of the specification is that it allows applications to be built and communicate with one another. The applications can be written with any programming language so long as the basic COM specifications are met. A company that employs Visual Basic programmers can write applications that work freely and openly with an application built by a company the only hires Visual C++ programmers. This adds flexibility to the development cycle and different components of an application can be developed with different programming languages and environments.

Multi-Use Component Development
Using these ideas and technologies it is possible to develop COM components that contains application business logic used for both client/server and browser based clients. The actual business logic used within the application is probably one of the most important and expensive sub-systems in the entire application, second only the physical data in the database, so developing and maintaining a single set of components can reduce the current development time and future maintenance money, especially if the application is required to support multiple type of clients.

It is important that the proper amount of analysis and design be performed on the application requirements. Looking thoroughly at how the application is going to be used on both the browser based client and through a client/server application, the interfaces and methods exposed from business logic COM components can be designed to support both types of applications. Encapsulating the internal functionality of each component hides implementation details of the logic and allows it to be used by many different types of clients. It is very important that most all of the business logic be contained in the middle layer. If any of this logic is written in the form of an MFC executable and used as a presentation layer, it will be lost when moving the presentation of the application to a web page and browser.

Existing or legacy business logic contained in non COM application components or dlls is not completely lost. Another concept called Wrapping can be exploited to expose the proper COM interfaces and still reuse the existing logic contained in the legacy components. For example, if the legacy component is in dll form, a COM object can be designed to load the dll and expose the required interfaces and methods for other application to use. When a method is executed on the outer COM component, it can simply call directly through to the legacy dll for functionality and return the proper results. As time goes on, the legacy component can be replaced with a pure COM component that provides the same interface as the wrapper. The existing components of the application will not have to be rewritten because the COM wrapper hides the fact that the legacy component was still in use.

After the business components have been developed it is only a matter of distributing them to the proper client computers or application servers. Functionality that approves work requests or initiates important sales orders only needs to be written once and reused in multiple types of applications. When users are in the field and these operations are performed, you can always expect the same result as a user sitting in the office using a client/server application because the same application code is performing the functionality.

GIS Integration
Just about every major GIS vendor has exposed some sort of COM interface that can be used to access data and functionality within the system. This has opened some of these proprietary systems up to outside access and has enabled applications to be built on top of them very easily. New technologies and standards like eXtensible Markup Language (XML) is also opening new doors to pass data between disparate systems. XML allows developers to define tags that can be used to describe the actual data, not just how to present it like Hyper Text Mark Language (HTML). A new extension of XML called Geographic Markup Language (GML) and has been developed to describe Geographic data like points and lines. By using XML within the business components of you application, it will be possible to more easily use them to produce web pages in the future.

GIS vendors have also provided developers with map components that are completely selfcontained and can be embedded in web pages, VB applications, and VC++ applications.

They also provide for easy extendability using technologies like COM. It would be very convenient if you wrapped the GIS supplied mapping component in another COM component and exposed a series of interfaces and methods from your COM wrapper that the application would used, instead of using the GIS exposed interfaces directly. Companies that use more than one GIS solution or ones that are currently looking at new GIS solutions can provide wrappers for the map components so that they can be freely changed out without affecting the overall application or web pages. This can save time in the future and provide for greater flexibility when interacting with GIS systems.

In any case, is it very important to properly gather requirements for any new application. After requirement have been gathered, properly analyze them and design an application that provides a fair amount of flexibility. As technology rapidly changes, it may become necessary to change directions in the middle of a development to provide for different presentation medias. If the business logic components are properly abstracted and encapsulated it may mean the difference between reusing them for new products or rewriting them when the tide changes.