I'm working on a project that relies heavily on communication between multiple WP7 devices. I wanted to use WCF callback contracts to create a subscribe/unsubscribe architecture for my services however I have recently found out that I can't use wsDualHttpBinding on Windows Phone 7 but only basicHttpBinding.
Can anyone suggest any approaches using basicHttpBinding which might allow for a similar approach?
You could always use Push Notifications to send the data to the phone (the other option would be polling the server at a predetermined interval which would kill battery life on the device).
You could look at using (raw) Push Notifications to tell the app that there is a new message on the server to retrieve.
Related
I have created UCMA trusted application using C# console application.
I want to monitor all Lync Users instant messaging calls (in one place) as well as store their conversations in the database via this console application.
Is it possible?.
If possible, please give an idea or any url.
UCMA trusted applications will only respond to traffic to the endpoints associated with that application so if you want to monitor all instant message traffic it would be the wrong API.
I would suggest using SIP Application API http://msdn.microsoft.com/en-us/library/office/hh364644(v=office.14).aspx to create a server application. This will also require the use of MSPL documented here
As Dai has asked - is the console application a requirement or will a windows service be ok?
Try our this sample application SipSnoop it basically shows all the metadata passing throught the lync server, you can tweak around it according to your requirement.
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.
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.
I am not sure though what exactly to ask since im very new to WCF. So I'll try to explain what I am doing. I need to create a web app with textbox and button. On button_click the data in the textbox should be push on a win form app supposedly to be deployed to a client. So what's connecting them is the wcf service. I am not exactly looking for codes as solution rather a theory or what I am missing. Thanks.
The simple method is to have your web site publish the button state and have the clients poll for updates. That is very easy to do with wcf, all you have to think about is security - if any.
The hard way is to let the clients to "sign" up on the wep application and then push the state to the clients. Each client would need its own wcf listening endpoint that can be called from the web application. The implementation is simple enough, but I'll suspect that you will run into issues with connectivity. Do the end user have rights to open ports for listening in windows? If the clients are behind nat-routers can you be sure that you can connect to them?
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