My experiences with SOA-part II: Principles

It has been quite a while since I published a post on my blog. As usual am held up with tasks both on the work and personal front and added to that the festival season had brought in some travel and leisure.

Well, in this entry am supposed to cover the principles of SOA. So, what essentially are the priniples of SOA? The following are the set of widely accepted principles of SOA:
1. Reusability
2. Loosely Coupled
3. Abstract the logic underneath
4. Composability
5. Autonomous
6. Statelessness
7. Discoverability
8. Possess a contract

Keep in mind that it is all about services. These principles are inter-related to each other. In the next part, I'll cover how we started on this project, the role of ESB and something on the unit testing and CI.

Architect and Army general

An interesting post on how an architect should be - The Architect Said What

An interesting article on Scripting languages

Came across this article on CIO.com that considered the various scripting languages - Ruby, Python, Perl, Javascript and PHP and provided info on where each language fits the best. The opinions from experts like Zed Shaw and Martin Aspeli. It is very good read, the article is here

Web Services, Security and SocketException

I use Soap UI for testing my web services and one service exposed to our clients is SPNEGO enabled and whenever I test this service using Soap UI there is an error - java.net.SocketException: Software caused connection abort: recv failed. The reason for this error is mostly due to the client side settings, network issues, windows socket binding, server side shared JVM. In my case it got resolved when the Http Settings were changed a little on the Soap UI HttpSettings. I just enabled the Pre-emptive Authentication and I could successfully consume the web service. This service is consumed by applications written in Java (Axis2) and .NET. We have advised out clients to increase the time for Socket timeout and enable pre-emptive authentication to avoid any potential issues in the future.

My experience with SOA - part I: Myths

It had been slightly over an year since I started working on a SOA project and people have been asking me to share my experiences and learnings. I decided to write a series of posts on my blog focusing on one aspect everytime. In this entry, I'll address the myths about SOA.
1. If your project has web services then you are doing SOA: Funny does it sound, isnt it? I have been hearing this statement for a long time. Web services is just an architectural style that facilitates achieving the fundamental principles of SOA.
2. ESB is SOA: another popular myth. SOA is technology neutral and is not coupled to one particular way of doing it. This myth defeats the core principles of SOA - loose coupling and vendor diversity.
3. SOA is out of the box: Well, SOA is not the panacea to all the business problems. There is no out of the box product that guarantees this. There is a popular myth that simply wrapping the legacy systems with web services to achieve SOA.

The above myths are mostly from a technical perspective, I have not touched upon myths from a business angle. There are myths that SOA is easy (umm, I wish it were that easy), SOA is very expensive, SOA is always a flop, etc.

In the next post, I'd cover the core principles of SOA.