I have built a Windows forms application in C# using WCF for client -> server communication. I have recently begun toying with Silverlight and built a web front end for the application which still uses the same WCF service for web client to server application. What I'd like to do is have my WCF behind a firewall on a different machine and then build an "intermediary" WCF service which would live in a DMZ between IIS hosting my Silverlight client and the WCF box.
Essentially I want to seperate the WCF service which runs my windows forms application from also acting as a webserver. Does it make sense to build this intermediary app to increase security?
Can't see how that would increase security other than forcing connections to the WCF service to go through the DMZ ... but a straight forward http proxy server would do the trick.
The intermediary becomes more useful when you have a whole bunch of services and you want to centralize things like aunthentication, message logging in a single location or if you want to do some fancy (or not so fancy) message routing such as load balancing between a few services.
Related
I have an external (public) website developed in Silverlight. The Silverlight app currently calls http based wcf services hosted in IIS.
I am now having to call a wcf service with net.tcp binding hosted in a different app server. I have the net.tcp wcf service hosted in a windows service on port range 4502-4530 and with an interface to expose clientaccesspolicy.xml file as part of the service. I am able to invoke this service from my Silverlight app in the web server. I want the SL app to make direct call to net.tcp, rather than routing the call to it from another http based service.
Question is will this work without any issues when exposed over internet.
Client browser --> IIS webserver with Silverlight website --> App Server with wcf service on net.tcp.
I am assuming in this case, from XAP SL would try to make direct call to the app server service using net.tcp ?
The communication between the web server and app server could be opened up for ports 4502-4535. But I am wondering what about the client. Does this setup require the ports to be available even in the clients machine (with browser)?
Any insight is much helpful.
Thanks.
Take a look at http://support.microsoft.com/kb/2425652; there is sample code included as well! If you setup clientaccesspolicy.xml correctly; it should work as long as clients can access your TCP server.
If your clients are behind some firewall which is blocking your server's ports; they may face connectivity issues!
I've gone through some tutorials on creating a WCF service. I'm using Visual Studio 2012. I got a very simple WCF Service Library (vb.net) and Windows Application (vb.net) communicating via WCF. That's a start.
However, my project requires I do the following:
My Windows Service - This is already an application that has it's tasks.
My Application - This is an application that is already developed as well.
I need the service to talk to the application. The service will need to send the following information to the windows application:
Status Updates
Metric Information (mostly integers for counts)
I need the application to send information to the service. It would need to send:
Reload Configuration command
Should be relatively simple, but I've never worked with WCF until today. So I have some questions...
Do I need to re-work my current windows service into a WCF Service?
Since it won't be in IIS, do I also create a WCF Service Library or do I roll this into the windows service somehow?
What is the best way to set up the different types of communication? (i.e., sending over specific metrics and reload commands)
Probably the main question is what components, in addition to my current windows service and application, will I need to make this work?
I hope that was clear :( I think I'm confusing it all... but I hope not
Your Windows service can host the WCF service. Similarly, if you want, your application can host a WCF service. The application could talk to the WCF service in the Windows Service, and the Windows Service's WCF could talk to the one in the application. Depending on the nature of the communication, you could also just use a callback channel to permit the Windows Service's WCF to call back to the application.
I suppose you should configure your WCF windows service to use named pipes. If your windows service is already built then the easiest way to do it would be to build another one as a WCF windows service and wrap the already existing functionality.
Hope I helped!
What are the pros and cons of hosting a WCF service in IIS versus using a Windows service?
FYI - I have googled but it's surprisingly hard to find relevant answers.
We've just implemented a big WCF service, and did it as a self-hosted windows service. The reason we did it that way was our architects wanted the extra control you get from hosting your own and taking IIS out of the equation. Basically, when you go the self-hosted route,
you process each request
you configure your own endpoints
you configure your certs
you control the exception handling
etc.
Our WCF service is industrial scale with rev proxies, load balancing and about 50 methods attached to the endpoints. And we use multiple encryption protocols depending on the types of devices connecting.
However, if I was doing a smaller WCF web service with just a single server, a single endpoint and a few method calls, I'd probably use IIS to manage the endpoint and implement the SSL letting the UI do the configuration work that would otherwise have to be done in code. It's just easier from what I've seen.
Long story short, if you host it, you control everything in code. If you're interested in a quicker delivery, I'd start with IIS.
I am currently working on a silverlight client, making use of a web server, and an application server.
Most of the users sit within our firewall, so they do not have any problems accessing the WCF service running on the application server (through a Service.svc file).
However, some users will sit outside of our firewall, and only have access to the web server, and not to the application server (Where the WCF service is).
I am hoping someone could tell me if there is a way for the client to use the WCF service on the application server, through the web server, without rewriting the WCF service on the web server, and only relaying the calls through that server.
I hope this is a clear enough description of what I need.
Thanks
Sounds like what you want is a router service. Unfortunately, there's nothing built-in into WCF to do that (at least until .NET 4.0 with its RoutingService.).
You can certainly build it yourself, either by building a specific, one-off routing service (i.e. you implement the same contract and manually forward each operation to the service inside the firewall), or by building a generic, reusable routing service.
If you choose the second option, a couple of articles might help get you started.
Rather than have your Silverlight clients accessing the application server directly, route all the requests through a proxy service on the web server.
An example of this is the "Cross Domain Proxy" pattern.
Two weeks ago I needed a way to communicate a wcf service with a windows service running on the same computer. The windows service had to get data from a external source and share it with the wcf service (hosted in IIS) who had to give it when a client made a request. I chose to do that with ipc.
I done it and now the windows service is the ipc server and the wcf service is the ipc client. This goes well but I think I made a mistake doing this because to make it run right the windows service must to be executed with the ASPNET account, for this the ASPNET password account must be assigned and when I do that the IIS does not work correctly.
I am thinking on different alternatives, but in all of them the problem persists. Some ideas?
Edit:
What I needed was a system that made public, in a web service hosted in IIS, data gotten through telnet from another old system, what is a little unstable. How the response of this second system was slow I chose to put a process (the windows service) between the web service and the old system. The windows service had to save the data collected from the old system and when the wcf service asked it give it all at once through ipc.
Why does the windows service need to run as the ASPNET user? Is that because you're using an IPC connection that requires authentication from the caller?
Another alternative (if you have control over the windows-service code) would be to make that a WCF service as well (using a ServiceHost in the windows service). The IIS service could connect to the windows service using a NetTcp or NetNamedPipe binding if you need the IPC-like performance.
Why not just create another account with the same permission set of the ASPNET user which both the WCF service and your other service run under? That way, you have control over the password.
Ideally, the windows service should run as a WCF service, that way its easy for the client to communicate with it.
The next question is weather the 'client' needs to be a WCF service. If this client needs to serve other applications then it is appropriate, otherwise it may not be nessesary. I don't know enough about your system, so its up to you to decide what's best!