ATLAS Web Service issues

November 06, 2005 @ 12:58 am

I've not had a lot of time recently to take a closer look at ATLAS, but today I went back and reviewed some of the functionality for some demos I had to set up. A couple of things come to mind that are immediately problematic at the lowest level, which is the Web Services Bridge.

The Web Services bridge may not be the sexiest piece of ATLAS, but it's the base for data retrieval and to me at least it provides an easy way to pull data from the server and work with the data. In fact, looking at a lot of the more advanced features it seems it's actually easier to struggle with the JavaScript yourself than let the ATLAS script code try to generate the right thing for you .

The Web Services Bridge provides the key data link for ATLAS based applications and allows accessing existing Web Service behavior via JSON based interface that is integrated into ATLAS. What's nice about this not-so new idea of using JSON in ATLAS is that it works both ways - you can push data to the client, manipulate and send it back in the same object format and the Web Service will in most cases recognize the passed back value. ATLAS provides the basic infrastructure to maintain the type information of the object which is pretty cool.

However, there are a number of issues that are problematic in order to use this in any sensible way at this time:

1. Web Service supports only property based objects

When returning objects, fields are serialized to the client just fine, but sending an object back up to the server will fail if there are any public Fields in the object definition.

2. Serialization Attributes are not respected

The WebService functionality via JSON also does not respect either [NonSerialized] or [XmlIgnore] attributes when exporting or importing resulting in problems with serialization of objects that have these attributes explicitly set to avoid generic constructor problems.

3. No exception handling

Currently there's no coherent exception handling. When an error occurs it spits back an HTML page. It sure would be nice if there was some way to marshal exceptions of some sort back to the client. SoapExceptions from the server certainly, regular exceptions for WebMethods attached to pages.

4. Object model for some complex objects is pretty non-intuitive

I was playing around with returning a DataTable to a client page directly and trying to access its functionality. While I would expect to get this documented in the future the current syntax of Table.getItem(0).getProperty('ProductName'); is kinda tedious especially since the JSON serialization appears to provide the proper naming and array structure. Wouldn't it be much easier to logical to create an array based object array that matches the structure of the table rather than an alternate definition that doesn't even match the DataTable interface in the first place?

For any sort of real work the Exception handling is a complete show stopper. The current way of returning HTML pages in response to errors is a big problem and this needs to be taken care of ASAP in my opinion. In order to do this I think the result from a remote call is going to have to include more than a single result value in order to convey both request status information and result information so that you can check when the callback returns whether an error occurred by checking an exception object or error flag etc.

This would mean instead of a straight result, you'd get a Result object, which has something like a Status object and a Value object, where the Value is actual result from the call.

Couple of more first impressions as I'm looking at this functionality and reading the message board:

The new script syntax seems pretty damn verbose to accomplish some relatively simple things. A lot of the syntax feels really non-intuitive as well as ATLAS is using some new syntax to describe the behaviors of controls. Noting some of hte messages on the forum you can see what kind of gyrations you often have to go through to accomplish a fairly simple task. It's a complex model to learn even when it ends up being just a few lines of code. The problem is that the syntax and names and behavioral is DIFFERENT than either server side markup, or client side markup, so now you're adding a a third (or fourth) set of syntax to your page layout. This is getting a little crazy. You're jumping back and forth between ASPX code layout, C# code on the server, ATLAS Client Script and JavaScript. Hello, does that strike anyone as one hell of a brain wonk? Too many freaking context switches here...

I realize that there's some definite benefit to this script abstraction, namely browser independence and managing of cumbersome display logic for browsers, but I think it's going to be real important that any new syntax that is used can address a wide variety of scenarios without breaking down, allows easily dropping down into code if necessary and is also easy to use. The latter is currently not the case. There are way too many moving parts at this point to keep straight and I'm not sure that designers are going to be able to fix that problem in the future.

Still I'm looking at ATLAS and I think there's a lot of potential there. I really hope we'll see another build soon that fixes some of the core problems so there's a bit more of a chance to do something real with this without breaking down right away... right now it's really nothing more than a very preliminary prototype.

Now playing: Die Toten Hosen - Was zählt

Feedback for this Weblog Entry

re: ATLAS Web Service issues
by Kevin Wright November 06, 2005 @ 5:42 am

Is AJAX any better for this sort of stuff than ATLAS in its current state?

Kevin

re: ATLAS Web Service issues
by Dennis Bailey November 06, 2005 @ 9:47 am

Rick,

I was looking at AJAX and Atlas myself for a project, then I found the following link on the MSDN site:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/lifewithoutrefresh.asp

