I'm new to WCF and need some assistance with architecture for the following solution:
I want to create a WCF Service that hosts a FileSystemWatcher. This service must watch a series of folders on the machine and when a file is placed in a folder or is renamed I need this WCF service to 'Publish' an event.
Another WCF service must then 'Subscribe' to this event and do some processing.
The basic idea is that there is one service to monitor a predetermined set of directories, whilst an appropriate service gets notified that there are files available for processing.
So my questions are :-
1. Regarding the FileSystemWatcher WCF Service, I want to host it in AppFabric but am not sure exactly how this is going to work. I.E. When this service is deployed to the server I want the appropriate FileSystemWatcher object to be called and stay 'on' and monitor folders indefinately. Can WCF do this in this manner or is this a better candidate for a Windows Service
2. Can one WCF service publish events and another WCF service subscribe to these events and how? All WCF services hosted inside AppFabric?
WCF is a communication framework that can be used to expose or consume SOAP/REST services. A Windows Service is one way of hosting such applications. WAS/IIS and self-hosting are other methods. A Windows Service provides greater control of service startup/shutdown, which seems relevant to your scenario.Windows Server AppFabric improves some of the control over applications lifecycle hosted in WAS/IIS, but it is still a fundamentally different hosting choice to a Windows Service.
As far as I know WCF has no inbuilt event publishing capability (I assume you're referring to the publish/subscribe pattern). However, you can implement such a pattern using WCF duplex channels. There is no restriction on an application concurrently acting as 'server' and 'client'.
I have a WCF service running inside Windows Service and it is located on my local network. What I want is to be able to discover WCF from my Silverlight app on my WP7 (on the same network).
I know there a Discovery feature in WCF, however it requires to UDP, which is not supported on WP7. So are there any other ways to discover local WCF?
I also do not know prior to launching WCF the IP address of the WCF service.
The solution I came up with, is to use Sockets as on WP7 they support multicast.
So set up would like this:
Desktop service - Windows Service hosting WCF and small Socket app
which listens on specific port.
WP7 client - before connecting to WCF
a broadcast would be sent using Sockets to find out an IP address of
the machine which runs WCF, when got a response connect to WCF.
For a WCF Service to be referenced in a WP7 project the WCF Service MUST be a BasicEndpoint
You could provide a basic endpoint that exposes a kind of catalog service. It doesn't have to implement UDDI but it could be a custom protocol to suit your needs and return addresses of web services.
This way you only need to know a single address. Of course you can cache returned addresses and query the catalog service only when you are not able to connect.
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.
I'm reading into WCF and Service Bus topics, but I don't get the use of Service Bus in some topics. Check this image of the use of Service Bus:
http://ecn.channel9.msdn.com/o9/learn/Azure/Labs/IntroServiceBus/Lab.html/html/images/4a0aa8f8-f4d1-49b6-b950-cf954402c599.png
In above image Your Service is behind a firewall, and then you apparently need a Service Bus. But if you want to expose Your Service, isn't the solution to simply remove the firewall? And then every client can connect to Your Service.
I understand that you don't want to remove the firewall for your total network, but you can create a publicly visible webserver with IIS and run Your Service on that. Or am I missing something?
A service Bus helps you enhance your services architecture.
Many organizations have what is refereed to as point to point or spaghetti integration.
This is not good.
A service bus would help you have a single point of integration. e.g. in the image you linked (The Azure Service BUS architecture), by adding the service to the ESB you can unify service authentication using Access Control even if they sit behind a firewall instead of each service being responsible for authenticating itself. Further , even if the address of the service changed you would only have to change it in one place (the ESB) instead of all the applications that reference it.
A service bus can do many other things including validating services messages, enhancing them in case they don't meet your requirements, transforming them e.g from plain old XML to SOAP , routing messages, enhancing messages etc.
WCF is a way of setting up and managing communication interfaces. It cares not for the content of your messages.
A service bus, however, is different in that it's responsible for message routing.
You can build a service bus using WCF and other bits, but WCF in and of itself isn't a service bus.
Service Bus is a relay service so all clients will point in the cloud. Hackers will attack relay service in the cloud rather than your WCF service. All security aspects taken care by relay service.
To precisely answer your question, not all WCF services are hosted on service bus and your solution may be just sufficient. It depends on your need and existing infrastructure.
I highly recommend Juval Lowy's this article.
Excerpt from the article:
The relay service is a service residing in the cloud, whose job is to assist in the connectivity, relaying the client calls to the service. Such a relay solution does require both the client and the service intranets to allow connections to the cloud, but since the cloud constitutes neutral territory for both the client and the service, most environments allow calls out to the Internet. First, both the service and the client must establish connections and authenticate against the relay service. At this point, the relay also records where the service is and how to best call back to it. When the client calls the relay service, the relay service forwards the call (the client message) to the service. While the sequence seems straightforward, in practice it involves a considerable amount of intricate network programming, messaging and standards know-how, security expertise, and more. Such a solution is simply out of reach for the vast majority of applications. This is exactly the gap the Microsoft .NET Service Bus is designed to fill. It is a ready-made relay service, hosted and managed at a Microsoft data center. The .NET Service Bus acts as a perimeter network in the cloud, providing a single place to manage credentials of the client and services. The .NET Service Bus is the front end of the service; it encapsulates and isolates the service from malicious callers lurking on the Internet and is responsible for repelling various attacks from denial-of-service to replay attacks, while obscuring the identity and true location of the actual service.
The main difference between connecting to a regular Windows Communication Foundation (WCF) service and using the relay service revolves around hosting. In the relayed case, the service must connect to the .NET Service Bus, authenticate itself, and listen to calls from the relay service before the client sends its requests. This means that you either must launch the host explicitly or use an NT Service as a host, and that you cannot benefit from hosting in Windows Activation Service (WAS) (or IIS) since WAS will launch the host only after the first request comes in, and that will never happen because the host has not connected to the .NET Service Bus in the first place.
The .NET Service Bus supports a WCF-friendly programming model by offering a set of dedicated bindings and behaviors. By and large, except for a few slight twists to the programming model, working with the relay service is no different than working with any other WCF service. The .NET Service Bus supports the core WCF features of reliable messaging, message security, and transport security.
I have a callback service that is hosted over wsDualHttpBinding. I'm looking to add a client that will poll for the data rather than receive the callback (will be a mobile device using wince for demo purposes). I was curious what the best way to do this is? You cannot create a client proxy using NetCFSvcUtil with a service hosted with wsDualHttpBinding (I understand that), but you cannot host a callback service over basicHttpBinding. I really need the same service hosted over both basicaHttpBinding (clients will poll for data) and wsDualHttpBinding (callback will notify clients of data). Any ideas on the best way to handle this without creating two separate services to host the same data?
What do you mean by two separate services hosting the same data? Do you expect to share same service instance to handle both wsDualHttpBinding and basicHttpBinding requests?
Your current problem is that service interface for duplex communication cannot be used for basicHttpBinding. You have to create second service contract and implement it in the same service. In that case you can expose two endpoints for the service: one duplex with WSDualHttpBinding and one with BasicHttpBinding. Endpoints must have different relative addresses. From the perspective of the client those endpoints are separate services - each of them requires separate client proxy. So unless your service is singleton you will have new service instance for each client proxy. New service instance means no data sharing.
Thera are some possibilities to modify this behavior but it means replacing Instance provider.