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.
Related
I am new to OWIN and Katana. I really don't get why I should use OWIN, while I can use IIS. To simplify, my question is: What do I lose if I skip learning OWIN and use IIS for my websites?
I googled but there is not a simple explanation. There is some information here, but they use some jargon phrases so I cannot understand it.
In asp.net WebApi v2, the OWIN pipeline becomes the default. It is eventually going to be the standard pipeline under any asp.net project.
I cannot put it better than what is written here : http://www.asp.net/aspnet/overview/owin-and-katana/an-overview-of-project-katana
The section "The Open Web Interface for .NET (OWIN)" explains perfectly the goals of OWIN.
Without OWIN, the asp.net bits are coupled to the way IIS communicates with the application. OWIN abstracts web servers and framework components. That means that your application code will now be aware of the OWIN interface, but not of the webserver that is serving the request.
In return, applications can be more easily ported between hosts and potentially entire platforms/operating systems. For example, the ability to host an application in a console or any process allows Mono to host it without efforts... (Raspberry Pi anyone)
The second aspect is that it works as a pipeline.
You can plug any middlewares (and as many as you want) between the webserver and your application.
This allows for more modular solutions. You can develop redistributable middlewares that can impact the request/response coming to/from your application, but keep these modules separated from the application code.
To persuade yourself of the benefits of this modular approach, take a look at the nuget packages available for OWIN : http://www.nuget.org/packages?q=owin
A lot of these packages were previously core asp.net functionality, and have been extracted as middleware.
For example, adding support to login using various OAuth providers becomes an infrastructure concern (a middleware) and does not need to be part of your application code anymore :
http://www.nuget.org/packages/Microsoft.Owin.Security.Google/
http://www.nuget.org/packages/Microsoft.Owin.Security.Facebook/
http://www.nuget.org/packages/Microsoft.Owin.Security.ActiveDirectory/
...
Or if you want to automatically replace all the images from your website by cute cat images, you can do that transparently as well :
https://github.com/serbrech/Owin.Catify
EDIT : It is now available as a nuget package : Owin.Catify!
public interface OWIN
{
void ListenHttpCallAndServeWebPage();
}
namespace Microsoft.OWIN
{
public class Katana : OWIN
{
public void ListenHttpCallAndServeWebPage()
{
// listen to a port for HTTP call and serve web page
}
}
}
Yes, thats right. OWIN is an interface and Katana is an implementation of OWIN interface by Microsoft. Therefore we hear these 2 words (OWIN / KATANA) together and manytimes we get confused between the difference between these 2 terms. So, Katana is Microsoft's implementation of OWIN interface. Say there is another company named BIG-BOSS who wanted to create their own implementation of OWIN, they can do that and name their implementation as 'BATANA' and advertise phrases like OWIN / BATANA.
So, why OWIN !!!
Think about a country where the only vehicle available for movement is a truck. Nothing else. If you want to buy a vehicle, you would buy truck. Well, that used to serve good but people started to realize that, they don't need truck all the time, especially when they want to go to watch a movie or buy milk, driving a heavy truck not only costs high fuel, but also add stress on driving. But yes, if they want to carry lots of heavy stuff, truck serves the purpose very well.
Then, the Government of that country came up with a specification for vehicle makers. The specification is as follows:
A vehicle needs to have 4 wheels
A vehicle must have a steering.
A vehicle must have headlight and signal lights.
So, based on these specifications, anyone can make vehicle according to different needs and they can name their vehicle accordingly. Therefore, Sedan, Pickup Truck, SUV, VAN, ..etc.. all kind of vehicle showed up in the market. If someone does not need to carry heavy stuff all the time, rather needs a vehicle just for going to workplace, he/she can buy a little Sedan. Someone can buy SUV if he needs little more power.
Based on the above example, we can say that our ASP.NET Web application uses System.Web Assembly which is heavily loaded (like a truck) and if we want to make a little Web Application where our purpose is just to serve some files based on a little set of requests, we are bound to use that heavy System.Web assembly (truck). Now, OWIN shows up. OWIN is a set of specification (we can call it interface) that defines a Server. Based on that specification, someone (like a vehicle maker) can make various kind of servers based on specific problem domains / application needs. Microsoft created their own Implementation for OWIN named Katana in the same way which can serve Web API. As WebAPI is a light weight technology, which does not need full blown System.Web things, a light weight Server implementation (like Katana) can boost the performance heavily when you use Web Api hosted on Katana.
Now, if you ask, 'Do I need it' ? Answer is, 'It depends on your need of performance'. If you don't mind driving your truck even for going to watch a movie, then, perhaps you do not need OWIN. But if you feel that, a light weight Sedan car is all you need to drive within a city, small distance, watch movie..etc.. yes, You may check what implementations of OWIN available in the market. Katana is one of the implementations of OWIN, therefore you can check what Katana offers. Not only Katana, if any other company implements OWIN according to specific Domain (for example, a server for Medical Devices which will download latest medicine information) and if you are a doctor, perhaps, you can check that implementation of OWIN. Moreover, you yourself can create your own implementation of OWIN targeting any specific niche.
In terms of web applications, if you are a simple Web developer, developing custom Websites for your clients, perhaps, you do not need to worry about custom implementation of OWINs, because IIS will serve you in a balanced way. If you build a Web API project, you will get Katana based template ready made from Visual Studio -> New Project, so you won't have to worry about anything other than learning Katana specific techniques. At this moment, Katana is not mature enough to completely replace the need for IIS for ASP.NET MVC, but perhaps, in the future it will.
Then When I may need to write my own OWIN Implementation ?
Answer: Well, say for example, you have developed a Windows application which should run as a server in the background and listen to a port number XXXX. Your server will respond to only some set of Requests like this:
GET Inventory
DELETE Inventory ID=4
PUT Inventory ID=5
That's all. And nothing else. So, why would you need a full IIS web server for this little task? You can create your own OWIN implementation in that case. (Perhaps, you will use Katana for that)
Ok, so I understood that, if I want to make a ASP.NET MVC website, I don't have the option to replace IIS, then why should I need to know about Katana at this moment ?
Answer: Even though Katana is not mature enough to replace the need of IIS so that you can host your ASP.NET MVC website directly on Katana, but Katana implemented many cool interfaces of OWIN so that you can take the advantage of using those features side by side. For example, allowing your users to login using Facebook, Google, Twitter etc was not very easy before. Katana gives you many hooks (as a middle-ware) so that you can let Katana take care of external Social Media based Authentication easily without writing plumbing code. There are many other benefits to using Katana that you may find out when you start using this technology.
A simpler version of that answer is that Katana is gong to fully replace System.Web assembly and the old ASP.NET pipeline, which gives you both better flexibility (use it in more scenarios and use only the parts you like) and performance.
So everyone should watch its evolution now and be ready to switch when it is finally completed.
Below is a diagram I drew to fill in the details Microsoft fails to include in this article.
OWIN is such a standard that it let application frameworks run upon it and forget about everything beneath it. On the other hand, OWIN itself utilizes various host adapters to make sure it can talk to the underlying web servers (IIS and many others).
I am now working with the Jexus web server author to investigate how we can write a host adapter to bridge OWIN/Katana and Jexus. We are really happy to learn that OWIN is flexible and highly customizable.
Reference:
http://blog.lextudio.com/2014/06/why-owin-matters-a-lot-for-asp-net-developers/
Why I should use OWIN, while I can use IIS?
OWIN is designed to decouple web servers from the frameworks you work under. It can make the applications lightweight and portable for the mixing frameworks and servers.
And Katana is Microsoft’s implementation of OWIN components.
Since last few years Microsoft is making web tools more agile and responsive as the their plan is progressing. For an example, the development of ASP.Net MVC and ASP.Net Web API. They do not depend on System.Web dll which is a huge burden they feel now I think. Advantage is both developments fixes can be provided on a timely manner and the cycle is faster than ever. Also now developers can deploy these applications on custom OWIN hosts or Katana, which is a reference of OWIN implementation.
What's the point after all?
Microsoft has released a project which is a lightweight OWIN based web host on top of IIS, called `Helios. The goal is to avoid ASP.NET/IIS relationship by providing some independent small components that can be used, installed and manage independently running on a web-host that implements the OWIN specifications.
One of the core reasons is the performance-factor. Helios will be able to achieve 2x-3x more throughput than standard ASP.Net application. In terms of memory consumption, Helios is much better than System.Web dll. In a taken benchmark Helios architecture allowed a sample application to achieve 50000 concurrent requests with approximately 1GB less overhead compare to a standard ASP.Net application.
OWIN is an abstraction between the web application and the hosting platform. If you write your web application using OWIN you are not tied to IIS, you can use another host if you like.
You asked why use OWIN rather than IIS, but these are not alternatives to each other. OWIN sits between IIS and your application so that you can switch out IIS without rewriting your application.
You might also like to check out this page https://github.com/Bikeman868/OwinFramework/wiki/OWIN
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'm having a look at the best way of developing a server application that presents an ASP.NET MVC front end for management/reporting.
The server app (service?) will also need to provide TCP listener as well as communicate to devices on a COM port.
The most obvious way I can think of doing this is to have an ASP.NET MVC web app and have a windows service that talks to the web app using a web calls/services. I guess then I'd talk to the service using the tcp listener or remoting?
The only other way would be to actually host an web server component in the service, and not use IIS which seems a bit to over the top.
Does anyone have any experience of this/recommendations?
It's a bit open ended but hope I've explained the basics.
TIA
Sam
I would probably try and decouple things a bit more.
Start off w/ a core project where all your business logic lies (agnostic of how users interact with it); sort of the DDD Domain Model idea.
Then, create two projects which consume that core project, one that is your MVC app, and another that's a WCF or ServiceStack-based service which can handle your TCP stuff.
Share state between them using the normal means; either inter-process comms, shared database, etc.
It sounds to me like you're looking for something very close to Windows Communication Foundation. Your requirements for IIS hosting, ASP.NET communication, and TCP communication. MSDN has a brief overview of WCF up here. There's also an article available about the transportation protocols here.
There are some good -- if a little old -- WCF questions here on Stack Overflow. I've just started delving into this world myself, and I have to admit that it's daunting at first. The Beginner's Guide (found under the first hyperlink above) has some slightly old, but very useful tutorial videos about WCF.
I will say that, although it may seem daunting or difficult, it's certainly better to use an existing, established technology for your purposes than to try to write your own homebrewed solution for something like this.
I started ServiceStack because I needed a high-performance web services framework option that promotes the correct way to develop web services.
ServiceStack can be run on top of any ASP.NET host or self-hosted using the HttpListener option. See the Starter Templates for example projects of a Console App or Windows Service hosts. Although even under IIS, ServiceStack is very fast and imposes very little overhead with a hello world service executing in sub <1ms response times.
ServiceStack also comes with .NET's fastest text serializers and a myriad of high-performance caching providers so you can escape the XML config bound ASP.NET's session and caching provider model.
Because ServiceStack encourages a clean message-based development model your same web services can take advantage of the Redis MQ Host allowing it to be invoked outside of HTTP context using Redis as a broker - with no code-changes required.
Redis is one of the fastest distributed NoSQL data stores.
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).