| GISdevelopment.net ---> GITA 2003 ---> E-Biz |
Providing web services with legacy GIS
Prof. Dr. Dieter Keller
SHH GmbH Fritz-Müller Strasse 107
D-73730 Esslingen
Telephone: +49 711 31508-109
E-mail: keller@shhinfo.de
Prof. Dr. Dieter Keller
SHH GmbH Fritz-Müller Strasse 107
D-73730 Esslingen
Telephone: +49 711 31508-109
E-mail: keller@shhinfo.de
Abstract
Most of today’s GIS-work has to do with viewing, analyzing especially filtering and updating previously collected data. In other words the data that is already available in most cases, but captured in legacy systems, that are tied to the desktop or to LANs in a classical two tier architecture. But the data has to be made accessible to a broader audience in order to yield its real asset. The Internet especially its WWW service offers new techniques of integrating different systems containing different data in the form of unique web services. The paper describes a modern flexible and inexpensive three-tier system architecture wrapped around an “old” legacy system architecture. Key technologies like CORBA and J2EE are discussed in the context of this modern architecture as well as the usage of XML based SVG graphics and the role of the OpenGIS intermediate format GML. But all those technologies don’t make much sense, if there is no clear business model behind them.
The Utility-It-Environment
NIS [Network Information Systems] are special representations of GIS [Geo- Information Systems]. One popular application of NIS is the support of business processes in utility companies. A utility company runs into serious problems if the support task for kernel business processes is not sufficiently fulfilled anymore. For this, there can be the following reasons:
- The business processes changed and are not represented correctly in the NIS
- The technical basis of the data processing system is not supported by the manufacturer anymore.
- The customers acceptance of the system is too small.
- New technical evolutions offer considerably more efficient solutions in modeling of the business processes.
- The knowledge monopoly of individual employees is a bottleneck; it causes the dependence on people.
- Changes of the legacy system lead to unexpected side effects and are responsible for the general attitude: Never change a running system.
- The maintenance costs are high - compared to the corresponding improvements.
- The system has a high failure rate - the failure rates can be caught only through few employees.
The NIS Legacy System
In the following chapters our own legacy NIS will be used as an example for the constant evolution that will finally lead to Web Services. Fortunately, our legacy NIS, Paris, has to fight comparatively little with problems of the above mentioned kinds since it is still relatively "young". When the product was shipped for the first time in 1997, it was a typical desktop NIS with a CAD frontend (MicroStation) and a local data container (MS-Excel). Already 2 years later, the product changed and was shipped as a fully equiped client/server NIS using all advantages of this technology in a Local Area Network [LAN] environment. An outstanding feature of the legacy system can be described best by “Modelling instead of Programming". In other words the NIS offers a simple object-oriented modeling (including inheritance) which is based on an integrated GIS databasearchitecture. In the utility sector usually inflexible industry-specific shells are used for approaching business processes. Instead of this, our legacy NIS offers a flexible object modelling that directly adapts to business processes. As a starting point for an object modelling process, object libraries for electricity, gas, water, waste water and long-distance heating are provided, so object modelling never starts from the scratch. When switching to the client/servers architecture a new software layer was established, that allowed almost every relational database system to be connected with the NIS (Oracle, DB2, Interbase etc.).
From the NIS point of view the legacy system supports currently most of the business processes of utility-companies. Office-tools are simply integrated and the connection to other programs can be simply realized by data exchange. But the liberalization of the markets goes hand in hand with company fusions high/dynamic changes in the IT. The future will bring a lot of changes.
The Final Goal
The ambitious goal of future development is the optimal and flexible integration into businesswide business processes modelled in a WAN [Wide Area Network e.g. Internet or Intranet] (Interoperability in a distributed computer environments) on the application level (Enterprise Application Integration [EAI]) under consideration of third party legacy systems.
So, our legacy system should have to go for the Internet/Intranet and should be able to couple elegantly with available third party systems on the application level. Thus, the future NIS should be able to make common services available for an enterprise portal. The coupling of systems via data exchange is outdated and does not correspond to the expectations of the customers in the future. Ideally, the above mentioned services would be personalized, that is every person gets his specific work environment. When realizing the above ideas, we enter unnoticed the ebusiness market, because we establish C2B [Customer to Business] and B2B [Business to Business] connections via the WAN. Last but not least we are forced to provide an accepted payment model for our services.
Realization with Web Services ?
Reading the definition of the final goal, software people directly see the affinity to Web Services. Since Microsoft´s admission of the SOAP [Simple Object Access Protocol] specification (1.12.1999) to the Internet Engineering Task Force [IETF], Web Services have not disappeared from the IT newspaper headlines. Although the definition of the term “Web Services“ consolidates more and more, it is not yet clearly defined (Micosoft itself offers some possible definitions). A possible Web Services definition (at the time of starting the evolution of the legacy system) can be:
"A web service is a network accessible interface to application functionality, built using of standard Internet technologies. " (Snell et. al., 2002) In other words, if an application is accessed via the Internet/Intranet with protocols such as HTTP, XML, SMTP or Jabber we name it a Web Service.
Switching to a new software architecture
Additional Requirements
During the conceptional phase some additional requirements occur, namely:
- As far as possible no usage of software modules that have to be licensed, especially to avoid dependencies in pricing.
- Portability: all applications must be operating system independent.
- Preserving the previous fields of application and simultaneously development of new fields of application (in particular in the field of the alphanumericalclients).
- Taking care to GIS standards (OGC) and at the same time preserving the strength (e.g. the highlights) of the client/server NIS.
- Not only reduction of the the NIS acquisition costs, but also of the entire customer costs (Total Costs of Ownership [TCO]), in particular the maintenance costs of fat clients of the legacy system.
In a first step the legacy system is supposed to be expanded by an online informationsystem. A flexible base-technology is developed to design alphanumerical screens that are part of customer use cases. These screens are supposed to be suited for the fat-client legacy system and the online informationssystem as well. Using a special technique the alphanumeric screens allow the connection and the cooperation with different CAD systems. For editing graphical changes additionally a web based graphics editor is provided that works perfectly with the alphanumerical screens. In a last step the applications are provided in the form of a Web Service to yield flexible Enterprise Application Integration [EAI].
Realization of the first Steps
Contrary to the NIS legacy system (two-tier architecture), the looxx WEB online informationsystem is based on a three/tier architecture. The additional tier comprises middleware. Some authors (Orfali, Harkley, Edwards, 1999) designate middleware as the diagonal stroke in the client/server concept. Generally middleware is communication software, designated to connect distributed applications.
On the client-side a computer with operating system installed and standard browser is sufficient. To display vector data inside of the browser a freely available plugin from Adobe (http://www.adobe.com) is used. The file format used by the plugIn (SVGViewer), the Scalable Vector Graphics [SVG] format was developed especially for the Web and offers certain advantages compared to non web graphics formats.
In order to guarantee an extensive independence of the operating systems, parts of the Suns J2EE [Java 2 Enterprise Engineering] architecture are used for the realization of the online informationssystem. In addition other Open Source software is used. Further components of the online informationsystems standard middleware are a web server and a servlet engine (Tomcat). In principal the application works together with every web server (Apache, IIS etc.).
User interfaces can be designed by the usage of the xhtml-format. Afterwards they are postprocessed by converting them to JavaServer Pages [JSP] and adding specific libraries, the Paris TagLibs. The TagLibs expand the standard xhtml-tags with respect to specific GIS/NIS functions. Basically the TagLibs provide Corba calls (defined in the Interface Definition Language [idl]) of Paris Data Services Layer within a JSP. In this way data of the legacy system can be published in a powerful way. Additionally, a separation of presentation and business logic is achieved. Using the TagLibs, use cases and workflows can be modelled and represented quickly on the screen. The TagLibs can be understood as a kind of macro language. The graphics can be linked into a JSP with the aid of the TagLibs at any time. It is easy to extend the Paris TagLib with other TagsLibs provided by the Open Source community or somebody else. For example, a TagLib to access a third party external database via JDBC [Java Database Connectivity] can be added by copying one single Java ARchive [jar] file.
With CORBA [Common Object Request Broker Architecture] another interface is added to the middleware. This interface yields a clear separation of the client/serverfunctions of the legacy system. It provides access onto the Paris Data Service Layer and the legacy data respectively. It also provides additional possibilities of links to other systems (for example SAP, Smallworld etc.), that are already tested. In addition the different programming languages of the web-application (Java) and the legacy system (C/C++) are matched elegantly with the language independent CORBA-interface description language [idl].
In the Data Service Layer all functions that allow access on the flexible data structure of the legacy system and all functions that preserve data consistency can be found. In this layer, the object-relational mapping is carried out too. Network tracing functions (Net Tracing, Connectivity) and functions that represent graphics depending on the scale (Adaptive Scaling) are also provided by this layer. Additionally part of the major layer is an abstraction layer, that allows the connection to relational databases of different vendors.
The generation of graphics output from the database is located here. Currently the graphics formats DGN and SVG are supported. GML can be exported as well. The Geography Markup Language [GML] is a XML related markup language defined by OpenGIS Consortium [OGC]. With the availability of GML, simple data conversions (with XSLT, a simple standardized XML markup language, suited for conversion and styling) into different GIS/NIS are possible. Because GML date conversion can be done on the fly, a data interface is provided for third party systems on the application level.
The first web services
Features and Use Cases of the Online Informationsystem The design of the online-informationsystem should be simple and configurable and should provide the following features:
- Logon (a logon to the client/server legacy system, not just a logon to the Web- Server)
- Project-Management (assignment of user(s)/group(s) to projects)
- Choosing and opening different project views (a general overview using generalization and adaptive scaling features; fast display of view areas with 500 kB in size)
- Query By Example (QBE) functionality for SQL like queries on objects
- Presentation (e.g. display) of a-numeric data, that is previously filtered by QBE
- A configurable Quicksearch option for fast object retrieval and display (graphical and alpha-display).
- Presentation of vector data in themes, layers and (object) groups
- Presentation of (geo-referenced) background raster data in jpeg/png-format
- Assignment of vector- to alphanumeric data and vice versa (using events to assign and highlight the corresponding vector- and alphanumeric data)
- Textsearch in vector graphics
- Legend attachment and plotting by maintaining scale-settings (without rotational settings) as well as dynamical PDF-Printout
- Linear measurement function and area calculation function (e.g. square meter calc.)
- Rudimentary e-business functions
- Alphanumeric data display and selection of data
- Quicksearch and location service of objects
- Display of graphical data
In the screen shot we can see the "administrational " use cases of the project and view selection, as well as the practical use cases of the utility companies. With the button Special it is suggested that there are simple extension possibilities for customer defined use cases.
According to the present opinion it does not make any sense, to provide Web Services in the form of individual, small functions. It will be easy to provide all the Corba interface functions (as Remote Procedure Calls [RPCs]) to the audience. A function like GetNumberOfObjects () can have a very high asset in the Corba layer, but as a Web Service it increases the complexity of the Web Services interface. Despite of the fact that the granularity of Web Services is not yet touched, we plead for an interface on application level. Corba-functions can be combined in an additional layer (JavaBeans). On such a level we are also able to implement the functions "GetMap" and "GetFeatureInfo" defined by the Open GIS Consortium [OGC] (OGC, in 2002).
Preview
At the time of writing this article, a Web Service is a platform and implementation independent software component that can be
- described using a service description language (e.g. the Web Service Description Language [WSDL]),
- published to a registry service (e.g. Universal Description Discovery and Integration [UDDI]),
- discovered though a standard mechanism (at runtime or design time),
- invoked though a declared API (e.g. Simple Object Access Protocol [SOAP]),
- Composed with other services (Graham St. et. al., 2002).
Despite of the fact that the online informationssystem makes no use of SOAP, the last two items are fulfilled. Starting with JSP/Taglib defined alphanumerical pages/screens and a graphical view we are working on the support of the new definition of Web Services and on the next two features
- Edit of alphanumerical data and
- modification of graphics (graphical editor).
References
Graham St., Simeonov S., Boubez T., Davis D., Nakamura Y., Neyama R. (2002): “Building Web Services with Java”, SAMS Publishing
OGC (2002): “Web Map Service Implementation Specification“ Orfali R., Harkey D., Edwards J. (1999): "Client/Server Survival Guide - Third Edition", John Wiley & Sons
Siedersleben J. (Ed.) (2002): “Software Technik – Praxiswissen für Softwareingenieure“, Hanser
Snell J., Tidwell D., Kulchenko P. (2002): “Programming Web Services with Soap“, O´Reilly & Associates Inc.