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.
Related
I really dont know what is this mean if we control both server and client then we can using Channel Factory !
For implementing a wcf service we should do 3 step:
1. implement our service
2. implement WCF host
3. implement WCF WCF client
when we create a WCF client then we can control it, it is not true?
If you control server and client you can use Channel Factory. On client side you need an assembly of the service interface. Therefore you "need to control both sides". Theoretically it's sufficient if you just control the client side but have access to the shared assembly with the service interface.
On client side you then can create a channel:
var channelFactory = new ChannelFactory<ISomeService>("someEndpoint");
This approach might save time, but keep in mind, that it couples your client quite close to the service! Depending in your requirements it could be better to use a service proxy instead.
Take a look at this article: http://www.codeproject.com/Tips/558163/Difference-between-Proxy-and-Channel-Factory-in-WC
Edit:
So your real question is: "What is meant by the term 'controlling client and server'?"
This simply means that you or your organization has the ability to change the client software and the server software. So if you develop the client software and the server software you "control client and server".
Imagine you're developing a weather service with a public API. In that case you don't have control over the client(s), because anyone could develop a client that communicates with your service.
I'm a WCF newbie, and I need some help to begin with a project:
I will have a managed application (server) that needs to communicate (messaging system) with several clients over the internet and vice versa.
What is the best approach to achieve this?
using wsDualBinding?
UPDATE
I decided to use the NetTcpBinding mode instead.
It depends on what capabilities your service needs to expose, and what type of clients you need to support. Any of the HTTP-based bindings will work over the internet, its simply a question of the way the data is encoded.
A summary of the built-in bindings and what they support can be found here: http://msdn.microsoft.com/en-us/library/ms731092.aspx
But the most common are:
BasicHttpBinding - This is a basic web service-style binding, usable by any SOAP client.
WebHttpBinding - This allows your service to be used by non-SOAP HTTP clients
WsHttpBinding - This allows your service to use extended service features like transactions and sessions.
WsDualHttpBinding - This is required if your service needs a duplex channel, meaning your service needs to make callbacks up to the client.
Since you specifically asked about the dual binding:
If you are writing an application that needs to be able to make a callback from server into the client, then a dual binding is really your only option. Since you specifically mentioned chat, however, I don't think a dual-channel service is going to work very well.
The way the callbacks work in WCF is that your client makes a call to the service, using a dual channel, and must provide an implementation of the callback interface. The server can use this to make calls to the client for the duration of the service method call; the callback context is per-service-call, so once that call returns, it is no longer valid. In other words, your server cannot just asynchronously "call into" your client, it has to wait for the client to "poll" the server. And if you're going to do that, you don't really need the callback anymore.
Honestly, I don't think I would use WCF for an interactive bi-directional chat application, but I can think of two possible options to do so:
Do the polling client option, using a simple BasicHttpBinding on the server and continuously ask for new messages.
Set your client applications up to self-host a local WCF service, and provide the endpoint information to the server when you log in. This requires your clients to accept incoming connections, which gets messy (but if you can pull it off, I'd go for a NetTcpBinding here.)
WSDualHttpBinding is not a good choice for internet. Callback works great only in local network (intranet) that has no Firewall and NAS restrictions.
See this post for more details:
Connecting over internet to WCF service using wsDualHttpBinding times out
Use WsHttpBinding if you want to set up server to server communications (that should work for WPF).
Use WebHttpBinding if you are planning to use data from Javascript.
I am designing a WCF service that will serve clients that request things like 'GetProduct' and 'UpdateProduct'. In addition, there will be another service that the clients will subscribe to that will send them PUSH notifications.
The 'PULL' and 'PUSH' WCF services will run under a Windows service.
I would like to encapsulate some sort of monitoring solution that allows me to open a WPF application that will connect to the services and show me how many clients are connected right now to both services (supposed to be identical) and will allow me to disconnect clients from the service and maybe view logs that the service has logged.
How do I design this on the services side ?
Do I need to create a 3rd service for the 'monitoring' app that when requested - will check how many clients are connected to the 'PULL' and 'PUSH' services ?
Or do I just add a function 'GetNumOfClients' and 'DisconnectClient' to the 'PUSH' and 'PULL' services ? this seems wrong, because it introduces logic to these services that does not belong there, and also allows clients to disconnect each other...
For logging use log4net or health monitoring. Log4net is versatile and configurable. You can turn on WCF diagnostics logging which has extensive information about what is going on with your service on You can read here how to turn on and use WMI providers to instrument your service and what performance counters are available.
Why is there a requirement for disconnecting a client? You can "disconnect" the client when you throw an exception in your method which fault's the client channel but beyond that you should not be concerned with managing service connections.
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'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.