Integration of GeoReport in a modular JEE application
Mikael Couzic
I have a complicated question and I think you guys could help me a
lot. Let me introduce the context :
I work in a BI company that has a GWT based web portal which allows
its clients to consult the data it generated for them. Lately, the
need has risen to display this data on a map. Considering the
technology stack we use, we naturally started to work with GWT-
OpenLayers, a GWT wrapper for OpenLayers.
However, two new events changed things quite a bit. First, we now have
a project of a new web portal, based on JEE and capable of easily
integrating portlets. GWT would be abandonned. So the GWT nature of
the cartographic module is not so critical, and it could even prove
problematic in the future.
The second event is our attending to a presentation by Andrea Gioia on
the integration of GeoReport in SpagoBI. What Andrea showed us was
almost exactly what we were looking for.
So here I am !
The way I see things coming, I think we'll have to have both versions
of the portals cohabitating for several months, and I would'n like to
develop the same app twice !
I haven't had time to look deep into GeoReport yet, and I'll keep my
investigation going but if you guys could provide me some guidance it
would help me a lot.
Just a few more details about the project :
I will be assigned full time to it, with a maximum duration of 2-3
months.
My first idea in making my project as reusable as possible is to
modularize in a SOA way. Does it make sense to you ?
Thanks !
Mikael
Fabio D'Ovidio
sure, you can use SpagoBI with a jsr168 compatibile portal and
SpagoBIGeoReportEngine (just included as internal engine in SpagoBI) to
manage cartographic services (OGC) or data.
Consider that, GeoReport joins the informations coming from Data
WareHouse within cartographic features coming from WFS service or file
system spatial vector data and display a thematic map based on your own
indicators. GeoReport also provide an OGC WebGIS interface in order to
integrate external services or maps.
Let us know!
Fabio D'Ovidio
Mikael Couzic ha scritto:
Fabio D'Ovidio
using SpagoBI (or PentahoBI), modifying the module that queries the
datawarehouse (separated from cartographic data or services), so without
using SpagoBISDK or Pentaho API to connect to an external DataSet.
Mikael Couzic ha scritto:
--
*Ing. Fabio D'Ovidio*
/Location Intelligence Unit Manager/
Mail
f.do...@inovaos.it <mailto:f.do...@inovaos.it>
GMail
fabiod...@gmail.com <mailto:fabiod...@gmail.com>
Skype
dovidio_fa <skype:dovidio_fa?add>
Web
www.inovaos.it <http://www.inovaos.it/>
Blog
www.geobi.org <http://www.opengeobi.org/>
Inova Spa <http://www.inovaos.it/>
* *
*INOVA S.P.A.*
viale Casiraghi, 359
20099 Sesto S.Giovanni (MI)
via A. Nobel, 281
81031 Aversa (CE)
Tel. (Naples): +39 081 197 57 600
Tel. (Milan): +39 02 241 34 41
Fax. +39 081 020 25 75
Couzic Mikael
I've been reading a lot of code from GeoReport in the last couple of days, I now have a bit clearer idea of how it works.
Your second suggestion seems the right one in my case (using GeoReport only). However, I'm a bit reticent to directly modify the module that queries the datawarehouse (MapOl if I'm correct). If I do that I'll have to do it again when my datawharehouse changes (and it will).
What I'd like to do is abstract what changes and cut down MapOl's dependency on the datawharehouse by introducing a new interface (in the Java sense). MapOl whould then be dependant on the interface, and not the datawharehouse. The implementation of the interface would be left to anyone willing to integrate engine in a BI solution, and MapOl would be generic.
Obtaining genericity with the Dashboard would be nice too, but I haven't found a concrete solution yet... I'll keep looking.
I was a bit afraid I would'nt be clear enough in my explanation, so I made a small graph to illustrate it (there's also the .dia file if you want to edit it).
You'll see in blue the generic, final modules and in red the specific implementations.
I'd be glad to contribute to the project in a way that allows easier reuse, however I might need a little help for describing the BusinessDataService interface. If I do it, I'm pretty sure it will end up being incomplete.
By the way, I have a few questions :
- What does the name "MapOl" stand for ? (I know, I'm curious)
- Is there a reason MapOl is a JSP instead of a Servlet ?
I hope to hear from you soon !
Mikael
--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "geobi" di Google Gruppi.
Per postare messaggi in questo gruppo, invia un'email a ge...@googlegroups.com.
Per annullare l'iscrizione a questo gruppo, invia un'email a geobi+un...@googlegroups.com.
Per ulteriori opzioni, visita il gruppo all'indirizzo http://groups.google.com/group/geobi?hl=it.
Fabio D'Ovidio
Couzic Mikael ha scritto:
> Hello Fabio, thanks for answering !
>
>
> I've been reading a lot of code from GeoReport in the last couple of
> days, I now have a bit clearer idea of how it works.
>
good :-)
> Your second suggestion seems the right one in my case (using GeoReport
> only). However, I'm a bit reticent to directly modify the module that
> queries the datawarehouse (MapOl if I'm correct). If I do that I'll
> have to do it again when my datawharehouse changes (and it will).
> What I'd like to do is abstract what changes and cut down MapOl's
> dependency on the datawharehouse by introducing a new interface (in
> the Java sense). MapOl whould then be dependant on the interface, and
> not the datawharehouse. The implementation of the interface would be
> left to anyone willing to integrate engine in a BI solution, and MapOl
> would be generic.
very good, it could be a great idea in order to work with GeoReport
alone and not together with a BI platform such as SpagoBI or PentahoBI,
etc...
Anyway consider that a DataSet for BI platform is already generic and
indipendet from the way used to obtain data (SQL query, MDX query,
Script language, etc...), so by using a BI Platform, MapOl module is
already indipendent from the kind of Data Store: it could be a Data
WareHouse but also simply a DBMS table, or other...
Consider also that BI Platform SDK is used also to execute reports
througth the WebGIS (Client) interface. In that case you must be
dependent from the tool you would use to make reports!
> Obtaining genericity with the Dashboard would be nice too, but I
> haven't found a concrete solution yet... I'll keep looking.
As explain above, you could develop an interface for each kind of tool
used to make reports. So I think that it would make more sens to keep
GeoReport dipendent only from the BI Platform (that contains APIs to
connect to more than one BI tool, like PentahoBI and SpagoBI already do)...
You could think instead a way to improve map themathization a part of
choropleths and propotionals...or a WMS-SLD implementation of GeoReport
(instead of GeoJSON and WFS approach).
> I was a bit afraid I would'nt be clear enough in my explanation, so I
> made a small graph to illustrate it (there's also the .dia file if you
> want to edit it).
> You'll see in blue the generic, final modules and in red the specific
> implementations.
>
> I'd be glad to contribute to the project in a way that allows easier
> reuse, however I might need a little help for describing the
> BusinessDataService interface. If I do it, I'm pretty sure it will end
> up being incomplete.
It think you could start to study a BusinessDataService interface just
only to query a DWH and start with Mondrian server.
What do you think?
I think you can refer to SOLAPLayers developed by GeoSOA and you could
use SOLAPJson de facto standard used by it in order to send MDX response
to the WbeGIS Client.
Let us know!! It would be greatly appreciated !!!
>
> By the way, I have a few questions :
> - What does the name "MapOl" stand for ? (I know, I'm curious)
Open Layers Map (in the sense that the Map deals with every kind of OGC
cartographic layers)
> - Is there a reason MapOl is a JSP instead of a Servlet ?
Not in particular....and we are going to modify the JSP in a Servlet (we
already did it in SpagoBIGeoReportEngine)
See you soon!
Fabio D'Ovidio