I found examples of building micro services with .NET using RabbitMQ e.g. Microservices with C# and RabbitMQ or using OWIN e.g. Use OWIN to Self-Host ASP.NET Web API 2.
The goal of the OWIN interface is to decouple server and application, encourage the development of simple modules.
Is it correct that with OWIN you don't need a message queue like RabbitMQ? Or does it make sense to use OWIN and RabbitMQ together?
The articles cover two different aspects of creating micro services.
OWIN let's you deploy asp.net applications in a single process, without the necessity for the asp.net runtime or IIS. This makes for a much simpler deployment and scalability. You might consider deploying with Windows containers.
However, as you yourself pointed out, asp.net core let's you do the same thing and has the additional benefit of being cross platform. Polyglot programming is another tenet of micro service based development. With asp.net core you can use docker containers and mix and match all kinds of services: https://github.com/aspnet/aspnet-docker
Rabbitmq let's you introduce asynchronous patterns into your code, loosely connecting your micro services.
Both are arrows in your micro service quiver. A real life application will likely use both approaches.
Related
I need to create client application and server service application, that uses Remote Procedure Calls with windows authentification and impersonation.
Since WCF is not supported in Net Core and gRPC uses http/2, which not supppoted by Windows Authentification are there any alternatives I could use for that?
WCF is a Windows-only framework, while.net Core is cross-platform.
The links below contain some usage and examples that you can refer to.What replaces WCF in .Net Core?
Thanks.
I have found the ServiceWire package to be an excellent replacement for NamedPipes and WCF, especially if you do not need to queue requests or share objects.
While more modern approaches would be preferred, if you already have heavy WCF dependencies or WCF knowledge, you can look into CoreWCF.
I create my API rest with Django, but I don't understand how convert an API to micro services, I don't understand the real difference between these.
I see an API like a micro service, but I don't know convert an entire API in micro service, I need create micro web servers?
Please, I can't understand a micro services, and I need understand this.
A microservice exposes it's interface, what it can do, by means of an API. The API is the list of all endpoints that a microservice respond when it receives a command/query. The microservice contains the API and other internal+hidden things that it uses to respond to client's requests.
An API is all that the clients see when they look at the microservice, although the microservice is bigger than that. A microservice hides its internal structure, it's technology stack, it's database type (sql, nosql - it could be anything); a microservice could move from sql to nosql, from python to php, but keep it's API unchanged.
API - It a way of exposing functionality over web. Imagine you have developed some functionality in .Net but not you are developing some software in a different language. Would you develop the same functionality again? No. So, just expose it via web service.Web services are not tied to any one operating system or programming language. For example, an application developed in Java can communicate with the one developed in C#, Android, etc., and vice versa.
Microservice - They are used to break a complex software into small pieces of individually deployable, testable, loosely coupled sub-modules. Micro Services are designed to cope with failure and breakdowns of large applications. Since multiple unique services are communicating together, it may happen that a particular service fails, but the overall larger applications remain unaffected by the failure of a single module.
API Vs Microservice - Now that we have broken our complex software into loosely couple sub-modules. These sub-modules communicate with each other via an API. Therefore, Microservices and an API solve different problems but works together!
More Details:
The Difference between Web Services and Micro Services
RESTful API vs Microservice
a microservice is an autonomous RESTful service. It means, there is just one service on each server. In Spring Boot when you bootstrap your RESTful service, it will get an instance of tomcat(it's embedded tomcat) and run your service on it. So, if you have more than one service on a server, it is not a microservice, because these services are not autonomous.
What are the pros and cons of using each technology?
WCF Web Api is now merged into Asp.net
Asp.net web api now supports self hosting.
I still imagine if I want to expose multiple protocol schemas for the same operation I would still lean towards WCF or can Mvc end point do this too?
Also does the new Asp.Net web api expose Wsdl? If not how would the client figure out what operation is available to them?
Arguably the best feature of Mvc is the modelbinder. How robust is the WCF equivalent?
So can someone tell me what advantage does the Asp.net web api bring to the table? WCF seems overwhelmingly the more powerful/scalable choice, imo. About the only thing the Mvc Web Api has over the WCF model is probably ease of development, but that means squat if it ends up being a serious design limitation down the road.
First, I suggest you read my post on the subject:
http://blogs.microsoft.co.il/blogs/idof/archive/2012/03/05/wcf-or-asp-net-web-apis-my-two-cents-on-the-subject.aspx
Regarding your WSDL question - since the WebApi does not use SOAP, it does not require a WSDL, and does not export one. You can use Hypermedia to return resources with a list of possible activity URLs (think of it as a self-describing resource)
The choice depends on what we want to do.
ASP.NET Web API is a framework for building non-SOAP based services over HTTP only - so there aren't more transport protocols available using this framework.
WCF / Windows Communication Foundation is a framework for exchanging SOAP-based messages - here we use a lot of transport protocols: HTTP, TCP, Named pipes, MSMQ, etc...
I am not sure about which one has better performance regarding the amount of data, maybe WCF since we can use low protocols. Any comments are appreciated.
The WCF Web API primarily focuses on REST implementations. If you are setting up a REST implementation, the standard WCF bits are a bit of a pain in the rear. If you are setting up RESTful services, you will find the WCF Web API a much nicer experience. If you are setting up SOAP services, then the WCF Web API is not your best friend, and you are better off using WCF for your services.
Use WCF for intranet/B2B sites n Web API for B2C/C2C/internet sites...SOAP/XML is still the standard for intra-businesses communication n it's not going to go away!!!
I am new to WCF and Web Services in general. What are the improvements that WCF brings to the table? Can anyone give a side-by-side example of a traditional web service and the same one written using WCF and point out the differences and advantages?
Duplicate question Moving ASP.net webservices to WCF
EDIT: Think i found the answer you where looking for a side-by-side code based comparison and even better it's from MSDN: Comparing ASP.NET Web Services to WCF Based on Development
There are several related questions:
Difference between aspnet web method and wcf webservice
Benfits of using WCF
Moving aspnet web services to wcf
However you asked for a side by side comparison in which case i think Sam's Wcf vs ASMX blog article is more what you are looking for.
Quoting ad-verbatim (let me know if i should just leave it as a link):
WCF vs. ASMX
Protocols Support
WCF
HTTP
TCP
Named pipes
MSMQ
Custom
UDP
ASMX
HTTP only
Hosting
ASMX
Can be hosted only with HttpRuntime on IIS.
WCF
A WCF component can be hosted in any kind of environment in .NET 3.0, such as a console application, Windows application, or IIS.
WCF services are known as 'services' as opposed to web services because you can host services without a web server.
Self-hosting the services gives you the flexibility to use transports other than HTTP.
WCF Backwards Compatibility
The purpose of WCF is to provide a unified programming model for distributed applications.
Backwards compatibility
WCF takes all the capabilities of the existing technology stacks while not relying upon any of them.
Applications built with these earlier technologies will continue to work unchanged on systems with WCF installed.
Existing applications are able to upgrade with WCF
New WCF transacted application will work with existing transaction application built on System.Transactions
WCF & ASMX Integration
WCF can use WS-* or HTTP bindings to communicate with ASMX pages
Limitations of ASMX:
An ASMX page doesn’t tell you how to deliver it over the transports and to use a specific type of security. This is something that WCF enhances quite significantly.
ASMX has a tight coupling with the HTTP runtime and the dependence on IIS to host it. WCF can be hosted by any Windows process that is able to host the .NET Framework 3.0.
ASMX service is instantiated on a per-call basis, while WCF gives you flexibility by providing various instancing options such as Singleton, private session, per call.
ASMX provides the way for interoperability but it does not provide or guarantee end-to-end security or reliable communication.
WCF is far wider in scope than ASP.Net webservices.
WCF can run in any application. APS.Net webservices only run in IIS.
WCF supports models like ReST, Remoting, SOAP, MSMQ etc. ASP.Net only supports SOAP
WCF is more configurable.
WCF supports a more declarative way of programming. You can get more done with less code.
ASP.NET Web Services are pretty much just that. Web Services. They're SOAP/WSDL based and provide their services only to the web.
WCF Services offer a much more flexible framework. For instance, depending on how the service is defined, it can be a Web Service hosted in IIS which serialized its data via XML and uses the REST model...or it can be a Remote Windows Service that is hosted in it's own process and serializes its data via binary. All of this is achieved using the different Service/Data contracts in WCF.
In short...you can make a WCF service look almost identical to a .NET 2.0 Web Service fairly easily but, with a little work, you can do a WHOLE LOT MORE.
I have a MVC pattern in place where I have been developing WinForms and WebForms against. Now, I would like to move onto Silverlight and thus need to 'web services'-enable my Model layer.
Where do I start? I can't seem to find any good resources. Many talk about EF or ADO.NET Data Services. What do I need to do to my Model layer to enable it for WCF REST?
There are many approaches you can take to build your server-side
ADO.NET Data Services - here is some documentation
ASP.NET MVC - if you do decide to use ASP.NET MVC, then this tutorial shows you how to access the service from Silverlight. Essentially Tim is showing you how to access the particular REST service exposed by ASP.NET MVC, but the same techniques (WebClient, etc) can be used to talk to any REST service
Build your own WCF SOAP-based service which implements the MVC pattern. This link shows you how to build and access WCF SOAP-based services in Silverlight.
Build your own REST service which implements a MVC pattern. There is a universal way to comsume any REST service from Silverlight, which is described here. To build the rest service you can use whatever platform you choose. You may consider the WCF REST support that comes out-of-the-box in .Net 3.5, or the WCF REST Starter Kit, which builds on the out-of-the-box REST support in WCF to give you some extra features. Or you can consider any other REST service framework of your choosing.
If you are going to proceed with the technologies you are talking about then forget completely about the term REST. What these technologies allow is you to do is object remoting over HTTP with the HTTP verbs. There is nothing wrong with that, just be aware of what you are trying to achieve.
The more you read and understand about REST the more confused you will get while trying to use Silverlight 3, ADO.Net Data Services, WCF REST Starter kit. These are all fine technologies to achieve what they were designed to do. Unfortunately, you will not learn how to do REST properly from these tools.
If you really want to do REST in .Net then start looking at OpenRasta.