When talking about RIA applications, we usually have the following physical architecture:
That is, we have the application actually running on the client’s machine, we access the host server in order to perform operations that cannot be made locally and we save to some persistent storage, usually an RDBMS.
We have two choices, server side and client side. On the server side, we would need to develop a real service layer. This is usually called if the RIA app is making use of services that will also be consumed elsewhere. It is an old, traditional, approach. It is also more costly than the alternative, assuming that we need the server side only to support the application itself, which is quite common.
In many cases, the application itself is the only reason for development, and in that case, spending time in the server side is probably a waste of our time for a lot of tasks. It is easier and cheaper to perform tasks completely on the client. And at that point, the server side functionality is limited to “let us just expose the data the application needed” . It is no longer a real independent piece, it has became merely a data transfer tier, with no additional responsibilities.
Note: you still may want to keep some minor validation logic on the server side, but that is about the extent of server side functionality in this case. Well, that and authorization :-)
RIA Services are supposed to make building that part in RIA applications as simple as possible, making the data transfer side (which we are usually almost totally unconcerned with) as simple and idiot proof as possible.
This is why this post it titled taking advantage of. If you are aware that your server side functionality isn’t important, you can deal with it in as brutal a manner as possible, because that is not where you want to spend your time. You want to spend you time actually doing something useful, and that is probably going to happen all on the client side.