Europe flag FP7 Capacities Logo
Home > The Middleware

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:

  1. 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.
  2. 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.
  3. 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), etc...
  4. 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 2):

client/server infrastructure diagramFig.2

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:

  1. 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 in java.
  2. 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.
  3. Mobile interface- It consists of all the visitors mobile specific features: multimedia content, waiting time at different exhibitions, interactive maps of the park, etc...
  4. 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 data collector).
  • 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.