Johannes Kebeck has an interesting post showing how to get the benefits of the MapPoint Web Service method, FindNearRoute, through the use of SQL Server 2008. He uses a newly-added feature of the Virtual Earth API that allows developers to gain access to a complete returned route-geometry when performing a route. This new feature, however, does require that the mapping application use customer identification (which, in turn, requires that you sign up for a Virtual Earth platform developer account).

If you haven't checked out Johannes' blog lately, you might want to give it a go now. He has written a whole slew of Virtual Earth and SQL Server 2008 posts lately, and there's a wealth of good information there.

We've already started using SQL Server 2008 in some of our development applications, and are planning on taking advantage of ArcSDE 9.3's ability to utilize SQL Server 2008's spatial data types. We're hoping that by doing this, we'll be able to offer access to our geometries through both traditional GIS tools (ArcGIS Desktop for our shop) and web services (ADO.Net Data Services returning JSON and XML and other services built on top of WCF). As we're already using ArcGIS Server 9.3's REST capabilities from within our JavaScript/Virtual Earth applications, if we can "close the circle" by tying SQL Server 2008 and Virtual Earth together in a robust and meaningful way, we may just be able to hit the proverbial bulls-eye. We've already written quite a bit of code that brings these technologies together, but are still deciding on the best overall approach.

One thing that is still unclear to me is if we're going to utilize ESRI's tools heavily or try to avoid them as much as possible and stick with all of the non-ESRI .NET technologies. In a lot of ways, we're already going the latter route (saying ArcGIS Server 9.2 still leaves a bad taste in my mouth), but I've been impressed with ArcGIS Server 9.3 so far, so I'm withholding judgement until we see how the new set of technologies perform in a couple of months.

And from the Microsoft camp, I expect that more direct integration with SQL Server 2008 will be coming soon to the Virtual Earth API. I haven't, however, heard of any solid dates yet. Any integration will be much-welcomed, as it will save us precious development time.

Whichever route we decide to take, it's pretty obvious that now is a great time to be working in web mapping. Especially if you're able to take advantage of all the integration points available through .NET.

I've been meaning to play around with Microsoft's new ADO.NET Data Service stuff (formerly known as "Astoria") for some time now, but couldn't find the time until today. When I last blogged about it, the technology was still in a Community Technology Preview. Since then, however, it has matured, is now packaged with the ASP.NET 3.5 Extensions CTP, and will undoubtedly be included in a future service pack or release of the .Net Framework. Until then, though, you have to walk a difficult road to get it installed and working as, like a lot of Microsoft's "unofficial/unsupported side projects", it isn't just a single install to get it up and running. It's, rather, a series of installs followed by obscure IIS configuration changes followed by pulling your hair out followed by (finally) some ADO.Net bliss.

Here are the steps to get your development machine setup to work on ADO.Net Data Services. These instructions apply to a 64-bit Windows XP SP2 installation. The steps may vary for other versions of Windows, but I'm pretty sure that most of them will apply in most cases.

• First of all, Visual Studio 2008 is a prerequisite for developing ADO.Net Data Services. You can use any version, including Visual Web Developer Express.
• Next you need to download and install the ASP.Net 3.5 Extensions CTP. If you're on a 64-bit operating system, you may have to manually copy the System.Data.Entity and System.Data.Entity.Design .dlls from your GAC to your .Net v3.5 directory (I had to). A bit more detail:
  • For some reason, these two dlls don't seem to install correctly when you run the ASP.Net 3.5 Extensions CTP installer. To solve this:
    • Click "Start>Run" and then paste the paths below into the "Open:" dialog and hit enter:
      • C:\Windows\assembly\GAC_MSIL\System.Data.Entity\3.5.0.0__b77a5c561934e089
      • C:\Windows\assembly\GAC_MSIL\System.Data.Entity.Design\3.5.0.0__b77a5c561934e089
    • From each of the now open directories, drag and drop the single .dll into the following directory: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5.
• Next you need to download and install the XML Editor QFE and the ADO.Net Entity Framework Tools Dec 07 CTP, in order.
• And now you should be ready to develop ADO.Net Data Services! There's a great walkthrough available on the ASP.Net 3.5 "Quick Starts" site.

After you've created your data service on your local dev machine, you're probably going to want to deploy it to a dev server, right? Well, I did. And, of course, I ran into another issue that required quite a bit of Googling and cursing to solve. After deploying the application and pointing a Virtual Directory at it, I received the following error message when browsing to the .svc in Internet Explorer:

