Is there any third party tools available to Monitoring WCF Service?
I have created WCF Service with 5 Methods (OperationContracts) and Hosted in IIS.
Does there any tool available to specify how many times each method was called and what is Request and Response of the each call ? (Similar to SQL server profiler).
Use standart tracing and diagnostic tool for WCF, and work with .svclogs using SvcTraceViewer.exe application.
If you host under IIS, use AppFabric. It a great tool, when you can easily manage the settings of your services, including tracing and diagnostic. There is a nice article about using it http://www.dotnetcurry.com/ShowArticle.aspx?ID=771
The AppFabric Dashboard provides a centralized gateway to view and manage the health of WF and WCF services deployed locally or to a server farm. It exposes real-time data from the Persistence database and historic data from the Monitoring database, and it allows you to “drill down” to examine instance and WCF Call metrics in greater detail.
http://msdn.microsoft.com/en-us/library/ee677236(v=azure.10).aspx
AppFabric helps to monitor WCF service like How many time the operation is invoked, Errors/ Faults and also supports historical data.
I am working on a web application which acts like a Devicemanager. Clients can register with the devicemanager and connect to the devices that the manager provides.
I was thinking of using a duplex WCF service for the device connection/disconnection.
Is WCF the correct technology to use?
I will need the clients to be constantly registered to be able to connect/disconnect.
Duplex WCF service implements callback function in web services world.
With callback client sends request to server with some kind of reference to its own method that should be called by server when time came. This allows server to communicate with client when server think it is necessary.
You situation contains no need for callback implementation because process is always controlled by client:
Clients can register with the devicemanager
Clients can connect to the devices that the manager provides
So answer for Duplex is NO (if my understanding of your question is correct)
Should you use WCF – YES.
WCF is right technology if you want to set up communication channel between two applications and TCP/IP is too low level for your needs.
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 am looking at various options for a WCF based publish subscribe framework. Say I have one WCF web service that will be the publisher and 1000 clients registered as subscriber. For some published messages all clients will be interested but at the same time I wish the ability to notify a single client with a specific message. On receiving notification the client will call other web service methods on the web service.
Is NServiceBus suitable for this kind of scenario ?
If I use MSMQ for transport does it mean that every PC where the client is installed requires a queue to be created ?
Some of the challenges include how you want the publisher to behave when a given subscribing client is down - do you want that message to be available when the subscriber comes back up? If so, then some kind of durable messaging is needed between them - like MSMQ.
Your question about notifying a single client, is that as a result of a request sent by that client? If so, then standard NServiceBus calls in the form of Bus.Reply will do it for you. When using WCF, if the response is to be asynchronous you'll need to use callback contracts.
NServiceBus can do all the things you described, and has the ability to automatically install MSMQ and create queues so that greatly simplifies client-side deployments.
You also have the ability with NServiceBus to expose messages over WCF so you can support non-NServiceBus clients if you need to as well. It also has its own http gateway and XSD schemas which can allow clients on non-Windows platforms to interoperate even without using WCF.
Hope that answers your questions.
A service I have in WCF occasionally goes down due a problem with a COM component. While I am troubleshooting I would like to setup another host to make regular calls to this service to monitor availability.
It is slightly more complicated that a simple HTTP call though as the service is secured by SSL and WCF authentication (username / password). I'd also like to be able to parse successful calls to see if they return warning / fail states from my code.
Would you recommend any monitoring providers for this or is it beyond the simple monitoring they normally provide?
Regards
Ryan
You could enable WCF logging and auditing facilities either on the server or the client to produce a log of all traffic. Then you can analyze the results using the WCF Service Trace Viewer Tool provided in .NET Framework 3.0 and 3.5 SDK.
In your situation I would probably enable logging only at the message level. This will reduce the amount of information that ends up in the log file and will help you focus on analyzing the data that's actually being sent back and forth from the services.