...

• Client (written in C/C++) - does not have to work on the machine on which the API and UI work. Allows user to add new data to the Catalog dataset.
• UI (written in PHP/javascript) - server part. It allows you to present the collected data. For now, it is not communicating remotely with the API. Both must be on the same machine.
• API (written in PHP) - server part. Handles client and UI SOAP requests. The middleman between them and MySQL.
• MySQL - Dataset of tool serves as a source of the data.

Main problems of the existing solution

• The tool is very hermetic and designed for one platform (Gateway)
• Very problematic to create environment for Catalog QT
• Current solutions are old and less efficient
• Very difficult to add new functionalities or extend existing ones
• The authorization module is based on Single Sign-On from Gateway and works only on GW
• SOAP - a tool with great possibilitiesand large requirements, that we do not really need
• Only one request can be handled at the time (catalogUpdataProcess is a serial application) and quite fragile when it comes to error handling. In case there is a major issue with data import and catalogUpdateProcess fails, there is no way to recover other than restart the process again

Benefits of using Java and Spring Boot Framework

Faster development process

...

Parts on new Catalog QT tool

• Client (Java based) - this application will be responsible for sending user's request (equivalent of catalogScheduler  application)
• Server (Java based) - this part of application will be developed using Spring Boot. Spring Boot is used by a large community of developers, so we can rely on extensive experience and numerous projects based on this solution.

...

• Server side (catalogUpdateProcess) will be embedded inside WebService container (e.g. using RabbitMQ)

Main problems of new approach

• we have to develop all the parts using new technology
• we won't be backward compatible with old installations

Main benefits of new approach

• No need to configure lot of components and modules to run serwer side modules. 
• To run the Server side components, it would be enough to run a single java file.
• No Apache, GlassFish

...

•   or other www container needed to run it -

...

•  Spring Boot has its own.
• Better handling multiple requests for storing data

What was tested

Spring Boot Framework

...

For now, the User Interface UI does not query the API remotely, but knows its location on the machine on which both of them are located and query it locally.
Thanks to the separation, UI could connect to any API on any machine and browse stored data remotlyremotely.

Integration with IMAS Docker image

...