WP7 U.S. Launch

Windows Phone 7

Monday, November 8th, 2010 came and went, the release of Windows Phone 7 has occurred. I’m sure many of you piled into a car at lunch time with your work buddies, drove down to the phone store, fought for a parking space, pushed through the throngs of people pounding at the doors trying to get a mere glimpse of the glory that is Windows Phone 7, let alone purchase one… Right, the events didn’t quite unfold that way for me either on the big release date of WP7.

The first part of that recount is true however, we did pile into a car at lunch time and drive down to the local phone store, but instead of thongs of people, we were greeted with two cardboard signs for iPhone 4 and the iPad. After milling about for almost five minutes we finally asked someone if they had a display for WP7, which we were directed to and left without much ado. I had the odd feeling we were the only four people in Naples which had any insight to this historic day when Microsoft finally does mobile right. The Samsung Focus didn’t disappoint with its’ sleek display, lightweight frame, and zippy feel, but the fanfare was lacking even from the experts at the store. There were no other phones on display to try out unfortunately.

I checked with a store rep to ask if they had any in stock and he announced they had sold out. Somewhat good news I thought to myself, but then learned that they had only received a single phone which was sold earlier that morning. I don’t know if that quite counts as “selling out” their initial launch, at least in my neck of the woods. Regardless of the lackluster personal experience during the WP7 launch, I do predict the following: Microsoft WP7 will share a similar release as Xbox originally did when Playstation 2 was deeply entrenched in the market. I believe WP7 will slowly gain adoption in the mainstream and eventually overtake Apple (and other phone OS’s) by enabling developers and phone manufacturers to create purposeful, consistent, quality products – both apps and physical devices.

Hopefully, I’ll have a phone in my hands to help spread the word soon!

P.S. – Blog postings on the two apps I have created coming as soon as I’ve tested on a real phone and deployed to the marketplace, stay tuned!

Testing Web Services with SoapUI


Web services are great aren’t they? You can easily link Java code, .NET code, and even many more obscure languages together with some type of XML-based web service. However, working with all of these different sources of code can be a little concerning as bug tracking and testing is concerned. Often times, when a change occurs it could impact several areas, which is why it’s great to have a tool to test just the web service (or a collection of web services) and experiment with different values passed to the service quickly.

I’m sure there are several options out there but I’ll share the open source one I’ve been using lately, SoapUI. Here are a few steps to get you started:

Step 1 – Download and Install

Head over to SourceForge and download SoapUI community edition. (I think I recently read that SourceForge owns ThinkGeek – if you haven’t been to ThinkGeek you’re not a true geek!)

Step 2 – Create a New SoapUI Project

SoapUI New Project

Enter the project name to whatever you like (CalculatorWebservice, for example).

Enter the WSDL location of the web service; this can either be local or a remote address. If you would like to follow along you can use the following public web service URL: http://soatest.parasoft.com/calculator.wsdl.

By default “Create sample requests for all operations” should be checked, this creates a stub request which you can modify to plug in your own values later on.

Step 3 – Open Stubbed Request

SoapUI Navigation

Use the navigation tree on the left side of the window to open your new project you’ve created, this should read “CalculatorWebservice”. Choose an operation to expand (we’ll use “Add”) until you expose “Request 1”. This is the stubbed request that you will alter to begin testing the web service. Double click “Request 1” to open the XML request in a new window.

Step 4 – Modify and Send Request

SoapUI Request

The nodes will originally display a “?”, expecting you to enter a value for the nodes. Enter all values that you would like to pass into the web service. If you are following along with the example, you can enter 1 for x and 4 for y. Click the green run button in the top left to send the web service request.

Step 5 – Evaluate Response

SoapUI Response

The split screen will now favor the response window which should have the XML response returned from the web service (if you passed in bad data or if the web service failed, you should see the failure related response as well).

You now have a quick and easy way to load up multiple web services, adjust the input values and test the responses before complicating the situation with your own code. Hope this helps!