Академический Документы
Профессиональный Документы
Культура Документы
Abstract XML and HTTP as AJAX does. Since AJAX and Web
Services are XML based structures they are able to
As the Web platform continues to mature, we see an leverage each others strength.
increasing number of amazing technologies that take
Geographic Information Systems (GIS) visualization AJAX uses HTTP based XMLHttpRequest protocol
applications to new levels of power and usability. By for the message transfers. Web Services use Simple
integrating new powerful technologies into GIS Object Access Protocol (SOAP) as a communications
systems, we get higher performance results with protocol. In order to be able to integrate these two
additional functionalities. The most recent different computing environments using different
development capturing the attention of the browser message protocols, we should have found a common
based application developers is AJAX (Asynchronous protocol or we should have converted the message
JavaScript and XML). In this paper we present a format from one protocol to another. Since there is no
generic and performance efficient framework for ready to use common protocol to handle messages
integrating AJAX models into the browser based GIS communications between AJAX and Web Services, we
Visualization Web Services systems. created a new framework converting message formats
from one computing environment to another which
1. Introduction integrates these two powerful technologies and obtains
the best performance results.
AJAX [3] is an important web development model for
the browser based web applications. It uses several This framework is designed for browser based web
technologies which come together and incorporate to applications using Web Services. It enables users to
create a powerful new model. Technologies forming utilize AJAX and Web Services advantages.
AJAX model such as XML, JavaScript, HTTP and
XHTML are widely-used and well-known. Google In this paper, we first give some background
Mapping is an example of a high performance AJAX information about the web technologies we have been
based application. using in our proposed architecture. These are basically
AJAX, Web Services, and GIS Web Services. In
Web Services [2] are self-contained, self-describing, Section 3 we mention some related works about the
and modular. Unlike earlier, more tightly coupled AJAX and Web Services. In Section 4 we first give a
distributed object approaches such as Common Objects generic architecture for integration of any Web
Request Brokers (CORBA), Web Service systems Services and AJAX. Then, we give sample usage
support an XML message-centric approach, allowing scenarios to prove our integration concepts; one of
us to build loosely coupled, highly distributed systems them is for Google and GIS Data Server (WFS)
that span organizations. Web Services also generalize integration and the other one is for Google and GIS
many of the desirable characteristics of GIS systems, Mapping Server (WMS) integration. Section 5 is about
such as standards for providing general purpose the future work and Section 6 is the conclusion.
specifications for publishing, locating, and invoking
services across the Web. Web Services also use
widely-used and well-known technologies such as
Client can use AJAX in her web applications just by Porting OGC services to Web Services will offer
writing her own custom JavaScript codes that directly several key benefits, including:
use the XMLHttpRequest protocol's API. At that time,
client should be careful of the coding and Distribution: It will be easier to distribute geospatial
implementation differences between different web data and applications across platforms, operating
browsers. Instead of using pure AJAX and dealing systems, computer languages, etc. They are platform
with the browser differences, client can use some and language neutral.
newly developed libraries providing higher level
AJAX services and hide the differences between Integration: It will be easier for application developers
browsers. Among these are DWR, Prototype, Sajax, to integrate geospatial functionality and data into their
and AJAX.NET. custom applications. It is easy to create client stubs
from WSDL files and invoke the services.
2.2. OGC GIS Web Services
Infrastructure: We can take advantage of the huge
amount of infrastructure that is being built to enable
the Web Services architecture – including development
The client browser makes a request to the server broker This generic integration architecture can be applied to
(via a JSP page), which in turn makes a request to the any kind of Web services. Since return types of each
Web Service by using previously prepared Web Web services are different and they provide different
Service client stubs. The response from the Web service API, you need to handle application specific
Service is then transformed by the service broker, and implementations and requirements in browser based
presented to the client browser. Below we will go in client side.
more detail to explain all these steps.
In Section 4.2, we prove the applicability and
First create an XMLHttpRequest object to make a efficiency of the proposed integration framework by
remote scripting call. giving two important usage scenarios in GIS domain.
- var http = new XMLHttpRequest();
4.2. Usage Scenarios
Then, define the end point as an URL to make a call. –Integrating Google Maps with GIS
The URL address should be local. This an intermediary Visualization Systems
proxy service to make appropriate requests for the GIS
Web Service. Integration is basically coupling AJAX actions with
- var url = “proxy.jsp”; the Web Services invocations, and synchronizing the
actions and returned objects from the point of end
Then, make a call to the local proxy service end point users. The usage scenarios in Section 4.2.1 and 4.2.2
defined above by the user given parameters. use the generic integration architecture illustrated in
- http.open (“GET”, url + ”?bbox = “ + bbox Figure 1. In the usage scenarios there will be minor
+…[other parameter-value pairs]……) difference in the form of extensions. Differences come
from the service specific requests created according to
proxy.jsp is an intermediary server page to capture the service provider’s service API (published as
request (HttpServletRequest) and response WSDL), or handling returned data to display on the
(HttpServletResponse) objects. Proxy JSP includes just screen. But these are all implementation differences.
one line of codes to forward the HttpServletRequest
and HttpServletResponse parameters coming from the 4.2.1. Google’s AJAX Integration with WMS: There
first page via XMLHttpRequest protocol. are two different path working in parallel by the given
- jb.doTask(request,response) user parameters created by the client actions. Actions
are interpreted by the browser through the Google
“request” and “response” parameters come from the Mapping tools. JavaScript captures these actions by
user interface page. This first page includes some ActionListeners and Google Binding APIs and gives to
JavaScript, XHTML, CSS and JSP to capture the user Layer-2 object. Please see the Figure 2.
given parameters and to display the returned result on
the screen. On the browser user interface class is a JSP page. It
includes two JavaScript class-references. One is for the
“jb” is a java class object which handles creating Google Map object and the other is for the WMS map
appropriate requests by using its request-response image and bindings to the Google Map object.
handlers and Web Service client stubs. Request-
response handler also handles receiving and parsing Interconnection for creating Layer-2 is done in
response object coming from GIS Web Services accordance with the proposed architecture defined
interacted with. above in Figure 1. For Layer-1, a classic Google
mapping application is used through the AJAX web
After having received response from the GIS Web application module and XMLHttpRequest protocol.
Service, “jb” object sends the returned result to Google handles creating the map by using
XMLHttpRequest object in the first page. XMLHttpRequest and given remote JavaScript file in
- PrintWriter pw = response.getWriter(); the browser [4].
- pw.write(response);
When we use this type of interaction interface to
WMS, we can utilize all the OGC compatible
Figure 2: Integration of Google Maps with OGC XMLHttpRequest uses DOM for parsing returned
WMS by using architecture defined in Figure 1. structured responses in XML. If returned data is
oversized for the server then the DOM parser throws
“Out of Memory” exception. In order to overcome this
4.2.2. Google’s AJAX Integration with WFS: WFS drawback of the DOM and Google Map, we have used
provides feature data in vector format and vector data Pull Parsing [19]. After parsing and handling GML
are encoded in GML according to OGC WFS documents returned from WFS, the result is written
specifications and depending on the parameters given into the web browsers response object. Through the
in the “getFeature” request. GML is an XML encoding responseXML call of the XMLHttpRequest in
for the transport and storage of geographic JavaScript, the browser gets the result and makes
information, including both the geometry and appropriate modifications to the data and display on
properties of geographic features. the screen.
In response to the “getFeature” request, the GML file XML Pull Parser is a recent development that
encoded in XML is returned in a SOAP envelope as a demonstrates a different approach to XML parsing. It
response to this request. After getting a response, the does not provide any support for validation. This is the
client extracts geometry elements. The most important main reason that it is much faster than its competitors.
and commonly used geometry elements are Points, If you are sure that data is completely valid and
LineStrings, LinearRings, and Polygons. GML is an validation is done at the server side (as in our case) or
OGC standard for feature data representation. in a database, then using XML Pull Parsing gives the
highest performance results. In our usage scenario
Even though Google Mapping API supports just two of explained above, data comes from the OGC compatible
them, Points and LineStrings, the other geometry data server (WFS).
elements can also be converted to these two types with
minor updates. Having extracted and obtained This parsing approach is called pull parsing because
geometry elements, these elements are plotted over the the parser only parses what is asked for by the
Google Map by using “GPoints” and “GPolylines” application rather than passing all events up to the
[1] OGC (Open Geospatial Consortium) official web site [17] Sayar A., Pierce M., Fox G., “Developing GIS
http://www.opengeospatial.org/ Visualization Web Services for Geophysical
Applications” ISPRS 2005 Spatial Data Mining
[2] Booth, D., Haas, H., McCabe, F., Newcomer, E., Workshop, Ankara, Turkey.
Champion, M., Ferris, C., and Orchard, D. “Web Service
Architecture.” W3C Working Group Note, 11 February
2004. Available from http://www.w3c.org/TR/ws-arch [18] EcmaScript web site http://www.ecma-
international.org/
[3] Jesse James Garret, Ajax: A New Approach to Web
Applications. [19] XML Pull Parsing web site http://www.xmlpull.
http://www.adaptivepath.com/publications/essays/archives/0 org/
00385.php