SOA – The Four Commandments

Recently, I got an opportunity to meet and chat with some very able and talented developers and architects here at our .Net user group – KolkataNet. As usual, we got into discussing technology. This time around the buzzword was SOA (Service Oriented Architecture). To my utter surprise, none of them (including me) were not able to come up with a decently ‘complete’ definition for SOA. I must confess here that deep down inside I was not very unhappy about it. I was glad to find that when it comes to SOA, I am not the only confused bloke (lol).

This set me out to dig deeper into this highly hyped term. And really, the crux of finding was that the so highly hyped SOA is nothing but just a natural growth of the craft of developing software. The craft has come up a long way from procedural to object-orientation to component-based and now to service-orientation. Of course, every stage has had its own compelling drivers to take it to the next one. Hence, SOA is no revolution, it is just an evolution. There are business (rather marketing, lol) aspects to SOA too. But let us limit our focus to SOA as software development approach.

So what is SOA? In order to qualify itself as an SOA, an architecture must adhere to the infamous Four Tenants of SOA. Which are:

Boundaries are explicit. Developers should define explicitly what methods/properties are going to expose to the client.

Services are autonomous. Services and the consumer application are independent. So in future if we need to modify or enhance the services feature then we can take the services offline and work with that. So this won’t affect the consumer application.

Share Schema/Contract not class implementation. We need to share only the schema to our clients. If should not share any implementation information in to our clients. For example, we should not ask them to give any connection string info in the attribute level, which will expose what database we are using for our service.

Compatibility based on policy. The services should define all the requirements in order to use the services. We should not have person – to – person communication about the services.

So next time when you profess to have implemented SOA, check against these tenants to make sure that you are not exaggerating.



Get rid of the “Manager” syndrome.

Are you one of those coders who often find themselves stuck on deciding a meaningful, explanatory name for their newly created classes? Do you frequently end up creating some “Manager” or “Master” class? If so, then beware! There is something wrong going in there with the vision and perception of your classes. Perhaps, you are asking your nice little classes to do too many things for you; they probably are losing their focus and are perplexed about their existance. Perhaps, you burden these poor fellows with too many responsibilities.

Is anything wrong about having a class to do more than one thing? Well, the Single Responsibility Principle (SRP) says “Yes” there is.

Consider the following class:

public void Save(Employee emp){…}
public List Get(){…}
public double CalculateGross(double basic){…}
public void NotifyEmployee(Employee emp){…}

This is the what the class does for you:

1. Saves the newly created employee object to the database,

2. gets the list of employees in the database,

3. calculates the Gross from the basic using the business rule,

4. Sends email Notifications to the employees.

Now if you were to give a meaningful, unambiguous and self-explanatory name to the class GiveMeName, what would you name it? Well, confusing … isn’t it?  The confusion is a very good indicator of the fact that we are doing something unfair to the class here. We are making the poor guy cater to too many responsibilities.  I bet the best name you can think (like me) would be Employee or EmployeeManager. This is where we lose the trick.

Try breaking the GiveMeName class into three small classes:

public void Save(Employee emp){…}
public List Get(){…}
double Calculate(double basic);
public void Notify();

These classes are much more focused and their names are beautifully self-explanatory and suggestive of their purpose and meaning of existence. They tell you why were they born and why do they exist. Thus there would be one and only reason for any of these classes to change, for, there is one and only one responsibility these classes cater. This will ensure Orthogonal code and hence maintainability of your code. It will help your code to stay closer to universal principle of programming – Tight Cohesion and Loose Coupleing.

So next time when you create a class and find that it’s name doesn’t come obviously to you, and you have to satisfy yourself with some “Manager” kind of name with your class, think twice, think if you have taken a leaf out of the book of SRP.

Test Driven Development

As a software developer I always found it very embarrassing to face the truth that my code is also entitled to have its share of bugs. I would find it so very irritating when I have worked passionately for hours to build something and a tester would walk-in with a sheet in hand and suggest “hey bro! You missed out”. I might argue with him but deep down inside I would know the fact that I have indeed “missed out” on something. This is one embarrassment we developers go through all the time but it is only us who could be blamed for this. We don’t think enough before jumping into the code.

There have been so many instances where I have felt like rewriting a piece of code which has become ugly over a period. These code would smell. But my boss would silence my itch with a question that “why would you want to finger something which is up and running?”.

While these problems had become a way of life for me, I came across a refreshing way of software development – Test Driven Development (TDD). TDD is a process pattern for constructing iterations of development projects that employ unit testing. It is a core tenet of “Agile Development”, specifically the Extreme Programming (XP) camp. Unlike the conventional approach to software development where coding is followed by testing, TDD requires to have the tests in place before writing any code. These test-cases serve as the specification and scope for the functionality to be provided.

TDD Life cycle

Add a test: Add a new test. The test must fail for the first time as because the test must be created before any the functionality itself.

Run the test: The test must fail for the first time.

Write code: Write code to develop the functionality.

Run the test again: All the test written for the functionality must pass indicating that all specifications have been met. If not, refactor the code until all the tests pass.

TDD requires developers to think and think hard about specification and scope of the functionality to be developed before writing any code. This ensures that a good deal of brain storming going into understanding the problem before making any efforts to solve it.
Refactoring code is a risky affair because you can always run into this risk of “breaking something while making something”. Having unit-tests in place gives developers the cushion to refactor code confidently. After making the code change the developer can simply run the automated test and to ensure that everything is alright.

Coding for testability demands a much more civilized design to be in place. The code must have “Separation of Concerns” clearly defined. It must be orthogonal. It must follow “Dependency Inversion” Principal. A code not easily testable simply suggests a flaw in the design.

As a newbie, I found writing TDD a little time consuming and cumbersome. But as I get more and more used to it I can really see an increase in my productivity and improvement in the quality of code that I write. The benefit that I reap by investing a little extra time is huge. It’s definitely worth a shot.