"Plug and play" Geospatial applications
Dennis F. Beck Vice-President - Business Development Smallworld Systems, Inc. 5600 Greenwood Plaza Blvd (303) 779-6980 (303) 779-1051 (fax) Email: dermis. beck@smallworld-us.com Overview Plug and Play has a really good sound to it. Just stick it in, and it runs. No worries, no problems, your business needs are met. Like so many marketing phrases and buzz words it begins to stick and really takes on a special meaning of its own. The phrase plug and play was coined by the computer hardware industry. Prompted by Microsoft, and their desire to move from the complexities of attaching devices, such as printers, Plug and Play established a much easier approach by taking away the manual effort of having to define the attached devices on a computer or network. Then it was simply a matter of "plugging and playing". Since its early beginnings the software industry has continually evolved from having unique, custom applications for every organization to a more widespread acceptance of packaged solutions. Packaged solutions in turn, are evolving from having been very heavily customized to now being ready for use with minimal customization. All of this is possible because of the reality of Moore's Law. Moore's Law was observed by Gordon Moore back in 1965. Moore was preparing a speech and started to graph data about the growth in memory chip performance when he realized that each new chip contained roughly twice as much capacity as its predecessor, and each chip was released within 18- 24 months of the previous chip. If this trend continued, he reasoned, computing power would rise exponentially over relatively brief periods of time1. Moore's observation, now known as Moore's Law, described a trend that has continued and is still remarkably accurate. It is the basis for many planners' performance forecasts. In just over 25 years the number of transistors on a chip has increased more than 3,200 times, from 2,300 on the 4004 in 1971 to 7.5 million on the Pentiurn@ II processor. With hardware solutions continuing to support Moore's Law, Plug and Play applications takes on a new importance. The big cost items in a system implementation are often times not the hardware or software anymore, but rather the resources necessary to make the whole system work. Trained personnel are commanding great premiums to make these systems come together. And with real competitive pressures driving the need to automate businesses, the solution that has the best functions and gets in faster for less money will be the winner. This problem of the continuing need for skilled technologists to deploy applications has been termed by David Taylor as the "Software Crisis"2 By relying on applications that do not require heavy customization it is possible to greatly reduce the need for programmatic customization of software applications. Plug and Play geospatial applications may well solve this problem for our industry. This paper presents a definition of the concept of plug and play and looks at how this has historically evolved in the software industry. The concept is then related to geospatial software applications. The different technologies and standards, such as COM/DCOM, CORBA and Open GIS that support plug and play geospatial applications are explored and contrasted. Examples of the use of these applications are then related to different Geospatial business areas. Plug and play defined In looking at a definition for Plug and Play it is not possible to use traditional sources such as Webster's Dictionary. This is because Plug and Play, like so many technical words, has taken on a special meaning, and has then evolved over a very recent time. The next best source I have found in my research has been with the developers of the concept, Microsofl Corporation. Microsoft has defined plug and play as: ".. .A combination of hardware and software support that enables a computer system to recognize and adapt to hardware configuration changes with little or no intervention by the user. A user can add devices to, and remove devices from, a computer system without awkward and confising manual configuration and without intricate knowledge of computer hardware. For example, a user can dock a portable computer and use the docking station keyboard, mouse, and monitor without making manual configuration changes."3 While this definition is sufficient for the hardware and operating systems, software applications require a different definition that does not appear to have a generally accepted definition. The addition of the geospatial component adds another level of complexity. I propose the following definition for plug and play software applications: Enterprise refers to the fact that the Plug and Play geospatial application is not simply a single user application, but rather a key part of a corporate information system requiring access by multiple, distributed users. This greatly increases the complexity in the same manner that networks of personal computers with attached peripherals increase the complexity of systems over isolated, unconnected desktop PCs. Integrated refers to the fact that the Plug and Play geospatial applications are not working alone, but working in conjunction with other applications and information systems. For a utility this refers to the integration of a Customer Information System, a Work Management System and so forth. Customization is work that is required to make the base Plug and Play geospatial applications conform to the business requirements of the application users. Customization is typically not considered to be core application programming modifications to the source programs of the base Plug and Play geospatial application, rather it is setting up the unique requirements of a given system. Standardized, open protocols are forms of communication between the Plug and Play application and other systems. These commonly include formal standards such as CORBA and the Open GIS as well as commonly accepted vendor de facto standards, such OLE/COM, and vendor database stored procedures. Towards plug and play - Today 's standards By its very nature, Plug and Play implies an adherence to some form of standard. This is not unlike plugging in an electrical appliance. A computer laptop will work in most outlets in the United States, but a trip to Europe will reveal that the system suddenly needs to have a special adapter to plug into an outlet. And one needs to be sure that the AC adapter for the computer supports 240V power, or the laptop may not last too long. (I know, I nearly had this problem the first time I took a laptop to England many years ago but I unplugged quickly when I began to smell smoke.) The fundamental building block for support of a Plug and Play architecture is Object Orientation. Object Orientation is a term that has been grossly misused, but when implemented at a core level of an application system it truly allows an application to meet the requirements of being plug and play. It is not the purpose of this paper to explain the details of object-orientation but for purposes of clarification it is important to briefly touch upon the basic concepts. Some of the confusion that exists around object-orientation is due to the fact that the word object is used in different ways when discussing geospatial information and applications. There are object databases, object-based modeling and object-oriented programming environments. For purposes of this paper the discussion will center around objectoriented programming and the object model. With regard to object-oriented programming, the key elements are inheritance, polymorphism and encapsulation. It is the property of encapsulation that we will address as it relates to Plug and Play geospatial applications Encapsulation is a way of packaging data and procedures together in an object. Encapsulation promotes the hiding of data so that the details are not made available external to the object. What this does is to promote a well-defined interface to the object, thus protecting the data from other interactions. The importance of this in Plug and Play geospatial applications is quite obvious when you consider the interactions that occur in an information system between the different components. The commercialized support for object-orientation is manifested in a number of ways, these include COM/OLE and CORBA. COM/OLE originated from Microsoft. The initial standard was OLE, Object Linking and Embedding. This was enhanced from a compound document protocol to an object model, thereafter referred to as COM, or Component Object Model. While COM doesn't support inheritance, it is true to the concept of object-orientation in that the actual COM model has stayed constant since 1993. This means that applications that are written against COM'S initial release can still work unchanged with today's enhanced COM standards. COM objects are not language dependent, rather they are written to the COM standard in common languages such as C++. Visual Basic and Java. Having this well-defined interface in a COM object is a big part of what has made applications in the Microsofl world so valuable. Multiple applications actually appear as the same program to the users and code can be downloaded to a browser providing a very standard way to distribute code to users, which is what ActiveX controls do. Another standard for distributed objects is CORBA (Common Object Request Broker Architecture). A consortium of software vendors and end users known as the Object Management Group is developing the CORBA standard. OMG member companies as well as other software applications vendors are developing commercial products that support these standards. CORBA provides the mechanisms by which objects transparently make requests and receive responses, as defined by OMGS Object Request Broker (ORB). Like COM, the CORBA ORB is an application framework that provides interoperability between objects, which are often built in different languages. While COM was initially just for Microsofi platforms the CORBA standard has been focussed from the start on the use of different machines in heterogeneous distributed environments. The overall architecture of this system is referred to as the Object Management Architecture. A look at plug and play geospatial applications It is the author's opinion that we are at the early stages of true Plug and Play applications that meet the definition that has been proposed herein. There are examples available today that are beginning to be meet the standard of Plug and Play. For this paper we will look at an outage management system and how it can fit the Plug and Play definition. A Plug and Play Approach to Outage Management. An electric utility's outage management system (OMS) is the application that receives a report of trouble, typically from a customer information system, and then analyzes the problem and provides the support services to identify the problem and dispatch the crew to the problem. These systems require extremely high availability, and they are integrated with other enterprise applications such as the Customer Information System (CIS), Interactive Voice Response (IVR) and Mobile Dispatch. Needless to say, these systems are a critical link in providing high-quality service for any utility organization. The original approach to these applications was typically to develop a custom system for each utility. The earliest applications were typically mainframe based, and they were written to meet the unique requirements of a given utility, even to the level of their electrical phasing. These systems typically had batch interfaces to the CIS and there was no direct relationship to the automated mapping database. As mini-computer based application products became available for OMS many of these problems were still not addressed and in some cases more complexity was added as the systems needed to be populated by a batch interface to the Geographic Information System (GIS) to receive the information about the electric network. The lack of a real time interface created a built-in problem of data currency. Data accuracy was a fundamental problem also since the GIS did not necessarily ensure that the data met the OMS application requirements for network connectivity and other elements to support data validation. Geospatial information technologies are now advanced enough that it is possible to solve many of the problem that have prevented making OMS a Plug and Play Geospatial application. Several problems have to be addressed to meet become plug and play. The fundamental problem is to have a database architecture that supports the different transaction models of an OMS. For example, the geospatial view, which is used to prepare the detailed database of the network with all the support for mapping, inventory and system engineering will be a long transaction database since it must support the nature of the engineering work and update process. The network model, which is used to provide a view for analyzing potential outages requires a short transaction database since it is changing nearly every minute based on events that are occurring during an outage situation. If these databases are not kept synchronous all the problems of improper data management due to multiple, unmanaged sources of data begin to reappear. This has been a fundamental limitation of the traditional GIS model. In addition to being able to bridge the transaction models it is fundamental that the network elements be represented with an object-based model. This object model supports the necessary relationships between the different systems, such as a one-to-one or one-to-many relationship between the systems. When this is included with the corresponding database triggers the systems can act as one unit so that custom application programming does not need to written to manage the data in the disparate systems. The last item worth mentioning is the use of table driven customization tools so that the models can plug into the geospatial data model and business rules for the given organization. This supports direct input of information about the business processes without having to do programmatic customization of the system that will need to be maintained as releases occur on the product. All these elements listed above provide a foundation for the support of the Plug and Play geospatial application model. Implementation periods have dropped from years to months to implement a system. And while the industry is getting closer all the time, the big question is, will we ever reach the ultimate goal of truly plug and play geospatial applications? Plug and play geospatials - Will we ever get there? This paper started by taking a somewhat skeptical approach to the concept of plug and play geospatial applications. While these applications have greatly improved in capability over the last ten years, the implementation of a complex geospatial application still is not a trivial process. Plug and Play application support provides a way to get the application up and running very quickly. It also reduces the impact of maintenance costs for the users, and overall, there is a significant reduction in the lifetime ownership costs of the system. The important thing that can't be forgotten however is that the reason for implementing the application still hasn't changed. Business rules need to be reevaluated, the system needs to be set up to support the advanced systems engineering considerations such as system fail-over support and hot back-up and recovery. All things considered Plug and Play applications allow the attention to be drawn away from long programming cycles and extensive maintenance, and the focus can shift to making the applications work to meet the needs of the business. Conclusion By our definition, Plug and Play geospatial sofiware applications are integrated computer programs that enable applications to run in an enterprise environment with minimal customization and integration work. Plug and Play applications plug independently into enterprise databases and spatial data models with communications supported via standardized, open protocols. Plug and Play geospatial applications are getting closer to reality. At the foundation of this is the need for a sound architecture that will support the system without having to deal with the underlying details of the data management systems for a given organization. The days of extensive custom programming to support the needs of the core geospatial applications for a company are beginning to go away. And maybe some day, it will be completely a "load-and-go" situation. Bibliography
| ||
|
|