What is the diffence between appfabric service bus and WCF?
Is service bus is an alternate for wcf on azure?
Does service bus provide all the functionality as wcf?
when to use service bus and when to use wcf in azure application?
Please help me....
Thanks in advance
The service bus doesn't provide services themselves - instead if provides connectivity to services - e.g. routing, scalability, security, etc.
So you will normally write your services in WCF, and can then optionally provide connectivity to those services using the bus.
This article provides a good intro to the service bus - http://msdn.microsoft.com/en-us/magazine/dd569756.aspx
You don't need to move away from WCF. However, imagine your application, sitting in Windows Azure, trying to access a WCF service in your data center (or hosted somewhere). And imagine that the data center has a firewall that blocks incoming connections. Service bus offers a way for you to make service calls to that service endpoint. Essentially, the two sides each connect to an AppFabric Service Bus endpoint. At that point, they have a connection where WCF calls can be made.
The bindings are similar to what you use today. If you're using netTcpBinding, for instance, you'd now use netTcpRelayBinding, as the calls are relayed through the service bus.
The Windows Azure Platform Training Kit has a very good introductory lab to walk you through the basics of Service Bus.
ServiceBus is a way to communicate asynchronously. Asynchronous communication implies it is good for multi-machine programming due to fault tolerance and it does not block.
WCF is a programming stack used to interface with various mediums (ie. Pipes, TCP, HTTP, ServiceBus).
They serve orthogonal purposes. You can use WCF without ServiceBus and ServiceBus without WCF.
Related
There is very limited information on azure signalR service. I need to clarify a question so any help would be highly appreciated.
how azure signalR service actually scale out ? I mean, as far I have worked on it. it seems that you have to include a primary key of azure signalR service to your hub. you can host you hub anywhere. So how hub scales out.?
SignalR Service manages all the client connections, as well as certain state information such as group membership. Your ASP.NET Core application establishes a connection to the SignalR Service instance.
When the application wants to send a message to connected clients, it uses this connection to instruct the service to do so. The service can also invoke hub methods via this connection.
You can read more about the service protocol.
When a client initiates a connection, it calls a negotiate endpoint on your ASP.NET Core application, which redirects the client to connect to the SignalR Service instance instead.
Because the ASP.NET Core application only needs to execute hub logic and most of the heavy lifting is done by SignalR Service, your application does not typically have to scale out to handle more SignalR connections. You can scale it based on the needs of the web traffic (serving web API and MVC requests, for example), and you can scale the service based on the needs of your SignalR traffic.
This is the documentation that I found and followed to have a signalr hub that worked across multiple App Service instances but behaving as a single hub.
You need to create a "backplane" in Azure using Storage queues and topics.
Details here: https://learn.microsoft.com/en-us/aspnet/signalr/overview/performance/scaleout-with-windows-azure-service-bus
#anthonychu is this still needed / applicable??
I want to connect to On-Premises database from Azure. Basically i will be hosting my web Application on azure and will be using Database from On-Premises.
According to www.WindowsAzure.com both Azure Service Bus and Windows Azure Virtual Network are used for connecting to On-Premises database. But what is the difference between these two and which of them should be used according to different situation ?
There is a big difference between both approaches:
Service Bus is connectivity on application or messaging level. Here you will have two options:
Service Bus Relay : here you have to expose a web service (that connects to your local database) over the Relay binding. This will
make a publically reachable service in a firewall friendly way. This
is mostly a synchronous approach.
Service Bus messaging: you will have to have a local process that listens on messages / events that you put on a queue or a
topic/subscription from your application. This is mostly an
asynchronous approach.
Virtual Networking: here you can set up connectivity on network level and you would be able to connect to your database as if he is on the same network as your cloud based application. The advantage here is that your code would not have to change, compared to a standard application (except for connectivity retries)
Both approaches are totally different, but can be valid, depending on your preference of architecture. (web service oriented, network level connectivity, or asynchronous processing).
Hope this helps.
We have used an Azure Service Bus relay REST Service to expose our internal WCF webservice to external customers.
Functionally all good, but we have noticed that it's significantly slower than connecting directly to WCF end point. I would have thought that Azure Service Bus just relays the internal endpoint without introducing any performance bottleneck.
Could someone please share what are the things to consider (in terms of performance) for Azure Service Bus? Any hints on how we can optimize the performance will be great.
The Service Relay REST Service is 16seconds slower than connecting directly to WCF Service. I noticed the main bottle neck is between Service Bus and Internal WCF call.
1) If your clients are using ChannelFactory, then cache the channels.
2) Is your endpoint on a data center near you and your customers? If not, I would highly suggest you change that.
3) According to the docs, if you are using NetTcpRelayBinding you can also set the TcpConnectionMode to Hybrid, which will establish "direct connections between two parties that sit behind opposing Firewalls and NAT devices"
I currently designing a solution for communication between a Charge Point for Electrical Vehicles and the backoffice. the ChargePoint are connected to the Network of the Telephone company and the backoffice is hosted on Azure. The Chargepoint don't have a public IP-address. In order to send messagese from the backoffice to the ChargePoint we want to implement Azure Service Bus (ASB) Relay. The ChargePoint OS is embeded Linux and Azure is Microsoft. The ASB Relay only works with WCF bindings. I found out that mono supports WCF but cann't find if it supports httpRelayBinding?
what kind of communication are you looking for between the device and service? If you need Relay like two-way or one-way synchronous RPC communication then you could use a simple http client to call into the service, a sample for this is here: http://code.msdn.microsoft.com/windowsazure/Relayed-Messaging-Bindings-a6477ba0
Also if you are looking for different patterns of communication such a brokered messaging where you can send/receive messages w/ data then you can consider using Service Bus Queues and Topics. I recently covered some of these usage scenarios in my session at TechEd: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/WAD-B336
I have searched a lot on this topic but didnt get any satifactory answer.
In Windows Azure how can we consume an external (third party) Web Service from the worker roles? Is it as simple as using a web reference in the solution or is it necessary to use Azure Service Bus?
It's as simple as calling the webservice using whatever method you need (REST, SOAP, etc.). For .NET developers using .asmx or WCF SOAP services, just generate the proxy like you normally would. In this model, there is no difference between what you do onpremises when the cloud is the client.
You would look at using the ServiceBus when you are hosting your own services (as opposed to consuming them), typically behind firewalls onpremises, and you want to give secure access to them or integrate them into cloud scenarios. There are other scenarios and capabilities of course, but that is a main one. If you simply want to consume another web service, the ServiceBus has nothing to do with that.
As long as the 3rd-party web service endpoint is reachable, use it the same way you'd use it from an on-premises server. If you need to connect to a service endpoint behind someone's firewall, then you'd want to consider AppFabric Service Bus.
Just remember that you'll be paying for bandwidth out of the data center (unless the 3rd-party web service is Windows Azure homed, and in the same data center).