GIS meets e-Business: Using standardized components interfaces to build distributed e-Business Applications more efficiently
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.
