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