The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Working with RIA by jumping on the SOA/Web Services ship first

Check this out:

"Working with RIA by jumping on the SOA/Web Services ship first"

And I quote from it:

Lesson 1: Start with a good foundation

While San Dimas has a radically different UI from the eBay website, it is not something that has been built totally from scratch. eBay's web services platform has been in development since 1999, and San Dimas uses those web services exclusively to connect to eBay's backend systems. We've had to make zero changes to our web services thusfar to support San Dimas. If we had, it would have put the project schedule at serious risk (and believe me, there was enough risk already as it was).

If you are starting out developing an AIR application, I recommend that you consider an SOA or web services architecture - this will ensure you don't tie yourself too closely to one type of client, whether that be browser-based, desktop, or something else.

I've come to agree with this notion, as I leave pure GUI behind me, and am now adopting Ajax/Web services as my preferred platform. But once I get the platform right, I think I could use some targeted RIA applications as well, because they would build on the platform which is in place already, so it wouldn't take much effort on the server side.

If you were expecting to use RIA, did you have other expectations? Or maybe the way eBay and myself think of it will have a lot to do with what's planned for RIAs?

I mean, the ammunition for RIA seems to come from the server, and not from the client.
Joao Pedrosa
Wednesday, July 18, 2007
Nope, and it makes perfect sense.  When all of the business/validation/security is in the backend and out of the UI, it gives quite a bit more flexibility in which UI's you choose and implement... and simplifies them.
KC Send private email
Thursday, July 19, 2007
We probably need a new name for these rich desktop apps that happen to use web services in the back-end just to distinguish them from browser apps. This is a very cool architecture, but runs the risk of putting inappropriate logic on the client and winding right back up in the fat-client days we worked so hard to put behind us.
Stan James Send private email
Thursday, July 19, 2007
Howdy - thought I'd join the conversation here. I'm thinking of expanding on the SOA/Rich Desktop point that I made, and I'm curious if anyone else here has other examples I could research or any questions that they would like to see addresses in a more in-depth discussion.

Alan Lewis
Product Manager, eBay San Dimas
Alan Lewis Send private email
Thursday, July 19, 2007
I would not go crazy with Ajax and Web Service data delivery models. We have seen firewall issues and other things that sometimes short out that line of communication. There is news of hacks now that exploit AJAX and browser dependency on JavaScript and security settings which make it not always a reliable solution. Desktop compounds some of those issues with security software, corporate proxies, caching, hacked web servers, etc.

A good solid web service and data delivery model should reduce client-dependencies to as few as possible, and move more of the data delivery into native XML stored on the server and/or the client, batching data up to the server. There are ways to use non-soap, http posts to move data to the server that goes through some of these hurdles.
Saturday, July 21, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz