At the Professional Developer Conference (PDC) in September, Microsoft offered a first glimpse at its AJAX (Asynchronous JavaScript and XML) strategy, which has been given the code name of Atlas. As you probably are aware, AJAX is the current buzzword in Web development. It promises the ability to write richer browser applications and to retrieve data from the server to update the contents of the current page without having to completely repost the page to the Web server. The advantage of this type of application is that it provides efficient usage of the bandwidth available to Web applications and-, in many cases, provides a smoother, more responsive, and non-flashing user interface that Web applications are not typically known for. On the flipside, AJAX relies on more recent browsers and fairly extensive use of client-side script code to provide the rich interaction between the browser and server.
The buzz over AJAX aside, Microsoft’s first effort in the AJAX space was disappointing. ASP.NET 2.0 will ship with a technology called Script Callbacks (http://www.asptoday.com/Content.aspx?id=2381) that is native ASP.NET. Script Callbacks are simple and quirky, an interface-based implementation of page callbacks that are entirely bound to the ASP.NET page lifecycle. Although functional, the model used in this architecture is both limited and implemented in a way that makes using it rather cumbersome and unnatural. Microsoft developed this technology for internal use early in the ASP.NET 2.0 cycle, before AJAX became fashionable. It’s used internally in several of the ASP.NET server controls, like the GridView and TreeView, to support client-side updates of the data displayed.
If you are looking to do AJAX-style development with ASP.NET 1.1 or 2.0 today, there are easier and more fully implemented solutions available from the community. I personally like Jason Diamond’s My Ajax.Net (http://jason.diamond.name/weblog/2005/07/06/my-ajax-dot-net-library) and have used it quite a bit. Another popular library is Michael Schwarz’s Ajax.NET (http://ajax.schwarz-interactive.de/csharpsample/default.aspx), which is probably the most used AJAX implementation on .NET today. Both are open source and come with source code and, more importantly, both are easy to use and provide simplicity for the 90% use case scenarios. They also work with ASP.NET 1.1, so you can use it in all of your ASP.NET applications.
Atlas to the Rescue
Not to be outdone, Microsoft entered the AJAX space for real with the announcement of the Atlas Project just a few weeks before PDC, and officially previewed the technology at the conference. As expected, Atlas is a very ambitious project and covers a huge range of features including a variety of approaches to implementing AJAX-style applications. Atlas is slated to be shipped as an add-on to ASP.NET 2.0 sometime in 2006, so it’s still a ways off. One nice thing announced is that Microsoft is planning to ship Atlas outside of the regular ASP.NET product cycle initially so the product can rev much more quickly than a full ASP.NET cycle. Atlas likely will ship as an add-on assembly (or assemblies) plus a script library that can simply be added to an application. At a later point, it’s likely that tool integration with Visual Studio will take place, resulting in a tighter binding to the core ASP.NET platform.
So what does Atlas bring to the party? A lot of things, but it’s important to understand that not all of the features in this overwhelming library are necessary to start doing AJAX-style development. Here are the some of the core features:
Web Service Connector Bridge
One of the core features of the Atlas framework is the ability to bring down data to the browser quite easily by using a new Web service interface that gets hooked by the Atlas framework. This special HTTP handler interface allows an Atlas client application to communicate with a .NET Web service using the JSON serialization format. JSON is a JavaScript-compatible, light-weight serialization format that encodes any type, including complex type, into a string that can be evaluated in JavaScript and provides a type reference. This simple interface allows you to take advantage of existing Web Services-or new ones-to access server-side logic from the client applications without all of the overhead that SOAP entails.
This interface is two-way, so you can receive data from a Web service and you can send it back up to the server using the same mechanism. Atlas can serialize and deserialize the JSON format both on the client and server. To facilitate this process, the Atlas client framework includes the infrastructure to manage type information that becomes part of the JSON serialization strings that travel over the wire. What’s really nice here is that in combination with the client-side script framework, you can return many common types from the server and use them easily on the client. For example, you can return arrays, collections, data tables, and data rows, and the client framework provides a CLR-like client implementation of that type. Custom types are also supported.
This deceptively simple implementation provides a lot of power to existing applications that might not even need to take advantage of all that the Atlas framework has to offer. This is a close match in functionality to the tools I mentioned earlier, only more closely integrated with standard ASP.NET practices.
Web service methods can be implemented both in a separate Web service class or they can be called directly in the current page. One interesting feature of the page-based WebMethod call is that all of the page’s POST data gets written back to the server and the callback with full support for the page lifecycle, including access to updated control values and ViewState. The full Web service interface can work with current ASMX implementations or with Indigo services.
Personally, I prefer the external Web service approach because it promotes better separation of the UI logic and the data service functionality. Using the Web service also means that the data is much more reusable. For example, if you end up building a true Smart Client application, it will be able to consume the exact same data using a standard Web service from exactly the same code base.
In preliminary tests, I found this mechanism, in combination with the rich type support, very powerful. The ability to pass complex types and collections of types from the server to the client and back easily makes it quite easy to update the user interface, modify data, and send it back without having to resort to writing complex string-encoding schemes to pass the data around. For interfacing with business data, this mechanism really provides clean separation of the UI and business layers.
Client-Side JavaScript Framework
As mentioned above, Atlas provides a rich client framework that supports many of the core services required by other parts of Atlas. Atlas uses a layered client architecture of services provided by the framework. Most of these layers are internally used, such as the rendering features for controls, the browser compatibility layer, and the network layer used to send requests back and forth.
But one layer you’re likely to see a lot of in your client applications is the Core framework and Base Class Library, which provide a small subset of .NET CLR and BCL functionality on the client side. The Core functionality provides a number of language features that are interesting. There’s namespace support and type registration to provide a simulacrum of typed JavaScript variables. Perhaps most interesting is the client-side BCL implementation, which provides support for many common basic classes and structures that are used in .NET development. This means that the code you write on the client script end looks a lot closer to .NET code than it currently does, even if some constructs are bound to quirky JavaScript language features.
Client Side and Server Side Controls and “Atlas Script Markup”
In addition to the framework, Atlas also provides a core set of controls that provide browser-independent implementations of many common ASP.NET controls. What this powerful feature buys is an abstracted control model that alleviates the developer’s need to fully understand the nuances of every browser running on a client. If you’ve ever done any sort of UI development with client-side JavaScript, you know that the syntax and object models of various controls varies ever so slightly and these client-side implemented custom controls alleviate the need to have to code to these browser-specific nuances.
It’s hard to tell right now how this works, but the Atlas framework uses these controls internally to manage the browser-independent rendering of script code. Examples of this have not been provided, but it was shown by Nikhil Korhan (http://www.nikhilk.net/) in the Server Control talk (http://www.nikhilk.net/Entry.aspx?id=92) at PDC. At the moment, these controls are internally used by the Atlas Server Controls and the “script markup” they generate in the client-side HTML page. Atlas uses declarative script tags to drive functionality through behavior attributes. For example, you tell the control to invoke a method on another control (or data control) to retrieve the data or set the value of a given property.
The script markup is interesting in that server controls generate their declarative markup to the client within an embedded <script type="text/xml-script"> tag. The Atlas client framework then evaluates this script markup dynamically to generate the page behavior and layout. In other words, unlike server controls, these controls use the client-side controls and framework to manage the parsing and code generation at runtime in the browser. This takes a moment to grasp. The reasoning behind this client-side parsing and execution seems to be to avoid having to generate reams and reams of JavaScript code and then inject it into the page before sending it from the server. By doing it on the client, this markup functionality can be added easily to any page and can stay relatively small describing the actions of the page.
Microsoft seems to be emphasizing this declarative style of programming, but that doesn’t mean that script code-driven logic is not available. You are absolutely able to drill down to the script level and write the control code and logic yourself. If you do, you can take advantage of the control architecture and BCL implementation so you get much richer client-side functionality. But keep in mind that some of these features are hacked together around the limitations of JavaScript, like the Type subsystem and Object Oriented features in general. It’s still JavaScript. Bend it as they might, Microsoft is sticking to a pure JavaScript implementation.
All this is still pretty vague as there’s zero documentation, but it shows the direction that Microsoft is headed. The idea for the markup code is that rather than writing potentially browser-specific JavaScript code, you write declarative markup that the Atlas framework renders into control and script code that is dynamically generated and executed at runtime. Bertrand LeRoy (http://weblogs.asp.net/bleroy/) has a nice example (http://weblogs.asp.net/bleroy/archive/2005/09/20/425698.aspx) that demonstrates the server control/markup syntax a lot better than the simple PDC labs. In that example, you can get a pretty good idea of what markup will be capable of by providing a very UI-centric interface.
Although I think that this is a noble goal, I have many misgivings about this declarative model, because it’s completely UI-centric. You map a Web service (or other datasource) to a property or method of another control, but there’s very little room for custom code that is almost certainly going to be required in addition to 1-1 mappings. In addition, the markup model introduces another “scripting” layer into your applications with yet another markup syntax. All of the markup gets translated into JavaScript that eventually executes.
The functionality of this markup reminds me of Ruby on Rails to some degree, and it’s a model that I dislike vehemently. I don’t trust code that is handled for me to serve all of my needs, and this has the beginnings of a high-level description language that doesn’t sit well with me. I have to admit that I had similar misgivings about the template-driven approach that ASP.NET controls use, and eventually I came around to it once I understood fully what you can and can’t do with that approach. I expect that the same will happen here.
The Good, the Bad and the Ugly
Looking at Atlas in this early stage is a mixed bag. As with many previews, the documentation is nearly non-existent beyond a few hands-on labs that give a cross section of the features available. The labs are actually quite good at demonstrating a number of common scenarios, from the most basic to the cool factor. But the labs are not a good substitute for documentation. They only address a very minimal subset of the capabilities and provide absolutely no insight into how things work behind the scenes, which at this point, would be beneficial.
If you want to know how things work, your only avenue is to open up the JavaScript libraries with their bunched up, line feed-removed code and dig through the spaghetti code that is JavaScript at its best. Most of the meat of Atlas is in the JavaScript. For the server-side code, you’ll need to dig out your copy of Reflector and start digging into the binary bits. Looking through all of this, you’ll find that there’s a lot of implementation code-Atlas has been a long while coming at Microsoft.
I spent some time going through the labs and that worked just fine, but as soon as I started going off the beaten path, a number of things started breaking. For example, the Web service functionality started breaking on even some simple custom types I set up. There’s no exception handling in the Web service behavior, so if anything goes wrong on the server, or you need to notify the client of a non-success result via a SOAPException, the server spits back HTML instead of an Exception or other object that includes an Exception. Even some of the simple steps failed outright. Working from the labs and trying to use the server control markup to fire custom code also proved difficult-I was stopped dead in my tracks at nearly every corner due to lack of documentation.
Playing with Atlas at the moment is beyond even bleeding-edge technology. Don’t spend your time with it unless you’re willing to dig into the code base and find your own “documentation” there.
But this is understandable from Microsoft’s point of view. It’s meant as a very early glimpse at what Microsoft is doing. I don’t think there’s any hope of doing anything useful with this technology now other than checking it out and giving Microsoft feedback about direction. One thing is for sure: this stuff is likely to change drastically, so don’t get too familiar with what’s there today.
Pain Factor: Client-Side Scripting
Atlas provides a lot of technology and functionality at the library level, but it doesn’t provide any new tool support, at least not at the moment. I would argue that the biggest deterrent to efficient client-side and AJAX development is the lack of tools to debug your client-side script code. Writing client script code is easily four to five times slower (for me at least) than it is to write the equivalent server-side code. Lack of IntelliSense, compilation, and the lack of decent documentation for the various object models make all of this difficult.
Microsoft is addressing some of these issues with the client-side libraries and bringing a more consistent object model to client-side code via the client-side markup. By using these client-side libraries, Microsoft is able to abstract away some of the browser compatibility issues and provide the developer with a consistent single-access model to code against. This is an important step in the right direction, but tool support is absolutely required if we are to build applications that rely on an increasing amount of client-side logic.
Client-side debugging is not being addressed at the moment. That support is something likely to come in future versions of Visual Studio.
Smart Client and Thin Client-No Contest, Yet! There are some interesting issues that Atlas brings up. It’s obvious to see that Microsoft has heavily invested in Atlas by the sheer breadth that this toolkit attempts to address. With all the talk about Windows Vista and Avalon-uh, Windows Presentation Framework (WPF)-and the return of the Smart Client, it’s also clear that Microsoft sees the importance of Web-based applications and continues to provide tools to build rich applications for this platform.
Try as we might, rich client advances to date have had very little impact on how Web applications or distributed applications are run, at least for outward-facing applications. Even though it is now nearly as easy to create rich client applications that run inside the browser, the Web paradigm is still way, way more prominent than any rich client-distributed scenarios. Smart Client applications continue to be a hard sell when it comes to public content. With the coming of WPF and the XAML markup language, Microsoft surely is hoping to have a compelling platform to build rich client applications that can directly run in the browser like Web applications, by taking advantage of the super-rich presentation layer that WPF provides.
There’s no doubt that WPF has huge potential to provide this rich and powerful platform, but it’s by no means a foregone conclusion that it will take off for Web-style distributed applications. Imagine that you could build rich applications that take advantage of all that Windows has to offer, from rich rendering to advanced layout and databinding running native .NET code that you can actually debug. Wouldn’t that be nice? But I wouldn’t count on it becoming a mainstream reality anytime soon, as much as I would love to see it happen.
This smells very much of the Internet Explorer 4.0 model, where IE at the time was a much more compelling platform on which to build Web applications than most other browsers of the day. But even so, it never took off as a dedicated platform with Web developers and developers in general sticking to a more generic approach that worked across platforms. We shall see. I would love to be proven wrong by time. <g>
I think Microsoft comprehends the continued importance of pure Web development, and Atlas is a sign that this path will continue, even if it potentially has a negative impact on the adoption of WPF-based Web interfaces. Atlas squarely steps in the path of WPF, providing a model for building rich Web applications that can provide a more interactive user experience. Advances in the Web client platform have been in stagnation for quite some time, and hype or not, AJAX is injecting a new vibrancy and energy into the Web application platform. Even in its simplest form, AJAX style Web applications can provide a better user experience and more interactive applications at the cost of a more complex client/server model. Atlas promises to ride that wave into new territory and possibilities for Web applications, and hopefully, it will provide an easier way for ASP.NET developers to get there.
Time will tell, but it’s an interesting start.
