Am wondering if anybody has tried this a technique to get events to the client from the server side. I have an environment that uses Unix based servers and so can't use WCF duplex / callbacks etc.
The idea being that my clients are windows boxes running a thick .net app would spin up a WCF self host and register their self host URL on the server for that session. They would have a very simple contract and the server would when it has an update call out the client server telling it that an Update is waiting on the server for it and the client would then get it etc.
I still trying to get my head round WCF so not sure if this is a good way to go, are there any security implications I should worry about ? are there ways to get the Duplex calls to work across platform.
I have done something similar before using sockets or maybe a cross platform message queue would be a better way to go on this anyhow.
Thanks
76mel
At the very least, that sounds like it ought to work, though I'd guess you could host in IIS as well since the *nix servers could then just make a web call, right? I'm not sure what self-hosting would gain you, though it should work fine, but might be a bit more of a pain in the neck to configure, etc.
Please update here whenever you've made a decision because it sounds like an interesting challenge and some of us would like to see how you make out.
We use self-hosted WCF for a similar scenario. We also wanted to avoid making our client application dependent on IIS, to prevent both licensing and deployment hassles.
It works fairly well for us, though WCF might be overkill for what you need. Since you're using HTTP, you could create a simple web service built directly on Http.sys.
Another way of getting similar results could be to have the client poll. This does depend strongly on what requirements are there. If you need a near real time update, this obviously doesn't work as you would have to have way to many polls to do this, but if it's ok to take a minute or more to get updates to the client, polling might just be the answer.
Related
I have a windows phone 8 application, which communicates with WCF service using basicHttpBinding. The service is hosted on IIS7 (and not using windows azure)
As the service may go down for any reason, I am exploring the use of message queues to increase the reliability of the system.
I have looked at NetMsmqBinding provided in WCF - but it looks like this binding is not supported by WP8 client.
I am also looking at using RabbitMQ, but cannot find any working example with WP8 client using WCF.
Please can anyone suggest what is the best way forward? Any sample code (or links) will be much appreciated.
Thanks
First off, netMsmqBinding cannot be used across the internet. This is because it uses MSMQ which is not exposed over http.
When you're making calls to a resource across the internet, unreliability is something you need to factor into your application. Because of the number of possible problems you can encounter, it's generally not a case of if, but when, there is a failure and it's how your application deals with this which is important.
Even so, there are things you can do to minimize the reliability issues you experience, one of which does involve queuing.
Where queuing can be useful is taking large, complex, and long running processes offline. Because calls to such processes implemented synchronously often time out, you can gain a lot of reliability by making the actual processing call asynchronous.
As an example, it would be fairly common to have the web server invoke some offline process via message queuing and return to the client that their request is being processed. Because doing this is inexpensive calls are far less likely to fail. Your problem then becomes one of how to return the response to the client once the offline processing has been done.
I am working on a project in which I want to use a Windows Workflow 4 State Machine. The Visual Studio solution templates and most guidance seem to steer everything towards hosting as a service in IIS that is created dynamically from send and receive activities within the workflow.
However, I would prefer to not use the send and receive activities and then host in my own WCF service which would allow me to use a Windows Service instead of IIS and use other bindings like TCP instead of HTTP and create my own interface instead of exposing MEX. In addition, it would be portable to any other hosting arrangement like in a WPF app or a console or whatever.
This feels a lot more flexible to me. Somehow, having service operations as part of the workflow seems like pretty tight coupling of two things that aren't that related. Is there any downside to my approach? I'm new to WF so I might be missing something.
Depending on the kind of workflows you are running you might need to write quite a bit of pluming code that workflow services provide for you.
Things to consider:
Are your workflows long lived?
Are you sending multiple messages to the same workflow?
Do your workflows need to survive a host restart?
Are you using Delay activities to respond to timeouts?
Do you need to be a able to retry action after error situations?
Lots of these things are automatically taken care of with a WF service and need your attention otherwise. It is certainly doable, I have done it in the past, but be aware of of what you are losing.
We set up a windows app that talks to a windows service for certain operations. It's set up and working using wsHttp but we need to add the url to the URLACL list for the service to run. Is this going to be an issue with other bindings as well, or are we basically just using the wrong one at this point?
In the future the service might be moved from the end user's local machine to a server on their network, so maybe we should use some other binding?
Seems like the "next" best option is netTcpBinding, but to use that you need to start the TCP Port Sharing service: http://msdn.microsoft.com/en-us/library/ms731810.aspx
Since the whole point was to simplify installation on client machines and reduce the number of changes to their configuration I'm not sure that gives any real advantage. I could convert to netTcpBinding for speed since it is the fastest protocol... but in this case it's fast enough to not justify more dev time.
Hate answering my own question, but hopefully this helps someone else down the line!
I want to communicate xml serialized objects from the server to the client and the other way arround. Now it is (probably) easy to invoke methods from a mobile client (compact framework) using WCF, but is there a way so that the server can invoke methods on the client side or some other way to pull data from the client? I know that callback contracts are not available in the compact framework as you can see here: http://blogs.msdn.com/andrewarnottms/archive/2007/09/13/calling-wcf-services-from-netcf-3-5-using-compact-wcf-and-netcfsvcutil-exe.aspx
Originally I thought of socket programming and of developing this by myself, then someone here mentioned WCF. But it seems like WCF only would work in a non mobile environment as I need callbacks.
Anyone can help me with this? Is it possible to develop a two way communication with a desktop server and multiple mobile clients using WCF, or will I have to do socket programming?
Thanks for any advice or any kind of help!
at ctacke
Thank you for your help. I actually stumbled across your Padran web server before.Havent really checked it out yet. But I definitely will do that later on. Anyway, a socket solution does not seem that bad at the moment. In the meanwhile I figured that it is quite easy to send data from multiple clients to a 'socket server'. If I can manage those connections somehow I can send data back to the clients. And then I would have to come up with some kind if protocol which handles the data or commands I send over the network... I guess the hardest part would be to make up such a protocol as I do not have a clue about that atm...
Even if you go to sockets it might be a bit difficult due to routing, carrier filtering and NAT translations (you've not mentioned what your actual network topology is). This is the reason that most mobile applications have to poll the server, even if it is a "push" paradigm (like Exchange's push mechanism, where the client actually polls).
Generally speaking, unless you're on something like a local wireless network where you have solid, routable, unfiltered network access, the client should periodically call the server and ask if the server has data. If it does, then it pulls the data from the server.
EDIT
Now that we know a little more about your topolgy from your comment, I can steer you a little more. Unfortunately Microsoft has not made it easy for Windwos CE devices to host services (WCF or otherwise). There is, in theory, the required infrstructure to build up your own WCF channel and actually host a service, but it's not a trivial task. I looked into it quite some time ago and figured it was a couple months of work and that would have been with the assistance of someone in Redmond that knew how the existing Exchange channel works.
Personally I'd opt for hosting a REST-based web service using our Padarn web server because it's simple to do and I've done it for quite a number of clients now. I realize that it's a little self-serving to propose Padarn as a solution but the entire reason I implemented custom IHttpHandlers in Padarn was because I couldn't find anything else out there that really provided any easy way for a CE device to host it's own services and it's a problem we often have to provide a solution for.
The other options would be things like a proprietary socket solution, hosting an FTP server on the device, using the (abhorrent, IMO) MS-provided HTTP server with ISAPI, Telnet or something along those lines. All of them seem either a hack, a lot of work or both.
Just a technology update, now that .NET 4.0 is out.
I write an application that communicates to the server through what is basically a message bus (instead of method calls). This is based on the internal architecture of the application (which is multi threaded, passing the messages around).
There are a limited number of messages to go from the client to the server, quite a lot more from the server to the client. Most of those can be handled via a separate specialized mechanism, but at the end we talk of possibly 10-100 small messages per second going from the server to the client.
The client is supposed to operate under "internet conditions". THis means possibly home end users behind standard NAT devices (i.e. typical DSL routers) - a firewalled secure and thus "open" network can not be assumed.
I want to have as little latency and as little overhad for the communication as possible.
What is the technologally best way to handle the message bus callback? I Have no problem regularly calling to the server for message delivery if something needs to be sent...
...but what are my options to handle the messagtes from the server to the client?
WsDualHttp does work how? Especially under a NAT scenario?
Just as a note: polling is most likely out - the main problem here is that I would have a significant overhead OR a significant delay, both aren ot really wanted. Technically I would love some sort of streaming appraoch, where the server can write messags to a stream while he generates them and they get sent to the client as they come. Not esure this is doable with WCF, though (if not, I may acutally decide to handle the whole message part outside of WCF and just do control / login / setup / destruction via WCF).
For bidirectional communications, your best bet is NetTcpBinding, rather than the http bindings, if they're available.
This has the advantage of only requiring that the client can initiate a connection with the server.
I would go with Windows Azure Service Bus. See my answer in the following question:
WCF, 4.0, Bidirectional
Take a look at Windows AppFabric, good place to start is Here. It fundamentally wraps up WCF and WF into an application server, with WCF activation supported through WAS. Its where I would host this type of app. It offerd full duplex connection orientated, p2p or sessions between client and server. Don't confuse the Windows appfabric with Azure appfabric, (formely called Azure Service Bus).
As regards bindings above, both NetTcpBinding and WsDualHttp offer callbacks, but the ws binding you get a lot for your cash, especially if it's a mixed programming environment and you have to flatten the wsdl to make interop work. I also think that WsDual is easier on routers traversal, although I understand talking to friends, that Windows AppFabric mitigates this, with new Relay Services, (which i've not seen, and I think have now been renamed).
Hope that helps.