"Re-announcing" service periodically when using WCF ServiceDiscoveryBehavior announcement endpoint? - wcf

I have a Managed Discovery Service hosted with a known URI. I have a discoverable service that when it starts, it announces itself using an AnnouncementEndpoint added to the ServiceDiscoveryBehavior of the service.
The specific use case I would like to solve is the following:
Managed Discovery service starts.
A discoverable service starts and announces itself to the Managed Discovery service.
The Managed Discovery service is restarted (for any various possible reasons).
How then does the discoverable service refresh itself (re-announce) to the Managed Discovery service?
I know the Managed Discovery service can persist endpoints and restore them upon start but I want everything to be dynamic and self repairing so that there's no chance of stale endpoint information.
An alternative use case would be:
An existing discoverable service is running.
A new Managed Discovery service is brought online.
How do we force or invoke the same Announcement service contract call to the new Managed Discovery service?
I hope this is enough information about what I want to accomplish.

I found the answer myself. In the scenario where you need to control announcements outside of the ServiceDiscoveryBehavior , you would use the AnnouncementClient class.
AnnouncementClient client = new AnnouncementClient(announcementEndpoint);
var endpointDiscoveryMetadata = EndpointDiscoveryMetadata.FromServiceEndpoint(netTcpEndpoint);
client.AnnounceOnline(endpointDiscoveryMetadata);

Related

Nothing happens after adding service to Wcf Test Client

I added the service to the WCF Test Client app and I get Service Added Successfully, but I don't see any of the operations available.
This WCF service is already being consumed by several javascript charts, so I should be able to see something here.
What am I doing wrong?
By default, WCFTestclient doesn’t support call the Restful service by using a client proxy. WCF creates the Restful style service with WebHttpbinding. thereby the client proxy class generates nothing thought the service WSDL is available.
Besides, we are capable of making a successful call to the service by using a client proxy. please refer to the below link.
WCF: There was no endpoint listening at, that could accept the message
the above client proxy class is generated by adding service reference.
https://learn.microsoft.com/en-us/dotnet/framework/wcf/accessing-services-using-a-wcf-client
Here is a detailed exposition of WCFTestClient from Microsoft document.
https://learn.microsoft.com/en-us/dotnet/framework/wcf/wcf-test-client-wcftestclient-exe?redirectedfrom=MSDN
Feel free to let me know if there is anything I can help with.
 

WCF Service hosted in Worker Role on Windows Azure that acts like a proxy and needs to call other services hosted in other Worker Roles

as you can see, I am relatively new on SO please don't kill me after posting this question :) I will do my best to describe the dilemma I am currently in.
I am creating something like a "Guardian Service" that is hosted on Windows Azure inside a Worker Role. This service has external ports, that can be accessed via HTTPS to allow clients to call it's service methods.
The WCF service is meant to call other services hosted in other Worker Roles that have only internal ports open, and which can be accessed only through the use of the Guardian Service. That's the main idea. Similar to a proxy or something.
I read already an excellent article from Jim O'Neil, what the caveats are when you try to access internal service points from within other WCF Services hosted in worker Roles:
His blog Troubleshooting Endpoints on a WCF Web Role
This is not the point for this question, and totally clear to me how to do that.
I have no idea at the moment, how I could do this, without implementing every contract from every single service I want to make accessible from within the Guardian Service to the outside world.
There must be a better way to decouple those things.
Any tips are appreciated.
Thank you.
I do not know the exact requirements for your project but I would say that what you are looking for is WCF Routing. I've used it in the past to redirect requests for different versions of Workflow instances.
The way it works is completely transparent to the client connecting to its endpoint. The router implementation must decide where to send the requests to, based on the request data (message headers and body).
In your case, if you are using SOAP and namespaces correctly, you might be able to base your decision on the message soap address and then send the request to the correct endpoint. You could also look at the Action property of the message.
Some links that might be useful:
http://msdn.microsoft.com/en-us/library/ee517423.aspx
http://www.codeproject.com/Articles/227699/RoutingService-on-Azure

WCF, FileSystemWatcher and Architecture

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'.

Identity of thread in self hosted WCF service when called from Web Application

