Atlas Architecture Overview

On the client, Atlas provides a set of scripts forming the Atlas Client Script Library consisting of the following:

• Browser Compat Layer - This is where we abstract out differences between browsers, so that higher level functionality doesn't have to have if... else... code all over the place, or is at the very least minimized. Today we support Atlas running on Safari and Firefox.
• Script Core - This is something that rightfully should have been part of JavaScript, but it isn't. It includes a set of type system patterns allowing you to use standard OOP constructs such as namespaces, classes, interfaces, inheritance, enumerations, delegates, and so on. The goal is to provide mechanism to encapsulate data, logic, behavior into classes much like you would in any other programming language, so as to enable a disciplined approach to scripting. In addition, we've added a number of more intuitive APIs to built in JavaScript objects to bring them closer to their .NET equivalents.
• Base Class Library - This was inspired by the BCL in the .NET Framework. It consists of useful types such as StringBuilder, Debug, Event, and IDisposable. In addition, it contains our abstraction over XMLHTTP via WebRequest, and WebResponse (much like their System.Net counterparts). On top of WebRequest, we've built MethodRequest which allow calling into WebMethods defined on .asmx, and .aspx files, or any server class for that matter. This layer also includes serialization - specifically, our JSON serializer, though the intent is to provide other forms of serialization. Finally this layer contains services such as Profile and Authentication that integrate with the corresponding functionality back on the server. All in all, this provides familiar APIs to script code, thereyby making it easier to develop and read/maintain.
• Component Model and UI Framework - This layer introduces the notion of components (types that can be self-describing of their object model). Components also participate in the dispose mechanism managed by a top-level Application class. Other features build on top of components and their OM descriptions. Specifically we have a parser for parsing script components persisted in declarative XML-script. Bindings allow wiring up components to transfer property values from one component to another (these bindings are "live" via change notifications). Actions allow performing work by calling into component methods in response to events raised by components. The UI framework features specific types of components: controls, behaviors, validators etc. Controls represent UI elements. Behaviors are a mechanism to attach additional semantics to existing controls (eg. Drag/drop). Validators, are like behaviors, but are meant to define validation rules associated with an input control.
• Controls and Components - We have an early set of built in components such as Timer, and Counter and controls such as the usual set of form controls, ListView, and a map control (based on Virtual Earth) thrown in for some sizzle.

On the server end, we built our Atlas framework bits on top of ASP.NET 2.0. It has three primary pieces to it:

• Server Control Framework - We have defined a new control ScriptManager that manages the set of scripts sent down to the client, as well as any XML-script markup generated by server controls. Server controls can start to participate in this processing by virtue of implementing IScriptComponent. In addition to this core framework, we have server-side representations of various client component model types, and controls.
• Web Services Bridge - This allows using both .asmx style and Indigo style .svc services to be used from client script (as well as WebMethods defined on .aspx pages, or any other referenceable type on the server dynamically registered as a Web service). In order to make it simple to do so, we automatically generate JavaScript proxies when the services are referenced via <script> tags. Secondly, we provide the necessary plumbing to process an incoming request with JSON-serialized parameter data, invoke the service method, and serialize the result using JSON to send back to the client script.
• Application Services Bridge - We use the web services bridge to expose a few of the key ASP.NET application services. Specifically, we currently allow you to authenticate users (using the membership service), and to retrieve and update user data (using the profile service).

I'll talk about our client services piece in the future. For now, I'll just say, its designed to be a mechanism to safely expose mechanisms for client script to integrate well with desktop functionality and other applications on the client.

Over time, we intend to add a number of features, enhancements, and of course address feedback we get from you on top of this core architecture we have put in place. I'll be delving into details over time as well. What are the areas that interest you?