"A name was started with an invalid character. Error processing resource"

Well, what is this? I found lots of others asking that very same question, and finally stumbled onto a solution in the MSDN forums. I'll outline the steps here, as much for my own sanity if I run into this problem again on another server as to help others. These steps apply for IIS 6. If you're on IIS 7, here's a quick tip: make sure that you make the directory an application and not just a Virtual Directory...

• First of all, make sure that you have the ASP.Net 3.5 Extensions CTP installed on the server. This should be obvious, I know, but it wouldn't be the first time...
• Next, you'll need to manually add a script mapping for the .svc extension to your application's properties in IIS Manager:
  • Open IIS Manager.
  • Right-click on your application and choose "Properties".
  • On the "Virtual Directory" tab, click on the "Configuration..." button.
  • On the "Mappings" tab, make sure that .svc isn't already present in the "Application extensions" section. If it isn't, click on the "Add..." button.
  • Click on the "Browse..." button and browse to and select C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll.
  • Back on the "Add/Edit Application Extension Mapping" dialog, type ".svc" in the "Extension:" textbox and click "OK".
  • Click "OK" two more times to get out of the application properties.

Theoretically none of this should be necessary, as IIS's script mappings are supposed to be updated whenever a new version of the .Net Framework is installed on the machine. However, I found that this didn't happen in my case (I was, again, doing this on 64-bit machine (Windows Server 2003), so maybe it is another funky 64-bit thing). I also found that running ServiceModelReg.exe, which is supposed to WCF-enable IIS, didn't work either.

So after you do all of this (and I honestly hope that you had a much easier time than I did) you're good to go.

I'll post about my actual development experience with ADO.Net Data Services in a separate post. But I'll put in this teaser: You can do some really cool stuff with these extensions!

Brief Introduction

Microsoft's ADO.NET team recently released a new project, as a Community Technology Preview (CTP), through Microsoft's Live Labs. The project, codenamed "Astoria", is a technology that allows developers to easily build and deploy data services (either on their own servers or to Microsoft's hosted "Astoria Online Service") that are accessible to applications through HTTP requests. This idea is not necessarily new - there are other ways to build a web services interface - but the ability to easily build a data service for SQL Server that is accessible through HTTP is definitely groundbreaking.

As the "Astoria" site preaches: this type of service is especially useful for AJAX-based applications that work hard on improving the user experience, through the use of Flash or Silverlight. Once an "Astoria" data service is published, you can query the underlying data structure by passing parameters in the URI. For example (and this is taken from the "Astoria" Overview document that is available on the Live Labs website):

To access all customers in a database:

http://myserver/data.svc/Customers

To access a customer whose key is "ALFKI":

http://myserver/data.svc/Customers[ALFKI]

To find all orders that are associated with a customer whose key is "ALFKI":

http://myserver/data.svc/Customers[ALFKI]/Orders

And so on, so forth. You can get much more focused than the above examples. You can drilldown into related data, filter out records, sort records, and even page records.  You get the picture, right? It really is a powerful way to interact with a database.

How does "Astoria" make it so simple? Well, when you build an "Astoria" data service with Visual Studio (and, by the way, you need Visual Studio "Orcas"/2008 beta 1 to install the "Astoria" framework and build these types of data services) you build an Entity Data Model (EDM). "Astoria" then uses this model to wade through the underlying database and figure out how data are related. It can then use this simplified information to serve the data and make them accessible through the RESTful interface. "Astoria" can currently represent data in XML, JSON, and (as Pablo Castro, Microsoft's ADO.NET technical lead, mentions in a really great presentation that he gave at MIX 2007) *very experimentally in RDF+XML. XML support is probably the most accepting, but JSON is, of course, perfect for use with AJAX applications.

Helpful/Interesting Resources

I find "Astoria", and the underlying concept of taking complex data and making it broadly accessible intriguing. Again, I understand that this is not new territory. SOAP and other web services are a more powerful way of accessing data, but I see "Astoria"'s restful interface meeting the needs of many. The ability to easily publish a database and make it accessible to the web is something that will allow many developers to build richer (and lighter-weight) web (and mapping!) applications.

• Project "Astoria" Homepage
• Pablo Castro's "Astoria" Presentation at Mix 2007
• John Udell's "A Conversation with Pablo Castro about Astoria's RESTful Data Services"