GIS meets e-Business: Using standardized components interfaces to build distributed e-Business Applications more efficiently
Roland M. Wagner Fraunhofer Institute for Software and System Engineering (ISST) Berlin/Dortmund Emil-Figge-Strasse 91, 44227 Dortmund, Germany E-Mail: Roland.Wagner@isst.fhg.de Abstract With the great success of introducing the OGC Web Map Server and the OGC interoperability activities, the GIS world moves towards easy and quick availability with Web Services. The ISO 19115/19 Metadata standards describe geo-information content and services. More Services are being developed. But how do all these different components fit and work together in the real world? Some experiences to solve this question could be gain by designing and developing a distributed Geo-eBusiness web application for a German State in a team of three OGC members. The main guidelines of the contracting body for the design was to use as many suitable standards and recommendations as possible. This approach opens a quick and efficient perspective to design the application. On the other hand some new strategies are required above today’s standardized components to solve resulting problems, e.g. multiple data storage, ID scopes, causalities or installation processes. Therefore, the handling of designing in teams, interoperable interfaces, development in teams in a distributed environment, usability and maintenance are covered in detail in our paper. These aspects are described from different point-of-views e.g. developer, provider and user. Introduction Since a long time, the public administration collected geo-referenced data for their purposes. The Romans military knew their road network and the distances. But this information was also relevant for private trade organizations to plan their business in that time. Maps were published und distributed. Today, the digitalization of public geo-information is more or less terminated. The digital geo-data is being used in public and private GIS for many purposes. Therefore digital processing is used for creation, integration and manipulation of geo-referenced data in a broader use since beginning of the ninety’s. As in former times, the private sector needs the public geo-referenced information but today as digital data for their purposes. With the introduction of the Internet World Wide Web protocol and at the end of the ninety’s wide bandwidth communication was achieved, which is the technical precondition for digital on-demand distribution for high volume data. Other business and juristic questions of e-commerce could be solved in the meantime. That opens a new perspective for marketing, ordering and delivery. Task Public and private geo-data is being created and hosted in many offices with different purposes and organizational structures at different locations with different technical equipment. Therefore ”interoperability” is a key issue for trading public data. The approach of a German state was to use all suitable recommendations and standards for its e-business project to achieve interoperability and for future improvements. On the other side, the solution need to cover all known everyday requirements. Intention An online distribution of geo-referenced data should cover all digital and analog products, which are many ten-thousand items in the case of a state mapping agency or a large data provider, which requires corresponding software and hardware solutions. Specialized data-server components are necessary, because of the wide range of different kind of products. Other components are required to cover search-, security- and pricing & ordering-aspects. These components are provided by several manufactures and with different software characteristics. All these components need to be integrated and used in two main workflows:
1 Metadata-Information System (MIS) Search and retrieval of geo-referenced information is essential especially in distributed environments. The OpenGIS Consortium and the ISO are working on catalogue specifications and have released the ISO 19115 specification for meta-data. A suitable OGC approach for a web service interface is the draft Web Registry Service (WRS) catalog specification. Although the web service interface is being still discussed, the main approach is sufficient for many tasks. 2 Web Mapping Service (WMS) In April 2000, the OpenGIS Consortium released the WMS specification for bitmap geodata. This popular light-weight standard is very suitable for (geo-) graphical navigation and selection in standard www-browsers. There are several products available. 3 Web Pricing & Ordering Service (WPOS) The WPOS 1.0 specification was released in November 2001 as a result of the regional GDI NRW Testbed I in Germany. It covers all geo-domain specific e-commerce functionalities. It considers the domain-specific complex pricing models. Business price models can be represented and in digital and generic manner in the XML complex Configuration & Pricing Format (XCPF). The specification was designed along the OGC basic service model. 4 Web Authentication & Authorization Service (WAAS) This security service covers the aspects of authentication and - protocol-specific - the authorization of service requests in distributed environments. It may use other common security mechanism like SAML, SSL/Basic Realm or other. The service was developed, implemented and tested in the GDI NRW Testbed II in 2002. The specification was designed along the OGC basic service model. 5 Geo-data Management Service (GDMS) Geo-referenced data can be handled and stored in many different representations with different abilities. Therefore specialized servers are used depending on the requirements. In the case of a Geo-eBusiness application, all these different servers need to be integrated and accessible. Many servers have a relative simple web interface for external usage. But the encoding of the interface is different from server to server. The OGC web mapping service (WMS) uses the popular approach to integrate data streams with cascading. This mechanism is well described in the OGC WMS specification. The GDMS takes a similar integration approach, but with an encoding “wrapping” and, in a simple implementation, only an integration of data files in compressed package files for delivery. Therefore the GDMS is an abstract service, which integrates many wide used geo-data servers with the advantage of a single interface. The specification was designed, developed and implemented by the Fraunhofer ISST in a Geo-eBusiness project and will be published. Approach Chapter 3 describes the requirements, the desired functionally and components for a GeoeBusiness solution. It mentioned as well the main workflows. Traditionally the front-end purchaser workflow is being discussed entirely. On the other side, the maintenance workflow is important to set up and to maintain the integrated system. The assumption that the maintenance workflow is “simple” and “secondary” may end in unwanted constructions. Therefore and because of experiences, the maintenance workflow will be described first and in detail. The front-end and the purchaser workflow is much more intuitive. 1 The back-end with the maintenance workflow This workflow has to cover the changes in the system. That may be quite simple in the case of a few products. But in the case of 35.000 product items, the maintenance is crucial for the success of the distributed platform. The integration of several components into an application requires some general rules. The unique identifier or “ID” for a product item would be the most known general rule. ![]() Figure 1: Maintenance Workflow But which component defines it? Is it instantly valid and known in all other components? Are there some sequence arrangements necessary? These questions may be expressed on an abstract level as “the causalities of data streams”. A skillful arrangement of these streams has the advantage of elegant, light-weight interfaces and in some cases the ability to automate processes and therefore to reduce manual maintenance efforts. Light-weight interfaces are curial in the case of “black box” components from different suppliers. Products can be assigned to a product groups to combine similar characteristics. That provides an easier overview and prevents in the case of series massive data redundancies. In fact, in the case of a Geo-eBusiness portal, each product consists of a dataset with geodata, meta-data and pricing- & ordering-data subsets. Different components are specialized for the required workflow steps and need these data item subsets. From a methodical point of view, the primary data-set is the geo-data file. All other data sub-sets are directly depending on the geo-data file. Of course, not all data entries, e.g. provider address or price model, can be derived by the geo-data file, but the important often-used parameters like bounding polygon, layers or formats could. These technical parameters can be processed (and updated) automatically within the integrated components, which decrease maintenance efforts. Figure 1 shows this approach from an architectural point of view. Several servers provide their capabilities in a XML format. The capabilities contain geo-datasets and their configuration parameters, e.g. layer, data formats and geographical extent as simple data types, organizational structures like product groups and short descriptions, IDs. The GDMS “wraps” in the second step the server specific encoding of the capabilities into an abstract representation. Additional organizational structures may be added at this level. Co-ordination-transformation may be used to convert data entries into a unique measurement system. The MIS editor may import in the step 3 organizational data, like product ID’s, product group ID’s, geographical extents, formats,…The XCPF editor, which creates the WPOS price models (XCPF), can use the same GDMS interface to import the organizational structures, configuration parameters, which are often relevant for pricing, but are always relevant for the product configuration. The needed interface between the MIS-Client and the WPOS-Client can be reduced to the unique product ID for the user-selected items. The other great advantage is the easy visualization of important parts of the GDMS capabilities, e.g. with a simple XSL style sheet. This visualization may be done as a simple product tree to offer professional user a direct link to pricing & ordering for known products. In this short listing, three applications use this interface. In a more complex chaining of services, this data source interface is even more important. After this workflow, the integrated system is being set-up to be used by purchasers. 2 The front-end with the purchaser-workflow Chapter 3 describes the requirements for a front-end workflow. Therefore the used components need to be arranged and integrated. A purchaser will be directed through the integrated system by using the information pages and service-clients provided by the software component suppliers. A purchaser may use two procedures to define the products for pricing & ordering. For new user, occasional or non-professional user, the catalogue offers a wide functionality to searched by keywords, by a geographic bounding box, by categories, by names and other attributes. The result is a hit list with all available products. If the purchaser already knows the product by a product name, he may move forward directly via a product tree listing of all products to the pricing & ordering client. Figure 2 shows the sequence. The step 3 in this figure contains the pricing functionality. Because of security aspects, the WPOS is being protected by the WAAS security service. The price information requests (getpriceModel and getPrice) can be access anonymously. But authentication and authorization are required for the ordering and on-line delivery requests. ![]() Figure 2: Purchaser Workflow Behind this functionality, some technical mechanisms are required. The web front-end is separated with a permanent general menu frame for navigation and a main frame for each processing step. The portal frames are providing session-IDs to solve the state-less WWW-protocol problem. This long session-ID is the first general parameter, which be will delivered and received by all component web client. With the session-ID mechanism, the user may jump at any time from a component to another component and back. The integration of the components is realized by a chaining of clients. These request the right service. The interface from the MIS-client to the WPOS-client can be defined as a standard HTTP get Link containing a list of product IDs. onclusion and Outlook Designing Geo-eBusiness applications with public component interfaces have several advantages. OGC, ISO and GDI NRW specifications are aimed to achieve interoperability and easy enhancement capabilities. The importance of a single interface for the geo-data access and for depending workflows was identified in a Geo-eBusiness project and described here. There is a need for that specification. Therefore it will be analogues documented and published as other specifications. References De La Beaujardière, Jeff, 2001: Web Map Service Implementation Specification 1.1.0 , Open GIS Consortium Inc. (http://www.opengis.de). OGC Web Registry Service, Draft, Open GIS Consortium Inc. (http://www.opengis.org). OGC Basic Service Model, Draft, Open GIS Consortium Inc. (http://www.opengis.org). Wagner, Roland-M.; Gabriel, Peter; 2001: GIS meets e-Commerce: Pricing for Geodata in a Distributed Environment. In Proc. of DigitalEarth 2001 Conference, Frederiction / Canada. Wagner, Roland-M; 2001: Web Pricing & Ordering Service Implementation Specification (WPOS), Fraunhofer Institut für Software- und Systemtechnik (ISST), Dortmund, Germany, October 2001. (http://www.isst.fhg.de ), Version 2.0 expected for end of 2002. Web Authentication & Authorization Service (WAAS), Draft, GDI NRW c/o Fraunhofer Institut für Software- und Systemtechnik (ISST), Dortmund, Germany, (http://www.isst.fhg.de), Version 1.0 expected for end of 2002. | ||
|
|