News Stay informed about the latest enterprise technology news and product updates.

Moonlight and RIA client-server protocols: drop the SOAP, you are under a REST

By Yuval Shavit, Associate Editor,
With the release of Moonlight 1.0 last week, I had the opportunity to speak with Novell’s Miguel de Icaza about OS interoperability as it relates to RIAs. Moonlight is the Linux port to Microsoft’s RIA platform, Silverlight.

One of Silverlight’s advantages over Flash is that it includes a subset of .NET, including WCF for easy communication with the servers that do the real work behind RIA widgets. When Silverlight was a Windows-only platform, interoperability wasn’t an issue; companies that wrote Silverlight apps probably had Windows servers, so the client and server ran the same platform.

But Moonlight brings Linux into the fold on the client side, and that raises the question of interoperability. For now, the question is largely one-directional: how can developers design Silverlight apps that run on Linux but talk to Windows servers? But if Silverlight comes to compete broadly with Flash as a platform, companies may start having to worry about Windows clients talking to Linux servers, too.

De Icaza suggested that one solution may be to just drop WCF, which uses SOAP. Although there’s certainly an architectural appeal to creating more cohesive communication between clients and servers, de Icaza said, he’s seen a general movement back to the simpler REST protocol. [Ed note: Microsoft offers a REST kit for WCF – but SOAP is the more common use. WCF with REST loses an important WCF characteristic: strong types.]

But de Icaza was careful to add a disclaimer: his work doesn’t focus around enterprise applications. In those tightly controlled environments, using WCF and SOAP still makes sense, he said.

Of course, SOA is all about the enterprise, so that’s a pretty big disclaimer for any architect working behind a corporate firewall. But data from many services within an enterprise eventually finds its way to the user in one form or another, and maintaining two protocols — one for internal communication and the other for external publishing — defeats one of SOA’s main objectives: modularity and reusability of services. What happens if that tax calculation service needs to communicate with a RIA shopping cart next year, for instance?

The saying goes that if you live on the cutting edge, you risk getting cut. SOA architects should keep a careful eye on RIAs, lest they have to re-architect their brand new systems.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.