Using Ruby or PHP with .NET

Question

Hi,

Currently we have a web application written in the providers own proprietary language / framework. Unfortunately, with it's limited syntax and "wonky" architecture its not great to work with.

With some really great development platforms out there (.NET, PHP, Ruby - note that I know nothing of PHP or Ruby but i've heard they are great :p) we would like to abstract away the web application from their data access code so that we can use anything we want to build the web application.

What I am proposing to them is that they give us a service layer written in a common development language that we can then use in our applications. Unfortunately for me (as a .net developer) I do not think they would choose to write this in c#.

So my question is this, what would one suggest the service layer be written in. Ideally it should be something that as a .net developer I will be able to pick up and even better the ability to use the service layer within .net or php applications (i've read a bit about Ruby.NET so believe this is possible?).

From my very quick glances at both Ruby on Rails and PHP I would say that Ruby appeals more to me (PHP seems a bit "scripty", but what do I know, I haven't used it).

Intestested to hear from developers who use both.

Thanks Ben

Answer 1

Why not use HTTP as your interface? Since they already have some sort of web infrastructure going, this should be easy - Describe the interface as a set of URLs that you can POST to and GET from. For this route, check the internet for all the articles on REST and RESTful architecture.

Then, take a step back. Don't let the zealots kill your spirit. Just make the interface work and don't worry too much about being pure REST (though the advice is generally sound).

This approach gives you quite a bit of flexibility in how you then write your web page.

This way, it doesn't really matter which language is used for the service layer: All you are interested in is the interface you use to access the service layer. Other options would be for them to provide a SOAP interface (with a little luck, can be easily consumed by .NET) or an XML-RPC interface (don't know about consuming that in .NET).

My point is this: You shouldn't be dictating the language the service layer is written in. You should be dictating the interface the service layer exposes - and then consuming that in the language of your choice.

Answer 2

Regarding the languages mentioned. PHP and Ruby are both interpreted "scripting languages", as for that matter, are Perl, Python and plenty of others. PHP is more tightly focused on web development whiel the others are intended for general-purpose computing.

There appears to be a PHP compiler for .Net, but it may not be under active development. The last news on the site is dated March 2008. I have no experience of this (and don't actually like PHP very much, TBH).

IronRuby is now at v1.0 RC2 and is actively under development by Microsoft. It works well and interacts happily with the .Net framework. Syntactically it's an implementation of Ruby 1.8.x and is compatible enough to be able to run the widely-used Ruby on Rails web framework, which is a fairly intensive test of a Ruby implementation's compliance. From a C# developer's perspective, metaprogramming and everything-really-is-an-object can take a while to sink in. I'd say it was worth it.

Asking your provider to write an interface in Ruby may not, however, be a great idea - doing it well and in a "Rubyish" style may be an investment they're not happy to make. Consuming something like a web API would be a very suitable purpose for Ruby, which I would expect to be slower to run than (say) C#, which wouldn't matter so much in a situation where factors such as network latency are likely to be major contributors to total elapsed time. I'd think there was a good chance that a Ruby app of this type might be cheaper and quicker to create and maintain.

Answer 3

Thank's for both your replies. A SOAP/REST api would certainly give us the flexibility we need and would not tie us down to one particular development platform. We have had talks of using an ESB solution like Sonic for another project so expect the vendor may leverage this to provide a SOAP api.