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).
Related
I'm brand new to C#/.NET
Why does ASP.NET have so many different choices of projcets? (Web Application, Web API, Web Site, MVC ect). I just want to listen on a tcp port, and a way to send a response. If there are libraries to help me do routine stuff like constructing the HTTP request, parsing the header, ect - then cool. But I don't want a super opinionated framework that tries to do everything under the sun.
Why do I need IIS at all?
Addressing your points in reverse order, first - why do I need IIS?
The answer is, maybe you don't. If you are doing a simple listener that won't be exposed to the public internet, then you don't need it.
If you are doing a web application that needs to scale, be robust and easy to manage then it can help you with:
Logging
Operating in a multi-server environment for scale/high availability
Handling multiple requests in an isolated way
Serving multiple applications from the same host with sandboxing to ensure each application has guaranteed resources (memory, CPU)
Application lifecycle management
IP address restrictions
support for FTP, CGI, WebDAV
URL rewriting
Response header manipulation
Failed request tracing
Protection against some DoS exploits like slow HTTP attacks
Etc.
In short, it is an industrial strength, real world web server that will keep your application up reliably in a hostile world and scale as your application grows. it is certainly overkill for some cases if you don't need this kind of scale/high availability/management capability. In those cases you have the option to self host ASP.Net in a Windows Service or even a console app. This might sound complicated, but it has been made pretty simple by OWIN - Open Web Interface for .Net. This is an abstraction of the interface used by Asp.Net to communicate with its hosting server.
There is a very good tutorial on how to self host web API in a console app here
http://www.asp.net/web-api/overview/hosting-aspnet-web-api/use-owin-to-self-host-web-api
It does exactly what you ask for in your comment:
You create a console app project
You add references to the right assemblies (the tutorial uses NuGet to download the assembly packages)
You code up your web operation logic
You compile
You run the resulting exe
That's it!
On your second point about ASP.Net - it is a framework that has gone through a lot of evolution trying to keep up with very rapid changes in the web development world. This meant it got a bit bloated and lost some of its coherence, but recently the developers have been focussed on making it more lightweight, more modular and simpler. Scott Guthrie summarises it in his blog:
http://weblogs.asp.net/scottgu/introducing-asp-net-5
Why does ASP.NET have so many different choices of projcets? (Web Application, Web API, Web Site, MVC ect). I just want to listen on a tcp port, and a way to send a response. etc...
Because each project has its own purpose.
If you want to just listen on a TCP port then you could go learn Microsoft's Katana OWIN (but I highly doubt if this is what you want).
Katana OWIN
Briefly going through each projects purpose:
"Web Application" actually opens up another window and lets you choose from the following:
Web API is for exposing RESTful services or JSON data.
Web Forms is for making web pages that use Web Form components.
(A bit like Windows Forms, but Web)
MVC is for making Model-View-Controller web applications. This is where you build components with a separation of concerns. Model for data. View for what the user sees. Controller for controlling how your page behaves.
Why do I need IIS at all?
IIS is for serving .NET applications.
Without it, it would be quite hard to serve .NET applications.
I'll start with 2 then move on to your first question. IIS will run whatever the .NET web service you need, be it a monstrous WCF service, an ASP.NET application or the most basic http handler.
To my knowledge, ISS is the most straightforward way to use .NET web services. If you are used to PHP, it's basically LAMP or WAMP for .NET, which means it is sort of necessary. There are alternatives, as Mike Goodwin points out, but I have to admit I am not familiar with those third parties. Since replacing a layer for another doesnt mean much, I would stick to the "normal" procedure.
Since you dont want the framework to do a truckload of operations for you, your best bet might be along those lines:
Create a basic ASP.NET projet
Remove the default ASP.Net page because it seems you dont want it
Add a Generic Handler to your project. This will result in a myFile.ashx, which handles http requests and let you build any response you want
Of course, if you dont want to bother with IIS configurations, you'll need someone to setup an URL on IIS and map it against your handler repository.
EDIT:
"Abstraction layers" would be the very definition of frameworks, for good or ill, so you're stucked with it.
Now, since you have a low level background a not-so-intrusive way to work with the .NET web services would probably be the three steps I suggested earlier. You are still stucked with IIS though, in order handles the communications (i.e. manages sockets/requests). That's the way the framework works.
STILL, THERE IS HOPE. If you have complete control over your server (which is not my case, some other IT team manages the web servers), you certainly could build a windows service that listens to some socket and work the requests accordingly. It is a most unusal solution if you want to serve web pages, but would work rather well if you only want to push some data through http requests. If you go down this path, I suggest you take a look at the System.Net namespaces, you'll find some classes like "Socket" there. Combined with a console application or a windows service, you could work something out.
One of my coworkers is former microcontroller designer, I know exactly what kind of feeling you have towards the .NET framework. You'll go through some frustrations at times, but most of the time there are work arrounds. Feel free to request more details if you need some.
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.
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.
I am starting a new project which will need a ASP.NET MVC 2.0 website, a Silverlight section and a Windows Phone 7 UI.
My plan was to use WCF RIA Services to create a set of services which would be used in all different UI projects. With the Silverlight project I would use the standard tool integration, the Windows Phone looks like it may have to be WCF Services exposed by the RIA Domain Services, but I'm not sure about the ASP.NET MVC website.
My initial thoughts I would simple reference the class library containing the Domain Services and use them directly. Could this be considered a viable approach to using RIA Domain Services in a ASP.NET MVC website?
Kind Regards
Michael
I know a long time has passed since this question was asked, but since I had to make such a decision, I might as well document it for the benefit of others.
I work in an environment where lots of legacy and new apps co-exist, with the legacy apps being phased out. So we've had to build interoperability between everything from MS Access, to web service end points in C#, VB, Web Forms, MVC 3, even Flex, Reporting Services...the list goes on.
One of the biggest pain points in a multiple-client scenario is the maintenance of interoperability over time. As data, requirements and delivery mechanisms change, keeping things smooth ends up taking a lot of resources.
My approach has been to create one and only one mechanism for reading a given source of data by defining 1) a model, 2) a serialization/deserialization layer and 3) a service layer. All projects that need to use XY_Data must use the XY_Service to get XY_Objects via the XY_Serializer. Direct db calls or stored procs, etc are allowed in the XY_Application. This allows me to drop in replacement DLLs (versioned) with bug fixes and upgrades without restarting anything. I hardly ever do a full publish.
So yes, what you're suggesting will work. I would recommend only that you rigorously enforce the single-source-of-truth and DRY policies both in your data and your APIs.
For clarity when I mention tiers in my question, I am referring to physical tiers (i.e. different servers for presentation, application and database)
My company has a public facing website that is currently built as a typical 2 tier system (web server and database server).
Soon a project will start in which we will be re-writing the whole site. We are required to split the project across 3 physical tiers. Actually, when you consider the browser then you could consider it 4 physical tiers.
In my experience most asp.net applications are built on 2 tiers. The web application itself may have several layers but physically it is deployed to two servers (web and DB).
I have searched for examples but it seems that layers and tiers get confused. I see a lot of multi-layer examples but no multi-tier examples.
In a nutshell it would seem that the web application makes web service or WCF calls to the application layer that marshals data to and from the database using ADO (or L2S or EF).
Does ASP.MVC help achieve this? Does it make it any easier or just different?
Is there a good reference or example of this somewhere?
I don't think adding another tier increases security, but it definitely slows down performance and significantly increases development cost and complexity.
In the end, you can partition your application with an additional tier anyway you want. If it were me, I'd probably create the dumbest pass through tier I could if I was given this "interesting" requirement.
In fact, managing security around another tier implies significantly increased opportunities for security holes to be accidently exposed.
ASP.NET MVC should have no impact, but you will likely end up using something like WCF. For marshalling data back and forth, you probably want to use DTOs which are not tied to any particular database or ORM.
This is not a situation I'd be happy to find myself in. Increased complexity does not lead to increased security.
Gday Rick,
I work for a company that has the same multi tiered policy due to security.
I have an ASP.NET MVC web application on one tier that connects to a application tier that a web service sits on and is basically a facade for the database and a mainframe. Pretty much exactly the same as your setup.
ASP.NET MVC makes it really nice and easy to use this setup because you can easily build a validated object model in your ASP.NET MVC application. Once the object passes all top end validation you can easily transfer it on to the application tier via a web service.
I suppose this would be easy to do with a classic ASP.NET application however I think MVC makes things a lot easier!
Check out my blog for an example of how I have validated my models before sending to the application server.
Cheers,
Michael
In my opinion ASP.NET MVC isn't going to help, or hinder this scenario. Basically you'd going to have your model exposed not as Linq2Sql, the Entity Framework or any other ORM but from the middle tier, probably by WCF.
This presents the usual challenge around authentication and authorization - namely how does authentication flow between tiers., but that's are unique to MVC, a WebForms solution would have the same sticking points You'll also lose the model validation bits that an ORM may supply and will have to provide that yourself in your web services repository, but that's just a matter of implementing the right interfaces.
This is an odd requirement. Did it come from the customer? It is possible that some customer education is needed.
I know J2EE systems can be split over three tiers, with web server on the first application server in the middle and a DB on the back end but I havn't heard of this with .NET.
As mentioned before... MVC won't really matter in this situation. The closes analogue I have is we had a financial client separate out their web services into tiers...
so something like
1) public facing load balanced web services
2) web services
3) application code
4) database code
I don't remember if layer 3 and 2 were physically separated (been a while) but essentially layer one was fairly thin and just threw the requests over the dmz to the inside service.
So you could probably do something similar with the web site... potential for bottlenecks, but would get you the physical separation you need.
Good Luck!