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.

Whenever I read the article “How to be a Programmer: A Short, Comprehensive, and Personal Summary“, I find it new and get a new perspective. A must read for all working in software and IT industry.

SOA is touted as it going to remove all the integration pain points. But with disparate technologies and platforms supporting the services within the organization, managing the softwares is a big pain. Managing the end points and configurations to support *ability (maintainability, extensibility, availability… ) are becoming a operations nightmare in managing them in high SLA environments where penalty clauses are included for service non availablity. Everybody will prefer a platform where services autodiscover others and manage the connectivity themselves during failovers. You can incorporate this when you are working on greenfield project or with a refactoring budget. But during the course of a release, if you (as a developer) want to refactor to make your life better, you can put the following things which will help both development and operations. The following is mostly based on webservices. I will put another post for ESB models.

1. Separate the application and connectivity configurations. Let the operations manage the connectivity configurations. Application configuration has to be managed by developers and released to operations. If a application configuration changes frequently, let operations handle that parameters. Configuration loader has to manage it intelligently.

2. Put singleton configuration loaders to load the configurations and have a JMX or similar module to support refreshing. With this we can avoid restarts in high SLA environments.

3. Put the heart beat monitors to check the health of other services. By taking proactive steps, we can minimize the impact due to non-availability.

4. Put a seprate monitor to monitor the health of your service. With this you will not let down your consumers during a critical work flow.

5. Design the application for failover.