What is the difference between N-Tier and SOA architecture

Question

As per my understanding regarding N-Tier and SOA architecture.

N-Tier

N-Tier means dividing application into layers, Example I am developing application in asp.net and I pushed total DB Layer to WCF then it is called N-tier.[Tightly coupled]

SOA[Loosely coupled]

As per my understanding regarding SOA its very generic term and how well we going to loosely couple our architecture then its called SOA. Best example for SOA services - Stock feeds/ weather feeds.

My conclusion:

Even though if we develop application using WCF it does not mean its SOA if it is tightly couple with single client/ or .net applications only can understand about services.

Can you help me in understanding of SOA VS N-Tier.

Answer 1

I think the main point to SOA (as compared to standard N-Tier architecture) is re-usability of the underlying services. That is why you create web services to serve as your data sources with the intention that they might serve other applications that you will write in the future. This is where the aforementioned loose coupling comes in very handy - your web services are generic enough and independent enough to be used in many different applications.

Answer 2

Hello,

those two cannot be compared because each describe different thing. Also be aware that Tier is not the same as Layer.

Tier - process boundary. When you build 3 tiers application you know that UI, BL and DB will be in 3 different processes which can be on three different machines.

Layer - logical boundary. Single tier can contain multiple layers. It is just the way you build your application to follow OO principles.

SOA - SOA application can be multi-tier and multi-layer but generally it doesn't have to. SOA is an approach to architect the application in meaning of reusable autonomous interoperable remotely called components. SOA services have to follow four tenets.

To show simple difference between N-Tier and SOA lets assume that you are building service layer on the top of business logic which uses some database. It looks like you are building N-Tier SOA application, doesn't it? Unfortunatelly not every application exposing services follows those tenets. Probably the most critical in this case are "Explicit service boundary" and "Services are autonomous". If your services share some business logic functionality or data in database they don't have explicit boundary and they are not autonomous => the application is not designed as SOA.

There is also difference between small SOA and large SOA. Mentioned application is small SOA - each service has to follow tenets. Large SOA is for enterprise integration where you count application with all its services as single unit which has to follow tenets.

Best regards, Ladislav

Answer 3

Think about it this way: an SOA service is something that the data access layer in your N-Tier application could call but it is also something that the data access layer in my N-Tier application could call. However I probably wouldn't use your data access layer in my application.

For example:

Your data access layer for working with employee time sheets will be tailored to your application related to time sheets.

My data access layer for working with employee quality of work reviews will be tailored for the functionality of performing employee quality of work reviews.

However, both of our applications as well as any other employee related applications could benefit from an SOA service that works with core employee data like Employee ID, Name, Cubicle Number, etc..

Answer 4

Ladislav is spot on the money, and you are correct in your assumption that by using WCF alone you are not guaranteed of building a SOA.

Here are some practical examples of how to build a SOA using WCF.

I would suggest you read articles by Thomas Erl and Roger Sessions, this will give you a firm handle on what SOA is all about.

SOA Design Pattern

Achieving integrity in a SOA

Why your SOA should be like a VW Beetle

SOA explained for your boss