DESCRIPTION OF THE MIDDLEWARE
The middleware will orchestrate all the operations among the several software modules
to provide a complete and personalized service. All the settings and information
will be stored in a POSTGRES database. The direct access to the database will be
granted only to server side components. These components will be developed in Java
and will communicate with remote middleware components and add-on modules based
on apache tomcat technology (a web platform, which will be used to provide web services
and web pages). In detail, the middleware will be responsible of the following tasks:
- Authentication- The identity (and then the profile) of the users will be
granted by middleware via a login mechanism and made persistent along the work session.
Every action taken by a user will be processed by the middleware taking into account
the user identity and his profile.
- Navigation- Users will access the granted application features (form, report,
etc), based on their profile, using a navigation menu. Menu behaviour, its content
and the features provisioning will be controlled by the middleware.
- Data management- The middleware will act as interface between clients and
data for the information used by reports (read only), forms (both read and write),
- Settings provisioning- The customizability of the application is possible
using xml structure documents. Beyond the basic features of the software, every
aspect of the add-ons behaviour will be designed using these xml documents. The
information needed to make this process persistent among the sessions and for all
the clients and users will be stored in a specific data repository (the settings
database). The middleware will provide settings information and will "compile",
validate and store the updates to the settings from the xml documents. This approach
gives the future opportunity to supply the middleware with a graphic IDE capable
of generating an xml structure document, without any changes to the platform.
The client/server infrastructure can be summarized by the following diagram (Fig
The client/server logic and the data and settings provisioning mechanism will make
this platform portable and independent from the client side. Indeed the user interface
will be available as:
- Custom client interface- This is the "client side" of GEEWHEZ and it will
make available login interface, navigation menu, tools, forms, reports, etc.. Due
to general client application capabilities, it will give the best performance and
user experience, beside the only way to access to the object designer tools set
and the client side "extensions". On the other hand, the custom client interface
will require a first installation to be used (but an update service will automatically
download and install new releases). The client-side interface will be developed
- Internet interface- It will use a common internet browser (Internet Explorer,
Firefox, Chrome, etc.) and no installation. It will make available login interface,
navigation menu, tools, forms, reports, etc.. It is the best way to access to the
software outside the corporate network or from guest clients. As mentioned above
all web pages will be provided using a web application (part of the middleware)
developed under Apache Tomcat.
- Mobile interface- It consists of all the visitors mobile specific features:
multimedia content, waiting time at different exhibitions, interactive maps of the
- Extensions- The middleware will make possible the integration of external
custom tools. This flexibility can be very useful from the point of view of scalability
in scenarios where specific tasks (e.g. integration with other software, communication
with non-standard external devices, etc.) are needed. These extensions can be "plugged
in" both server-side and client-side. The client-side extensions will be broadcasted
and installed automatically by the update service.
In a nutshell, an add-on module can just consists of a set of basic setting information.
This information will be used by the middleware to produce a specific navigation
menu and also all the expected corresponding functionalities. The functionalities
will be available as web pages or application forms, basing on the used interface.
This basic scenario can be somehow integrated, by more specific and advanced server-side
or client-side procedures, following the basic idea that:
- Configuration should be the only thing to do for all the basic purposes (and this
will be the most part of the modules functionality, e.g. a form, a report, a device
- There will always be a way to "plug" specific, non-standard functionality, either
for what concern server-side, either client-side behaviour (the extensions).
The work plan of GEEWHEZ is characterised by three different iterations.
- The first period will be dedicated to the middleware design and its implementation.
This task will highlight the core aspects of SME information orchestration. The
middleware will completely respect the SME structure and will provide a proper software
implementation of it. The middleware will be tested in one prototype centred on
the water monitoring and surveillance add-ons.
- The second iteration will be characterised by the development of the leisure add on and finally.
- The third iteration will be centred on ERP tools.