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.
Related
I have a XSD that I have generated classed from. After filling a class with data and serialize it, I want to send it to one or more specific clients.
My plan is to use SOAP, but the only way in my head to do this would be to create "www.example.com/message/custNumber" the same soap message in different URL's and let the client continuously look for new messages.
When the message is received at the client(s), they will need to send a acknowledgment back to the server.
Is this possible with SOAP? Or should I be looking at other ways for communication?
WCF has the possibility to dynamically set the endpoint of the service and with duplex message exchange pattern you can define that some messages require a ack back from the receiver.
I am wondering how to process responds from WCF RESTful service in a right way. For example, service could throw new WebFaultException(HttpStatusCode.Unauthorized);. But how can I get a particular reason of this respond and process it on client? I know that I could use WebFaultException<T> and extend exception with some data describing details. But what if client is written in native C++ or php... The whole idea is to interact with the service from console application (could be written using a huge set of languages) via HTTP/HTTPS and query some data.
The output is available in two forms JSON and XML, and handling error would depend on how it is being structred in the response.
you make like to have a look at this.
I recently discovered SignalR, seems that it can fit into high-load projects with hundreds of concurrent connections.
But as far as I can see, it is only supports full communication type of software (real-time).
So here is the question: is it possible to create REST services with SignalR without client code & persistent connections?
Basically I just need that asynchronous high performance server side part from SignalR & HTTP request handler (if exists).
Regards.
Nope that's not SignalR's purpose, use WebApi if you want to make a streaming restful api. Take a look at push content http://blogs.msdn.com/b/henrikn/archive/2012/04/23/using-cookies-with-asp-net-web-api.aspx.
I'm trying to build a http listener (webservice) with wcf. This listener is part of a bigger desktop application. This desktop application also invokes the http listener.
When the listener receives data it should be passed to the desktop application. I tried to build an httpbinding service and use the callback mechanism
[OperationContract(IsOneWay = true)]
void OnDataReceived(Data data);
The problem is that I need wsDualhttpbinding because of the callback.
Do I really need to use the dualhttp to send data from one .NET app to another or am I missing something?
Thanks
Yes you need dual or duplex communication. HTTP by its very nature is a single direction protocol. The client has to invoke the server. The server has no way to talk to the client with out that.
Your problem is you have an event source which is exposed as a WCF service. The only way to for the service to send events to it's clients in real time is via a full duplex connection which means using either duathttp or dualtcp bindings.
However, using duplex bindings is complex at best. It would be simpler to allow the client to subscribe to the service and to then receive messages when events happen which the client is interested in.
This is much simpler than duplex bindings because there's no actual connection between client and service, only asynchronous messages.
While WCF provides bindings for msmq transport, it does not provide a binding with this kind of pub-sub support, so you can either code for this or you can use an open source messaging bus like NServiceBus.
If you are using a callback mechanism, as opposed to a polling mechanism, then yes, you need Dual binding as the WCF services needs to be able to both Send and Receive messages (as opposed to Receive and return responses)
I have the following architecture for a project I'm working on.
My question is how to begin implementing the TCP/IP responder part.
It's function, in case the diagram is hard to read, is to wait for a connection from the Order Viewing client, and subsequently notify said client of incoming orders.
I was thinking a queue, but unfortunately I don't know where something like this would fit in the VS2008 hierarchy of things.
If it's part of the ASP.NET web page, should I use the application start event to start the TCP IP responder?
It's not a web service, because those respond to http requests...
If I had to implement your "TCP responder" I'd probably implement it as a windows service and have both the ASP.NET app and the Winform client contact it (e.g. to avoid the problem of recycling of the ASP.NET etc.)
That said, I can think of gazillion easier ways to get the effect you want to achieve (getting the winform client to know about new orders) such as
Using Queues as you mentioned. Windows comes with MSMQ (you need to enable it in add windows features). Using MSMQ from C# is fairly easy. You can also use WCF if you like
exposing an http endpoint on the client and have the client notify the ASP.NET server where it is listening by calling one of its pages
write the orders to the DB and poll it from the client/use System.Data.SqlClient.SqlDependency to know when there's a change
Heck even writing the orders to a file on a shared folder with a FileSystemWatcher would work (though I'd probably wouldn't recommend that)
Why don't you use http? You already have the http server so you don't need any TCP responder - just do http polling at the client.
And if you don't want polling or have too many clients then you can use something like SignalR for notifications.