Hello! My name is Vitali Diatchkov, I am GIS software engineer at Arbonaut Oy LTD (Finland).
Some times ago we looked to open source web mapping projects to choose one for our GIS RIA (rich internet applications) development to be based on. After analysis of the project requirements had been starting at that time we preferred a Mapbender to OpenLayers. Because of a lot of good stuff had already been implemented for the server side and power of database-founded configuration and user management. Our challenge was to incorporate Mapbender as a mapping component to the main Java enterprise application running at the appserver. The challenge here is because of totally different environments (J2EE an PHP). It means it is impossible just simply wrap Mapbender as a component in particular presentation layer component technology (like JSF or whatever) and utilize it. In our case it is a ZK Java and server-side-based Ajax framework (www.zkoss.org). Briefly to say about the chosen architectural solution: zkMapbender component for the server side is developed in ZK framework technology that wraps a particular Mapbender GUI instance living in a IFRAME inside of the main frame of J2EE web application. All the business logic is running in J2EE web application at the appserver. zkMapbender component generates an IFRAME where Mapbender instance for the particular GUI is loaded from PHP environment through proxy servlets of the appserver where the man J2EE web application is running. It solves security issues of JavaScript interaction through multiple documents loaded in different frames from different servers. Special GUI is developed for Mapbender where the mapframe takes all the place and tools are located on the top of the rendered map. This is a background information to figure out what we are doing. To make Mapbender working in a such heterogeneous environment, some PHP modules are replaced by Java modules developed for zkMapbender component and JavaScript for the client is also re-implemented. Most of the modules like navigation tools are working fine without any hackings. Re-implementation concerns only those modules (from PHP to Java environment) where long-running asynchronous communication is needed: selection of features, creating of new features by digitizing tools and so on. An example: spatial request goes directly to zkMapbender component living at the J2EE application that knows how to request features (whether from WFS server or directly from PostGIS database e.g.) and the component configured for the particular application business logic and data model knows how to load features and generate the same JavaScript output like mod_wfs_result.php generates in PHP environment. Small conclusion: we use Mapbender as not like a mapping application framework, but more as a mapping component utilizing existing Mapbender's functionality implemented in PHP and extending by new custom functionality implemented in Java needed for the particular enterprise web application. I could write much more technical issues about how do we solve unsolvable problems during merging of so different environments.. But now I would like to share some thoughts about Mapbender itself. Like I said I consider Mapbender as a very powerful mapping application framework. It is more intended for the application development not serving like a component. I have been developing for GeoTools, UDIG and GeoServer (great open source Java-based GIS frameworks) during several years. One big drawback of Mapbender from my point of view that in some places it tries to invent the wheel: implementing its own geometry model, feature model in javascript for the client side when there are consistent and widely accepted OpenGIS Consortium API specifications, and their different implementations (GeoAPI, JTS - JavaTopologySuite) that follow standard API naming conventions and design patterns. An example: in GIS a Feature model is on the top of Geometry model. Seems Mapbender is more "geometry"-term-centric when Geometry object has a child Wfs_element that represents a "Feature" entity. It is very misleading for the "GIS standards"-based development. Another example where I see the potential future refactoring: selection and digitizing tools are tightly coupled with modules at the server side handling WFS requests. In current conditions to change PHP server-side logic by the Java-implemented logic for these tools we had to refactor almost all the javascript code for the client side. What if the client-side javascript would be server-side agnostic to easily replace server-side logic? In our case GeoServer (that having good modular architecture) is injected as a module to out J2EE application - it is not a standalone application anymore - and all operations serving by Mapbender like query/create/modify/delete features are processed without WFS XML requests/responses being sent by mod_wfs_result.php to GeoServer but they are executed directly by our J2EE application against PostGIS or OracleSpatil database. And we have very improved performance of vector data processing operations (by other words feature management operations) because of eliminating redundant components (standalone WFS server) for the particular project with very limited and constrained spatial data model. If selection and digitizing tools would work through listeners design pattern and architecture would have several abstraction layers we could just easily replace server-side logic and communication protocol but client javascript of tools would still work without any changes. In case of digitizing tools I mean replace geom2wfst.php by the custom logic in J2EE web application and WFS requests protocol by geoJSON for example (for transferring features between client and server-side component responsible for create/modify/delete features). Sorry for the long set of words :) We are ready to improve thing together in future. I have just described several use cases where things would look much better for the utilizing Mapbender as a mapping component framework, from my point of view and also as a great mapping application. Any comments and criticism are appreciated. Regards, Vitali Diatchkov. _______________________________________________ Mapbender_dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapbender_dev
