I am building a website using ASP.NET MVC which gonna be deployed as Azure app service and I got another program which will interact with the website backend in real time and sends live data which needs to be displayed on the website as live data and it is bi-directional. We used message queues (Azure service bus) before and these doesn't seem to be reliable (delays coming up on sending and receiving data).
Can anyone suggest me what is the best way to go with?
Websockets or database operations or anything else
Related
I have an API running on a Function App in Azure.
I want this API to only accept communications from two parties:
A blazor website
All copies of a piece of packaged software (a WPF application which will run on customer computers)
I want all other traffic to be rejected.
What is the best way to configure this networking scenario?
The ideal setup:
API should only be able to talk to the Blazor App as well as the client programs, not outside connections. The API can talk to the database which lays behind a virtual network. This Database VNET is already set up.
Any help is appreciated.
Use API Management in front of the API and require Ocp-Apim-Subscription-Key in the requests.
Also, add ip restrictions to avoid unauthorized access
I need to host ASP.NET based app as Azure Web App which should communicate with WCF based Azure Web App. ( WCF app is also an azure Web App not an on-premise app at all).
What are possible ways to achieve easy and flexible communication between both app services?
Do we need to establish a communication channel specifically?
Both Apps under IIS On-Premises are used to communicate without any problem over NET TCP protocol. But I think now we need both services to communicate over HTTP instead of Net TCP?
What problems we may have?
What things do we need to bear in mind?
First of all, we need to be clear that azure webapp only supports ports 80 and 443.
Secondly, in your project, you said that it runs normally in local, because I don't know what you mean by communicate, and I don't know how to achieve it. Normal communication may be socket or websocket, etc. It is not clear what communication you are talking about. If it is socket and you need to use a port other than 443/80, then it is not supported.
But I know clearly that azure web app supports wcf, which means that both of your webapps can be deployed successfully and run normally. If there is a problem, you can update the error details in the post, and we can provide you with further assistance.
I am trying to figure out which Azure service to use to create a distributed application. The application consists of
A desktop (Windows) application which is fetching, manipulating and storing data in Azure
A backend which stores data and does background processing.
A web front-end which allows me to view the data and trigger background processing in the backend
Any number of desktop application instances can connect to the backend and access the same data
The desktop application and the web application will send and receive data to the backend. Each message can be up to 100 MB (images etc).
The Azure universe is a bit overwhelming, and I'm trying to find out how to set this up.
My initial thought is to let the desktop application communicate with an Azure Cloud Service with WCF. The cloud service is set up with a WCF web role. A separate web application (web role?) is communicating with the same WCF web role.
The WCF role will also start worker roles to do more heavy, time-consuming processing.
Any ideas and insight is welcome! :)
For WCF service and web front-end you can use both Azure Cloud Service or App Services - it mostly depends if you need to install some 3rd party components on the machine (Azure Cloud Service allows you to do that).
For background processing use Web Job in App Services or worker role in the Cloud Service. You should also use some queue (I like more Service Bus then Azure Queue from storage account). Your worker role or Web Job should monitor this queue and when you put some message to it then some background processing should be triggered. Background processing could be done also in WCF process itself, but using worker roles or Web Jobs allows you to provide more availability.
For storing blobs (like images) definitely use Microsoft Storage (Blobs), for other data you can use Sql Database or something quite new: DocumentDB. Sql Database is simpler to use and easier to migrate data to other servers etc. but is more expensive.
And of course you can do the same on Virtual Machines, but I guess it wasn't something that you asked for :)
I'm starting up a little code project to learn from the process, but I am not sure what's the best way of communicating between the different parts.
First, I have a pure html/js client where the users need to get live updates frequently.
Secondly, I'm considering having a web api application running to provide data.
Thirdly I have a console application running, that needs to communicate with the web api application.
So I'm thinking about using WebSockets all the way from client->web api->console app, but I have trouble making it work. I can make the console app work as a server, but I can't figure out how to make the web api work as a client, so that when it spins up, creates a connection to the console app, and keeps it open for communication, while it delivers data to the clients upon requests.
I tried with different implementations and I have ended up with SignalR, as it seems like that's what people use today :)
Since I have all these problems getting a connection I am wondering if there are better ways of sending data that fulfills my requirements?
If WebSocket (using SignalR) is the way to go, can you provide some links with working examples? I have tried all the top links from Google with no success ^^
Thanks in advance
Your WebAPI project can act as WebSocket server as well. Check this link that uses an IHttpHandler, but you can also do it in a WebAIP's controller how is explained here : Using WebSockets with ASP.NET Web API
The console application should connect as client, using for example ClientWebSocket class.
WebSockets are persistent full duplex connections, so once the client is connected both ends can push information to the other end.
I am creating a client application that downloads and displays market data from Yahoo! for a university project, but that also sends out notifications to mobiles (so far using Google cloud messaging). So far it's a WPF client and the "server" is a class library - so far working. What I was wondering, is can you mix this server with a WCF service - the WCF service I was planning on using for registering devices, as well as accepting and parsing commands.
So I would call .Start() on my server object, and it will be constantly running in the background, while a WCF REST service runs alongside it - or would I be better simply having a thread running on the server that can accept input... sorry if this is confusing, but just wondering if it can, or has been done before or any advice. :)
Just to explain a bit better
The client front end and the "server" are running on the same machine - I was calling it a server because it is not only updating the front end, but sending out GCM notifications at the same time. I was wondering if maybe a WCF service could be added to make it simpler to handle adding devices to a database ("server" reads a list of device reg ids from a database, sends notifications to these) by allowing an android app to details via REST or something similiar
I would explore wrapping the class library in a Windows Service (which is essentially a process that runs continuously, and can be stopped/started/paused) and keep your WCF service as a web service for client communication.
How the WCF client service communicates with the Windows service is up to you - whether you store the data in a shared database, keep it in memory and have another WCF layer communicating between the two, etc. A shared database would be the most straightforward, especially if you want to persist the data for use by other apps/services as well.
WCF Service would be useful if you had one notification service on your server with multiple WPF client application connecting to it. If you have just one application running on the same server then not sure if it will be worth the overhead.
The usual pattern is to host WCF service in IIS, that way it always starts whenever first request is received. WCF is very flexible though, therefore you can host in in Windows Service, Console Application, etc.