Many would argue that most significant technology that Microsoft if offering for the Cloud is the Service Bus. It allows applications to communicate across the Internet without regard to firewalls, NATs, routers, and the like.
Many would argue that most significant technology that Microsoft if offering for the Cloud is the Service Bus.
Cornerstone of Software + services
The reason the .NET Service Bus is so important is that it gives you ability to bridge your existing on-premise software assets with any new assets running in the cloud. This is a strategy commonly referred to as software + services.
It is generally very difficult to connect cloud-based applications to on-premise software is usually running behind multiple firewalls or NAT devices. Secure bidirectional communication channels between two computers is notoriously difficult. Read on to learn why.
NATs and Firewalls – Blocking an otherwise clear connection
The client and server of a network connection frequently do not have a direct and open path for communication. Packets are filtered, routed, analyzed, and transformed both on the endpoint machines and by intermediate machines on the network.
From Client to Service the barriers are:
How to enable several machines to share a single external IP address
That is what a NAT device can do. NAT devices remap ports to internal IP addresses. A NAT device will modify datagram packet headers while a packet is in transit across a traffic routing device. NATs use stateful translation tables to map the “hidden” addresses into a single address and then rewrite the outgoing Internet Protocol (IP) packets on exit so that they appear to originate from the router.
Simple firewalls apply rules based on the source and destination addresses and ports in packets. Intelligent firewalls can also examine the contents of packets to make decisions. A common configuration for a home user firewall is to prohibit incoming connections unless an outgoing connection was made to that machine previously. This is yet another example of how firewalls limit connectivity between 2 machines.
But do you really want to do all that?
The point is that you wouldn’t want to have to do that work of translating addresses.
Take a scenario where you want to connect Siebel with your app in the cloud. Here is a quick diagram where we show the connection.
There are 3 main pillars of technology that makes up the Windows Azure Platform. .NET Services is important because it is all about connecting the pillars to your on premise application(s). In future blog entries, I’ll discuss Windows Azure and SQL Azure.
.NET Services – The Relay
A relay is used to connect applications with .NET Services. This example will demonstrate how to have “senders” and “receivers.” In the diagram below we could make “Your app” a “sender” and the “Customer/partner app” the “receiver.”
Juval Lowy has a great article on how much networking “Kung Fu” is involved in easily connecting two or more computers.
Define access control rules for a customer
Anytime you connect 2 computers you need a way to secure them. Security is a big topic and involves a lot of reading and learning. It is also fast moving. There is a great article in MSDN Magazine by Michele Leroux Bustamante about the bigger picture.
We normally talking about “claims-based access control,” which is a term that means users “claim” to be someone with “rights” to do “things” with our software. An example might be, “I am Bruno and I want access to some resource, such as the internal Microsoft Human Resources Web Service within our corporate firewall.”
It is great to support “federated” security model. This means that even companies work more effectively together because they can securely access each other’s corporate resources, such as internal applications, web services, even printers. Federated models are often built up a Security Token Service. You can ready about security tokens here: http://en.wikipedia.org/wiki/Security_token.
Federated models typically mean that you will need to support a Security Token Service. Security tokens are issued by a Security Token Service (STS). The STS is trusted by both the client and the Web service to provide interoperable security tokens.
The STS verifies the credentials presented by the client, and then in response, it issues a security token that provides proof that the client has authenticated with the STS. The client presents the security token to the Web service. The Web service verifies that the token was issued by a trusted STS, which proves that the client has successfully authenticated with the STS.
This approach removes the need to provision and manage duplicate accounts for a single user, and enables single sign-on (SSO) scenarios, which dramatically simplifies security administration.
To make an interesting I want to make my own application, based on the weather. So, to kick things off, I want to create a SOAP client to connect to the national weather service.
The National Weather Service has a nice web site where you can get your local 7-day forecast (updated hourly). But what’s even more interesting,all this data is available from a SOAP-based web service, the National Digital Forecast Database (NDFD).
I was reading the docs here about creating an application that makes calls a weather service for data.
Our weather stations need to access a source for weather – National Weather Service
The first step to using the web service is to create a SOAP client. The client creates and sends the SOAP request to the server. The request sent by the client then invokes one of the server functions. There are currently nine functions: NDFDgen(), NDFDgenLatLonList(), LatLonListSubgrid(), LatLonListLine(), LatLonListZipCode(), LatLonListSquare(), CornerPoints(), NDFDgenByDay(), and NDFDgenByDayLatLonList().
I will create a cloud based app that depicts the following. I want to create a number of services that communicate with each other via an “event model.” There are many way to write such a relationship between services and we are exploring just one approach.
The weather service exposes a number of SOAP-based data results for queries about the weather. The data is available from the National Digital Forecast Database (NDFD). It supports a simple Object Access Protocol (SOAP) Web Service. This all means that we need to figure out how to call into the NDFD.
When you read about what is there at the NDFD, it ends up being a bunch of web service method calls. I don’t know what each one means yet, but my short term goal is to just connect and get some data.
WSDL – www.weather.gov provides a WSDL interface, which allows Visual Studio 2008 to generate the needed proxies and stubs. The wsdl can be found at:
Here is your typical diagram that shows consumers of weather data to get a “soap response.”
The diagram below is a rough start. Notice it talks about a simulated news ticker service. The thing is, I want to kick it up a notch. Let’s do our own thing.
A need for an on-demand distributed network of computers. In addition, information will be broadcast to an endpoint with multiple listeners
Weather information will be broadcast to listeners, which are “weather billboards” visible at airports
Weather information can also be sent to a central listener from various weather stations (physical stations that send weather)
We will simulate with web service calls from the National Weather Service
A message buffer is needed because some listeners will be disconnected due to instable internet connections
High Level Project
I will illustrate how to build this in my next blog entry.