Feeds

Consume .NET services without Silverlight

Adobe Flex comes through

Providing a secure and efficient Helpdesk

Unfortunately my application failed with a fault message: "Security error accessing url". Running the application in debug mode got me a more explicit message: "Denied due to lack of policy file permissions". Although I was using a local web server, Flex considered it to be a different domain. I had to add a crossdomain.xml file to the web application explicitly giving permission for cross-domain use. Silverlight is equally cautious, but currently gives a less helpful 404 error if it cannot find a suitable policy file.

After that, everything worked. A few lines of code later, and my Flex app could also create and delete rows in SQL Server, via same WCF web service.

Building a CRUD app for Flex

Flex client, meet .NET service

In its online help, Adobe remarks that: "SOAP is often very verbose and heavy across the wire, which can result in higher client-side memory requirements and processing time."

It is likely true, and it would be interesting to test. Another concern is that large amounts of wrapper code can make debugging difficult, in the event of subtle SOAP compatibility issues. On the other hand, the ability to create Flex clients that seamlessly interoperate with existing .NET web services is a real advantage. Further, provided you don't peer too closely at the innards, Visual Studio does a good job of simplifying web service implementation.

What about Silverlight versus Flex? Silverlight 2 is in beta, and still lacks a visual designer unless you wheel out Expression Blend, whereas FlexBuilder has this built-in.

On the Silverlight side, using a WCF web service is a little easier, as you would expect from a single-vendor stack, and I suspect its performance is better. That said, and leaving aside the large amount of wrapper code, which Flex generated, the code in my simple client ended up similar in both.

Given that I was initially skeptical whether this would work at all, it is a good result for Adobe's client; it also suggests that for many projects either one will do.®

Secure remote control for conventional and virtual desktops

More from The Register

next story
Not appy with your Chromebook? Well now it can run Android apps
Google offers beta of tricky OS-inside-OS tech
New 'Cosmos' browser surfs the net by TXT alone
No data plan? No WiFi? No worries ... except sluggish download speed
Greater dev access to iOS 8 will put us AT RISK from HACKERS
Knocking holes in Apple's walled garden could backfire, says securo-chap
NHS grows a NoSQL backbone and rips out its Oracle Spine
Open source? In the government? Ha ha! What, wait ...?
Google extends app refund window to two hours
You now have 120 minutes to finish that game instead of 15
Intel: Hey, enterprises, drop everything and DO HADOOP
Big Data analytics projected to run on more servers than any other app
prev story

Whitepapers

Secure remote control for conventional and virtual desktops
Balancing user privacy and privileged access, in accordance with compliance frameworks and legislation. Evaluating any potential remote control choice.
Saudi Petroleum chooses Tegile storage solution
A storage solution that addresses company growth and performance for business-critical applications of caseware archive and search along with other key operational systems.
High Performance for All
While HPC is not new, it has traditionally been seen as a specialist area – is it now geared up to meet more mainstream requirements?
Security for virtualized datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.
Providing a secure and efficient Helpdesk
A single remote control platform for user support is be key to providing an efficient helpdesk. Retain full control over the way in which screen and keystroke data is transmitted.