At what point (if at any) does it make sense to take some of the features of a .NET web application and split them into separate web services?
For example, we have a very large web application that also calls a series of long running operations (our core business logic). We also have a dll with client-specific custom features that is called directly from the web project. Sometimes we need to move very quickly to change these client functions, often in hours.
However, if we make a change to the client-specific features (or an emergency change to the core features) and publish a new project, then it would kick all the users out the system as the app restarts. It would seem like there's a better way ... but I'm not sure what it might be ...
First of all, it makes sense to remove everything from the web project that is not involved with the UI. Put that in separate class libraries.
Do not create web services unless some other application will be calling them. Simply placing the code into separate projects will be enough. Web services should only be created if they are a requirement.
I think it makes sense to create service app (not like Web Service, but more like Windows Service). You could communicate between your webapp and service app using Message Queue.
Related
I need advise on the architecture of my new application. In the environment I work in, we normally create Win based apps and these compose a UI layer, Business Layer, WCF Service Layer, and Data Access Layer. These are on a 3 tier architecture with Services Server, Database Server and clients machines accessing the application via Citrix on an Application Server. I just created a web aplpication and my admin has suggested this should be hosted on a separate web server, my question is, is there a need for my web application to use a WCF Service Layer, since it can be hosted on the same application server? Basically, do websites need to use wcf/service layers and what are the benefits?
1.
Read this:
http://www.codeproject.com/Articles/10746/Dude-where-s-my-business-logic
My advice:
At the least, you should use WCF, and use "named pipes". You can deploy both the Host (WCF) and the Client (Asp.Net website) on the same machine.
The Asp.Net website will be the "client" and access the service.
Then, if you ever want to horizontally scale, all you have to do is change the .config settings to use a different protocol besides named-pipes.
Aka, you'll have the "logical separation", even if you deploy both on the same physical machine(s).
They (websites, any project) don't "need" to do anything.
You can write inline sql code behind buttons on webforms if you want.
But its not maintainable. And its not scalable. And it is probably foolish.
But putting in the time to SOA a mid to large sized application is worth the effort in the beginning, IMHO.
This is a question without a concrete possible answer, do you need a wcf? well that depends on the requirements and the architecture you want to put in place.
based on the small context you provide maybe you can get some the following benefits
WCF Provide state for operations
Fast processing (binary serialization)
WCF are more likely 'to be testable' than legacy asmx web services
You can access the same backend you built for your desktop applications
regarding if than can be accessed from the same server, the short answer is yes (obviously you need to measure your server capabilities)
I've done some app's that doesn't use a wcf at all, and other that use it for certain operations you can take a look to this SO answer to get a good example where a wcf could be a good candidate in an app.
I am supporting an ASP.NET app, which is installed on a web server and a VB6 app installed on a different app server. There is code duplication in the VB6 app and the ASP.NET app. I want to use some of the code in the ASP.NET app in VB6. I believe I have three options:
Expose the required functionality in an ASP.NET web service. The VB6 app will consume the web service.
Rewrite a small section of the vb6 app in .NET and extend the asp.net app. This will eliminate some of the code duplication.
Setup a class library for the ASP.NET app. Install the vb6 app on the web server. Expose the required functionality from the class library in a type library.
Which option is best? I believe option 2 is best.
Option 1. That leaves your shared, already-tested code on the most modern platform.
This is very hard to answer, as it varies for each company and each situation.
As a general rule, I'm very much in favor of using web services where possible, especially if multiple applications are using the same logic for the following reasons:
If I have to change the logic, I can do it in one place and fix all apps that depend on it
The same can be said for database connection strings, etc.
A bug fix can also often be fixed in one place.
I've had difficulties with a particular database that I need to deal with, where the vendor's updates tend to break their .NET adapter. Twice I had to modify/recompile a ton of apps to resolve this. Since then, we made it a policy to connect to that DB only via web services, so I'll only need to update one app in the future.
When developing mobile apps, the simple fact that we already had all our code in web services makes it that much easier to write apps that are strictly UI and leaving the business/database access logic as-is in existing web services.
All of those are pretty much "Standard" arguments for the SOA approach.
All things considered, my first recommendation, not knowing your specifics would be option #1.
There is a fourth option - a total rewrite of the VB6 app, if it's feasible, and if you can convince those who control the budgets and time allotment. Even with that, you can use the Service Oriented Architecture and split much of the logic into web services.
I have web application that are using multiple clients.
I should create one copy of application for all clients or every client should have its own copy.
I am using Asp.net MVC and SQLServer.
What you suggest.
Creating seperate projects per client will be troublesome to maintain while a single project for all clients could be difficult to customize. It is a fine line and your needs will dictate how you build your solution.
One of my more recent projects where we do SAS (Software as a Service) we were able to build our MVC application using a plugin architecture so that each client COULD have their own DLL deployed to the BIN that would enable customizations for just that client (to the Views, Assets or even the Controllers). We are able to leverage a single code base and have many clients, most without customizations and some with minor to heavy customizations.
Every client has a unique URL for their "portal" and most often they have private domains, so http://app.mycompany.com or http://mycompanyapp.com and some are even hosted on our own site, http://hostingcompany.com/client/.
By building an application that can determine what client it is based on the URL we were able to handle all of these cases with ease. When we deploy we have a single code base (deployed just ONCE to a single folder) and all of the sites use that same code deployment.
We run a web farm where we have many .NET Web Servers and have load balancing setup and the sites all have ping pages that our load balancers interact with to determine their health.
Like I said, your needs will determine what the best solution for you is.
Nick , what about database should we use one database every client or should have separate database for each client in my scenario our application is more database centric so there are lot of changes done for each client as per there business roles .
Is there a business case for using WCF WITHIN your web application (ASP.NET/SQL Server)?
I'm not talking about a service to be consumed by others, but rather a service to be consumed WITHIN the web app. So far, the only use for web services WITHIN the web app I came up with is when I need to call the database from the client (through AJAX).
Please don't give me the copy/paste lesson on web services, all I'm looking for is a CONCRETE EXAMPLE of WCF benefiting the web application, and NOT the other apps consuming the services.
Quick clarification: by "web application" I mean a self-contained CRM of sorts. It does a lot, but it DOES NOT talk to any external apps/db's, and DOES NOT need to have service points open for other apps to consume.
We have a Windows service that gathers live data from the web. Because the data is ephemeral (it's only really valid for around 3 minutes), there's no point in recording it in a database. To retrieve data, the Windows service offers a (TCP transport) WCF interface which is only exposed to the web-server, from which our web-app requests data.
I think it very much depends on how you define "application".
If you're talking about a single web application then with the exception of provision ajax data as you've already noted I'm struggling to think of a generic reason why you'd want to as a web service (even more so for WCF) is just an exposed API and if you're in the application surely it would be better (in all kinds of senses) to go straight to the API without the additional overhead of wrapping and unwrapping the calls and the data - which is pretty much redundant.
On the other hand if by "application" you mean an assembly of "stuff" that delivers a solution to a set (or even various sets) of end users then yes, of course... there is definitely a case where the flexbility of having components communicate via services outweights the overhead issue. Where it gets grey is if there is an assumption that a single application will (or at least might) later become multiple applications wired together - but if you're not doing it now then you're just causing yourself pain you don't need so shouldn't bother. If you need to split it deal with that as a self contained exercise as and when you need to split it.
One concrete example from my practice: On one web site we use actively tables which are implemented with respect of jqGrid plugin to jQuery. The contain of grids will be loaded per ajax. So the most pages of the web site are very simple and have clear XHTML code. The business logic with the interface to the database is inside of WCF service. Inside of WCF service we get data also from other information stores of the organization. In the same way if one will need later to have an input from our project the WCF service will be perfect.
So the usage of WCF WITHIN in our web application helps to archive clear interface, clear separation business logic from the HTML markup and better testability (with utit tests integrated in Visual Studio).
Providing web features through a custom HttpHandler such as in Elmah is extremely handy for ASP.NET Web Applications, because the handler can be embedded into any ASP.NET web app. It perfectly fits as a simple way to extend an existing web app.
Now, developing any significant set of features through a custom handler is a very tedious process. I am wondering if it is possible to directly embed an ASP.NET Application into another one through a custom handler (as opposed to cut and pasting the whole app in a sub directory).
Here is a small list of embedded web app that would be fit for such a purpose:
Health monitoring console.
Provisioning console (for cloud web app with auto-scaling).
App settings management console (considering a scheme IoC-settings-stored-in-DB).
Each one of those web parts could be provided as an HttpHandler; but again implementation is really tedious.
Does anyone know how to do that or how to achieve an equivalent behavior?
Do you usually put your features in a business logic DLL and just reference it from as many applications as need the business logic? What are you trying to reuse that this wouldn't work for?