Integrating Perl into language independent networked applications

[fx]

I'm writing a middleware app in Perl. My basic requirements are:

- language independent
- network based

It looks like it will initially be deployed with a Java application at the frontend and probably something in C/C++ at the backend - all of which are on different machines on the same network.

What I obviously need to do is have the Java client call subroutines and get return calues from the Perl code which in turn will call functions and get return codes from the C/C++ code. And as the languages around the middleware app will probably change with time, installation or environment, I need something pretty much standard.

I have briefly looked at CORBA and found some results from searching Perlmonks.

Is CORBA a good choice? I seem to recall reading something somewhere a while back that said its popularity is decreasing.

Is there some form of platform/language independent RMI-ish implementation?

Could anyone offer some other suggestions?

[Fletch]

See SOAP::Lite and RPC::XML::Server.

[Tomte]

I second that; from my own experience: for easy integration from the java-side use SOAP; I guess the C/C++ side will have a useable SOAP implementation too. Besides SOAP::Lite are a whole bunch of modules on CPAN waiting to ease your pain in implementing the middleware.

SOAP has a bit more to offer compared against XMP::RPC, is nevertheless easy to handle and as good a standard as any other xml-based standard I've seen ;).

[flyingmoose]

Except SOAP is a bloated designed-by-commitee implementation that has a lot of features you probably don't need :)

My suggestion is keep it simple! XML-RPC with a single-parameter to each function, that being an XML serialized object (or equivalent) will be much easier to process and read.

And don't forget to encrypt the stream!

[dragonchild]

Use Apache. Everyone knows how to craft an HTML request. Everyone knows how to read an HTML response. You can even have the responses be XML, binary ... whatever.

Plus, Apache allows you to use create your own HTTP commands. So, if you don't like GET, POST, and HEAD, you can add FOO and BAR. (There's an example in the Apache2 docs for adding EMAIL.) So, you can craft your own language of HTTP messages.

Oh - avoid Tuxedo. It sucks rocks ... and does that badly, too.

[thospel]

If you want a standard protocol with less overhead, fastCGI might be a good choice (purely as protocol between your client and your server, without a webserver involved)