My previous post describes the overall problem of communicating with services from Silverlight. Let's now concentrate on one specific but very important part of it: "basic back-end services" (and by the way, if you can think of a better name for this please let me know :)
What I mean by "basic back-end services" is services that you write specifically for your Silverlight app.
Let's take an example: Suppose you want to create an interactive shopping application (something like this or even this). Your users will search for products, add them to a shopping cart, enter payment information, and so on. Clearly some information needs to flow between the browser and the back-end server for this to work.
Traditionally (in the pre-AJAX world) if you wanted to do this on the Microsoft platform, you would create a bunch of .aspx pages in ASP.NET that would communicate with the server using postbacks. When a user entered a search string and hit "Search", it would generate a POST to the server, which would then respond with a newly-generated page.
Again, if we look at the Microsoft platform, ASP.NET AJAX makes this very easy with the UpdatePanel control: you don't need to write any code and you don't have to even know that these back-end services are there - you can think of them as being created automatically for you.
Notice that these back-end methods are very specific to your particular application - they are normally written specifically for this purpose and not reused for anything else. This is exactly the basic back-end services that this post is about. The opposite of this case is the interoperability problem - talking to services that have already been established for purposes other than your specific application and that you cannot change - but I will cover that separately.
In 1.1, you will be able to call services directly from .NET code in your Silverlight application. I will explain how in the next post.