We're using ASP.NET 4.6 (MVC & Web API) on our web site. Now we have the requirement to provide a "webhook" for an external service, and their client only supports SOAP 1.1 (and does not run .NET).
I've been trying to construct a WCF service that the external SOAP 1.1 can consume, using both programmatic configuration and Web.config configuration, but I can't get to a state where the service is actually usable from my own test client (generated with Visual Studio 2015).
All documentation seems to be inaccurate (for example, the information in https://msdn.microsoft.com/en-us/library/ms731361(v=vs.110).aspx does not work; there is no "envelopeVersion" attribute any more) or for previous versions of Visual Studio or ASP.NET or WCF. Also, documentation seems to suggest that basicHttpBinding means SOAP 1.1, but that does not seem to be the case.
I am fine with not using WCF for this, but I don't know what to use instead. I'm not sure ASMX would solve the problem, if ASMX is even usable on ASP.NET 4.6.
All working service instances I've been able to provide still emit non-SOAP 1.1 namespaces or similar in the response, producing errors on the client side.
The only working solution I have currently is to use MVC or Web API and parse a HttpRequestMessage manually and returning manually crafted SOAP 1.1 responses, which is a very brittle hack.
I have read many articles about the OWIN and Katana projects, but I could not get the whole picture of it.
For a normal web developer who uses ASP.NET:
What exactly is OWIN and what problems does it solve (in simple words). What is its relation to IIS?
Does OWIN replace IIS? if not, in what situations does OWIN best fit?
How could OWIN help me in my daily work projects?
How could OWIN help me in a self-improvement projects?
Regarding the comment above, OWIN is not a framework. OWIN is a specification on how web servers and web applications should be built in order to decouple them and allow movement of ASP.NET applications to environments which were not supported before.
Prior to OWIN, when building ASP.NET application, you were inherently bound to IIS due to the heavy dependency on System.Web assembly.
System.Web is something that has existed ever since ASP (non .NET version) and internally contains many things that you might not even need (such as Web Forms or URL Authorization), which by default all run on every request, thus consuming resources and making ASP.NET applications in general lot slower than its counterparts such as Node.js for example.
OWIN itself does not have any tools, libraries or anything else. It is just a specification.
Katana on the other hand, is a fully developed framework made to make a bridge between current ASP.NET frameworks and OWIN specification. At the moment, Katana has successfully adapted the following ASP.NET frameworks to OWIN:
Web API
Signal R
ASP.NET MVC and Web Forms are still running exclusively via System.Web, and in the long run there is a plan to decouple those as well.
On the other hand, IIS is a good, resourceful host for web servers. Entire ASP.NET performance issues using IIS has deep roots in System.Web only. Up until the recent time, when deciding how will you host your web server, you had two options:
IIS
Self-Host
So if you wanted a performance, you'd go for a self-host option. If you wanted a lot of out-of-the-box features that IIS provides, you'd go for IIS but you'd lose on performance.
Now, there is a 3rd option, a Microsoft library named Helios (current codename) which intends to remove System.Web out of the way, and allow you to use IIS on more "cleaner" way, without any unnecessary libraries or modules. Helios is now in pre-release version, and is waiting for more community feedback in order to make it fully supported Microsoft product.
Hope this explanation clarifies things better for you.
EDIT (Sep 2014):
With ASP.NET vNext being in development, Katana is slowly getting retired. Version 3.0 will most likely be last major release of Katana as a standalone framework.
However, all the concepts introduced with Katana are being integrated into ASP.NET vNext, meaning that programming model will be pretty much the same. Quote from forum post made by David Fowler (Architect of ASP.NET vNext):
vNext is the successor to Katana (which is why they look so similar).
Katana was the beginning of the break away from System.Web and to more
modular components for the web stack. You can see vNext as a
continuation of that work but going much further (new CLR, new Project
System, new http abstractions).
Everything that exists today in Katana will make it's way into vNext.
EDIT (Feb 2015):
ASP.NET vNext is now known as ASP.NET 5 and will be built on top of .NET Core 5. .NET Core 5 is lightweight factored version of .NET Framework, designed to support goals of ASP.NET 5 and .NET Native. However, ASP.NET 5 will be supported by .NET Framework 4.6 as well, that should become available together with .NET Core 5. Both ASP.NET 5 and .NET Core 5 will be licensed under MIT and will accept community contributions.
EDIT (May 2015):
Additionally, ASP.NET Web API brand will be discontinued, however it's technology will be base for new ASP.NET MVC 6. Previous ASP.NET MVC versions were built by implementing IHttpHandler, an interface defined in System.Web. ASP.NET MVC 6 removes that dependency, making it portable to various platforms and web servers.
EDIT (May 2016):
ASP.NET 5 will officially be renamed to ASP.NET Core starting with Release Candidate 2 that is scheduled to be released soon. Same will apply for Entity Framework 7 which will be renamed to Entity Framework Core. More information about official announcement and reasons behind it can be found on Scott Hanselman's blog post:
ASP.NET 5 is dead - Introducing ASP.NET Core 1.0 and .NET Core 1.0
EDIT (May 2016):
With the release of Release Candidate 2, ASP.NET Core has been modified so that future web apps are actually just .NET Core console apps setup to process incoming HTTP requests. This concept makes ASP.NET Core even more aligned with approach Microsoft has taken with microservices architecture support and its implementation through Azure Service Fabric. More information on can be found on official blog post:
Announcing ASP.NET Core RC2
If I have to define OWIN for myself, that would be: "The best ideas from the Ruby and Node.js web dev communities, coming to .NET"
But this would not help any ASP.NET developer. My own definition would be something along the lines of:
OWIN defines a standard interface between .NET web servers and web applications. The goal of the OWIN interface is to decouple server and application
If I have to answer the questions you've posed, then here it is:
OWIN is an interface specification. It decouples a web applications from IIS.
If you are using ready-made components (which is what Katana is), then some parts of the application functionality are much easier to implement compared compared to old ASP.NET. Authentication with third-party identity providers (Facebook, Twitter) is one example of this.
OWIN is essentially a collection of best practices, which have been proven in web development communities. It shows a way to implement web apps which is very open to extensibility. As each web developer should constantly be on the cutting edge of new technologies, this is one way to stay up to date with the whole web development community and not just .NET. If you learn OWIN, it would be much easier to learn other web development frameworks like Express for node.js or Rack for Ruby, because the practices they use are similar.
I will try to cover it from the practical perspective.
Katana is project name to implement OWIN in Microsoft.
What exactly is OWIN and what problems does it solve (in simple words). What is its relation to IIS?
OWIN (Open Web Interface for .NET) is a standard (OWIN Specification) and Katana is .NET library, you can get nuget from here. OWIN and Katana became somewhat synonymous on the web.
Before OWIN your only option was IIS with OWIN you can use any other application (that has entry point) as web server.
Does OWIN replace IIS? if not, in what situations does OWIN best fit?
No it does not replace IIS, you can use OWIN and IIS there's Microsoft.Owin.Host.SystemWeb nuget for that. It is best fit if you want to optimise/change the way it is handled in IIS, or you want to create your custom web server out of let's say Windows Forms Application.
How could OWIN help me in my daily work projects?
It could reduce your server running costs since your web servers do not need to run on IIS (Windows) anymore (Windows servers are more expensive than Unix based ones, and you could run it on Console Application under Mono in Linux).
How could OWIN help me in a self-improvement projects?
Learning Microsoft.Owin (and other related OWIN libraries) will improve your knowledge on how HTTP communication between client and web server works.
Good read if you want to understand more on what Katana and OWIN is.
What is OWIN?
OWIN stands for Open Web Interface for .NET. OWIN is a specification that describes how web development frameworks such as ASP.NET MVC should interact with the web servers. The goal of OWIN is to decouple web applications from the web server by introducing an abstraction layer. Such an abstraction enables you to run the same application on all the web servers that support OWIN. Additionally, it simplifies the overall system because the abstraction layer can provide a lightweight infrastructure to host the applications. IIS provides a rich set of features to the web applications. However, web applications may not need all these features. It might be sufficient for them to have minimal HTTP processing capabilities. OWIN compatible host can provide such a hosting environment to these applications. Moreover, you can define a pipeline of modules that are used during the request processing. An OWIN pipeline is a chain of OWIN compatible components through which a request passes.
What is Katana?
Katana is a set of components by Microsoft built using OWIN specifications. Some of these components include Web API, ASP.NET Identity and SignalR.
Above is extract from CodeGuru Article : http://www.codeguru.com/csharp/.net/net_asp/overview-of-owin-and-katana.htm
I heard that rest services are moved from wcf to asp.net web api frame work.
Our web application is built on vs 2010 (asp.Net 3.5) .So still i can use wcf rest services in my web application?
Please suggest some alternatives if it is not possible.
WCF can still be used to build RESTful services1, many services are already built with it and it's not going away. What you heard is that most of the new developments in terms of new functionality in the area by Microsoft will be made in the ASP.NET Web API framework, not in WCF. But as all the services out there can attest, WCF for building web services is still a valid alternative, if it does all you need.
1 The official name is actually "WCF Web HTTP Services"; REST is a well-defined set of constraints which need to be implemented, which would give the service some useful properties. There are some people who argue that people should stop using the term REST for all HTTP-based, non-SOAP services.
I am reading on internet about the difference between ASP.NET web service and WCF and have found that ASP.NET does not support any other protocol except http .
Can anyone please explain me the reason why ASP.NET web service don't support other transport protocols ?
It supports SOAP and other over-HTTP protocols. It is a design limitation, rectified with WCF.
ASMX web services are the original web service platform created as part of .NET 1.0. They are quite old, and the architecture is inflexible. In particular, they use the ASP.NET pipeline, which is focused on HTTP, not on multiple protocols.
They were replaced by WCF, which does not have these problems.
I need to make a change to an ASP.NET web service written a couple years ago on 2.0. I call this web service from an old 1.1 web site. I need to make some changes to the web service, so am thinking, should I rewrite this into a WCF service and if so, will I still be able to use it from my 1.1 web site?
Yes this will work. Your service will need to be at least .net 3.0, but as long as you use a basicHttpBinding or wsHttpBinding, you can consume it like any other webservice.
You can make a WCF service act and behave just like a traditional 1.1 ASMX web service, but is that what you want?
I think you need to ask yourself what featires of WCF are motivating you to upgrade.
Do you want to also expose the service as a REST-ful service? Do you need to implement message level security?
If it's just to go to the latest technology for the sake of the latest technology, I'd say stick with ASMX web services if your requirements for message and protocol security aren't that high and you're working with mostly microsoft technologies.
Writing a WCF service is regrettably more difficult than a plain-old asmx web service.
yes you can... make sure to choose the correct bindings and authentication methods