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)
Related
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'm new at WCF and I've got one problem, and I don't have an idea how to solve it.
I've got Windows Service app listening to COM ports, and GUI WPF app for configuring Windows Service app. Among that my idea is to send notification to WPF app every time when something comes to COM port and maybe send that data to WPF.
For communicaton between those two clients I use WCF, and for sending data from WCF service to WPF app I got to use callbacks.
I got to use two different ServiceContracts because of two different clients. One of ServiceContacts supports callback method, and one of them not so there are two different bindings.
Is there any way to invoke callback method implemented on WPF app when WS gets data from COM port. On WS I invoke proxy method defined in ServiceContract for WS, and get data in WCF service but when I invoke callback its always null. I know that there is problem with OperationContext and I know what problem is but I dont know how to solve it, or is there any way to solve it.
Please help me and thank you.
I think duplex WCF (i.e. contract with Callback) is one way to go if your WFP client is normally calling the "service" via WCF anyway. You will obtain the callback context in the "service" contract class (its constructor usually) and then use it to forward anything to the WPF client at any time. Google "Duplex WCF".
However this is a situation for which in enterprise scale you will use a middleware solution, i.e. a separate "message queue/bus" infrastructure to which the WPF clients subscribe and get their updates. If no one is subscribed, messages are sent to /dev/null. The "service" publishes everything to the bus at any case.
I have a windows application which hosts two services as netTCPBinding and also has some client dialogs.
one of the services is duplex. When i run two different instances of my software (one as server and one as client) there will be no problem.
However, when i run only one instance as server and client (in tandem), the duplex service does not work. The problem happens on Subscribe() method call. after timeout exception, Subscribe() method of host will be invoked.
Do you have any idea how to solve this?
There's not enough information in your question to provide a detailed answer, and I'm not sure but I'll give it a try anyway.
I bet your problem lies in the reentrancy behavior: Just mark your service implementation with the following:
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]
This will allow incoming calls from the same endpoint while you're processing a request.
The problem was not because of the WCF. It was because of the StreamInsight. If you are using WCF based sinks in embedded StreamInsight scenarios note that the sink will not be generated until an event comes into your query. In my case, it was not possible to connect to sink at first before sending data to source.
I have been reading a lot of forums regarding the use of WCF in web, most specifically, this topic: WCF with Flash tutorial, but I am really confused.
I have an existing feed server that is using WCF service. It is, with no problems, supplying real-time information to its windows applications clients. What i would like to do is to have a web application to subscribe to the feeds that i am supplying to the windows application clients. With the forum that i have read (the one i have indicated), it seems like it will be a request reply method. And i think, using that, i wouldn't be able to achieve the real-time transfer of feeds for it.
I would like to know if there is an equivalent for the callback function in web development.
I think Duplex service meets your requirement.
Please use Duplex type of WCF services.
A duplex service contract is a message exchange pattern in which both endpoints can send messages to the other independently. A duplex service, therefore, can send messages back to the client endpoint, providing event-like behavior. Duplex communication occurs when a client connects to a service and provides the service with a channel on which the service can send messages back to the client. Note that the event-like behavior of duplex services only works within a session.
Links:
http://msdn.microsoft.com/en-us/library/ms731064.aspx
http://www.c-sharpcorner.com/uploadfile/dhananjaycoder/a-simple-duplex-service-in-wcf/
http://msdn.microsoft.com/en-us/library/ms731935.aspx
You can also use web sockets which is new in WCF 4.5. Below are web socket WCF links:
http://msdn.microsoft.com/en-us/library/hh674271.aspx
My Winforms client/server application relies on UDP multicast to update all clients in real time. The server fires events into a known UDP sink, and each client receives them, both using instances of the System.Net.Sockets.UdpClient class.
This works great -- when it works. Each client has a remoting object on which it makes its synchronous calls, via TCP, and UDP handles the asynchronous stuff, so the client remains stateless. But many of our clients have UDP disabled in various ways -- some disable multicasting, some disable UDP altogether, some have it disabled on purpose, others by accident. I end up doing a lot more network administration than I would like.
The other choice, it seems to me, is for the server to manage client connections and send the events over TCP, but this requires a stateful server and does not seem very attractive. Are there superior alternatives?
You can try using WCF and the publish/subscribe design pattern. I moved a winforms TCP/UDP app much like you described to WCF using netTCP binding and a UDP broadcast for the clients to find the server, once they find it, they subscribe and you use WCF callback contracts to update the clients. You'll need to have intelligence on both sides if a connection is dropped.
Also in your case if the server is always a set address with WCF callbacks you wouldn't need to use UDP to find the server, so you could eliminate UDP and just rely on the netTCPBinding to push messages to clients and vice versa.