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.
Those two cannot be compared because each describes a different thing. Also, be aware that Tier is not the same as Layer.
Tier - process boundary. When you build 3-tier applications you know that UI, BL, and DB will be in 3 different processes which can be on three different machines.
Layer - logical boundary. A 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 the meaning of reusable autonomous interoperable remotely called components. SOA services have to follow four tenets.
To show a simple difference between N-Tier and SOA, let's assume that you are building a service layer on the top of business logic which uses some database. It looks like you are building an N-Tier SOA application, doesn't it? Unfortunately, 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 a database, they don't have an explicit boundary and they are not autonomous => the application is not designed as SOA.
There is also a difference between small SOA and large SOA. Mentioned application is a small SOA - each service has to follow tenets. Large SOA is for enterprise integration where you count applications with all its services as a single unit which has to follow tenets.
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
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.
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..
Related
The main use of SOA from what I have experienced is in Reusability of services and promoting business agility by connecting disparate systems. Is there other major importance. If yes, please state them?
I am looking for an answer which can make a novice understand what is SOA when you explain about its importance to him.
SOA is an architectural style, may be realized by web services, but SOA is not just about web services. Web services are all about exposing the implementation in a standard way, whereas SOA is concerned about integration.
It basically aligns your IT infrastructure towards the changing trends in the business.
Let us look at a simple scenario:
Let's say there is the company that has its IT infrastructure first developed in the late 80s and was completely running on the mainframe. IT dept had many alternatives to the mainframe, but since they are of different technologies, they follow different protocols, and so communication cannot happen directly. They need some sort of layer in between that acts as a translator. So, the IT department had to write the intercommunication layers to talk to legacy code, Everything went on well until a point when the competition in the business grew so much as of now where the same system is interacting with MDM, dot net, infra services etc.
All those cross-technology interactions had become too much to IT dept, both to develop and maintain.
So, SOA is like a set of standards that have to be followed while building the business application which enables applications to be cost-extendable, flexible and makes the overall application cost-effective.
I am trying to implement modular design in an asp.net project dividing the application into different modules like HR, Inventory Management System etc. Since I am trying to keep different modules independent of each other, I separated these modules in such a way that each module is a separate Visual studio solution having UI, BLL, DAL and even a separate database schema.
Up till now I thought this as a common practice for developing Management systems and ERPs but I am searching the web for last three days but hardly found any help full stuff regarding developing modular applications. Most of what I found is mere theory explaining the concepts of cohesion and coupling but not real world scenarios. So I wonder
Is it the right approach of separating modules?
How the real world modular applications are developed?
How should the different modules communicate with each other yet they stay independent of each other.
I think there should be a core application which makes use of these modules, how should the core application communicate with these modules?
There is some data, entities , objects which are common to each module, should I put them in the core modules in order for other modules to use them (I think this will make the modules coupled to core) or should every modules maintain its own copy of data + define those object, (which I think voilates DRY)
Any thoughts, links are warmly welcome.
This is a personal opinion and is debatable.
I separated these modules in such a way that each module is a separate Visual studio solution having UI, BLL, DAL and even a separate database schema.
Sounds like a total overkill. Abstraction over abstraction makes your application pain in the neck to maintain, support, and enhance. Is it that large that you need to separate modules into separate solutions?
Is it the right approach of separating modules?
No, I think it is a total over-engineering. I would suggest using projects to separate modules. And not separate solutions. The problem with solution is that it will require external dependencies management tool, which requires a lot of effort to bring in and later maintain.
How the real world modular applications are developed?
Using abstraction (interfaces and abstract classes) and separate projects.
How should the different modules communicate with each other yet they stay independent of each other.
By using interfaces, DI, IOC, TDD
I think there should be a core application which makes use of these modules, how should the core application communicate with these modules?
Core does not communicate with modules. In fact it should ideally not depend on any other project/library. This makes it simple to reference and use in large solutions.
There is some data, entities , objects which are common to each module, should I put them in the core modules in order for other modules to use them (I think this will make the modules coupled to core) or should every modules maintain its own copy of data + define those object, (which I think voilates DRY)
I would highly recommend using a single copy from the Core project. See this questions for details of why.
This is one of those topics that is entirely subjective for the most part, but you may wish to consider a SOA (Service Oriented Architecture).
Using SOA, you can define a service (for this example, I'll stick to web services, though other service types exist depending on requirements) for each business area - an HR web service, a projects web service, a finance web service and so forth.
You can then bring all these together with a front end system that will communicate with and utilise these services, that would normally be your core application, though depending on your needs and requirements you may opt for multiple front end systems.
For the front end system I would recommend using ASP.NET MVC which has the concept of areas and will let you separate the front end into specific areas - an HR area, a projects area, a finance area and so forth that will contain the models and views for each specific area.
Doing this will let you build in a modular manner, you can build your first web service, say, the HR web service, that has methods for getting relevant HR data and so forth, and then build the HR area of your MVC application. Expanding then simply depends on building the web service, and creating the front end in the MVC application. There is nothing stopping say the HR area then accessing the finance web service if it needs finance information, but it still keeps everything in distinct independent modules.
Using this method can also be helpful in aiding future interoperability - it may be that other systems in the company will find it useful to interact with certain web services. For example, in a previous role it was useful for the companies engineering software to integrate with the projects team web service as it allowed for engineering related information to be linked to it's related project.
If the system grows in terms of resource requirements it should also be fairly scalable as it is trivial to say, offload the projects web service to another service if it starts eating a lot of system resources. It also allows you to switch modules out if need be - if you ever decided to move to say, a Linux/Java platform, you could trivially move by porting module by module with no real interruption of the overall system.
But of course, as I say, this is simply one such option and much of it depends on the specifics of your circumstances.
It is too late to answer but it seems interesting.
Since I am trying to keep different modules independent of each other, I separated these modules in such a way that each module is a separate Visual studio solution having UI, BLL, DAL and even a separate database schema.
It depends on your scale of application. If you create a very small-simple application with a little functionality, then it is safe to has a combined assembly. Or if you want, just separate the UI with other module. At least it can help you to emphasize SOC. Keep in mind that loading multiple assembly can be slower than a single assembly.
Is it the right approach of separating modules?
Module separation always has a drawback, that it is require mapping. It means slower performance in general (maybe negligible, but still there is), and slower development time. If your application will be large and complex enough, it is worth it, since you can create modular unit tests for each module.
How the real world modular applications are developed?
No exact practice though, every problem needs a solution. You won't need a heavy multi-threading or dependency injection architecture for a simple calculator application.
How should the different modules communicate with each other yet they stay independent of each other.
Using interface. You can make the implementation different later on. Example is, you currently use C# Winform for your application, communicate to the BLL using interface. Later on, you want to migrate to ASP.Net, then you just change the implementation, but keep the interface to communicate with the BLL the same.
I think there should be a core application which makes use of these modules, how should the core application communicate with these modules?
There is some data, entities , objects which are common to each module, should I put them in the core modules in order for other modules to use them (I think this will make the modules coupled to core) or should every modules maintain its own copy of data + define those object, (which I think voilates DRY)
I assume it is an enterprise level application which share the same modules / data such as employee. If it is really need to behave uniformly, then you should provide the very basic logic at the core Level. At the application / implementation level, you may has different implementation to fulfill each requirement.
Do not force to uniform all of the business logic to the core. If a specific application need a different implementation, it is hard to make the core configurable.
Ok, So I have been taking in all sorts of great information about MVC, EF4, Repository Pattern, UoW, Service Layers, etc and now I am going to attempt to put it all together.
My question is, How should these be separated?
I was thinking projects like this:
1) Application - MVC App
2) Repository Layer
3) Entities - EF4/Partial Entity Classes
Any suggestions would be great!!
Thanks,
Sam
Here's one example of how you could structure your application:
Domain Models (Primary POCO objects)
Repositories (Implementation of some data access technology depending on the project requirements : EF, NHibernate, LINQ to XML, Remote web service calls, ...)
Service (business operations aggregating multiple CRUD operations into a business operation that will be exposed with the domain objects)
ASP.NET MVC application (Controllers, Views, View Models, Mappers between the Domain objects and the view models)
This layers could represent a physical separation (assemblies) or logical separation into the same assembly.
Don't separate code physically until you have a physical reason to do so such as deployment or code sharing reasons. Use folders and namespaces.
I've just been through this myself and by far the best approach i found is S#arp Architecture.
Excellent templates generate the project scaffolding for you and they have a good explanation why u really do want physical project separation. Good argument here. Theyre tutorial shows how TDD with this model is a breeze.
The beauty of this model is the separation of concerns it offers so if you did want to use EF, its a snip to swap out NHibernate.
I am Developing a mid-size application and want to implement Application Architecture, I've read some Architecture Books and Approach and think about
AAFN (Application Arcitecture For .net) presented by Microsoft
SOA
SDLM
SDO
MVC
and vice versa ...
this is a web application that will extended with some other small application ( just think about something like a M.I.S with a (or two) core)
Whitch Projects I should have I think about
Common // to use in all projects
Framework // main framework
DAO // data access object ( entityframework or nHibernate )
UI // will available in 2 variant web and windows(wpf) interface )
BusinessEntities // all subApplication project logic will goes there
ApplicationNameProject // each application have their Own Logic (in BussinessEntities)
ApplicationUnit // each application Entity will place here
ApplicationNameProject // each application data Entity (in Application Unit)
Services // WCF Services goes here to contribute with all applications
this is the architecture witch I think about, I do not have any force to use this, I want to know whats the best fit for me, can Change all of it or add some other projects and remove these projects
any help appriciated
There is no "best small or mid-size application architecture" as a silver bullet to fit any project, so drop that idea right now or you'll be in for a world of pain down the road.
The architecture for any given project will fit the purpose of that project. In some cases, ASP.NET WebForms with a direct queries into the database will be the most appropriate architecture, in some cases MVC will be the right architecture, in some cases a windows forms application built on top of a web service that connects to a relational database through an ORM like LINQ-to-SQL or NHibernate.
You can't decide on a one-architecture-fits-all approach, it just doesn't work. Each architecture has its merits and weaknesses and thus projects for which it is well suited and projects for which it should be avoided. You should pick the approach that makes the most sense for the current project/scenario.
Given that however, I tend to take a fairly uniform approach.
If I need a quick utility project that does a very specific thing and is highly unlikely to be needed for anything else, I might use a console application with queries against my database hardcoded.
If I need a common set of queries that I'm likely to need from multiple projects, I'll write them as stored procedures to get the performance benefits and build a data access layer that will leverage these stored procedures to give me standardized business objects, in a standard DAL (data access layer)/BOL (business object layer)/BLL (business logic layer) approach. This is advantageous because it means that once I've got this set of libraries built I can float any application over the top - for instance a webforms or MVC application.
MVC is advantageous because of separation of concerns - your controller can interact with your business library simply to access the data it needs and your views are really just that - a view of the data that the user can interact with. The views do nothing more than take the current data view to the user and transport any data changes back from the user to the controller - no logic is held in the view and as such it means that it's far easier to unit test and make changes to components without affecting the rest of the application.
The drawback to a multi-tiered or multi-layered approach like this though is that it takes time to architect it properly and if you're only after a throw-away utility application like they demonstrate on stage at developer conferences then this is complete overkill and I wouldn't bother with it.
Think of it like this: Every layer, every library, every component requires justification. If there is less justification for than against, then don't do it. The key is not to do something without reason - anything you do is correct providing that you have a well thought out reason for it, and by well thought out, I mean that you've found very good reasons for and against and you've made an educated decision, you've not made a decision based on half thoughts, or worse, no thought at all.
Anything but the most trivial .NET application should have several projects: a UI layer, some kind of business logic layer, a persistence (storage) layer and accompanying test projects. Each project should interact loosely through interfaces.
In general you should create the minimum number of layers you need to make your code testable and easy to understand.
To figure out what the minimum is that you need it can be a good idea to let your tests drive the internal design of the system. Each layer should have tests in its own right, with (possibly) the exception of the top HTML layer and the bottom SQL layer.
With that in mind it helps to separate concerns as far as possible. For example SQL queries should almost never be in the same block of code as HTML support: split things into multiple layers that each do one and only one thing. This makes changes easier.
Be aware of the difference between systems architecture (where loosely coupled Web services using e.g. REST interact) and the internal design of the system. It's a good idea to decouple the Web service interfaces (as consumer or provider) in their own layers as this is an area that often changes.
These designs are an art that's best learned by practice. With good unit tests you should find refactoring an application design fairly swift, so it's a good idea to look at technologies like Spring.NET or other inversion of control containers to make this easy.
I have a web application that is arranged into data, business and UI projects. As the system evolves changes are deployed by building all three projects and deploying them in one package. This has worked well and has allowed the illusion of “three tiers” without tackling the communications, versioning issues of truly separate systems.
So along comes a request for XML summaries of some of the data and my thoughts turn to a fancy WCF service that, one day, could be my “Web API” (ahh… the mind.. what a evil little monkey it is). So, assuming this survives the “is that really the best idea?” test here is my question:
What structure have you had the most success with when posed with two
evolving “clients” serving content from a single evolving “model”?
James, your question is rather board as there are a large number of variables that go into choosing the right type of architecture for your needs. I would recommend reading the patterns & practices Application Architecture Guide 2.0 to better understand the options and pick the best one that suits your individual needs.