Windows Azure Accelerator for Web Roles
Azure is a great platform to build applications on, and it allows you to scale up very high without a huge investment in infrastructure. However, what if you want to use Azure to scale down very low? What do you do if you want to run 20 different small websites, but you don't want to pay $1,200 a month for 40 extra-small web roles (2 per site to ensure availability)?
If that describes what you'd like to do, take a look at the Windows Azure Acclerator for Web Roles (WAAWR). It makes it easy to set up a single Azure web role that can host multiple IIS sites on it - 20, if you want, or more. You can set up 2 extra small instances of the accelerator role and only be out $60 a month for the instances. The initial deployment of the Accelerator takes several minutes, as is typical for Azure web role deployments, but deployment of each individual application is done even quicker and using the publishing tools built into Visual Studio. To see a demo of the WAAWR, watch Cloud Cover Show episode 51.
It's a great tool, go check it out - I won't rehash what's already out there about it. Instead, I'm going to focus specifically on how to use Node.js with the WAAWR.
Node.Js
A short while ago, Ryan Cromwell, a coworker of mine, asked if Node could be run with the WAAWR. It seemed like it should, as WAAWR was just setting up IIS sites in Azure automatically, and Node could run in IIS alongside .Net apps, but I wanted to try it out for myself to be sure - and it worked without any problems. The following are the steps to take to get Node working with the Windows Azure Accelerator for Web Roles.
Friday, February 10, 2012
Thursday, February 2, 2012
LinkPointTransaction.Dll
If anyone else out there ever has work with the LinkPointTransaction.dll assembly, I pity you. It is not an enjoyable experience.
I've been working on updating an eCommerce site, and before I started working with the payment code, I wanted to run a simple test transaction against LinkPoint so that I could gain familiarity with it before I started changing code around. Hopefully my story will help others in their struggle.
I first had to sign up for a developer account. That was fairly simple, and shortly thereafter I received three emails with 3 different accounts - apparently they have 3 different ways you can issue transactions.
1. Web Service API. This is a SOAP endpoint.
2. Virtual Terminal. This is where you log into their website and type in transactions manually
3. Connect. This is where you use LinkPointTransaction.dll to connect to their services
Once I figured out what the 3 different options were, I figured out that the app I was working on used #3. (Side Note: If you're starting from scratch, I would recommend checking out the SOAP endpoint so that you don't have to work with assemblies, COM objects, and custom SSL libraries that are several years old). I then went looking for documentation. I found the documentation site, but it took me a little while to figure out which PDF was the right one. I finally figured out that the API user manual was the right one. I had initially thought that the API user manual would have been the manual for the Web Service API, but I was wrong - the API user manual is for the Connect option.
I've been working on updating an eCommerce site, and before I started working with the payment code, I wanted to run a simple test transaction against LinkPoint so that I could gain familiarity with it before I started changing code around. Hopefully my story will help others in their struggle.
I first had to sign up for a developer account. That was fairly simple, and shortly thereafter I received three emails with 3 different accounts - apparently they have 3 different ways you can issue transactions.
1. Web Service API. This is a SOAP endpoint.
2. Virtual Terminal. This is where you log into their website and type in transactions manually
3. Connect. This is where you use LinkPointTransaction.dll to connect to their services
Once I figured out what the 3 different options were, I figured out that the app I was working on used #3. (Side Note: If you're starting from scratch, I would recommend checking out the SOAP endpoint so that you don't have to work with assemblies, COM objects, and custom SSL libraries that are several years old). I then went looking for documentation. I found the documentation site, but it took me a little while to figure out which PDF was the right one. I finally figured out that the API user manual was the right one. I had initially thought that the API user manual would have been the manual for the Web Service API, but I was wrong - the API user manual is for the Connect option.
Subscribe to:
Posts (Atom)