I googled two examples on how I can notify all clients when specific event happens and I'm confused which of them I should use:
Example 1 - http://www.nullskull.com/a/1360/notify-client-applications-using-wcf-callbacks.aspx
Example 2 - http://www.anujvarma.com/wcf-publish-subscribe-a-full-example-the-service-side-part-2-implementation/
In first example event, eventargs etc are placed on client side, in second - on service side. Where should I place events?
Brief of what I'm trying to achieve: simple card game project that uses local network. I want to notify all clients when one of the clients throws a card (placed it on table and ended his turn) and update they're interfaces, so each client can see thrown card.
If you are going to use WCF, then you need to implement broadcasting events with a duplex WCF service (broadcaster service). The first link does mention this.
I think the events you are referring to are the operations that occur on the service and client:
To create a duplex contract you create a pair of interfaces. The first
is the service contract interface that describes the operations that a
client can invoke. That service contract must specify a callback
contract in the ServiceContractAttribute.CallbackContract property.
The callback contract is the interface that defines the operations
that the service can call on the client endpoint.
You may want to also consider using ASP.NET SignalR.
SignalR allows bi-directional communication between server and client.
Servers can now push content to connected clients instantly as it
becomes available
Related
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 want to interrogate a WCF service and I need a robust solution.
It's not acceptable that the service go down just because there is another program using the same port.
Port are technical details that should be transparent to the end user.
Which solution can I use?
Can I try so look for the service at two endpoint with different port numbers? Or help the conflict even using the same port?
I’m not entirely sure what you are trying to accomplish, but if you need to “abstract” your WCF Service / multiple endpoints from client applications then you may want to consider the WCF Routing Service.
The Routing Service is a generic SOAP intermediary that acts as a message router. The RoutingService is implemented as a Windows Communication Foundation (WCF) service in the System.ServiceModel.Routing namespace. The Routing Service exposes one or more service endpoints that receive messages and then routes each message to one or more client endpoints based on the message content.
In addition to the destination client endpoints associated with each filter definition in the filter table, you can also create a list of backup endpoints that the message will be routed to in the event of a transmission failure. If an error occurs and a backup list is defined for the filter entry, the Routing Service will attempt to send the message to the first endpoint defined in the list. If this transmission attempt fails, the service will try the next endpoint, and continue this process until the transmission attempt succeeds, returns a non-transmission related error, or all endpoints in the backup list have returned a transmission error.
I thougth the reason is bound to firewalls.. in enterprise level apps the single port should be opened.. so it's better to already know the ports.
I have searched a lot, but still I had few doubts about MSMQ implementation of WCF service.
Hence I have put this quetion.
I want to implement single publisher and multiple subscribers asynchronous message system.
I have decided to use WCF service as the publisher.
I have multiple instances of the window service on different machines as the multiple subscribers.
Q. I want to know that, how this model can be implemented as the old MSMQ approach?
The object of following type would be used in the message
[Serializable]
public class Message
{
public string Signal{get;set;}
public Guid Identifier{get;set;}
}
In the above class, Identifier would be used by the windows service to decide whether the message was published for that service or not.
Q. How the different window services will read the same queue?
Q. Where the queue should be hosted?
Q. Is it possible to send the acknowledgement from Window service(subscriber) to WCF service(publisher)?
Any help would be appreciated.
In answer to your questions:
I want to know that, how this model can be implemented as the old
MSMQ approach?
First off, MSMQ does not support publish subscribe out of the box.
How the different window services will read the same queue?
So in publish subscribe, there in no ONE queue. Instead there are multiple queues, in fact one per participant in the pub sub scenario. So each publisher has a queue and each subscriber has a queue.
This configuration enables subscribers to send subscribe/unsubscribe messages to the publisher, and allows the publisher to send messages to the subscribers as necessary after evaluating the subscriptions.
Where the queue should be hosted?
These queues can be hosted locally to each participant, or can be hosted together in some clustered location.
Is it possible to send the acknowledgement from Window
service(subscriber) to WCF service(publisher)?
MSMQ does provide basic support for request/response messaging via response-queue and correlation-id message header fields, though this is not truly out of the box (as you are required to consume and program against these values)
If you are not required to use WCF there is a fairly mature platform called nservicebus which sits on top of MSMQ and does provide support for all the messaging patterns you need.
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.