Fog Creek Software
Discussion Board




Which technology for RPC through the Net?

Hi,

I'm currently looking at the different solutions available to move to a multi-tier architecture, and would like some opinions on the good technologies currently available to make that code accessible to our customers over the Net (ie. unknown latency, security risks.)

As a newbie, I've heard of XML-RPC, SOAP, DCOM (non .Net env't), Remoting (.Net), and Corba.

Are there others I should know about? Ideally, it should be easy on a VB developer (ie. should not require learning a new and difficult language if the code on the server needs to be rewritten.)

Thx much

Frederic Fauer
Monday, January 20, 2003

Either DCOM and .Net involves a lot of licensing fees (because you have to own either Visual Basic 6.0 or VB.NET 1.0) so use the one you can afford. If you can afford to upgrade you might save sometime using .NET, but really depends on your requirements. Tell us more!

Li-fan Chen
Monday, January 20, 2003

Technically neither DCOM or .NET *require* any licence fees beyond owning the OS.

You can write .NET code with just the freely download able SDK.  You might not get the nice (?) GUI of VS.Net but it will produce the same code.

To be more helpful: why are you looking to move to a multi-tier environment?  Answering that question would help you decide which RPC technology to use rather than making a pure technology decision.

Probably the easiest to get up to speed on would be .NET remoting or maybe SOAP using one of the toolkits if you don't want to make the jump from VB6 to VB.Net.

(.NET remoting as a technology can use different formatters between end points, one of which is SOAP under the hood).

Just another dude
Monday, January 20, 2003

Thx guys... but I'd rather avoid going .Net right now, and SOAP seems more complicated than XML-RPC. And Corba seems even more of a pain. Are there other ways that I should know about?

However, I'm a bit concerned about performance since a call to a routine on a web server through XML-RPC should be pretty slow. Are there JIT compilers for PHP, or some caching software to avoid reinterpreting the code every time a routine is called?

And if someone has a working VB5 client + PHP server sample, I'm interested :-D

Thx

Frederic Faure
Tuesday, January 21, 2003

PHP has some caching technology available for it. Zend technologies, home of the guys who wrote PHP, has a product called the Zend Performance Suite. It compiles your PHP code (which gives faster execution times, since your script doesn't have to be parsed every time it is run) and caches database results for whatever interval you specify. They claim a performance increase of 25x (though I've never used it, so I can't vouch for that). You can read more at http://www.zend.com .

Benji Smith
Tuesday, January 21, 2003

....Of course, I'm not sure what PHP has to do with RPC....

Benji Smith
Tuesday, January 21, 2003

Hey I went and checked out some licensing information and just want to retract what I said about the fees. But yeah you gotta pay for the OS tax as long as you're with Windows. REalistically most of us will be shelling out for a productivity tool like Visual Studio .Net though so don't discount that cost out of your balance sheet.

Li-fan Chen
Tuesday, January 21, 2003

Well RPC is a tool and so is PHP. In the end how you fit these modules into a solution really depends on the problem. You can have a fast solution with caching and ahead of time script compilation, and you can do the same with RPC calls over balanced servers accessing a common DB-backend farm. There are more than one way to skin this cat.

Li-fan Chen
Tuesday, January 21, 2003

"Ugh, holy hacking batman. The more XMLRPC gets put to the test, the more is shows just how weak it really is."

http://radio.weblogs.com/0104813/2003/01/13.html#a204

Just me (Sir to you)
Tuesday, January 21, 2003

I would replace CORBA with java/RMI in your list, maybe it's worth a look.

Starting from scratch, I would go to .NET, because it's really easy to use.

Ralph Chaléon
Tuesday, January 21, 2003

Frederick,

Since you are talking about "customers over the Net", make it easy on yourself and disqualify anything not HTTP based. It will not work "in the wild".

If you feel like it I would also be interested as to why you reject .Net for the server, coupeled as suggested with a VB client (with some SOAP toolkit). Seems like such a natural choice for your VB dev. team.

Just me (Sir to you)
Tuesday, January 21, 2003

Thx everyone. I'll take a look at Zend and other solutions to improve performance. I'll also take a look at Java/RMI.

As for rejecting .Net, it's because I prefer to use open-source and light solutions over bloated and proprietary solutions. I keep an eye on DotGNU and Mono, though.

Thx again.

Frederic Faure
Wednesday, January 22, 2003

As you stated:

"Ideally, it should be easy on a VB developer (ie. should not require learning a new and difficult language if the code on the server needs to be rewritten.)"

I think your decision to go with Zend optimised PHP or Java/RMI is one of almost Dilbertian excellence.

"As for rejecting .Net, it's because I prefer to use open-source and light solutions over bloated and proprietary solutions."

Always a pleasure to meet an open mind.

Just me (Sir to you)
Wednesday, January 22, 2003

*  Recent Topics

*  Fog Creek Home