Saravanan’s musings and scribbles

Look at this link if you want to understand the JBOSS Architecture. Initially I was under impression that JMX is used only for management and monitoring. But the JBOSS architecture shows how powerful is JMX and how it can be used to enhance modularity in your applications.

In my earlier post, I discussed about how the configurations can be managed in an enterprise application easily. This is an exclusive post to discuss about the configuration management best practices based on my experience.

1. Put comments for every configuration parameters. This applies for configurations as it applies for code. The operations team who will manage it cannot understand it without comments. Also if new instance is setup, you may not be involved and comments will help operations to decide the new value.

2. Where ever possible, put the example values in comments and how the application will be behave if the value is changed

3. If the configuration file is shared with other components, maintain a copy of parameters used by your application. This will help you if you want to maintain the configurations separately.

4. Though java properties files are good, to maintain large configuration information, I prefer Windows INI format for its grouping. Let the configuration readers return the values in java properties format.

5. Have a singleton configuration loader to manage the configurations. Application will always get the value from configuration loader and NOT cache it locally

6. Implement JMX console to refresh configuration values in singleton loaders so that application need not be restarted.

7. You can also put a monitor to load configurations if the file is modified. This will avoid the server restart to apply the new configuration values.

8. The last but the most important one – NEVER modify your configuration file without taking a backup. If the file gets messed up and without backup, your service will be severely impacted and you cannot meet your SLA.

User experience in SOA is the delight your service consumers have while using your service. First time service providers find it very difficult to match the user expectations leading to integration issues and schedule impacts. The main reason for this is the way the service is visualized by the provider. During the API design, the first time designer does is to think the service from his web application context and expose fine grained APIs which cannot be used by different consumers. These fine grained APIs restricts the API usage during integration with other services. The following are the guidelines I learnt by mistakes which will help you in improving user experience of your API.

1. Never expose a fine grained API unless and otherwise required.

2. Document, Document, Document

3. Don’t change the exposed API signature. Changing API signature will be nightmarish if you have fine grained APIs and is under usage.

4. Exceptions – You can use Runtime Exceptions but document it so that consumers can catch if needed.

5. Log, log, log – Log everything at API level. What comes in and goes out has to be logged. Never assume anything as trivial and skip logging. Storage is cheaper than spending hours in support and debug. If someone complains about your service and if you don’t any log to prove it wrong, till you prove you are culprit.

6. Keep track of your consumers and understand how they access your service. If the way they access is very much different, include unit test cases to check the connectivity if you change your container or argument names.