Microservices Matters

Feb 16 2009   5:05PM GMT

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

Jack Vaughan Jack Vaughan Profile: Jack Vaughan

By Yuval Shavit, Associate Editor, SearchWinDevelopment.com
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.

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: