کاشی سنتی رنجبران : DISGIS: An Interoperability Framework for GIS

مقاله ها

صفحه اصلی
مقاله ها
DISGIS: An Interoperability Framework for GIS

DISGIS: An Interoperability Framework for GIS

1402/10/01

DISGIS: An Interoperability Framework for GIS – Using the ISO/TC 211 Model-based Approach

Roy Gr?nmo Arne-J?rgen Berre Ida Solheim Hj?rdis Hoff Kim Lantz*

Roy.Gronmo|Arne.J.Berre|Ida.Solheim|Hjordis.Hoff@informatics.sintef.no
SINTEF Telecom and Informatics

Kim.Lantz@gis.dk
*GIS Denmark
Abstract
Emerging standards from ISO/TC 211 convey principles for building interoperable distributed geographical information systems. Important building blocks are UML for specifying the conceptual schema and XML for implementation-neutral exchange of geodata models. By means of a model-based approach using UML and corresponding mapping to XML and service implementations it is possible to provide a well-founded basis for interoperability. Essential parts of this methodology have been elaborated tested and proven successful in the Esprit project DISGIS. The ISO/TC 211 principles are recommended as a general framework for building interoperable SDIs within a GSDI.
1.    Introduction
Interoperability – the ability of organisations systems information technologies and infrastructures to operate together – is addressed heavily in different communities around the world. Component-based systems plug-and-play solutions and distributed computing platforms (DCPs) are advocated by software vendors and required by customers.
This paper describes a successful example of applying the ISO/TC 211 ([1]) model-based approach for the purpose of achieving interoperability between Geographical Information (GI) systems. The paper first introduces the challenges of interoperability (section 2) and then describes the ISO/TC 211 model-based approach around conceptual schema language encoding and service architecture (section 3). NextSection 4 describes the DISGIS the interoperability framework used in the Esprit project DISGIS ([2]). The DISGIS framework applies the ISO/TC 211 principles of using a UML-model as a basis for an implementation-specific (HALLO?) model and for further encoding into XMLthrough its UML-to-XML approach ([3] [4]). The following sSection 5 provides an evaluation of various XML encoding strategies. Finally Section 6 presents a conclusion and plans for future work is presented.
2.    The GSDI Interoperability Challenge
In the GI world today there are several geodata models interchange formats communication mechanisms operating systems programming languages etc. Typical GI systems work as depicted in Figure 1 with a tight and rigid coupling between a client and its server. For self-contained and limited usage within an organisation traditional GI solutions may work well. However more widespread use of GI calls for interoperability on several levels.
Interoperability is defined as follows: "Two components X and Y can interoperate (are interoperable) if X can send requests Si for services to Y based on a mutual understanding of Si by X and Y and if Y can similarly return responses Ri to X." [5]

Figure 1 GSDI community of today
Various standardisation communities are addressing the challenge of interoperability. The Also the geographical information(GI) domain has for several years been subject to standardisation efforts for the very purpose of interoperability – and with good reason. GI access exchange and use have become crucial topics both within and between companies local authorities and nations. The OpenGIS Abstract Specification ([6]) by the Open GIS Consortium (OGC) is one attempt to standardise digital GI; another is the emerging 191xx family of standards from ISO/TC 211 ([1]).
Work is ongoing on to harmonise the GI models from ISO/TC 211 and OGC e.g. the adoption of OGC’s OpenGIS Simple Features Specification for SQL by ISO/TC 211 ([7] [8]).and ISO/TC 211 GI models The ISO/TC 211 is addressing this the GI problem area from a top-down perspective usingby a UML model-based approach. while theOn the other hand OGC OpenGIS OGC work is working from a bottom-up perspective allowing for multiple implementation specifications which currently have not been derived from one common that might not have a precise and common implementation implementation-neutral UML model that they have been derived from. Right now Oone focus areacrucial point for harmonisation is now how to get the top-down and the bottom-up approaches to meet. In order to achieve this goal: Fromso that from one conceptual and implementation-neutral specification it shall be possible to have a well-defined mapping into implementation-specific specifications for various platforms and implementation environments ([9]). and This capability will make it possible consequently a possibility to achieve a basis for interoperability across various environments and DCPs.
3.    The ISO/TC 211 Approach to Interoperability
3.1    ISO/TC 211 Principles
The ISO/TC 211 technical committee is developing the ISO 191xx series of standards for geographic information/geomatics. The base series of standards is intended to be independent of any particular implementation environment or distributed computing platform (DCP). It is still intended to support implementation of the standards in different environments and to support data and service interoperability between different environments.

Interoperability at different levels is needed to integrate enterprise systems. The different levels may be separated by the five viewpoints of ISO Reference Model-Open Distributed Processing (RM-ODP) [10]: enterprise information computational engineering and technology. ISO RM-ODP provides a framework for developing distributed systems. Each viewpoint is an abstraction of the system based on a specific of concerns. Interoperability may be considered along all the five viewpoints. The main focus for ISO/TC 211 is on the technology independent computational and information viewpoints. The computational viewpoint focuses on service interfaces and interaction between different system components. The information viewpoint focuses on the information model for geodata that is being maintained and processed by the components.

Figure 2 From implementation-neutral to implementation-specific specifications
The ISO/TC 211 models are implementation-neutral meaning that the models are at a conceptual level and independent of implementation details of a particular environment or DCP. Still it is precise enough to serve as a basis for further mapping to implementation-specific models.
Figure 2 illustrates the ISO/TC 211 approach from implementation-neutral models to XML-based encoding and service implementations for various environments.
Implementation-neutral models are being described in UML according to the rules and guidelines in ISO 19103 Conceptual Schema Language ([11]). These models are mapped to an XML-based encoding format according to ISO 19118 Encoding ([12]). Implementation-specific models are created for target implementation environments and DCPs according to a mapping. The mapping describes how each construct of an implementation-neutral model is handled on the implementation-specific level. These principles are briefly described in the following sections.
3.2    The ISO 19103 UML Modelling Rules and Guidelines
ISO/TC 211 has decided to use UML (Unified Modelling Language) by OMG as the common language for describing the implementation-neutral models that are part of the ISO 191xx series of standards. The reason for this decision is that the goal of ISO/TC 211 is to create a framework that supports:
•    syntactic and technical interoperability
•    a basis for semantic interoperability
•    multiple interchange formats and
•    multiple service implementations.
The ISO 19103 standard contains rules and guidelines for how to develop implementation-neutral UML models. The ISO 19109 Rules for Application Schema defines a general feature model for representing geographic information.
3.3    The ISO 19118 XML Encoding
The models to be used for the ISO 19118 encoding are based on implementation-neutral UML models. It could also have been based on an implementation-specific specification of this model for a particular implementation environment but it is assumed that more optimal encoding formats exists for the different environments and that the native mechanisms within an environment will be used when it is known that all interaction will take place within that environment only.
The ISO 19118 encoding contains rules for how to map from the implementation-neutral UML models to a corresponding representation of data according to these models in XML. There are many possible alternative choices of XML formats that are able to transport data instances of the implementation-neutral UML model. Section 5.2 evaluates the ISO 19118 encoding approach against other GI XML encoding approaches.
3.4    The ISO 19119 Service Architecture
The goal of the evolving ISO 19119 service standard ([13]) is to establish a framework for specification of geospatial services and to identify a of services for further standardisation. In addition it defines how to map from implementation-neutral service models to implementation-specific service models for environments and DCPs such as COM CORBA J2EE EXPRESS/SDAI SQL etc. The goal is to be able to define implementation-specific profiles of the implementation-neutral models ensuring that there is a well-defined mapping between these.
The reason for having support for different implementation platforms is that it is not possible for the whole world to agree upon one platform. The technological development is fast and it is also important to preserve the value invested into developing domain models and to ease a change of technology. This is the main reason why ISO/TC 211 is focusing on standardising on implementation-neutral models with a precision sufficient for further mapping to implementation-specific environments and DCPs.
XML is introduced as a basis for an implementation-neutral exchange format. The XML format is derived from the definitions in the implementation-neutral UML models and not from implementation-specific models. Thus it can be used when there is a need to achieve interoperability between various implementation environments or within one environment if not a more optimised environment-specific encoding has been chosen.
For an implementation-specific specification to be a proper profile of an implementation-neutral specification it is necessary to describe how types with their operations attributes and associations are mapped from the implementation-neutral to the implementation-specific specification.

Figure 3 Supporting multiple implementation environments
Figure 3 shows a three-tier architecture that enables interoperability among different servers and different clients. The application layer involves the browser and editor clients that are offered to end-users. The business layer involves a model that is the basis for an interaction between the clients and the servers. The data layer involves stored representations of the information models according to standardised storage representations such as a SQL-profile for the implementation-neutral models or it can be stored in proprietary database storage formats and data stored as flat files.
There are existing client applications and there are existing storage formats within the GSDI community. The responsibility of the business layer is to enable interoperability that is communication among these heterogeneous servers and heterogeneous clients.
It is possible to use the specific communication infrastructures and representation forms provided by a specific implementation environment and DCP but then the interactions are restricted to be within that environment. Figure 3 shows the direct communication within a COM+ a CORBA and a J2EE environment within the business layer as well as within database environments such as SQL on the data layer. Such interactions have been standardised by OGC (Open Geodata Corporation) for instance by the Simple Features specification for OLE/COM ([14]) CORBA ([15]) and SQL ([7]). These have however currently not been derived from a common implementation-neutral model and are thus not directly interoperable with each other.
The ISO/TC 211 approach lends itself naturally to be supported by code generation and the DISGIS project has tried this out in practice as will be described and discussed in chapter 4.
Code generation can be used to automate the process at different levels. Code generation may be used to implement the mapping from implementation-neutral model to implementation-specific models as well as implementing the implementation specific models to a specific environment. There are several general advantages of using code generation:
•    The implementation is documented by an always up-to-date model.
•    Domain experts can intercommunicate with the programmers through the specifications and changes will automatically be incorporated in the implementation.
•    Much of the implementation can be automated resulting in less manual work for the programmers.
•    Implementation logic is centralised by generic code resulting in faster development consistency and easier maintenance. Each class may for instance have a copy() method which is generated by a single generic algorithm. The generic algorithm generates different copy() implementations for each class depending on the attributes and relations of the specific class.
•    The same naming conventions documentation and programming techniques will be used throughout the implementation thus making it consistent and easy to read.
•    Code generation removes the possibility of manual programming mistakes in all the generated parts. A mistake in the generated parts occurs globally thus increasing the chance of discovering this mistake.
A good code-generation tool supports the software development life cycle and not only the initial generation. Within such a tool the UML models can be edited and new code will be generated without effecting or over-writing the manual parts.
4.    DISGIS Interoperability Framework
Distributed Geographic Information Systems (DISGIS) ([2 16 17]) was an EC-supported Esprit project with a focus on developing mechanisms for GIS interoperability building on state-of-the-art technology from the distributed system domain and applying the ISO/TC 211 model-based approach. The DISGIS interoperability approach is consequently based on the ISO RM-ODP model for Open Distributed Processing the usage of UML for model specification and the usage of XML and/or binary streaming for data exchange.

Figure 4 final DISGIS pilots
Figure 4 shows the pilot configuration by the end of the project. The partners of the DISGIS consortium had 3 existing heterogeneous servers and 3 existing heterogeneous clients using proprietary geodata models. The DISGIS project achieved interoperability between each of the heterogeneous applications by following the principles of the ISO/TC 211 model-based approach.
Starting out with the principles of the ISO/TC 211 and OGC feature and geometry models the project members agreed upon a common feature model and associated geometry types and specified these by means of UML class diagrams. This initial implementation-neutral UML model was then transformed by hand to a second UML model specialised for implementation in C++. This second UML model is therefore called implementation specific. The project developed a code-generation tool that takes the (C++) implementation-specific model as input and produces C++ program code. DISGIS is extending the model-based approach to be model-driven by also generating parts of the implementations corresponding to the models.
The resulting common geodata model is called DG Mod (version 4) in Figure 4. The mapping framework prescribes to-way mappings between the common model and proprietary client/server models. The DISGIS API (DG API) is a service interface for feature access query and according to the ISO19119 service architecture. The communication between clients and servers is supported by a communication framework (DG CFW) that transparently supports service interaction on top of various transport protocols (currently sockets and CORBA but others like DCOM may easily be added). The encoding of features being communicated between clients and servers has been done both as binary and XML format. A coordinate transformation server was successfully tried out as an example of a more pure processing service.
The DISGIS interoperability framework consists of the common UML models with corresponding C++ implementations for the common geodata model and feature access service and a communication framework with transparent support for sockets and CORBA for interaction and transport of XML or binary streaming packages.
A of modelling requirements was defined to ensure proper precision of the model. A of mapping rules defined the transition from the C++ UML model to:
•    C++ implementation
•    XML encoding and
•    binary C++ encoding from Object Space.
A code-generation tool used the mapping rules to generate much of the C++ implementation and all of the encoding formats with streaming libraries (Figure 5).

Figure 5 DISGIS - a model-driven development
The DISGIS mapping from UML to XML is different from the ISO/TC 211 encoding and XMI DTD production rules but together with binary encoding it demonstrates that encoding format and streaming support can be fully generated from the common UML model.
The strength of the DISGIS mapping from UML to XML encoding of data instances is easy mapping rules and a compact XML format. Though the XML encoding used in DISGIS has a few limitations.
•    An XML DTD/Schema is not explicitly created. This means better performance at the cost of some validation of the XML document.
•    It uses a fixed order of the XML attributes. This means better performance but is not true to the XML 1.0 specification ([4]) from W3C. In DISGIS the import and export of XML was written by the same vendor utilising and ensuring the fixed attribute order.
•    It defines a precise mapping of the most common model structures (all that was needed to transport geodata in DISGIS) but not all possible model structures. It lacks secure support for list of strings two-way relationships and multiple inheritance.
These limitations of DISGIS XML encoding can be fixed so that the DISGIS approach is an alternative in the general model case.
When designing a communication protocol one must try to meet the following demands:
1)    Flexibility: The possibility to use different implementation languages such as Java C++ or other languages.
2)    Efficiency: The volume of GIS data implies that efficiency both in terms of memory usage andution time have high priority when designing communication protocols. It is important to have efficient implementations of bulk data transfers in the distributed environment.
These two objectives are often conflicting – efficiency means low flexibility and vice versa. DISGIS implemented two alternative streaming formats: XML encoding schema and C++ binary encoding schema from Object Space. The disadvantage of using XML instead of binary structures is the size and thereby the speed of the applications.
Extensive performance tests were made to compare the XML encoding to the binary C++ encoding. An important measurement of the tests was that the size of XML to binary C++ encoding ratio is between 1.62 and 1.66. This gives high expectations to the prospects of being able to use XML to communicate efficiently since the only real obstacle is the difference in size. Since this difference is less than a factor of two we would expect that XML could be used as a generic encoding format instead of using traditional binary formats which are dependent on a specific computer programming language or DCP. Also the experience from Internet development has shown that open simple and flexible solutions are winning compared to more complex and specialised solutions with higher efficiency. Still the approach of generating streaming from the UML models allows also for the generation of optimised binary streaming for special situations.
The DISGIS Interoperability framework provides a basis for interoperability between different existing heterogeneous geodata servers and clients through a mapping to a common geodata model and feature query access and service. The distributed communication framework enables the services to be supported for various communication protocols.
The results from the DISGIS project is now being used as the foundation for the next generation Norwegian National Geographic Infrastructure (NGIS) and is being developed further in that context.
5.    Evaluating other XML Strategies for Geographical Information
XML is evolving to be the de-facto-standard for interchange formats. There is ongoing work in ISO/TC 211 and OGC for defining geodata encoding formats with XML. ISO/TC 211 suggests a UML model-based approach to defining XML formats instead of defining the XML formats by hand. This section describes some of the main approaches that have been proposed for using XML in the GI domain and evaluates these against the ISO/TC 211 approach.
5.1    XML Metadata Interchange (XMI)
Object Management Group defines the XMI standard ([18]). XMI defines XML mapping rules that apply to several meta levels. The resulting XML formats encode meta models models or data instances depending on the chosen meta level. Applying XMI DTD mapping rules on a GI UML model results in one and only one XML DTD. This XML DTD defines an XML encoding format for representing geodata instances corresponding to the GI UML model. There are important reasons for using XMI:
•    XMI is the industry standard for mapping a UML model to an XML format.
•    Most UML tools announces recently released or future support of XMI ([19]).
There are two drawbacks that may prevent XMI’s popularity and its adoption in the market:
•    It is complex. The XMI specification requires some understanding of the OMG Meta Object Facility (MOF) ([20]) which demands thinking in terms of high level abstractions.
•    The first specifications of XMI do not say that XMI may define an XML format for encoding data instances corresponding to UML models even though it really does due to the generic capabilities of the MOF. Therefor it may be wrongly interpreted as only defining the encoding of models and metamodels.
5.2    ISO 19118 XML Encoding
The ISO 19118 ([12]) is currently based on the principles of the OMG XMI-standard for XML-based model interchange but has been optimised for dealing with data instances by using an alias-list mapping from long identifiers to shorter tags. The aliases associate each XML element name with a shorter name or code. Using compact element names makes the XML files more compact so that data can be streamed more efficiently across the network. These compact element names are introduced at the cost of human readability. Switching back and forth between compact element names and human-readable element names may be done by coming XML tools.
It is a goal of ISO/TC 211 to influence forthcoming versions of XMI to be more efficient for data instance representation. Ideally this should happen with the next major revision of XMI with the support of XML Schema.
5.3    SFXML/GML
OGC have started to standardise XML formats for encoding of geodata instances by introducing the drafts for Geography Markup Language (GML) [21] and Simple Feature XML (SFXML) [22]. These are two partly overlapping XML formats for expressing OGC Simple Feature data instances. GML is according to the OGC Simple Features for SQL. SFXML is according to the OGC Simple Features for OLE/COM. These two implementation-specific specifications are based on the OGC abstract specification. The abstract specification is an implementation-neutral model. The transitions from the abstract specification to the implementation-specific specifications are hand-coded and do not follow well-defined mapping rules. The transitions from the implementation-specific specifications to XML formats are also coded by hand.

