Providing web services with legacy GIS
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.
The Basic Idea
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.
