External Data Services

When you build a new system, in most cases, the new system needs to be integrated with the legacy systems, but the interfaces of your new system and the legacy system might not match. In this scenario, add an adapter for the interfaces.

These are the approaches to add an adapter:

Add in the client side

This is more straightforward, but there might occur the following risks:
  1. Security risk: Since the client communicates directly with the legacy system, the client requires to put the legacy system outside of the firewall, thus it might be reached from browser side.
  2. Authentication risk: This risk might not be applicable to the client/server (C/S) client. However, in case of the browser/server (B/S) client, the JavaScript cannot be compiled. Therefore, it is not safe to save the credentials in the client side.
  3. Browser cross-domain restriction: For security reason, browser does not allow data retrieval from different domains, thus making it difficult the client to retrieve the data from legacy system directly.
  4. Decouple requirement: A change in the legacy system leads to a change in all the clients and retesting, which is not a good design.

Add in the server side

This design must work well, but it cannot resolve the binding too tightly issue. That means, legacy system interface changes might lead to the rebuild of server side.

Add in a separate application

The new application gets data from legacy system, and wrapper to the interface required by new system, then it works. This is a good design to decouple the legacy system with new system. Legacy system's change only leads to the change of the separate application, but not new system. External Data Services (EDS) is just the separate application.

Since custom panel created by PVD is only an HTML to run in the browser side, it is not safe to save those web service URLs, database links, or credentials.