Trekking at Wayanad January 11, 2007
Posted by Saravanan in Personal.6 comments
Last weekend we went to Wyanad for a short trip and enjoyed the trekking through unexplored routes. We started from Bangalore around 3:30PM on Friday afternoon and reached Kalpetta at 8:15PM. Roads were good expect for few places. It took another 90 mins and 23 KM drive to reach RestInMist, where we stayed. On Saturday at 9:30 AM, we started trekking through streams, rocks, thick forests, swamps, pepper estates, leeches to reach a waterfall and returned at 5:30PM. It was an amazing experience.
Our Trekking
Improving user experience in SOA January 5, 2007
Posted by Saravanan in Programming, Software.add a comment
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.
How to be a programmer January 3, 2007
Posted by Saravanan in Software.add a comment
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.
Software Services Management in high SLA environment January 2, 2007
Posted by Saravanan in Software, Technology.add a comment
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.
