http://code.google.com/p/flexserverlib/

But taking your point into consideration, I’ll put a note about that in the overview section in the beginning of every post.

What line is missing from the employee_list.xml, as the xml entities were stripped out from your comment. You can email me here (brianr@webappsolution.com) so I can fix it, or use the Entitiy Encoder (http://www.dan.co.jp/cases/javascript/encode_entities.html) to make sure they are shown correctly inside of <pre><code>…</code></pre> tags.

Generally your tute is very helpful, especially considering the scarcity of resources out there on SAS, but due to the truncated source samples in your page it’s virtually impossible to follow without using your downloaded source. I feel like I’ve got more of a grasp if I can do it all myself with copy/paste from the website… but I guess that’s personal preference.

@Derek The idea is that it allows both the server-side and client-side devs to start working concurrently once they’ve established a well-defined service API — honestly, we’d never really create a AS Mock-Object (”ASMO”) BD and a stubbed out XML BD, that was really for example purposes only.

The real power is when you’re using RemoteObjects (”RO”) and you want to swap out your ASMO BDs with your real RO BDs and know that they’re going to return the same object type to your CMD no matter what the service is.

A key point to understand and establish is that our BDs are really the only place with server knowledge — BDs should be the only class in our client that have intimate knowledge of the services/server, and therefore is the only place where data marshaling and/or de/serialization takes place so that our CMDs can just say, I always expect this type of object from my BD no matter what. We don’t want a change in our end service provider to cascade through our app b/c we’re changing from AS stubs to XML services to real RO services — the end data model returned to the CMD should always be the same.

Now if the end service API changes b/c you need to modify your interface, then sure, you might have to chg the data in couple places in your client…but if not and you nail down an API in your design phase, then the only object that really knows about the different request and response types for your services is your BDs.

Another real powerful feature of SAS that I haven’t introduced yet is the ability to inject the config properties for ROs and HTTPServices like the url, destination, enpoints, etc…that’s the next post which I’ll have up this wk. I think it’ll all start to make a bit more sense once I add more to the tutorial.