We are now well into the final RTM milestone of the ASP.NET 2.0 and Visual Web Developer 2005 release. Having reached our ZBB (Zero Bug Bounce), we are now locked down on our feature set, and we’re focusing on the final quality, performance, and reliability push.
At the same time, we have started to work on our next release. One area we’ve been looking at for a while is the growing popularity of richer user experiences in browsers, through AJAX (Asynchronous Javascript and XML)-style programming.
All of the pieces of AJAX – DHTML, JScript, and XMLHTTP – have been available in Internet Explorer for some time, and Outlook Web Access has used these techniques to deliver a great browser experience since 1998. In ASP.NET 2.0, we have also made it easier to write AJAX-style applications for any browser using asynchronous callbacks, and we use them in several of our built-in controls.
Recently, however, the technologies used by AJAX have become broadly available in all browsers, and use of this model for rich web applications has really taken flight. There are a number of high-profile new AJAX-style websites out there today, including a number by Google, as well as sites like A9 and Flickr. Microsoft will also have more sites that use this technology out there soon – check out Start.com and the MSN Virtual Earth project for examples.
The popularity of AJAX shows the growing demand for richer user experiences over the web. However, developing and debugging AJAX-style web applications is a very difficult task today. To write a rich web UI, you have to know a great deal of DHTML and JavaScript, and have a strong understanding of all the differences and design details of various browsers. There are very few tools to help your design or build these applications easily. Finally, debugging and testing these applications can be very tricky.
What we’ve set out to do is to make it dramatically easier for anyone to build AJAX-style web applications that deliver rich, interactive, and personalized experiences. Developers should be able to build these applications without great expertise in client scripting; they should be able to integrate their browser UI seamlessly with the rest of their applications; and they should be able to develop and debug these applications with ease.
For this work, we’ve been working on a new project on our team, codenamed “Atlas”. Our goal is to produce a developer preview release on top of ASP.NET 2.0 for the PDC this September, and then have a website where we can keep updating the core bits, publishing samples, and building an active community around it.
Here are some of the pieces of Atlas that we are going to be delivering over time:
Atlas Client Script Framework
The Atlas Client Script Framework is an extensible, object-oriented 100% JavaScript client framework that allows you to easily build AJAX-style browser applications with rich UI and connectivity to web services. With Atlas, you can write web applications that use a lot of DHTML, Javascript, and XMLHTTP, without having to be an expert in any of these technologies.
The Atlas Client Script Framework will work on all modern browsers, and with any web server. It also won’t require any client installation at all – to use it, you can simply include references to the right script files in your page.
The Atlas Client Script Framework will include the following components:
o An extensible core framework that adds features to JavaScript such as lifetime management, inheritance, multicast event handlers, and interfaces
o A base class library for common features such as rich string manipulation, timers, and running tasks
o A UI framework for attaching dynamic behaviors to HTML in a cross-browser way
o A network stack to simplify server connectivity and access to web services
o A set of controls for rich UI, such as auto-complete textboxes, popup panels, animation, and drag and drop
o A browser compatibility layer to address scripting behavior differences between browsers.
ASP.NET Server Controls for Atlas
For ASP.NET applications, we are planning on building a new set of AJAX-style ASP.NET Server Controls, and enhancing our existing ASP.NET page framework and controls, to support the Atlas Client Script Framework.
ASP.NET 2.0 includes a new feature, called asynchronous client callbacks, that makes it easy to build ASP.NET pages that update their content from the server without requiring a page roundtrip. Asynchronous client callbacks wrap XMLHTTP, and work on a variety of browsers. ASP.NET itself includes several controls that use callbacks, including client-side paging and sorting in the GridView and DetailsView controls, and supporting virtual lists of items in the TreeView control. You can learn more about callbacks on Bertrand Le Roy’s blog.
The Atlas Client Script Framework will fully support ASP.NET 2.0 callbacks, but we’re planning on enriching the level of integration between the browser and the server much further. For example, you will be able to data bind Atlas client controls to ASP.NET data source controls on the server, and you’ll be able to control personalization features of web parts pages asynchronously from the client.
ASP.NET Web Services Integration
Like any client application, an AJAX-style web application will usually need to access functionality on the web server. The model for connecting to the server for Atlas applications is the same as for the rest of the platform – through the use of Web services.
With ASP.NET Web Services Integration, Atlas applications will be able to access any ASP.NET-hosted ASMX or Indigo service directly through the Atlas Client Script Framework, on any browser that supports XMLHTTP. The framework will automatically handle proxy generation, and object serialization to and from script. With web services integration, you can use a single programming model to write your services, and use them in any application, from browser-based sites to full smart client applications.
ASP.NET Building Block Services for Atlas
With ASP.NET 2.0, we’ve built a rich set of building block services that make it incredibly easy to build powerful, personalized web applications. These building blocks dramatically reduce the amount of code you have to write for common web application scenarios, such as managing users, authorizing users by role, and storing profiles and personalized data.
With Atlas, we’ll make these accessible as web services that can be used from the client framework in the browser or from any client application. For example, if you are building a website that shows a list of to-do items for the user, you can use the ASP.NET Profile service to store them in the user’s profile on the server. These items will then be accessible even as the user roams from one machine to another.
Services we will provide include the following (all based on the ASP.NET V2.0 implementations):
- Profile: Store per-user data on the server.
- UI Personalization: Store personalized UI settings on the server.
- Authentication: Authenticate users.
- Roles: Authorize user tasks and show different UI based on the user’s roles.
Because these building blocks are server based, you can use the same security model as for accessing the rest of the site. These services also won’t require any client download – just reference the script proxy from the browser.
All of our ASP.NET 2.0 Building Block Services are pluggable at the back-end using a common provider model extensibility pattern. We provide built-in providers that let you use a SQL Server database or Active Directory as a store, but you can easily plug in your own. For example, if you want to store user profiles in a centralized cloud rather than on your own database server, you can simply plug in a different provider – the choice is yours.
Client Building Block Services
In addition to DHTML, JScript, and XMLHTTP, we’re looking at additional services that allow websites to harness the power of the client to deliver an enriched experience.
The local browser cache is an example of such a service. When enabled, websites can store content in that cache and later retrieve it efficiently. But there’s no API from the browser to store data in the cache, and applications like Google Maps or OWA have to go through hoops to generate unique URLs so that the browser will cache the server response. With Atlas, we plan on providing programmable access to a local store/cache, so that applications can locally cache data easily, efficiently and securely.
Integration with other applications is another new dimension of a rich web experience. For example, when a user browses an auction site and bids on an item, they can see when the auction ends, but how easily can they integrate that event into their personal calendar application? With Atlas, we are also looking to provide a set of client-side building block services, and a model for how websites can securely publish connection points for those services. When the user selects “Add to Calendar”, the browser can call the connection point to get the calendar data, and pass it onto the local calendar application. The page doesn’t get to download or run its own code or initiate the action, so it’s safer than ActiveX.
Next Steps
As we move further along, more pieces of the story will emerge. In parallel, we are already working on our next release of development and debugging tools, so that we can deliver a great development experience for these type of rich web applications.
One question you may have is how Atlas relates to Avalon and smart clients.
We see Atlas as the best way to write a whole new generation of richer, more interactive, more personalized experiences in browser applications. Avalon is the next generation presentation model for Microsoft, and will let you build the richest user experiences on the Windows platform. Avalon will deliver phenomenal graphical experiences that use the latest in media integration and hardware acceleration. And Avalon will also let you provide persistent, immersive experiences that go beyond the browser.
Of course, when you’re building Avalon applications, you can reuse the programming model investments you make today with ASP.NET and Atlas. For example, the ASP.Net Building Block Services and Client Building Block Services will also be accessible from any Avalon client. This model gives you a smooth path to the next generation of applications.
Stay tuned here to hear more about our plans for Atlas and ASP.NET V.Next. And let us know your thoughts – Are you considering building richer AJAX-style web applications? What would you like to see in Atlas? You can post here on the blog, or send your comments to our feedback to our team alias at atlas@microsoft.com.
Thanks,
Web Platform and Tools Team
P.S. Some of you may be wondering how we chose the name Atlas. We’ve used several names related to Saturn for projects owned by our team. Saturn itself was the codename for ASP.NET Web Matrix, Cassini was the sample web server for hosting ASP.NET, and Calypso was the name for our community website at www.asp.net. And we thought Atlas would be a nice name for the roadmap to the next generation of rich, personalized web applications.
P.P.S. To learn even more come to the PDC this September