We are building a Silverlight-based system in the financial domain. We need to push notifications/stream data from the server to the Silverlight client. We use Silverlight 4 for the client and Windows Server 2003/IIS6 on the server side (this excludes AppFabric).
So far I haven't been able to find a Silverlight-compatible data push solution that would be secure and scalable. Out of the box sockets don't seem to support SSL and the PollingDuplexHttpBinding doesn't seem to scale for the web farm implementations/failover. It also looks like that IIS is not the best platform for long polling applications.
Has anybody successfully implemented an enterprise-grade notification push solution for Silverlight and what technologies/products have you used?
Comet servers are pretty scaleable a lot of financial systems use them.
An example of this marketsplus.com.au/evolve who use a Comet server to pump price info up to their Silverlight client.
Some Comet implementations are meteorserver.org, pokein.com or frozenmountain.com/websync.
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’m developing a .NET/C# application software for an instrument which has a built-in PC (Core 2 CPU/2.66GZ/4GB RAM) and will have access to the Internet from behind the facility IT firewall. The software is made up of two parts: a rich client desktop app for UI and device control and a web app (silverlight) for providing remote maintenance such as device configuration and calibration via internet using browser. This device web site will be hosted using IIS locally on the instrument. My questions are:
What is the risk of running an IIS hosted web site on a device?
What does it take to make it secure so that data and operation of the instrument is immune to potential hackers.
Is it a better design to provide web services (or WCF services) as the interface for remote maintenance? In this case, I’ll create a rich client service utility program that can consume the web services over Internet for remote maintenance purpose.
Wow, thats an interesting project!
Personally I would take a different approach and have the device/instrument pull the maintenance info from a centralized server instead of hosting the service that performs it.
Do you really want to worry about the maintenance of updates & patches on that device.
but Ill try to answer like you didn't have any choice.
1) the risks are the same as any website. you have to deal with authentication, in your case I would have allowed IP ranges.. etc.
2) Nothing is immune. But just google WCF security for a start.
3) Yes that is a better approach if the services are hosted outside the "instrument"
good luck, sounds like a fun one.
See the WCF Developer Center for much information on WCF.
One feature of WCF is that it's possible to host a WCF service in almost any kind of program. In particular, you could host a secure WCF service on your device - without needing to run IIS or any other web server at all.
I am in the process of integrating our custom web app with QuickBooks Enterprise 9. My thought is that I could use QuickBooks as my "database" of sorts. When a person creates an invoice, the invoice is actually stored only in QuickBooks. When a person views a list of invoices, they are actually viewing a list of QuickBooks invoices. I want to make sure the data is stored in only one location.
I realize that I could use the QB Web Connector, but the problem with that is I wouldn't have control over when the requests to QB actually get processed (That job is up to the Web Connector).
So I have my web UI to act as the QuickBooks "face," but I don't have any good way to get to and from the QuickBooks file located on an internal server. What I was thinking was that I could create a WCF web service and install it on the QuickBooks server. The web service could then be my integration point. My custom web app could then consume the web service and, viola, I have access to my QuickBooks files.
My question is this: Can a WCF app connect and run QuickBooks? If not, could i create a Windows service to act as my point of integration? If so, can my custom web app "consume" a windows service?
I'll start by warning you that QuickBooks probably isn't your best choice for a reliable back-end database accessible from a remote website. In fact... it's probably a really, really bad choice.
You should have your own application database, and then if you need to also exchange data with QuickBooks, do that outside of the normal lifecycle of your app, as a separate sync process.
QuickBooks generally isn't reliable enough for always-online type of applications due to a number of reasons:
Flaky SDK connections
Updates and single-user mode will
lock you out of accessing QuickBooks
Difficulty in establishing SDK connections from non-GUI processes (Windows Services and IIS processes)
With that said...
Yes, you could create a WCF web service, host it on the QuickBooks machine, and make your WCF web service relay messages to/from QuickBooks.
Yes, you could also create a Windows Service that does the same sort of thing.
Do NOT implement it as a Windows service, and do NOT implement it within IIS - instead implement it as a GUI app that runs alongside QuickBooks.
If you try to implement things as a Windows service or within IIS, the QuickBooks SDK requires you have a GUI available (it users a GUI COM message pump for events dispatching or something like that...) to process requests, so you'll probably need to use something like QBXMLRP2e.exe to straddle the process boundary between QuickBooks and your non-GUI Windows service/IIS. My experience has been that it's a gigantic pain in the butt, and requires mucking with DCOM permissions as well.
I have an example and some documentation on my QuickBooks integration wiki.
The IDN Forums are a good place to ask questions.
My recommendation to you would be to either:
Use the Web Connector and QuickBooks
and give up hope of keeping all of your data in one place. Cache the data in a real database, and update it by querying QuickBooks periodically. I'm almost done building a solution to do exactly this right now, and it works fantastic.
OR
Use a different account system. NetSuite is pretty nice. I'm not sure what else is out there, but if I were you I'd look for something SQL-based or with a strong SOAP/REST API.
I am working on a project that involves an embedded system which runs a non-microsoft OS with a C program for the application and am developing .NET software for its end user applications. For remote configuring with the .NET software (which can go across firewalls), I am considering using WCF. I know only a little about WCF so far but I've read that it is supposed to be interoperable with environments other than .NET. The embedded environment has an HTTP stack but no built in support for web services. Does anyone have any experience with this kind of thing or know if it would be appropriate at all? If so please provide some advice or point me in the right direction.
Thanks!
WCF is interoperable because it's accessed over HTTP. Visual Studio can help you build client libraries very quickly for WCF, but client access to WCF doesn't require anything other than HTTP calls with the proper payload. If you're looking at a remote server call and your built-in support in your embedded environment is basic HTTP, look at building your server-side as REST-formatted methods. Your debugger will thank you.
What kinds of data are you planning on transferring back and forth? For something this low level and proprietary I would recommend sticking with good old fashioned Sockets.
I will be passing configuration data back and forth...basically to enable technical support staff to remotely program the device. If I were using sockets this could be binary data, but there is a requirement that customers with firewalls shouldn't need to open any ports. Because of this I was thinking of sending XML over HTTP. So, is it better to use WCF or REST on the server side? Or WCF with REST?
I'm curious about your "customers with firewalls" requirement. Sockets with binary data or XML over HTTP can use any port (not just port 80), and I'm curious if your device will be "listening" on the network, or just making an outbound connection. If your device is listening, you will need to open a port on the firewall. Making an outbound connection ("phoning home") is much easier on the firewall.
So I think you could use sockets and binary data. However, I have faced similar issues on the last two projects, and I really wanted to implement WCF using REST on the embedded device, but no one else wanted to do it - I'm hoping someone else will be first, and publish some results!
Good Luck! (and post your results!)