Application server

Container of business logic, accessible in different ways:

• Web services with XML-RPC protocol: - Business logic implemented with PowerBuilder - Business logic implemented with Java and executed with Tomcat (RPC2).
• New services accessible through REST (HTTP requests) and implemented with Java, using Spring framework and running under Tomcat.

Container of different data repositories:

• Relational database (SQL) that contains business data with support for: - SQL Server - Oracle - Postgre SQL.
• Non-relational database to support the new framework (data cache, configuration, audit, etc.). The preferred database is Redis.

Container for messaging services between services. For this functionality. we have opted for the MQTT (Message Queue Telemetry Transport) protocol, which allows push functionality (notifications initiated by the server towards the client).

Web server

Based on NodeJS, it serves static elements (HTML elements, images, etc.) and acts as a proxy for business REST requests from the client to the server.

Client server

The framework has an API formed by services (either XML-RPC or REST) and accessible:

• Directly by any client that allows HTTP calls.
• By applications created from the API. For this, we chose Angular2 given its flexibility to create executable applications from a web browser and as an executable, be it Windows, Linux or iOS.

New features

• Dynamic definition of security by service and user role, on several levels:
  • Definition of list of services without access restriction.
  • Definition of list of services accessible by certain roles.
  • Definition of list of services restricted to certain roles.
  • Services accessible by any user role (logged-in user).
• For access to services with access control definition, the call must be made by providing the service with an access token received when logging in.
• Data cache based on Redis providing shorter execution times.
• Multi-language applications
• Dynamic event audit.
• Dynamic security configuration of failed login requests, allowing request blocking to avoid DoS (Denial of Service) attacks.
• Further dynamic functionalities thanks to server to client communications (push notifications).

Future architecture structure

The new paradigm is based on SERVICES. A service is a programme component that meets certain requirements:

• Abstraction and re-usability: operate identically regardless of the calling entity.
• Execution autonomy.
• Flexibility to run services from anywhere.
• No programmes required.

Works are executed from a:

• service flow.
• grouping of simple services into composite services.
• new situation.

Advantages of Architecture 2.0

• 
  Greater flexibility and adaptation
• 
  Based on standards
• 
  Increased speed and agility
• 
  Execution autonomy
• 
  Platform independence
• 
  Interoperability