I'm trying to integrate the kafka with dot net 4.5.
how can the kafka topics consumed from api in dot net 4.5?
need solution for consuming kafka topics under api and pass front end through webservice.
Related
Why do we have SOAP connect option while creating a connector when we already have a Web Service Consumer connector? We can configure a wsdl with Web Service Consumer and access a web service. What is the difference between the two options?
"Why do we have SOAP connect option" because MuleSoft want to provide a method for ISV to provide connectors to new and existing endpoints without Mulesoft themselves having to create them. Mulesoft Anypoint Platform success is built on the premise of connecting to anything and therefore SOAP Connect helps this.
Secondly connecting to a using WSDL location for consuming a soap web service involves a developer to know the service pretty well and therefore allowing error and interpretation errors but if you internally create a connector you can reduce implementation time and errors.
Thirdly on WSDL there are often many methods not applicable or and an enterprise does not want to consume and therefore a connector can filter these methods.
Connectors = Re-Use
Web Service Consumer connector = manual process
The Web Service Consumer is an existing connector that you can configure to point to a WSDL location for consuming a soap web service. SOAP Connect is a DevKit wizard that creates an Anypoint Connector that connects to a specific service, which can expose multiple WSDLs of the service.
With Web Service Consumer we have to call each API separately in separate flows. With SOAP Connect, you can package multiple WSDL files and API versions into a single connector, making the process of creating, maintaining and using a connector for SOAP APIs much faster and easier.
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.
I want to build a new mobile app backend. This backend might eventually support other types of clients such as desktop or traditional web application.
In the past for multi client applications I would use this stack of technologies. SQL Server -> Entity Framework -> TCP WCF Service Endpoint -> MVC Web Application or WPF Windows Application
I know I want my mobile client to be consuming a Restful Http Web API like the types you would host in the new Azure API product. But I'm not sure if I should still do the WCF layer or not.
Couldn't all my clients consume just the Web API now? Or would it still be wise to develop the WCF service and the layer Web API on top of that?
It just doesn't seem right to be using 2 different serialization technologies at the same time.
Yes, you could replace that with Web API and create a REST API but as Tim already mentioned on his comment, that is obviously just HTTP and not all the protocols WCF supports.
Having said that, API Apps have Swagger metadata to describe what the REST URIs (endpoints) can do (e.g. methods, content types, descriptions etc.). There are a lot of Swagger SDK generators which can read the Swagger metadata and generate the code you need to consume the REST API in your application for pretty much any language out there. For Visual Studio 2013 with the latest Azure SDK, you have this capability built in as well. This is pure code generation, no tight coupling or anything, we just generate the code you were supposed to write to consume the API.
we have planned to use ASP.NET Web API for Windows Service Hosting instead of .NET Remoting and WCF service host.
Is it possible to have all the features in Web API that we have in WCF Service Host?.
Can we pass multiple arguments and complex arguments like Byte [] easily ?
and Can we get response as Byte []?
if so, can anyone give some C# examples for these needs?
Via Mule I'm going to call a web service. For this what kind of security mechanisms exists. I have referred to the mulesoft.org but I could only find security reference from the point of creating web service based app.
I'm going to call a Restfull WS using JSON
You can create your own cloud connector to consume the API, it is easy to do and it provides you OOTB support for both OAuth 1.0 and 2.0
Here some useful link to get started:
http://www.mulesoft.org/documentation/display/DEVKIT/Your+First+Cloud+Connector
http://www.mulesoft.org/documentation/display/DEVKIT/Authorizing+your+Connector+with+OAuth+2.0