This may not suite your application, but for me it solved most of the headaches that a new technology such as Atlas was trying to do.

Dennis

re: ATLAS Web Service issues
by Rick Strahl November 06, 2005 @ 9:54 pm

Kevin,

ATLAS in its current state is experimental at best. It's not anywhere near production quality - it's a prototype.

There are other AJAX solutions available including ScriptCallbacks in ASP.NET 2.0 now shipping (http://www.asptoday.com/Content.aspx?id=2381) or some free third party libraries, of which I've used and like Jason Diamond's MyAjax (http://jason.diamond.name/weblog/2005/10/29/my-ajax-dot-net-release-12) now called Anthem. Jason's library is very easy to work with lightweigtht and easy to add to your project and works with 1.1 to boot. Anthem apparently will change things a bit, but the pre Anthem releases have been wonderful in their simplicity and flexibility...

re: ATLAS Web Service issues
by Bertrand Le Roy November 07, 2005 @ 8:33 am

That's interesting feedback. 1 and 3 are already fixed.
I'll relay 2.
About 4, you've got to realize that the developer is not the target for this object model. The DataSource control is. The idea is that we need a generic data structure that has automatic change notification. A simple JavasScript object graph doesn't do that for you.
If you need a simple object graph, just return a complex type, not DataTable, from your web service.
The same thing stands for the verbosity of the markup. It's an argument we've heard a lot and we're definitely going to make that better. There are two reasons for that, though. First, we want Atlas markup to be easily manipulated by designer tools and generated by controls. XML markup is always orders of magnitude better than code for that, but sure, there are xml dialects that are more verbose than others. The second reason is a clean abstraction that keeps the HTML and logic cleanly separated.

I hope this helps.

re: ATLAS Web Service issues
by Rick Strahl November 07, 2005 @ 11:29 am

Bertrand,

I think focusing on the DataSource control model is a mistake. This is the kind of thing that really limits the possibibilities of what you can do and forces you into Access like programming model that will be insufficient for more complex applications especially those that are driven through business objects. This model is flawed, just like the ASP.NET 2.0 DataSource controls are flawed with their fixed interfaces that force you into a very particular (and not very OOP based) code model. It has never persisted although MS has provided this approach over and over again over the years (Access being the only one where it's persistent - but think of VB 4/5/6, now the DataSource Controls, and now also in WinForms roughly although that's a different and more capable design). In almost all those cases DataSource controls were shunned by all but the greenest of developers because of the complete lack of flexibility on how to serve the data and in many cases the performance implications.

I do think that some sort of script is probably the right approach but I think there needs to be easy hooks that still allow you to drop down into 'code' EASILY. The advantage of the script in my view is a unified control and script model that lets us avoid browser dependent code which is probably 75% of the nastiness of client side code. The rest is just plain JavaScript madness <g>...

re: ATLAS Web Service issues
by Bertrand Le Roy November 07, 2005 @ 12:03 pm

From our customer feedback, data source scenarios are important, which doesn't mean that we focus on them as the only way to get things done. That's why I told you to use something else than DataTable as the return value of your web method if you're not going to use a DataSource and prefer to use client-side code.
You have a choice here, and all Atlas abstractions are available from code.

re: ATLAS Web Service issues
by Rick Strahl November 07, 2005 @ 2:14 pm

I know you're supporting pure JavaScript, but what I meant is providing script based support that can also easily call back into JavaScript code.

What I would like to see is controls that you lay out with script code that cause the page to set up with the ATLAS style client side objects. Now you can have events on those script controls (say a button click) that points back at a native JavaScript function. Within that function then you can reference the dynamically created controls from the script which have the rich and browser independent ATLAS programming model.

Yes you still write JavaScript, but you can take advantage of the abstracted control interfaces and get the script markup for layout. This would seem like the best of both worlds.

I'm not opposed to the DataSource control as long as it's not the primary mechanism available to the script markup.

re: ATLAS Web Service issues
by cv February 16, 2006 @ 6:15 pm

cvb

re: ATLAS Web Service issues
by Wes Hinckes February 21, 2006 @ 5:35 am

I'm researching Ajax implementations for my organisation and have previous experience with working within and developing a similar application framework (frame based, javascript data objects and data object collections, JSON alike data transfer, objectToDatagrid() functions etc).

Due to this I'm drawn to your comment dated 11/7/2005 2:14 PM and would like to know if you have seen anything out there that is close to fulfilling this ideal?

DotNetSlackers: ATLAS Web Service issues
by DotNetSlackers Latest ASP.NET News October 15, 2006 @ 1:52 pm