Abstract  Figura 1 - The Octapy Distributed Contents Management Framework architecture. The Octapy distributed content management framework Content Management System (CMS) allows to manage content, usually for a web site. The main goals of CMS are to allow easy creation, publishing and retrieval of content to fit business needs. One common dividing line between different CMS’s is the integration of the web and hence can two types of systems: a web based system, and non web based system. Plone is a free, open source web based CMS The reference architecture for a Distributed Content Management was designed around the following components: Document Repository System (DRS) stores and organizes the documents together with the associated metadata. Document Access System (DAS) creates friendly and flexible user interfaces to discover and access the contents. Contents Authority Management System (CAMS) stores and manages the ontologies used by each participating node to facilitate the DRS semantic interoperability. We also assumed the multi-tiers web architecture, with the application server playing the central role of business logic driver. All these systems communicate among them exchanging XML encoded messages over http, according to well-defined protocols that represent the XML communication bus core, see Figure 1. Octapy.Framework functionalities Octapy.Framework has a rich toolset to organize collections of (semi)structured digital documents into archives and/or cooperating archives; to create web based applications that use W3C protocols for the web services and contents access; to deploy open standards, such as Dublin Core (DC), Resource Description Format (RDF), Ontology Web Language (OWL), Simple Object Access Protocol (SOAP), Universal Description, Discovery and Integration (UDDI), to cope with the system interoperability intricacy. For more details see the official documentation. Octapy mapserver module description The Octapy MapServer (OMS) module is an extension to the Ocatpy Framework to manage the cartographic information/knowledge associated to the documents and viceversa.. It allows to manage the structured map persistency, to produce graphic map presentation and to manage the contents associated to each map entity. In this context the OMS main goal is to coordinate the activities and the interfaces toward the MapServer, to deploy multiple correlated representation of a map, to exchange messages through the OMS-HTTPServer so to achieve some interoperability degree. The OMS architecture is split in two levels: one dedicated to the map persistency management, the other to the map representation management. To delivery these functionalities some opens source libraries are used, such as the MapServer, an Open Source package developed at University of Minnesota. OMS API To guarantee an high integration level the API has been defined according to the event driven object oriented programming model. With this choice the programmer may select and filter the events to be captured, such as map creation, map drawing, map interaction with the associated documentation, and so on. This approaches significantly simplify the component orchestration on implementing sophisticated map services, see.4 The map persistency is guaranted allowing more than 10 different map formats, such as the: ESRI ShapeFile (de facto standard for structured map persistency); PostGIS PostgreSQL extension, OracleSpatial extension; MySQL (cfr. Figure 2). Furthermore, using the notion of dynamic layer we can create a map containing information/knowledge coming from different data/knowledge sources, see Figure 3.  Figura 2 - OMS data sources  Figura 3 - Layer schema Querying the contents associated to the map entities To query the Octapy system for cartographic information a specific programming interface. For example, starting from a point or region coordinate all the associated contents could be retrieved. It is important to note that OMS abstracts from specific kind of contents associated to the cartographic entities, leaving the opportunities to define specific content handlers. All the querying geometric coordinate are expressed either in geographic units, such as UTM50, Gauss-Boaga84, or in graphic coordinates (pixel). In this last case the OMS module automatically remap the graphic coordinate into the geographic one. OMS-HTTPServer Module The OMS integration with the Octapy CMS framework is carried out according to the services oriented architecture and the current implemented transport protocol is the http one. This kind of architecture and the http protocol exchanging information exhibits some advantages on implementing web applications such as : the independence from a specific programming language for client applications; a clear separation between the map management and presentation layer; all the cartographic business logic is encapsulated within a well defined software component, with a clear deployment process, see Figure 3. The XRef and XML Formats The XRef format goal is to provide an abstract map representation to be easily exchanged among OMSHTTPServer. An XRef document. The OMS also generates a map representation using the XML, where the map structured information, residing into the persistency map system, is serialized in XML. The main contents that this component manages are: • map extension, expressed in geographic coordinates; • coordinate projecting system; • the layers included in a map. The Zope binding ZOMS ZOMS is a specific OMS binding for the Zope application server, it uses the XRef format and the OMSHTTPServer module to export the OMS functionalities within the Zope environment. The main ZOMS feature is the complete separation between the business and presentation logic for the map management. For more details or complete documentation see the documentation page. |
Abstract |