I have a Windows Service that is self hosting a Wcf service, this Wcf service has a tcpBinding with default settings. The Windows service is running as LocalSystem.
The Wcf Service is referenced (default settings) by a Web application that is running in IIS 7.5 integrated pipeline within it's own application pool with its own identity.
Both are running on the same machine.
All is working fine, except that when in the Wcf Service when I check the identity of the current thread with:
Thread.CurrentPrincipal.Identity.Name
It returns the user of the Application Pool of the Web Application.. this is not what I expect. It looks like some sort of impersonation is going on in the Wcf service.
Is this standard behavior? I can't find any documentation on this.
And does it mean that when I try to access a database in the Wcf service i'm introducing a identity hop?
Edit, the config on service side:
Type serviceType = typeof(WcfService);
host = new ServiceHost(serviceType);
Binding tcpBinding = new NetTcpBinding( );
Uri tcpBaseAddress = new Uri("net.tcp://localhost:8001/Test");
host.AddServiceEndpoint(typeof (WcfService), tcpBinding, tcpBaseAddress);
host.Open();
On the client side:
NetTcpBinding tcpBinding = new NetTcpBinding(SecurityMode.Transport);
windowsService = new WindowsService.WcfServiceClient(tcpBinding, new EndpointAddress("net.tcp://localhost:8001/Test"));
I'm reading from Learning WCF by Michele Bustamante. I have used WCF for an application that I've refactored and we're interested in using WCF in new applications for the flexibility it offers. One of the downsides of WCF is that it can be tricky to use the .net attributes or .config files to get the settings just right. I have spent days tracking down issues with the WCF settings. I've even created automated tests that will check that my service runs the way it's supposed to.
In response to your question, Michele says very specifically in Chapter Seven that NetTcpBinding is secure by default, meaning that callers must provide Windows credentials for authentication. I believe that would explain why the thread appears to be running as the identity of the web service. This is to protect your service from being called by an unauthorized user.
I believe that the following quotation from pp. 419-420 will answer your question concisely. "If you are familiar with traditional .NET role-based security, you know that there is a security principal attached to each executing thread. That security principal holds the caller's identity, which may be tied to a Windows account or a custom database credential, and its roles."
That seems to state plainly that yes, this is standard behavior.
I believe that you can change the behavior through attributes and .config files. I recommend you get a good book on the subject. I spun my wheels in the sand a long time trying to get bits and pieces of information about WCF from the web.
To clearify:
I was checking the wrong property here. Because code would be executed under the WindowsIdentity.GetCurrent() identity.
By default this is NOT the same as the caller (which is in Thread.CurrentPrincipal.Identity). If you want this behaviour you can control this with:
host.Authorization.ImpersonateCallerForAllOperations = true;
and
[OperationBehavior(Impersonation = ImpersonationOption.Required)]
We actually have integrated security set at the website, and then any calls from the website to the WCF service we wrap in:
using (((WindowsIdentity)HttpContext.Current.User.Identity).Impersonate())
{
That makes sure the credentials of the logged in user are passed through, rather than the IIS app pool credentials.
Works like magic!
More information is needed, but I'm guessing that it's somewhere in the configuration for the binding on either the server side or the client side that impersonation is enabled. When adding service references, svcutil.exe is VERY aggressive in setting EVERY possible binding property in configuration.
If you could provide more information for the configuration on the server and client side, it would be appreciated.

What are my binding options for a self hosted cross domain WCF service with remote thick clients?

I'm trying to build a WCF self hosted service (eventually in a windows service) that will receive binary and text base messages from remote thick clients that have no accounts on my hosted machine. I'm trying to figure out both my binding options and security options, and in reading the patterns and practices guides, my head has completely spun around at least once.
The clients would be authenticated against a custom SQL based method, so I'd like to be able to pass that info in the initial login request and then set an authorization token of some kind. (This part of the problem is probably outside the scope of the question, but I included it in case it might make a difference.)
Any thoughts at all would be very helpfull.
Ryan
The choice of binding and security option depends on the usage of your WCF service. Is it just for your rich client or are you planning to expose it to the world as API? If it's just for your rich app, does it run on LAN or over untrusted, unreliable Internet?
With WCF you can configure the service to expose multiple endpoints with different bindings, for example both SOAP and REST. In general, I'd start with something stateless and lightweight like basicHttpBinding and webHttpBinding, passing user and password on every request. Once you have that up and running you can optimize cache authentication, provide binary endpoint etc.. only if it actually helps.
There's no need to have just one binding. Having said that if it's self hosted you're "on your own" here. I've never looked at what's involved.