Understanding SOA (Service-Oriented Architecture)

Dear All,

It’s been a while since I posted my last post. In this post I am going to walk you through the basic idea of Service-Oriented Architecture.

Many people get confused when they come across the word SOA, Well it’s no rocket science. Before understanding SOA, let’s understand what an architecture in the programming world is.

Architecture: An Architecture is just a fancy word for saying how do we lay out our applications.

Let’s have a little bit of idea about the history of Architecture before moving forward.

60's -70's: In 60's and 70's things were pretty easy, we had only one architecture. We just had a Mainframe and a dumb terminal from where users can access the Mainframe. The below diagram will give you detailed idea about it.

Mainframe 60-70's

Pros: Its easy, its single block. Your code is at one place and you know exactly how operate it without any trouble of dependency.

Cons: Scalability, this architecture is just fine if there are very less users but what if there are many users, there it will be a problematic as dumb terminal doesn't do anything at all.

80's Client-Server: In 80's lots of people started using PC's instead of dumb terminal. Still Mainframe exists but some of the things such as Presentation, some of the business logic and validations can be moved to PCs. So that it would take some of the load off from the Mainframe.

Mainframe is acting as data server and this Architecture is also called as Client-Server.

Client- Sever

Pros: Well here there is an improvement in scalability compared to earlier approaches as we have moved some of the stuffs from Mainframe to PC's.

Cons: The problem here is the maintenance. Let’s say there 1000 users who are using PC's, if I need to change some business logic or UI, I need to do manual changes to all thousand PCs. Another problem is all the PC in the large organization might be having different configuration with different Operating systems, so running your application on all of these would be challenging.

3-Tier Architecture: In late 90's and early 00's we came up with this architecture, here we reduced some of the problems of maintenance. Here we have 3 main parts. Server/Database, Application Server (where your code lives) and PCs, that's your browser.

3-Tier Architecture

Pros: The maintenance problem is removed here with app tier. So make change at one place and consume by all PCs. 

Cons: The issue here is with complexity. It’s very complex to coordinate with PC for changes and DB changes.

Finally, here comes the SOA in late 00's.

Service-Oriented Architecture: We can call SOA is evolution of 3-teir architecture. In SOA what we do is we divide the App tier into different parts and isolate them like independent parts and call them as web services. One thing I stress and one thing that people struggle when they try to understand what SOA is. SOA is not a thing, its set of certain technologies and set of rules combined together to make business development easier.

let’s understand this with an example, the best example could be typical Resource Enterprise like ERP, which includes multiple systems like Account Payable, Account Receivables, General Ledger and Purchase Order so on, to maintain all of these things ton lots of code needs to be written and different modules have to be created in app tier, rather doing that lets split them up and put them as separate part and call them as Web Service.

Simple task in this example would be credit check for the particular account of clients. In this, client credit check needs to be done, to do that let’s create a separate web service and consume it in App tier. If I need to make some changes in the calculation of the credit check for client, I just need to make the change in web service. 

The best part is, when I say credit check it can be useful to any of the applications who are dealing with banking. So if I make it as a separate part, any application can consume it. I mean other clients can also consume it based on some terms and conditions of the company. But if you keep it in the app tier only outside clients cannot consume it.

And Client who is going to consume the service need not to be in the same technology in which web service is developed. That is the web service written in .NET can be consumed by JAVA application and  vice versa, because web service take input in XML format and gives the output in XML format only. XML is understandable to any of the technologies.

Service-Oreinted Architecture

The current best live example could be PayPal services, most of the online shopping applications redirects you to pay PayPal service on click of Make My Payment. What it does is take you application Id (Flipkart, Jabong etc...), what’s the mode of amount deduction (credit card, online banking) and which bank. Then it redirects you to respective bank website and give you back the response on successful transaction.

It doesn't have to be that big service only, it can be simple part which you are using in multiple places of application also.

Why SOA is a such successful Architecture?

• Effectiveness and efficiency of Business-Level Services that are architected, designed and implemented
• Reuse Percentage
• Loose Coupling
• Frequency of Service Contract Changes

Benefits of SOA:
 Technology Point of View:

• More flexible architecture
• Integration of existing applications
• Improved data integration
• Supports business process management
• Facilitates enterprise portal initiatives
• Speeds custom application development 

 Business Point of View:

• More effective integration with business partners
• Support customer service initiatives
• Enable employee self service
• Streamline the supply chain
• More effective use of external service providers
• Facilitate global sourcing

Again, there are different ways to create the web services in .NET based on the requirement.

1. .NET Remoting

2. Web Services

3.Windows Communication Foundation(WCF)

I will be explaining WCF concepts in very great detail in my further posts.

Hope this helps..!

Thanks,
Ram