as a follow up, I just figured this out. Right now, as a proof of concept we have 3 remote webservices I need to connect to. For these webservices we all have proxy classes.

Now, obviously I can’t expose properties (singletons) in the local webservice even through the proxy file (as a way of directly forwarding to the actual webservice). That means, I have to implement *every* method from our remote webservice in the local webservice and forward that (Invoke…).

Thats about 250 methods… Besides the fact that thats quite labour unfriendly, its also a massive volnerability (not sure I spelled that one right). This kind of solution really qualifies as a Single Point Of Failure… If anything changes in the remote webservice the local webservice fails horribly and the proxy classes have to be recreated…

Oh, and as far as the Captcha goes, I wish my site were on asp.net, but I’m using inferior unix technology and it’s the best plugin I could find.

-Peter Kellner

thanks for elaborating a bit more on this topic. I share your understanding, I too have heard that the Silverlight team is adressing this problem.

Right now, we’re working on a Silverlight app ourselves while (hopefully) maintaining the whole SOA structure. So basically, we want to make use of our webservices through our custom proxy classes (obviously, with the advantage of not having to use the serialized objects). For now, the only way to achieve this is indeed by creating a local (scriptable) webservice and instantiating the proxy classes from there. Somehow it doesn’t feel like a pretty solution.

ps. your captcha can be very hard to read (and when you get it wrong, pressing the back button loses the whole input field… retyping it can be a burden).

You’re right that I solved it by using a local webservice. I probably should have made that more clear. My understanding is that the Silverlight team is working on the x-domain problem and will likely have that solved by release of 1.1 but who knows.
-Peter Kellner

Very interesting read. Just a question though, when you say “Silverlight supports access to remote data feeds. This allows for interactive applications to be built that rely on external datasources seamlessly.”, are you talking about accessing remote webservices (or even rss feeds) directly or by using a local webservice (proxy). We’re working on this right now and are constantly running into the “cross domain issue”. From your words, I get the feeling you either solved it or found a workaround.

Keep me posted!

Cheers, Nathan