I understand that in order to setup Service Bus we need to
Create Service Bus Namespace
Create on premise WCF and point to above Service Bus End Point through Binding.
WCF knows about Service Bus End Point, but how does Service Bus Relay know where to relay the message to specific WCF endpoint in the whole world?
Thanks.
Service Bus doesn't know where the endpoint is. The endpoint makes a connection to Service Bus and then Service bus uses that connection to send requests (relayed from the requesting WCF client) to the WCF endpoint.
The whole point of service bus relay is that there are no connections going from Azure into on premises machines because of the networking/NAT/firewall issues. There is only a connection from the on premises machine to Azure.
The Service Bus WCF Service Relay bindings implement the same behaviors as the corresponding regular WCF Service bindings with one major difference.
Generally, a WCF Service binding is setup to receive incoming connections from clients. The Relay Service bindings, however, are designed to establish an outgoing connection to the Relay service on Azure. The binding is designed to keep a control channel for this connection always alive. The message from the client arrives at the Relay endpoint for the WCF service on Azure, and is forwarded to WCF service through a variety of mechanisms depending on the binding type. The Relay Service bindings thus make it appear that a WCF service is receiving an incoming connection from the client, even though the initial connection was established as an outbound connection.
Related
Can we have a HTTP protocol binding using WCF to receive a message from windows server service bus on topic/subscription ?
The only wcf Binding you can use is netmessagingbinding which runs over tcp not http. If you want to consume messages via http you will need to use the windows service bus rest api
All ,
I have a doubt on the Request response pattern... Assume the following is my scenario
1.I have a service running on Windows Azure. This service can be called by users to execute a command.
2.I have a client applications that is running on my intranet. This client application will execute the command . The computer in which the client application is running is connected to internet , but does not have a static IP i.e machine cannot be accessed directly via the internet
3.I am planning to use Azure Service Bus through which my service on Windows Azure can communicate with the client application to execute....
In this scenario, can i use Request/response messaging i.e can the service post a message and expect a response from the client
OR
Should i use command queue for each client , the Service will push the command to be executed on a queue , the client will poll the queue and execute a command
Any help is appreciated
Since you are using WCF (based on the tag), you should consider using Service Bus Relay calling the WCF service asynchronously.
I assume you want to use Relaybinding here, using WCF.
Your web service (which is behind NAT, firewall devices, etc) is only opening outbound connections in that case. The service is listening on a registered endpoint in the cloud (that is accessible for him, because of credentials and protocol). All incoming service calls are sent over that port/socket. The response will then be sent back over the outgoing port again.
If the IP Address of your service changes, it wil register itself again (by listening on the same registered endpoint) and you can reach that service transparantly.
Another way you can achieve request/response in an asynchronous fashion, is through queues. This does not require any open connection between your client and your service and can happen fully asynchronous. This can be achieved by sending a message to the request queue for your specific service (with a Correlation Id). And when that service has processed that message, it can send the response to the response queue of your application, using sessions. A good example of this pattern can be found on Alan Smith's blog: http://www.cloudcasts.net/devguide/Default.aspx?id=13051
I’m new to WCF and are having problems by finding the solution to my problem.
I have WCF set up that handles some logic (simple database handling).
I then have a web page (ASP.NET) that gets it data from WCF (and also sends it data to WCF).
Now I’m trying to use an Azure Service Bus to send data to WCF. It works fine when I go through the ASP.NET website. It works like this:
1, Client application sends data to Service Bus.
2, ASP.NET Webpage reads data from Service Bus.
3, ASP.NET Sends data to WCF.
4, WCF updates the database.
Everything works fine.
But, I would like the WCF to constantly listen to the Service Bus.
How do I do that?
In this scenario you have 2 options:
Use the WCF endpoint of the Service Bus Queues: http://blogs.msdn.com/b/tomholl/archive/2011/10/07/using-service-bus-queues-with-wcf.aspx
Use the service bus relay: https://www.windowsazure.com/en-us/develop/net/how-to-guides/service-bus-relay/
Depending on your scenario you'll use one of these options. The first scenario uses queueing. If your WCF service should be unavailable for any reason your client will still keep working (messages are delivered to the queue and picked up by the WCF service whenever available).
The second scenario will create a bridge between your client and a WCF service (could be on premises, in an other data center, ...). Since it's a direct connection you can receive a response. But keep in mind, if your WCF service is offline, your client will receive an exception and you'll need to handle that.
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.