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).
Related
I want to protect a number of Azure App Services with Web Application Firewall.
I was able to make it work with one app and on the way to adding the other apps.
Is there any recommended way or things to consider given the fact that some of these apps talk to each other?
If AppA queries AppB, I understand that the call would not be routed through the internet since it's all between azure IPs, is that right?
But would that skip the Application Gateway?
We need to develop integration between ERP (Dynamics Nav) and cloud-based telephony provider.
The provider needs to have an endpoint published and accessible from internet but for security reasons it is not possible for us to allow inbound connections to our network. I think it should be possible to solve this by hosting small application in Azure which will serve as endpoint for telephony provider and to which ERP will connect as outbound persistent connection. The app will just forward requests to ERP.
Since I'm new to Azure the question is what of azure capabilities I could use to solve the task aside from hosting actual VM with application there?
I've just implemented the same using Azure Service Bus.
The VOIP system is putting a small JSON with call details after the end of the call and I'll get the messages from the Service Bus Queue from NAV.
The code is not complicated at all the whole solution is simple and cheap!
Let me know if you want to know more (= you need the code).
Cheers!
Azure AD has the concept of an "application proxy" that will open internal applications up using a connector that runs on prem. This doesn't require inbound ports and is protected by Azure AD authentication.
It's intended more as a user-facing way to get access to Legacy applications, although I don't see why it couldn't be used for integration as well.
https://learn.microsoft.com/en-us/azure/active-directory/application-proxy-publish-azure-portal
Otherwise, you could link an Azure Site to Site VPN up and use a service like API gateway to manage connections though this is more complicated.
I am developing a mobile application that makes extensive and continuous use of SignalR to communicate to a SignalR service.
I have previously assumed that I would use a Web Role to host the service, and then add more Web Roles backed by a backplane of Service Bus or Redis as and when the service needs to scale out. Using a Web Role would also allow me to significantly scale up if I wanted to avoid possible latency issues with the backplane.
However when I compare the pricing of the Web Role to Azure Mobile Services it appears that the Mobile Services may be cheaper.
So can Mobile Services be used instead?
And if so what are the pros and cons of doing so?
We are close to rolling out an update to Azure Mobile Services .NET backend which comes with some neat integration with SignalR built in. I'll be posting a blog on it on http://blogs.msdn.com/b/azuremobile/ (and of course on twitter #frystyk) when it's there and how to use it.
Henrik
I have a Windows Azure Mobile Service up and running, however, there is a need for that service to consume some data expose through an external SOAP service and store that information in the mobile service database.
I would like to set up a worker in the mobile service, so the calls to the external SOAP service are executed in a fixed period of time.
I've been looking for a solution to this problem, but haven't found anything yet. So any help that would get me in the right direction would be appreciated.
Unfortunately there isn't an easy way to talk to a SOAP service from your Mobile Service backend. The backend is based on Node.js, and even though there are some Node modules for talking to SOAP services, they are currently not supported in Mobile Services. We are working on a solution that will enable you to use any Node module in your service, but it is not out yet.
If you control the SOAP service and it is written using WCF, you may be able to easily add a REST endpoint to the service with just a few config changes and then consume it from your Mobile Service via plain HTTP requests by using the "request" module.
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.