I want to migrate my WCF services to Web API / MVC6.
Currently I have one application hosting multiple WCF web services (http://{ip}/{app}/Service{x}.svc/{vs_endpoint}). This model is pretty good, we can separate the public services from internal services and we have control over each service in particular, although they all are under one single application.
Would I be able to achieve similar thing in Web API / MVC6, having one project for multiple services? From my initial investigations I understood I would need to do something along these lines.
If yes, it would be nice to have some recommendations how to structure this project.
Also, can you share some pros and cons about one vs multiple projects to host these services?
Thank you in advance!
Yes you can achieve this by using either separate controllers or logically grouping controllers into areas.
Once you start programming you will automatically came to know that how it is possible and easier to do than wcf.
good luck...
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 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 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!