We would like to develop WCF service for SL clients, which should support session management (PerSession) and callbacks. The WCF service would be hosted as a Windows service.
What would be best WCF binding choice (wsdual, pollingDuplex, any other)? Please also provide for/against points.
Regards,
There are no others. Silverlight does not support WSDualHttpBinding. You can choose PollingDuplexHttpBinding or PollingDuplexHttpBinding.
Have been working a little more in this area and it appears this is an area of constant and recent change. As of Silverlight 4, NetTcpTransport and HttpTransport are both supported using either text or binary encoding. It appears SL5 delivers further enhancements.
There is an interesting benchmark app here which allows you to profile relative performance of the two protocols. Though it was built for SL4, you can download, update the target framework to SL5 and see how it goes. It is a great way to make sure you've got everything setup properly.
Using NetTcpTransport should mean you can also use PerSession instancing on the server.
Related
i'm about to decide on technology choices for an agent based application used in the transportaion systems domain.
basically there will be a central system hosting the backend, and multiple agents located across town (installed on desktops) that communicate with devices/kiosks collecting data and then transmitting them back to the central server. the central server could also be hosted on the cloud.
following are important
securing the data and communications between the device and the agent
and the agent and central server.
agents should be easily installable with little or no configuration.
near 100% uptime and availability
Does WCF fit the bill here?
if so what binding types should i go for? netTCP or wsHttp with SSL/HTTPS?
WCF is definitely a fit choice for this kind of scenario. For your bindings, the actual question is what technology you are going to use. Do you want to make the agents run in a non .NET environment like Java, then you should chose for wsHttpBinding. This binding communicates through SOAP and is very interoperable.
If you chose to use .NET agents, you might as well use netTcpBinding because they use the same WCF frameworks. It also supports binary encoding. If you really need to make a choice, take a look at the MSDN Documentation.
For your agents you could use a simple console application that runs in the background as a Windows service. WIX can help you with that (install an application as windows service), but thats all I know. WIX can also help you with basic installing and configure everything for you but it has a high learning curve so you might need to invest time in it.
I have previously built WPF apps that host their own WCF service running on a custom port. Which is a great simple way for other apps to send messages between each other.
I have recently inherited a Silverlight 4 app from a client and they would like a way to send messages to it. I figured that WCF would be a simple way, but it is not possible to host a service in Silverlight.
What is a good, simple, way to send messages/communicate with a Silvelight app?
I have seen a little about the LocalMessageSender but I have no experience with it, can a WPF app, running on a different machine send a message to a Silverlight application using the LocalMessageSender class?
(Polling from the Silverlight app is not a prefered option)
I dont mind having to run the app in out of browser mode to get around some issues if need be.
EDIT Updated question
You can add Silverlight enabled WCF services and communicate with them like you did in the WPF app.
just so you know, SL only supports basicHttpBinding and (new in SL4) netTcpBinding. The later is intended for Intranet scenarios. As tchrikch said, you should be able to reference your service just by adding a simple reference in Visual Studio. As for the communication part, this may prove to be a little difficult. I would suggest looking at HTML5 WebSockets and see if you can push messages to the client from the server that way. I've only recently started looking at this as a solution for one of our projects but haven't had time to look any deeper.
HTH
Steve
I need a way to exchange data between a process and a windows service.
The process (Windows Form Application, Console Application, in the future also a Web Solution) needs to instruct and interact with the windows service.
I want to know which way is the best to accompplish this.
I'll write the solution in C#, .NET Framework version does not matter.
In the past I've used Remoting (Activator), WCF Interface with Contracts, Inter Process Exchange IPC and some named pipe implementation. What is your experience? Other ways?
I would choose WCF. It is most modern and probably best supported approach at the moment. It "replaced" older technologies in most scenarios. Nice feature of the WCF is that if you need to move your service to other protocol you can do that simply in configuration.
If you expect that windows service will always run on the same machine as other application you can use WCF with netNamedBinding. If you decide to move your service to other machine you will have to change configuration (probably to netTcpBinding) because Named pipes in WCF are limited only to IPC.
My previous experiences have always been over an IPCChannel, mainly because the only code I've had to be involved in that does any form of inter-process communication. It's never caused me any problems and the code is working away quite merrily as I type.
The only real answer to this question is, whichever you're most comfortable with.
I'm just starting with distributed application development. I need to create (all by myself) an enterprise application for document management. That application will run on an intranet (within the firewall, no internet access is required now, BUT is probably that will be later).
The application needs to manage images that will be stored within MySQL Server (as blobs) and those images will be then recovered by the app and eventually one or more of them will be converted to PDF.
Performance is the most important non-functional requirement.
I have a couple of doubts.
What do you suggest to use, .NET Remoting or WCF over TCP-IP (I think second one is the best for the moment I need to expose the business logic over internet, changing the protocol).
Where do you suggest to make the transformation of the images to pdf files, I'm using iText. (I have thought to have the business logic stored within the IIS and exposed via WCF, and that business logic to be responsible of getting the images and transforming them to PDF, that because the IIS and the MySQL Server are the same physical machine). I ask about where to do the transformation because the app must be accessible from multiple devices, and for example, for mobile devices, the pdf maybe is not necessary.
Thank you very much in advance.
WCF, only consider remoting if WCF presents some issue such as performance in your use case. You have many many more scaling and customisation options available under WCF.
Depends. If sending the images over the net presents an issue then it may have to be done locally. However as in (1) your existing suggestion seems ok.
See .Net Remoting vs. WCF for a similar question.
Definitely remoting if this is an option
Transformation - same box that the service is; since the service is going to funnel the images anyway - this is the best place. I would not put it on DB server, to better distribute the load and to separate non-db load from db specific load.
In addition, look into .Net 4.0 RIA services. They allow you best combo of .Net Remoting and WCF
I am just curious to know the reason why it's not possible to host an ASP.Net web service other then IIS ? While in WCF it's possible to host a service in IIS, WAS or any console application.
Please clear the doubt..
ASP.NET is actually not specifically bound to IIS. The .NET Framework includes an HttpRuntime which may be used to write a custom hosting platform. You could easily write a console application, like you can for WCF, that will provide the ASP.NET runtime without IIS.
Technically speaking, you could also write an Apache module that hooked into either a separate .NET process hosting the ASP.NET HttpRuntime, or possibly hook directly into a .NET assembly. I don't know much about writing extensions to Apache, however assuming you can bridge the Apache unmanage to .NET managed gap, you would be able to host ASP.NET in Apache (which should be possible, you might need a native & managed C++ library to mediate.)
Microsoft's .NET framework is amazingly extensible. You can pretty much achieve whatever you set your mind to, if you have the will and the time (and perhaps the funds.) However, the .NET platform does encapsulate an immense amount of functionality, and it is up to Microsoft to choose how they spend their money. Naturally, they have their own business to worry about, and I would not expect them to expend tremendous amounts of money giving a leading edge to their competitors (it would be bad business, and quite a disappointing competitive practice, if you ask me.)