I have been developing n-tier applications using .NET for many years. But I still have no idea how to distribute the tiers/layers (dll) to other servers.
Let say, I have an MVC web application with 4 projects, i.e. MVC (UI), Business, Service and Data. Everything works fine if all class library dlls are in one server.
If I want to scale out the application by distributing the Service layer (dll) and Data layer (dll) to other 2 servers, should I convert the class library to WCF Service Library project (with TCP or pipe as communication protocol for better performance) ? Or should I use other technology like .NET remoting or Web API?
Will that be a lot of work?
Is that one of the purpose of creating multi-tier application?
Thanks.
Update:
Do you have any links (from Microsoft) that explain in detail how to scale out an n-tier architecture application to multiple server by distributing the DLL?
If I want to scale out the application by distributing the Service layer (dll) and Data layer (dll) to other 2 servers, should I convert the class library to WCF Service Library project (with TCP or pipe as communication protocol for better performance) ?
Yep, since they are on different machines, you need some kind of communication mechanism that goes beyond simply DLL invocation.
Or should I use other technology like .NET remoting or Web API?
Which approach you choose depends on many factors like complexity, performance...There are many options like
WCF webservices
Simple REST calls with WebApi
a message bus i.e. NServiceBus
...
Obviously remote calls will also be slower having a potential impact on performance etc.
Will that be a lot of work?
It will be more work and in my opinion that "more work" should really be justified. Keep your architecture as simple as possible or better, only as complex as really needed.
An alternative approach could be to have some deployment pipeline that deploys your entire application on different server instances and have some intelligent load balancing strategy. The only thing you need to pay attention to in that case is to properly share the sessions between your instances (stateless would be better ;) ).
My 50 cents...
As far as I know WCF replaced .NET Remoting (MSDN).
Anyway... Someone before me said. If you don't have to scale the application, do not do it. Communication cost alone between services of any kind will slow things down considerably. Probably to extent, where it would be slower than it is now (which I am assuming is the reason for scaling).
Prior to scaling, I would first see where the bottleneck really is. For instance, if the problem is your DB server, then moving services and data layer to another server is useless, as you will still be using the same database. So, you need to first find out what your bottelneck is.
The easiest and least painful way to scale (in my opinion) would be to just add another IIS server and a load balancer that would direct traffic to either one of them. You would need to store sessions in a database or use dedicated server, but that is about all the change you will need. Plus, if one of your server fails, one will still operate.
By default, avoid premature optimalization.
If you have a only web site, I would keep it as simple as possible and only create logical layering. There are a number of options: typical 3 tier, onion architecture etc. The key is that later, if really really needed, you could still refactor your code and make your data layer a separate physical layer. But unless you are creating a new Amazon or something, this will probably not be the case.
If you are in the situation, for example, that you have a web site, but also have to expose a web api; you could choose to have the web site consume the web api. In fact, your web site would then become a very thin layer (maybe not even using ASP.NET MVC) because most of the logic would be in the web api.
PS - .NET remoting is old technology, consider WCF or Web API instead.
Related
Please forgive the newbie question. I've spent the last three hours researching this, and I can't quite find the right answer, or perhaps I just don't believe it's as simple as it looks.
I need to deploy an application such that an application on the server-side does the heavy lifting, database wise, and the client-side version is fairly lightweight.
I have built a Data Access Layer class library (or at least a dll) that does all the heavy lifting. I have built a Windows Forms application that could serve as the lightweight client. They see each other. They talk to each other. They work happily together.
I'm kind of hoping all I need to do is put the dll on the server, point the reference to it in the client, and all will be well. The dll will run its code on the server, using server resources, and the client will run on the client. It's what the various websites seem to suggest, but it looks too simple.
Do I need to configure something like remoting on the server? Do I need to use System.Runtime.Remoting for something? Or is it really as simple as it looks?
Again, please forgive so basic a question.
what you are trying to do is build Client/Server application,
where you have
Client
client domainDomain
server Domain
Dal
Data
you will need to enstablish http conntection between client domain and server domain .
the common way to do this is using WCF
Explain the different tiers of 2 tier & 3 tier architecture?
http://www.codeproject.com/Tips/642296/Hello-World-Basic-Server-Client-Example-of-WCF
http://www.codeproject.com/Articles/14493/WCF-Basic-Client-Server
oh and welcome to stack overflow!
Well, you could use System.Runtime.Remoting, but that is a deprecated technology, i suggest using WCF for communicating between the client and the server.
I am at the start of a new project but I am not sure about some architectural choices.
I was hoping that you guys could share me your vision on this.
The client wants an internal website to manage their clients, projects, stock/products,…
Next to this they also want a website for their clients where they can view the products and order them. So for the external website only a small part of the db will be queried while the internal website will be much bigger.
At first I was thinking about using a WCF service for all businesslogic and repository.
But now I am not sure since I know that only a small portion of the actual logic will be used for the external part.
Using WCF as an extra layer always brings a shitload of extra work and complexity to the project. Is it better to just reference the business/repository layer in both website projects or make use of webAPI in the external website?
Really I need to hear some other opinions before I decide what to do.
There is nothing inherently wrong with going WCF, business layer assembly, or Web API. All have pluses and minuses.
WCF would make the most sense if you may someday have a many different clients needing access to the data/business logic and these clients may need to communicate differently (i.e. HTTP, MSMQ, full duplex, etc.)
Business Layer assembly would make sense if you are quite sure the data/business logic will not need to be accessed by clients other than the 2 web applications you are developing. That's not to say you're boxed in doing this though either. You could always start here and later remove reference to the assembly, encapsulate access to the assembly within WCF or Web API, and then reference WCF or Web API from web applications.
Web API is a good choice for several reasons. It provides the ability for many different clients access to the data/business logic without all of the overhead that comes with WCF. Additionally, if you have non .NET clients you need not worry about some of the tweaks you would have to potentially make on WCF bindings. You can also take advantage of some of what MVC provides you within the Web API such as model binding and validation.
I'm developing an ASP.NET web site with a n-tier backend utilising nHibernate - all good. As part of the development a large portion of the Interface will be written in Flash or more specifically Flex 4.5. In previous projects I would've created a webservice to broker data and actions between the Flash Interface and the business logic, however I'm looking for a more flexible solution that would allow data / objects to be easily passed to and from the service endpoint without too much redevelopment and with the onus of easy consumptionby Flex and others.
Enter WCF that seems to provide a robust server-side solution where we can use the existing POCOs in the business layer that can be easily serialised across the wire, amongst other things. Unfortunately I'm unsure (and inexperienced in this field) at the best direction to enable the communication from my C# WCF webservice to my Flex application, there certainly seems a few directions but without a clear and concuse path to take.
I would also like the service to be able to communicate to other non-Flash clients so locking myself into one particular route is something I would like to avoid. After some research I believe the best approach is for the WCF service to output lightweight data (i.e. JSON) or POX that should be easily consumed by Flex and other clients. Unfortunately my prototyping has been rather frustrating where the only end to end route I've got working is to Import the Webservice into the application and setting the WCF service to use basicHttpBinding, something I believe I should be avoiding as we need to implement somekind of security and the desire to keep communication as lightweight as possible. In addition, File Uploading would have to be factored in at some stage.
In short, what is the best method to have Flex communicating with WCF (and that's even if WCF is better than say ASMX) given the brief scenario above? In addition, I would really appreciate any tutorials or links that would demostrate an end-to-end system.
Thanks in advance - S
Flex has all problems and I wish flex and flash die soon if adobe is not keep up with today technology. I had a same problem to integrate ArcGIS-flex > WCF > CRM(Oracle). I found a solution with third party. This may help you if you decide to implement your solution using WebOrb
http://cookbooks.adobe.com/post_Connecting_Flex_4_with_WCF_Services-17006.html
http://www.themidnightcoders.com/products/weborb-for-net/developer-den/technical-articles/flex-net-integration.html#c1057
Is it wise to build a large application entirely based off SOA? Or just some portions? User account logins, accounting, gis mapping, sales, etc?
In other words, would it be wise to build a GUI to such an application in HTML & Javascript which does all it's exchanges via ajax to .NET web services on the back-end?
I can't see it worth loosing all the .net .aspx functionality such as forms authentication, view state, etc. But my co-worker is saying if we are going to go SOA there is no need for .NET on the front end. But i think there should be some sort of balance. Where do you draw the line? Should all calls to the database go through the web services?
I just want to say that "with SOA we’re building for change, while with Traditional systems engineering, we’re building for stability."
The problem with stability, of course, is, it only takes the business so far — if the organization requires business agility, then they’re much better off implementing SOA.
So, It solely depends on what you want to achieve, you are the one who should draw the boundary.
I read it in article on SOA few days back as I'm too working on SOA.
EDIT:
Meanwhile I came across this article and thought of sharing with you.
The video quite explains the current scenario of SOA and its views by different people.
I'm getting the words of the song 'If I had a hammer' coming to mind. SOA is an architectural approach to develop software as a series of services. In my opinion this is best for systems that have less than immediate latency and limited bandwidth, and high cost in access etc (these are all obviously highly subjective). You don't need full SOA just get loose couping between components which I would argue is a good goal to achieve.
DB calls can go through a service, take ADO.NET data services for example however you really have to weigh up with what the service is to provide. Take caching. A decent approach to SOA will consider that data is may need to be cached to reduce service load. So can your data be stale in the UI? Are you allowing that use case? Is right for login info to be stale (a rough example I know but possibly something that may need to be addressed).
All in all - it depends. I think some things lend themselves to SOA very well. If you take a DDD approach then the services that represent Domains would probably do so. In this way your UI talks to domain services and not rows in table as the DB is abstracted behind domain services.
Don't use one methodology to solve all problems.
See this SO question too
It's a service oriented architecture, not a service exclusive architecture.
Presentation logic and plumbing have to live somewhere; it all depends on where it makes the most sense for it to live.
For example, let's say you have a UI component that relies on a highly chatty but efficient set of calls to a database to generate a complex analysis of something (take your pick). If your web browser is making all those calls, you introduce massive network latency and concurrency issues. If a web service makes all those calls, you are potentially putting presentation logic into it to format that result.
If you are using Session state (or web services period), you are essentially using ASP.Net anyway. Try uninstalling it and see if your web services still run.
If presentation logic needs to live on the server side, it is better for it to live within a framework intended for presentation rather than a web service, IMO. If you haven't looked at MVC 2, do so. It makes it incredibly easy to set up an application that melds browser and server UI support (for example, jQuery validator controls backed by server-side validation).
Conversely, the web browser provides an expressive platform. Assuming browser support and team knowledge, the AJAX/SOA architecture you describe is a good one. I'm using it more and more and trying to make my server pages cleaner and simpler but I have no plans to exclude ASP.Net from my toolkit any time soon.
Client implementation should be completely disconnected from the back end web service in a SOA. The service should be able to be consumed by ANY client. If you are using .NET on the back end and front end because they can be coded to directly communicate, then you are missing the point, because now they are tightly coupled and what you have now is a stove pipe application. The client should have no idea how the server side is implemented -- shouldn't matter if the back-end web service is built using .NET, Java, or whatever.
In a true SOA, you should be able to search for services in the services repository, perhaps tie the outputs in with other services or use XSLT to create alternative outputs that weren't necessarily considered when the original service was built, and consume it in a standard way in any client on the front end.
It sounds like what you're really asking is how to build a single application. The point of a SOA is to provide standard data sets through re-usable interfaces, that have no specific application or implementation in mind. To start out building a single application with the entire back-end comprised of SOA services would be a huge undertaking. In MY mind, each back-end service should be built because of it's intrinsic value all on it's own and be provided to the entire SOA "domain". Then when you or I decide to make a client that does X, Y, and Z, we can just go find those capabilities in the SOA and injest them.
i am trying to tidy up my code, i have a number of projects that have References to my Service Layer i.e the DLL. What this means is that when i distribute a new service layer i have to upload a number of service layers which are generally the same..
Of course using the ADD Reference is very fast as its one assembly talking to another...
I wanted to know the pros and cons of an alternative method..
I could use a web service/wcf to wrap my service layer but isn't this defeating the object..
And what about speed, now my desktop applications need to call to web service/wcf instead of accessing the assembly reference??
My service layer talks to my data layer of course and my clients nevere talk to the data layer directly..
Its the issue of the service layer which is where my business logic is which is shared amongst a number of apps..
Desktop app, 2 x website, 2 x wcf projects(used as web services)
Any advice on how i can achieve the fastest possibly scenerio without repeating my code which is effect what i am doing now i.e.
each app (desktop, website, wcf) have copies on the same DLL and have references (add reference in vs 2008) ..
Ideas?
I think you would benefit best by using WCF (which wraps up .net remoting, msmq, etc.). Then you wouldn't have to copy a dll with each program... they can just point to a WCF service. This type of service oriented architecture is great for what you are describing.
From my experience with WCF so far, I have not noticed any performance hits, especially on an internal network.
Here's a good overview on WCF: http://msdn.microsoft.com/en-us/library/aa480210.aspx
Hope this helps!
If you deploy apps mostly on a single host, then chose publishing your middle-layer in GAC, supplying it with appropriate version policy.
If you deploy apps in a distributed environment, then use .NET remoting/WS/WCF. I think that remoting will be the fastest choice in your scenario.