Figure 6 OGC hand-codes XML specifications (GML/SFXML)
There are two major problems of defining the XML formats by hand:
•    Interoperability: Geodata encoded in one of the implementation-specific XML formats cannot be directly sent to the other OGC implementations.
•    Maintenance: The mapping from model to XML is done by hand and without well-defined explicit rules. Therefor it is hard to maintain the XML format as the model change.
By using the ISO/TC 211 model-based approach UML tools can generate XML encoding format based on the abstract specification in UML using the ISO 19118 UML to XML mapping. The implementation-specific UML models can also be generated from the abstract specification but the mapping rules for each platform need to be specified. The challenge is to reach an abstract UML model that is both implementation-neutral and precise enough to be a basis for different automated platform mappings.
6.    Conclusion and Future Work
ISO/TC 211 prepares the ground for geographic information data and service interoperability. A model-based approach using UML and XML is essential for making this work. UML is used to express the conceptual model. XML is used as a basis for implementation neutral data exchange thereby supporting interoperability between different implementation environments. The principles of ISO/TC 211 can be summarised as follows:
1.    Agree on a common precise and implementation-neutral UML model.
2.    Define mapping rules from the neutral model to different implementations and follow these rules for defining standard implementation profiles. This can preferably be supported by a code-generation tool.
3.    Use encoding rules from UML to XML to support mapping to a common XML format based on the neutral UML model.
Some of the advantages are as follows:
•    a consistent approach for defining various implementation and environment specific standard profiles
•    ease of maintenance ? yielding drastically reduced maintenance time and consistency when a new version of a standard is to be developed. The changes are initially defined on the implementation-neutral level and then propagated to the various implementation specific profiles
•    support for both high performance implementation profiles taking advantage of the facilities in various implementation platforms as well as support for interoperability between various implementation platforms and technical infrastructures
In the DISGIS project essential parts of the ISO/TC 211 approach were tried out and found useful. This year the full approach is being carried out and tested in ongoing projects around the Norwegian NSDI. With respect to GSDI the ISO/TC 211 approach should serve as a general interoperability framework for building compatible NSDIs. The first step will be to define the geodata models (ISO 19107) ([23]) and services (ISO 19119) that will be available through implementation neutral UML models using the ISO 19103 standard and corresponding ISO 19118 XML encoding then to define appropriate service specifications. The services should be made available through a global catalogue service for instance based on the principles from the OpenGIS Catalog service ([24]). The main advantage of the UML model-based approach in this context is that it is possible to support different local implementations and representations of the same logical geodata models and services. It is also easy to migrate to new technologies as the implementation-neutral models remain stable with respect to technology changes as for instance the assumed forthcoming change from XML DTDs to XML Schema representation.
References
[1]    www.statkart.no/isotc211
[2]    www.disgis.com
[3]    G. Booch J. Rumbaugh and I. Jacobsen The Unified Modelling Language User Guide: Addison-Wesley 1999.
[4]    W3C “Extensible Markup Language 1.0” World Wide Web Consortium February 1998.
[5]    M. Brodie and S. Ceri “On Intelligent and Cooperative Information Systems” International Journal of Intelligent and Cooperative Information Systems pp. 1-35 1992.
[6]    OGC “OpenGIS Abstract Specification” Open GIS Consortium 1999.
[7]    OGC “OpenGIS Simple Features Specification for SQL Revision 1.1” Open GIS Consortium May 1999.
[8]    ISO “CD ISO 19125-1 Geographic information - Simple feature access - Part 1: SQL option” ISO/TC 211 N 821 November 1999.
[9]    T. Iversland “UML as a common specification language for multi-platform domain standards demonstrated for the CORBA adn SQL platforms and the GIS domain.” in Faculty of Physics Informatics and Mathematics. Trondheim.: Norwegian University of Technology and Science 1999.
[10]    ISO “International Standard 10746-1 Open Distributed Processing- Reference Model” 1996.
[11]    ISO “CD 19103 Geographic information - Part 3: Conceptual schema language” ISO/TC 211 N 755 1999.
[12]    ISO “CD 19118 Geographic information - Part 18: Encoding” ISO/TC 211 N 709 March 1999.
[13]    ISO “Geospatial Services (Working Draft 1.0) - CD version forthcoming spring 2000”   ISO/TC 211 N043 February 2000.
[14]    OGC “OpenGIS Simple Features Specification for OLE/COM Revision 1.1” Open GIS Consortium May 1999.
[15]    OGC “OpenGIS Simple Features Specification for CORBA Revision 1.0” Open GIS Consortium March 1998.
[16]    A.-J. Berre R. Gr?nmo H. Hoff and K. Lantz “DISGIS: An Interoperability Framework for GIS - using UML and XML” presented at 5th EC-GIS WORKSHOP Stresa Italy 1999.
[17]    DISGIS “DISGIS White Paper - Final version” Distributed Geographical Information Systems - Models Methods Tools and Frameworks. ESPRIT Project No. 22.084 June 1999.
[18]    OMG “XML Metadata Interchange (XMI) Version 1.1” Object Management Group OMG Document ad/99-10-02 October 25 1999.
[19]    S. I. Brodsky “XMI Opens Application Interchange” IBM www-4.ibm.com/software/ad/standards/xmiwhite0399.pdf March 1999.
[20]    OMG “Meta Object Facility (MOF) Specification” Object Management Group ad/97-08-14 September 1 1997.
[21]    OGC “Geography Markup Language (GML)” Open GIS Consortium 1999.
[22]    OGC “Wep Map Server Interface Specification” Open GIS Consortium 1999.
[23]    ISO “2. CD 19107 Geographic information - Part 7: Spatial Schema” ISO/TC 211 N 818 November 1999.
[24]    OGC “OpenGIS Catalog Interface Implementation Specification (Version 1.0)” Open GIS Consortium May 1999.

درباره ما

روابط عمومی

آدرس