I just read on Ajaxian that the Cappuccino team announced Atlas, a new “visual layout editor and development environment”, today at the Future of Web Apps conference in Miami. I heard Atlas mentioned (not by name) by a member of the Cappuccino team, Ross Boucher while attending a Cappuccino bootcamp session at Web Directions North a couple of weeks ago. That said, after the brief description I still wasn’t quite sure what to expect.

Now that I’ve seen it in action, I must say that it looks pretty impressive. When Ross mentioned they were building Atlas, I expected that they were working on a GUI builder like the Ext GUI builder that has been around for awhile now. Atlas, however, is more than just a layout editor.

Using Atlas, you can build layouts and interfaces (there are a bunch of fancy widgets available that you can drag-and-drop onto the layout) and easily connect components. They even have some ready-built “connections” to allow developers to easily bring external content (RSS, Twitter, etc.) into the app.

Atlas won’t be ready for use until sometime this Summer, but you can check out a short screencast showcasing some of the functionality at the Atlas site.

I have been playing around a bit with Cappuccino over the last couple of weeks, and may be able to get a couple of example mapping apps built on Cappuccino up here soon.

The visual nature of Atlas reminds me of the “Ext Designer” tool that Jack Slocum previewed a couple of months ago. It is good to see these types of tools coming out, as they can only make things easier for developers. I do hope, though, that things don’t become too easy, as I could see a new programmer coming in and never wanting to get their hands dirty. That said, having visual design tools available does take down one more barrier, making frameworks like Cappuccino more accessible to those who may otherwise not be interested.

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”