We have a client server application.
My application need to be changed to work via WCF service in order to receive/send data to the database (security demands).
I also need another service which be hosted at the client side and will connect the client to the WCF service on the server side connect with Https.
The WCF service on the server is in PerSession mode.
Most of my work with the server is insert / select queries.
So my design is:
Client ->windows service ->WCF server service(iis7) ->database.
This windows service act as client and as server at the same time.
Act as server: for the Client application.
Act as client for the WCF service which located at the server.
The application needs to support XP and forward operating systems with .net 4.
The windows service will need to connect the WCF service on demand only (when the client application is launched).
I need to decide in which way to implement the client windows service.
I prefer to implement it with WCF hosted service with TCP/IP, but it feels like over kill to do so.
Should I use other IPC implementations? And if so which one?
So, what is the best way to implement this Windows service?
Thanks
I do not fully understand the point why a windows service should be used on the client side in order to communicate with the WCF service. But the question was not about architectural patterns...
So, for inter-process communication I would use NetNamedPipeBinding.
You can find more information on how to decide which binding to use here.
Using a WCF service for inter-process communication does not feel overkill to me at all. Actually WCF services are quite lightweight except the host initialization process, which should not happen frequently in case of a windows service I guess. WCF provides reliability and extensibility in exchange for this tiny inconvenience.
[EDITED]
I just reread you post, and I would like to clarify some details about the hosting. You can host a WCF service in a Windows Service, which is explained here, but not the other way around. Sorry, if I misunderstood your question. And yes, TCP/IP for inter-process communication is definitely an overkill, but NetNamedPipeBinding uses shared memory according to this article, so it should be the fastest way.
Related
One of our teams here has just completed a project using both WCF and
NServiceBus. When I reviewed the project I found that they had chosen to host
the WCF services and NServiceBus in IIS instead of NServiceBus host.
When I queried as to why this was I was told that when they hosted WCF services
(on TCP binding) in the NServiceBus Host that the WCF would regularly 'get
stuck'. What this meant in practice that usually around once a day the WCF
service would start actively refusing connections.
It is my understanding that IIS has custom code inside it to monitor the health
of the WCF endpoints and restart them when they 'get stuck'. I would like to
avoid hosting in IIS though as you don't get all the convention based goodness
of using NServiceBus host.
Can anyone shed any more light on this issue or suggest ways we might be able to
avoid the issue while using the NServicebusHost?
PS I Realise the description of the problem is a little vague I'm also hoping someone might be able to help me improve the question.
I can't understand the need to host everything in one container. Can't you host your WCF endpoints in IIS and your NSB endpoints via the generic host in a windows service. Then they can be managed as separate concerns.
Is it possible to host WCF Services with Appfabric Service Bus endpoints in IIS6 on Windows Server 2003 64 bit?
If not, are there any alternatives apart from upgrading the OS or using a Windows Service?
Any help would be great
Steve
I am unaware of any way to accomplish this with "pure" IIS6 as it lacks WAS and the auto-start feature that is needed to hook the IIS application up to the ServiceBus address before that application has actually been "spun up" by some outside client.
That said if you had some kind of start-up task on the server that would make a request to the application so that it could register with the Service Bus inside of the traditional Application OnStart lifecycle event, that could be a possible solution.
This is more of an architectural and security question than anything else. I'm trying to determine if a suggested architecture is necessary. Let me explain my configuration.
We have a standard DMZ established that essentially has two firewalls. One that's external facing and the other that connects to the internal LAN. The following describes where each application tier is currently running.
Outside the firewall:
Silverlight Application
In the DMZ:
WCF Service (Business Logic & Data Access Layer)
Inside the LAN:
Database
I'm receiving input that the architecture is not correct. Specifically, it has been suggested that because "a web server is easily hacked" that we should place a relay server inside the DMZ that communicates with another WCF service inside the LAN which will then communicate with the database. The external firewall is currently configured to only allow port 443 (https) to the WCF service. The internal firewall is configured to allow SQL connections from the WCF service in the DMZ.
Ignoring the obvious performance implications, I don't see the security benefit either. I'm going to reserve my judgement of this suggestion to avoid polluting the answers with my bias. Any input is appreciated.
Thanks,
Matt
I do think the remarks made are valid, and in such a case I would probably also try and use as many "defense-in-depth" layers I could possibly come up with.
Plus, the amount of work to achieve this might be less than you're afraid of - if you're on .NET 4 (or can move to it).
You could use the new .NET 4 / WCF 4 routing service to do this quite easily. As an added benefit: you could expose a HTTPS endpoint to the outside world, but on the inside, you could use netTcpBinding (which is a lot faster) to handle internal communications.
Check out how easy it is to set up a .NET 4 routing service:
What's new in WCF4 Routing Service - or: "Look ma: Just one service to talk to!"
Creating Routing Service using WCF 4.0, .NET Framework 4.0 and Visual Studio 2010 RC
I need to remotely spawn WCF services on a remote machine from a client. I cannot use IIS (no HTTP) or WAS (no Windows Server 2008).
Was wondering if there's a way to do it apart from these hosting environments without having to create a service on the remote machine responsible for the spawning of other WCF services.
If a Windows Service host is the only way, can someone point me to a good article or book for an efficient architecture for doing this (including lifecycle management of spawned WCF services).
Thanks
Riko
If you cannot use IIS/WAS, then you're only option left is self-hosting.
You can host your WCF service in either a Windows (NT) Service, or a console app, or any other app you like to have.
The point though is: other than IIS/WAS which will load your service class as needed, when a request comes in and needs to be processed, in a self-hosting environment, you have to have your host app up and running - that's why a NT Service seems like the best choice at least for production environments, a service that can be run even if no one is logged on to the machine. Console or other apps require a user being logged on, and the app must be running.
Hope this helps a bit.
Marc
There is one additional option you can use on Server 2003 - hosting WCF services in COM+:
http://msdn.microsoft.com/en-us/library/bb735856.aspx
This is not as easy as hosting non-HTTP services in WAS on Server 2008, but provides a better supported monitoring and deployment model than hosting as an NT Service. Generally in my experience, though, most people I know have used NT services since is fairly straightforward to generate one in .NET, and then they perf counters or something similar to monitor them in production.
I've got a WCF service on a server on one side of a firewall. I need to access the service from many workstations on the other side of the firewall. The network guys insist that all holes through the firewall are one-to-one so at the mo, I'll have to set up every workstation one by one. There could be loads and it'll get tedious and be prone to errors.
Is it possible to set up a WCF server on this side of the firewall that can in some clever way just act as a proxy to the 'real' WCF service on the other side of the firewall? If so, could you point me to some reference material?
There is a new concept of a WCF Relay service being developed for the Windows Azure "cloud" computing space. That would allow you to create your scenario fairly easily - just host some bits of your service out in the cloud.
See these links for more information:
WCF services hosted on Windows Azure
Software in the cloud: the Relay service
.NET ServiceBus: Hands-On with Relays
or search Google for "WCF Relay Service". There are also a number of new bindings specifically for these WCF scenarios.
Hope this helps.
Marc
UPDATE:
WCF v4 - to be released with .NET 4.0 later this year (2009) will include a RoutingService class which can be used in scenarios like this.
See more info about the WCF4 routing service here:
Content based routing in WCF 4
Routing messages in WCF 4.0
A developer's introduction to WCF .NET 4 Beta 1
I have a few suggestions, maybe one would work in your case:
Place the WCF service outside the firewall. If the WCF service needs to talk to the database, open the database port for the IP address of the machine running the WCF service.
Program or use code generation to create a WCF service that is simply a pass through layer
There may be some functionality in your firewall that allows you to publish an end point