I have one WPF client-server application. Now I have scenario like client will connect to server and server will push data to client periodically. I am bit confused about what technology and way should I choose for notification to clients.
SignalR is best for web application I think and I have desktop application. With WCF service, we can implement push notification through Duplex channel and callback. So can you please guide me what are the merits and demerits in using SignalR or WCF service ?
Thanks
Below are my observations from experiences:
SignalR pros:
Easy to startup, lower learning curve. You can easily run an example found from web
Exception handling (e.g. connection drops, timeouts) is embedded inside the API
SignalR cons:
Only supporting HTTP protocol
Duplex pros:
Supports TCP in addition to HTTP. This may be a serious performance gain if you know your client types and your system is working in a closed network. Also, working over TCP adds more connection stability than HTTP
Duplex cons:
Higher learning curve - harder to startup and have a stable solution. Want to verify it? Download a duplex and a SignalR sample from the web and see how much time you will spend to successfully run each other.
You need to handle all the exceptional cases (connection drops, timeouts, etc.)
I know I am not the only one who faced serious timeout problems when you want to use the duplex service for a long time. We need to make service calls periodically to keep client connections alive.
By the way, there are APIs exist for JavaScript, Desktop and Silverlight projects to consume SignalR services.
SignalR is not just about web. SignalR server side code does not care about the technology of its clients, you just need to have implementors at the client side.
If we isolate pusing data to the client, I would strongly recommend SignalR as it's much simpler than WCF in this aspect, I had my share of problems with WCF and I guess you had some yourself.
I found a simple console/web application sample here.
In general, Duplex WCF and using Callback like here seems very messy to me, there is a lot of configuration server side and this is why I think SignalR is simpler.
In addition, you can't use duplex (AFAIK) with javascript and objective-c.
I think you already got lots of data points about each of them. But selection of SignalR will provide you added advantage over development efforts which is in most of cases major decision block while selecting a technology.
You don't need to worry about API development / testing etc. and can have focus on your own implementation of the project.
Hope it helps!
SignalR can easily be used now with multiple clients from javascript, .NET both WinForms and WPF, and can even be used with a C++ client; Using a self hosted .NET signalr server (OWIN) is really nice way to have a standalone server that pushes / receives / broadcasts to multiple clients. The only thing that may be easier is ZeroMQ using its publish subscribe methodology.
One point that nobody has raised so far:
SignalR 1.0.1 requires .NET 4 on the server and client. Depending on
the version of your client and server that you are targeting that
might be an important factor to consider.
If you just want to update periodically for new data, you might be better to just use WCF and a polling mechanism from the client side rather than using either duplex WCF or signalr.
Related
I have a good understanding SignalR Hubs in a client/server scenario, where both the client and server are tightly coupled.
Let's say I have a WCF service that receives an update from some external resource. That service could update the database with a new value. However the client would need to be notified that an update has occurred. This could be handled through a service proxy that notifies the client (sounds a bit like polling) or some cache resource.
I could create C#-based clients and connect all the nodes via SignalR hubs, but this creates a closed, non-distributed system.
A SignaR hub that attaches to a WCF service could use the .Net 4.5 could implement a WCF asynchronous service operation, where a hub client would be notified with any service data changes.
I saw something similar in Push Notifications with NServiceBus and SignaR, but not sure if this is an optimal production-level solution.
What other methods could be used in this scenario and how would they be implemented?
If you are not using push notifications directly to the client or some kind of long polling then it is pretty typical to communicate with clients on another channel altogether. Not knowing the business case, it is hard to tell what would be feasible. Usually this manifests itself in the form of SMS, push notifications to mobile, email, etc. This does not answer your question directly, but you may find that there is another way to achieve your goal.
Please advise me on this.
I have both Wcf service (which will be responsible for highly secured data manipulations) and Web App in same Server and i will access this Web application (Which will consume this Wcf service for data manipulation) over internet.
1) Is this a good practice to have both in same server.
2) What WCF Security i have to choose either Transport or Message security.
3) What type of architecture i have to use (Eg: 3 tier or N- Tier)
I use VS2010 and .Net framework 4.0 and Sql Server 2008 for development.
Thanks in advance.
It is not a simple question to answer if it is a good practice to have the WCF service on the same server as the app. If you want ot shield the service as much as possible you could of course put it on a separate server behind the firewall only allowing the web app to access it. But then it does sound somewhat superfluous to create a service at all. Does it provide methods that should be accessible to a client? -- When determining the deployment scenario you also have to measure cost to security and scalability. More servers means higher costs both for buying the servers and for maintaining them.
I think you can use both transport and message security, but using message security you could transfer the messages on http, which means less traffic than https.
About the number of levels in your application, this also depends on the nature of the application. You might even consider CQRS or similar architectures. But if you have proper segregation of the layers and they only depend on the next layer you can always insert new layers if needed. Speaking of which: If you plan to use the WCF service as an internal DAL, you could also prioritize to just create a simple DAL with a proper interface, which could later be changed to a WCF service.
There are many good reasons for creating a web service and it gives you the opportunity of scaling on more servers later on, so I am definately not recommending against a web service, just saying that it might be overkill or introduce a larger attack surface in your application.
Performance wise you might get a boost by using tcp bindings rather than http, but connecting external applications is easier on http if some non wcf client is involved.
Perhaps this post contains more questions than answers, but you are the only one who can decide given the brevity of your description :)
i'm about to begin a WP7 project. i currently have a WCF REST service deployed on my LIVE servers, and my Android and iPhone clients are happily consuming this. how do i get my WP7 to communicate with my REST service? The server side is working fine and well, and there is no issue there.
what i thought i would be able to do was simply add my client library (compiled in SL) with all the interfaces, datacontracts etc, create a ChannelFactory, ensure the web behavior was on in the client and yay! away we go. this doesn't seem to be the case however. certainly i can't use the interface created because of the WebGetAttribute reference :S
what is the reccomended way? i would prefer to consume my service in the same way as the other services do for consistency, so i don't want to make new (and more verbose communication) bindings and simply expose the same service over a different endpoint. similarly using WebClient / WebHttpRequest just seems a bit backward: certainly we don't have to parse the response for the other types of bindings available, why would we for this?
any suggestions? basically i want to write as little code as possible to connect the client and the server (ideally as much as normal WCF communication would take) and would prefer to communicate with a channel, since there'd be no parsing or deserializing the JSON response on my behalf.
surely this is possible? most people working on mobile applications have chosen a REST service to communicate with, seems a bit odd that microsoft's mobile solution wouldn't neatly integrate with its own server side solution! i really hope i'm just stupid and have missed something quite glaring.
I believe at this point RESTSharp is your best option.
Another REST Client library: Spring.Rest
I am learning wcf but I have trouble understanding the benefits. Is there ever a time I would want to use traditional web services?
I read another thread with these benefits:
Opt in model for members using a certain attribute
Better security
No need to worry about binding (can't understand how this is true)
No need to worry about the xml
I read Programming WCF Services however this was an advanced book a bit like CLR via C#. I am now reading Learning WCF Services and will read Essential WCF (is recommended).
What would happen if I use a normal class to try to talk to a web/service reference? I know this sounds really naive, it's just my lack of experience in web services.
I am coding some WCF services so I am getting exposed to the specifics. They are interacting with a SOAP web service provided by my web host so I can get stats on my site. Is there anything wrong in this approach?
Thanks
WCF is a unified programming model for developing connected systems. What this means is that you use a single framework to develop service-oriented solutions. WCF allows you to keep your service implementation relatively unaware and care free of what's going on under the covers as far as how your service is consumed by clients and communication is handled. This allows you to take your service implementation and expose it in various ways by configuring it differently without touching your service implementation. This is the unified part. Without WCF, you have to get familiar with a framework specific for a particular communication technology such as ASP.NET asmx web service, .NET remoting, MSMQ etc and usually those frameworks impose on your service implementation and creep in such as using WebMethod attribute or having to derive from MarshallByRefObject object etc and you just can not take your service implementation and easily expose it over another communication stack. If I have a service that adds two numbers, why can it not be exposed over http or tcp easily without having to worry about low level details? This is the question in your post regarding binding. Binding allows you take a service and configure it so that it can be exposed over different transports and protocols using different encodings without ever touching your service implementation.
Is there ever a time I would want to use traditional web service?
Web service uses well defined, accepted, and used standards such as HTTP and SOAP. So if you want your service to be consumed by wide range of clients, then you would want to expose your service as a web service. WCF comes with pre-configured bindings out of the box that allows your service to be exposed as a web service easily: basicHttpBinding and wsHttpBinding. You may also want to consider RESTful services which is an architectural style that fits more natural with the HTTP model. WCF supports RESTful services as well
What would happen if I use a normal
class to try to talk to a web/service
reference? I know this sounds really
naive, it's just my lack of experience
in web services.
WCF service can expose the wsdl for a service just like ASP.NET asmx web service does. You can generate a client side proxy by simply adding a service reference to your client project. There is also a command line tool called svcutil that also generates the client side code that allows you to easily communicate with the service. The client side service class basically mirrors the service interface. You create an instance of the client side proxy for the service and then simply call methods on it just like any other .NET object. Under the covers, your method call will get converted to a message and sent over the wire to the server. On the server side, that message will get dispatched to the appropriate service method.
I hope this helps a bit.There are lots of online content such as videos on MSDN and channel 9 that you check out. The more you pound on it and expose yourself to it, the clearer WCF will get I am sure. Also, WCF is THE framework Microsoft recommends to develop connected system in .NET. The other technologies ASP.NET asmx, WSE, and .NET Remoting will most likely still be available going forward but may not be supported and developed further.
There are a number of existing approaches to building distributed applications. These include Web services, .NET Remoting, Message Queuing and COM Services. Windows Communication Foundation unifies these into a single framework for building and consuming services.
Here is a link from MSDN Why Use Windows Communication Foundation?
WCF is really the "new" standard and new generation of web service - and even more generally, communications - protocols and libraries for the .NET world.
Whenever you feel the need to have two systems talk to one another - think WCF. Whether that'll be behind the corporate firewall in your company LAN, whether it's across the internet, by means of a direct call or a delayed message queueing system - WCF is your answer. Mehmet has written a really nice summary of how WCF is the unification of a great many communication standards that existed in the Microsoft world before WCF.
I would think with the "Learning WCF" book, you should be a lot better off than with Programming WCF - that's quite advanced stuff already!
One of the mainstays of WCF is the architecture that you always talk to your service through a proxy - whether that service runs on the same machine using NetNamedPipe binding or halfway around the world in Down Under on a server - no difference, you always go through a proxy. That then also allows WCF to be so extensible - thanks to the proxy always being between the client (your application) and the service, it offers excellent ways of extending the behavior and the inner workings of WCF to your liking and needs.
WCF basically builds on SOAP communications - so interfacing and using existing SOAP services should be no problem at all. With the WCF REST Starter Kit and in the upcoming .NET 4.0 release cycle, WCF will also extend its reach into the REST style web communications, if that's ever going to be a requirement of yours.
All this really shows one of the biggest strenghts of WCF: it's a unified and extremely flexible and extensible communication framework, that can handle just about anything you throw at it. That alone is more than enough reason to learn WCF (which can be dauting at first, I agree!), and you won't regret the effort you put into this endeavor.
Marc
Have you a specific application you are writing for, or just getting your feet wet?
Google protocol buffers, is a very good choice of communications. John Skeet & Marc Gravell have both done C# implementations. See here
I'm writing a server app with a silverlight client. At some point I'd like non-silverlight clients to be able to use my services. Right now I've written some WCF services which get polled, but I'm not happy with the responsiveness. I'm thinking of switching the code over to using Silverlight/WCF duplex polling, but if I do that, will I be stuck with Silverlight as my only client? Is it better to write my own long-polling service using normal WCF http services?
I don't see your issue there. You can just define another binding for use by other clients (like WsHttpDualBinding). The same server code will perform the exact same task regardless of the underlying binding. That's the whole point of using WCF.
You can find a AJAX sample here for using a WCF duplex service http://tomasz.janczuk.org/2009/09/scale-out-of-silverlight-http-polling.html
By other .NET client - yes. By anything else : no. WsHttpDual is definitely NOT an interoperable protocol. It also has plenty of other drawbacks and pitfalls and I'd try to stay away from it as much as possible......
Marc