i'm making an asp.net website to support Json request.
Each request must send a message on a ESB (actually NServiceBus) but i'm struggling with response..
I can actually receive multiple request of same type so the website send similar messages of same type on the bus. How can I be sure that each message response from the bus goes to the exact "requester"?
How can I deal with slow or no bus response?
Take a look at the AsyncPages sample that comes with NSB. That demonstrates how you can use callbacks and the async support in asp.net to build robust message based communication from a website. Callbacks is there if you need to get a response back to the webserver that sent the request (command). It's often better to have the website only send messages off and then read the result from another data store (ravendb , sqlserver etc). That will give you the chance to get at the data even if the webserver goes down (callbacks are not persistent)
Related
I'm trying to write a .NET Core API Controller action that would basically act like a HTTP proxy:
Data comes in POSTed via Request.Body stream
Then POSTed to another backend service which processes the input data stream live and starts sending result back while still reading and processing input
Resulting POST response is read and streamed back to the caller of this 'proxy'
I tried a couple of things, playing with both HttpClient and old HttpWebRequest but still can't make this work properly, the process deadlocks somewhere.
I would also like to better control if possible the HTTP request output buffers as I observed that data starts to pile up in-memory if backend service can't accept it fast enough (stream.Write() calls don't block immediately and process memory spikes).
Any ideas or examples?
I have a simple Web API that receives POST messages from geographically dispersed clients.
I have a swathe of WinForms Applications that act as "satellite" applications which send payloads to websites. So these applications maintain state, logins, and other functionality specific to each website they represent.
Theory is:
WebAPI receives a request, and sends it to the specific WinForms application which then forwards on the payloads as per its requirement.
So External Client->Web Api Post->?IPC MECHANISM HERE? Sends Payload->WinForms Delivers Payload->Sends Response back->Back up the pipe and back through WebAPI
Where I am "missing" at the moment is the most efficient and quickest way possible for my my POST Request, to get the message to the respective WinForms Application AND get a response.
I have been reading about signalR. I have been able to create a Hub and send a message to one client (which is all I have for testing now anyway). BUT - I have read this morning that I cannot get "return" messages back from my client.
Some of the SO messages about this are dated and brings me to my question - is there any way I can achieve this with SignalR.
As an appendix to the question:
If not, are there alternative bits of tech I can be advised to review or pursue as an alternate?
FYI - I did have this all wired in internally to WebAPI itself which then simply responded with the return values, but as requirements have grown - "state"/"logins"/"sessions"/"cookies" need to be maintained which prompted the decision to "externalise" each payload delivery system.
I'd like to communicate from my web app to an endpoint on a different tier via MSMQ. I've found examples of how to do this by binding with WCF, but not how to with WebAPI.
Why do I have to use WCF?
Are they any other alternatives?
Other than WCF's netmsmqBinding, you could also obviously use the more native System.Messaging.MessageQueue .Net classes to read and write directly from queues. However, it sounds like you are trying to pull messages from a client such as a browser?
Although you can send messages to MSMQ via Http, you can't receive messages over Http directly.
So TL;DR I believe you will need to write your own capability to receive messages via HTTP / REST etc, e.g. via a WebApi controller action which reads exactly one message and returns same. In doing so you will likely lose any transactional boundary across queue messages.
I am currently working on a project which I think using soap as part of it would be a good idea but I can't find how it will work in the way that I need.
I have a C# Console Application called ConsoleApp, ConsoleApp will also have a PHP web interface. What I'm thinking of doing, is the PHP web interface controls the ConsoleApp in some way, so I click a button on the web interface, then this does a sends a soap request to a soap service and then the soap service, sends the information on to the consoleApp, and the result is returned back to the SoapService and then returned back to PHP.
This seems like it would need to separate soap services, one for php to interface with and one within the ConsoleApp but this doesn't sound right, I think I might be misunderstanding the purpose of Soap.
How can this be achieved. Thanks for any help you can provide
UPDATE
As requested I thought I'd add a bit more information on what I am trying to achieve.
In the console app, it is acting as an email server sending out emails that are given to the program and then being sent on, and if it can't send it retries a couple of times until the email goes into a failed state.
The web interface will provide a status of what the email server is doing, i.e. how many emails are incoming, how many are yet to be processed, how many have sent and how many have failed.
From the web page you will be able to shutdown or restart the email server or put one of the failed emails back into the the queue to be processed.
The idea is, when the user adds a failed email back into the queue it sends a soap message that the console app will receive, add the information back into the queue, log the event in the console apps log file, increment a counter which is how it keep track of emails that need to be processed. Once this has been done it should then send a response back to the web interface to say whether or not the email was successfully added back into the queue or whether it failed for some reason.
I don't really want to keep on polling the database every so many seconds as there could be the potential for their to be a large number of emails that will be being processed so polling the database would put a large load on the MySQL server which I don't want, which is why I thought soap as the email server would only need to do something when it receives a soap request to do something.
Thanks for any help.
Every web service is going to need a client (in your case PHP) and a server (ConsoleApp). Even though there are two endpoints, it is still one web service. Your PHP will send a SOAP request which ConsoleApp will receive, process and respond to with a SOAP response.
So when someone clicks the button on the web page, you can use JavaScript to build and send the SOAP envelope in the browser. The alternative is to POST the values to a PHP page that will build and send the SOAP.
I have to admit though, your scenario sounds a unusual. I personally haven't heard of web pages talking directly with console apps. Web pages usually talk to web servers, and the servers are usually the ones issuing atypical requests, like your request to ConsoleApp. While it is technically possible, but I think it is going to be harder then you are expecting.
Personally, I would ditch SOAP in favor of a much more simple and scalable solution. Assuming you have access to a database, I would have the PHP create a record in the database when the user clicks the button. ConsoleApp would then poll the database every X seconds to look for new records. When it finds a new record, it processes it.
This has the benefit of being simple (database access is almost always easier than SOAP) and scalable (you could easily run an arbitrary number of ConsoleApps to process all of the incoming requests if you are expecting heavy loads). Also, neither the PHP page nor the ConsoleApp have a direct dependency on the other so each individual component is less likely to cause a failure in the whole system.
The problem:
How to send data to and from a RESTful web service to an android phone. The data currently is sent in bytes and there are multiple messages sent both ways until the entire message is sent (denoted by some delimiter in byte array). It is easy to send to the web service from android using a POST to web service. The service must now send multiple responses back to android.
I am wondering if this solution would work, or if there is something better?
Suggested Solution:
After a successful post to the web service from android, the android will receive an initial response from the post function call. This response will contain a message ID. Now if that response does not have the message delimiter, then android makes a call to the POST function again with a special parameter containing it's Message ID and the web service will return the next part of the byte array. This continues until the entire message is sent.
Thanks in advance for any help. Also to note, the web service knows the phone's IP address after the first message and we must keep this connection-less (so no sockets)
REST uses a simple Request/Response mechanism. The way http works is that you send a Request, and the server sends a Response back. What you are mentioning is behaviour more like Web Sockets. You should do a little research on web sockets. They allow you to make a connection with a server from the client, and then until the connection is severed, the server can send messages to the client.