Developing a GIS Web-Service using .NET Technologies Pouria Amirian, Ali Mansourian Faculty of Geodesy and Geomatics Engineering, K. N. Toosi University of Technology, Vali-e-asr St., Mirdamad Cross, Tehran, Iran, P.C. 1996715433 Email: p_amirian@hotmail.com, b mansourian@kntu.ac.ir Abstract Nowadays, Internet GIS has been the most rapidly developing domain in the geospatial technology industry. In the GIS world, same as other IT related disciplines, the Internet and its applications, particularly the World Wide Web (WWW), make transfer of data, software and services much more easily than ever before. So, due to the high potential of Internet and Web, many different Web mapping software packages have been provided by different GIS software vendors. Although GIS software vendors are trying to increase the Geo spatial data accessibility with their software, but interoperability still is main issue in this domain (Peng 2004). One of the aspects of the non-interoperability of the current internet GIS software is the access interoperability issue; Service on the particular GIS server can only be accessed by its own clients and other clients (clients of other GIS servers) cannot access services of that server. The reason of this problem is due to this fact that different internet GIS solutions, utilize different technologies, which are not able to interact and interoperate with each other directly. This problem can be solved with Web service technologies. Since Web services are based on open standards they can provide interoperability in network environments such as Web. In addition to providing interoperability, they can be created by using any platform, operating system, programming language and object model. In general, Web services improve internet use by enabling program to program communication. Through the widespread adoption of Web services, applications at various internet locations can be directly integrated and interconnected as if they were part of a single, large IT system (Cerami 2002). More accurately, Web services represent a new approach to distributed architecture, one that favors simplicity, best design practices, and cross-platform use over raw communication speed (Newcomer 2002). With the high potential of these new technologies, GIS community can overcome the mentioned problem with current Internet GIS software. This paper intends to deal with the main components of a GIS Web service, responsibilities of each component and finally demonstrates the GIS Web service concept by developing a prototype GIS Web service based on Microsoft's .NET framework. Introduction In the GIS world, same as other IT related disciplines, the Internet and its applications, particularly the World Wide Web (WWW), make transfer of data, software and services much more easily than ever before. Individuals, universities, organizations and companies use the Web as a main infrastructure to publish spatial information, offer or consume GIS services and in some rare cases to conduct a complicated GIS processing. Currently the primary model on which the Web is operate, is based on human interactions. In the other words, the most of interactions are between Web browser and Web server. For example, user can use his Web browser to connect to the Web server which offers some kind of GIS services. Without considering the details of various technologies that enable interaction of user with map server, the user interact with the GIS map server through the Web page which is displayed on his Web browser. This level of interaction is fine for many purposes. So, due to the high potential of Internet and Web, many different Web mapping software packages have been provided by different GIS vendors. But each Web mapping software, utilize different technologies, which are not able to interact and interoperate with each other directly. For this reason, Service on the particular GIS server can only be accessed by its own clients and other clients (clients of other GIS servers) cannot access services of that server. On the other hand, application-integration is not supported with current Web mapping software. Today, GIS developers can't combine specific services from different Web mapping software, and use them as building block of an integrated GIS application. These problems arise because of this fact that, Internet-based applications need to be able to interact with other internet-based applications as easily as interactions between Web browsers and Web servers. But the essentially text-based Web dos not support software interaction very well. A more efficient method is needed to allow applications, interact directly with other applications to automatically and without human intervention, executing instructions that would otherwise have to be entered manually through Web browser. But the main barrier in front of application to application interactions is the interoperability. The following sections will briefly introduce the concepts of Web services and GIS Web service as well as how Web services can overcome the mentioned problem. Web services and GIS The Web as it exists today is intended for human consumption. Consequently, data is presented in a form that is human-readable, but this form of representation is error prone and difficult for applications to examine, extract and use both, automatically and programmatically. So there is a need for application to application communication and this is the idea of application-centric Web rather than human-centric Web (The Web as it works today). An application-centric Web is not new concept. For many years, developers and programmers have created and used CGI and CGI extension programs (such as Java servlets modules, ASP, JSP and Cold Fusion Web applications and so on) for communicating between different applications. But most of these systems were used as a part of tightly coupled business solution and they can't offer service to other business solutions. Web services are about delivering distributed applications via programmable URLs. Web services are eXtensibe Markup Language (XML) applications mapped to programs, objects, or databases or to comprehensive business functions (Newcomer 2002). Using an XML document in the form of a message, a program sends a request to a Web service across the network, and optionally receives a reply also in the form of an XML document. Web services are based on open standards, so they can provide access interoperability in network environments such as Web. In addition to providing access interoperability, they can be created by using any platform, operating system, programming language and object model. More precisely, Web Services are loosely coupled, self-describing services that are accessed programmatically across a distributed network, and exchange data using vendor, platform, and language neutral protocols (Marks and Werrell, 2003). Therefore, Web services are the main candidate for GIS application integration and implementation of truly distributed GIS solutions. GIS community can take advantage of this technology to make flexible, interoperable and scalable applications. As illustrated in figure 1, different software vendors can publish their own GIS services on the Internet and advertise it through standard mechanism (Service publishing and discovering mechanism). At the other hand, GIS developers can find and use one or more available GIS Web Services to use as building blocks for creating integrated GIS application, based on user requirements. By integrating different GIS Web services from various GIS servers, and use them as building blocks, GIS application is capable of access to user resources as well as different GIS server resources.  Figure 1: GIS Web service In addition to application integration and ability to providing GIS functionality, The Web services architecture establishes a particular type of relationship between service providers and consumers of information that supports the integration of spatial data. Web service architecture Web services are a fundamentally new framework and consist of set of standards for supporting network transportation, service communication, service publication and service discovery. In some cases Web services considered as a new architecture for software systems architecture. On account of, Marks and Werrell (2003), today the new paradigm for software system architecture is emerged. Software system architecture evolved form monolithic mainframe systems to diverse architectures of client-server to distributed systems to service oriented systems which have been implemented using Web service architecture. There are three major roles or components within the Web service architecture (here the word component is differs from similar word in the programming terminology). As illustrated in figure 2, major components in the Web service architecture are service provider, service requester and service broker.  Figure 2: Web service architecture This figure shows that service providers publish their service(s) with the registry repository of a service broker. Then, a service requestor initiates a search for a service by contacting the service broker and searching the registry repository for services that meet specific search criteria. The broker returns a list of services along with details of the associated provider for each service. Up to this point, the service requester has found the desired service(s). Subsequently, the service requestor binds with a selected service provider(s) based on the provided details of registry repository and consumes them. In the mentioned scenario, there are series of standards and protocols which enable communication, description, publication and discovery of Web services. Figure 3 introduce the Web service protocol stack (Mark and Werrell 2003):  Figure 3 :Web service protocol stack The standard mechanism for publication and discovery of Web services is UDDI (Universal Description, Discovery and Integration). UDDI provides a logical centralized registry repository of Web services. The UDDI registry repository allows service providers to publish their services by using another standard called WSDL (Web Service Description Language). At the other hand service requesters can find desired services through searching in the registry repository. Based on the contact specification which is provided by service provider (it can be the WSDL document(s) or simply an address of a URL), service requester can make a communication link to the Web service and consume it. For sending requests and response, Web service architecture can take advantage of different network transport protocols (such as FTP, HTTP, SMTP, BEEP and so on). As mentioned before, Web services are new technologies and for this reason they are not mature. So as Web services evolve, additional protocols maybe added and different technologies and functionalities for supporting network security, confidentiality, authentication and so on, added to each layer (Cerami 2002). In the nutshell, all of technologies for supporting service communication, service description, service publishing and service discovery are based on XML. So due to characteristics of the XML, Web services are not restricted to any platform, application and programming language. Implementation Its fair to say Microsoft initiated industry focus on Web services, and Web services support is perhaps the most significant aspect of Microsoft .NET, a broad-based initiative through which a variety of products is being developed and delivered to market (Newcomer 2002). In addition to Microsoft, some other major players in software and IT systems such as IBM, HP, Ariba, SAP, IONA, joined Microsoft to develop and support various standards and protocols of Web services. In order to demonstrating the concepts of Web services, the Microsoft .NET platform was used. In addition to Web service protocol stack, Microsoft provides new protocol called DISCO which provides the ability to dynamically discovering a web service through Microsoft .NET platform. In Figure 4, the work flow of finding and binding a Web service and consuming Web service as well as protocols which are used in each step is illustrated.  Figure 4: Microsoft .NET Web service protocol stack For implementing a prototype Web service, Visual Basic.NET and Microsoft SQL Server were used. Also, the prototype is just a simple application, but it can be used as starting point for implementing the National clearinghouse. In addition, it can be modified to get compatibility with OGC implementation specification such as WMS (Web Map Service), WFS (Web Feature Service). Figure 5 shows architecture of the prototype system. In this prototype the service provider is logically centralized but physically distributed database of spatial metadata. In other words, it has been assumed that there are different metadata custodians that each of them provides a Web service for accessing to their metadata. A federated Web service is written for accessing and consuming all of the metadata Web services, through the provided interfaces. This federated Web service acts as a service requester for metadata Web services and as service provider for any consumers. Each consumer can bind to this federated Web service and request metadata through provided methods of finding metadata. For client-side consumer a windows application and a Web application were developed. In both applications, user can select the desired geographic area to request available metadata from diverse sources.  Figure 5: Implemented prototype Conclusion Web services are a fundamentally new framework for supporting distributed computing in environments like internet. Also, these set of standards provide truly open platform that is not tied to any operating system, middleware system and programming language. GIS community can overcome different problems associated with current Internet GIS software by utilizing these technologies. The Web services are the foundation of new type of interaction: application to application interaction. In the GIS world, to fully take advantage of spatial data and processing power of GIS software, spatial data need to be shared and systems need to be interoperable. GIS fundamentally involves the integration of spatial data from multiple sources. The Web service architecture establishes a particular type of communication between service providers and service consumers. This kind of communications could support share and integration of spatial data from a technical perspective that is an important goal of establishing SDI (Spatial Data Infrastructure). However, there are still many issues to be resolved. The Web service technologies are all new and GIS demands its own requirements. Therefore, more research and experiments are needed to evaluate these brand new technologies. References
|