JavaEE solution configuration best practices

前端 未结 6 1874
余生分开走
余生分开走 2021-02-04 07:48

We build 3-tier enterprise solutions that typically consists of several webapp and ejbjar modules that all talk to a db and have several external integration points.

Eac

6条回答
  •  [愿得一人]
    2021-02-04 08:49

    I know this has already been answered and my answer is not necessarily generic, but here's my take on things:

    Note, here I'm only considering system/resource properties, not application settings. In my view, application settings (such as a payment threshold or other settings should be stored in a database, so that the system can be reconfigured without having to restart a service or cause downtime by re-deploying or re-reading a properties file).

    For settings that impact on how different parts of a system connect with each other (such as web service endpoints, etc), I would make use of the JNDI tree.

    Database connectivity and JMS connectivity would then be set-up using the Websphere console and can be managed by the Websphere administrators. These can also be created as JACL scripts which can be put into version control if necessary.

    In addition to the JNDI resources, for additional properties, such as usernames for web service calls to a backend, etc, I would use Websphere "Name Space Bindings". These bindings can be edited using the Websphere console and accessed via JNDI using the "cell/persistent/mypassword" name.

    So I could create the "mypassword" binding (a string), and the management for it falls to the Websphere admin (away from developer eyes or other people who should not have access to production systems), while the same EAR file can be used on dev, test, preproduction and production (which is preferable to have different EAR files for different systems, as the likelihood of other differences creeping in is reduced).

    The Java code would then use a simple JNDI lookup (and possibly cache the value in memory).

    Advantages over properties files:

    • Not having a "vulnerable" file that would need to be secured because system properties contain passwords.
    • Not having to add Java security policies to allow access to that file location

    Advantages over database properties:

    • Not tied to having one database tied to an application server.

    Hope that helps

提交回复
热议问题