Publishing WCF Services to Windows Azure

I had a little hickup today as I was playing around exploring Web services and Windows Azure. After scanning the Internet, I’m now convinced that most people out there working with Azure are hosting Web apps up there, not Web services, based on the amount of articles I found (unless of course people doing services just aren’t talking about it because it’s just soooo easy :)). Perhaps it was just my search terms, or maybe that’s what most people start with, but I found this interesting and thought I’d put together a post for anyone trying to get started deploying a WCF service to Windows Azure. I’m sure there’s some services-centric, probably SOA-ish folks out there wondering how to do this…

I put together a WCF service, and then deployed it:

  • Locally (using the VS.NET dev Web server)
  • Locally (use the Windows Azure development fabric)
  • Remotely (to Windows Azure).

In this post I’ll go through the steps I followed. To get started, I:

  • Created a Cloud service project
  • I added a WCF service (note that I changed to basicHttp binding)
  • I wrote a little code, ran the project locally, using the development Web server, and it worked no problemo
  • I created a test client based on the WSDL exposed above
  • I set my cloud service project as the startup project, and in Visual Studio, ran it.

The Azure SDK adds some Visual Studio templates, you get this:

In Visual Studio, my finished solution looks like this:

SIDEBAR: so why the heck is Brian using “Contoso”? More later, but this service is part of a greater whole which I will be blogging about.

For those of you who have not worked with Azure yet, one of the cool features you get is a “development fabric” that basically gets you a local copy of Windows Azure, including storage. Having spent as much time in airplanes as I have in the past year, this is really appealing. When a cloud service project is the startup project, running the solution will launch the development fabric. The UI for it looks like this:

Next, I repointed my test client to point at the address shown above. However, it failed. I got a 405 error, “method not allowed”. Turns out that the cause of this was that IIS7 did not have a handler mapping to SVC files, so didn’t know what to do with them. To fix this, I ran “ServiceModelReg -i” in the “c:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation” folder. Perhaps it was an installation sequencing issue that led to me not having WCF registered in IIS, or, maybe this is something you just have to do.

After I ran it, my handler mappings looked like this:

After that, I was able to call the service in my local Windows Azure development fabric. Cool!

Next up, how to deploy this to the cloud? You can do this using the CSPack command line utility, but for quick dev there’s an easier way. In Visual Studio, right-click the cloud project and choose “publish” from the context menu:

Now, you might expect choosing “publish” on a cloud service project would do something like, ummm… perhaps “publish the service”. Well, it doesn’t. What it does is actually prepare it for you to publish it in another step, it creates the configuration files you’ll need for that step. It also opens a browser that navigates to the Azure portal, as well as opening a Windows Explorer in the “publish” folder where it wrote out the two config files. You then use the portal to upload the files:

After you upload and start it looks like this in the portal UI:

And, that’s about all it takes. Clicking on the arrows in the middle swap out the “staging” and “production” instances of the deployed apps, which really is nothing more than a change at the load balancer level.

A year from now, it would probably just take a credit card number for this Web service to scale to millions of calls per hour. The future is closer than it appears I think, these are exciting times. Go forth and learn!

Technorati Tags: Azure,Windows Azure,WCF,Cloud,Cloud Computing

The BizTalk Ops Team – Maintaining a Healthy, Responsive and Available BizTalk Environment

One of the things that surprises me about BizTalk installations is, in my experience, the limited support they receive once a project has gone live. BizTalk is a large enterprise product and a dedicated team of BizTalk operational specialists and SQL Server DBA’s should be created for the task of maintaining operational and test environments.
In […]

Screencast: Configuring WCF services with behaviors

Screencast: Configuring WCF services with behaviors

I recently published a free video on Configuring WCF services with behaviors.

configuring-behaviors-200

In this WCF screencast, I'll show you how to configure WCF services with behaviors, which will allow you to customize different aspects of the runtime execution "behavior".

Check out our growing collection of free .NET screencasts and videos.  Subscribe to the Pluralsight feed to be notified when new screencasts are published.  Also, check out our growing library of online .NET training courses — see what you can learn with Pluralsight On-Demand!

Screencast: Configuring services with behaviors

Screencast: Configuring services with behaviors

In this WCF screencast, I'll show you how to configure WCF services with behaviors, which will allow you to customize different aspects of the runtime execution "behavior".

configuring-behaviors-300

Be sure to check out our growing collection of short screencasts on Pluralsight's screencast landing page.

Previous WCF Screencasts (RSS for all posts in the series)

New URI for my blog

This blog has a new URI. Please re-point your feed readers or bookmarks to http://blog.BrianLoesgen.com

Nothing else changes. I am still hosted with my buddies at GeekWithBlogs, and I will of course continue to blog about BizTalk, Dublin, SOA, Oslo, Azure, WF/WCF et al. The new link is easier to remember and provides a layer of indirection should I decide to change where the blog is at some point in the future.

I couldn’t think up a language of my own

I couldn’t think up a language of my own

So I decided to write an MGrammar for an existing language – XLANG (the language of
orchestrations in BizTalk).  The picture shows Intellipad in 3-pane mode with
an XLANG orchestration on the left, my MGrammar for XLANG in the middle, and the MGrammar
projection on the left. 

What’s the point?  Well to help me learn more about MGrammar for one, but I think
I have some pretty interesting stuff I can do with orchestrations once I can parse
them using my grammar.  More to come…

mgrammarforxlang


Check out my new book on REST.

Forcing Windows Authentication Across Domains

I’ve been getting this question quite alot recently, “BizTalk accessing SQL in another
domain…”, “SharePoint accessing Webservices via NTLM auth only in another domain…”
etc.

Most of the time we can find a box to stick in a User Name/Password somewhere (e.g.
File Adapter in BTS) that will more than likely solve the problem.

For the cases where you can’t or there’s some complicated RPC session (connect to \\server\IPC$ share)
that’s setup first (several MMC snap-ins for e.g.), then you’re given access, “It’s
so much easier if we’re all part of the same domain…”
speech you give yourself
over and over again….then I may have a technique to help you.

Basically we force our Windows to always use specific credentials when communicating
with the remote machine X
– on a per user by user basis.

It goes something like this:

(1) login to the local server in question under the acct that is needing access (e.g.
svc_acct) – this is usually the ‘Web App Pool identity’ or the ‘BizTalk Service Account’
(generally NOT your day to day account)

(2) under control panel -> Stored User Names and Passwords (on Vista this is ‘User
Accounts’)

(3) Then add the credentials to suit.

Viola – happy NTLM-ing & Merry Christmas…….

 

Mick.