Language Agnostic API Generation

I am currently working on a design for a collection of subsystems, and I would like to be able to offer the API's exposed by a given subsystem for use by other subsystems.

In the past, I have used SWIG to expose C api's to a variety of other languages. This has worked well for me, but ultimately the API is defined in C. So basically one side of the API is language agnostic, and the other isn't.

What I would really like is to have something similar to SWIG that could generate the interface between 2 arbitrary languages based on some description of the API.

I don't want to use web services.

For example, I would like to call a 开发者_StackOverflow'function' from java, and implement the 'function' in Python. I'd like to be able to generate the language interop using a code generator.

Is there anything that exists which can do this today? At least for simple 'function' calls - ignoring the more complex cases like callbacks and situations where you need to maintain references outside of the 'function' call itself.

I found this after following gooli's link to Protocol Buffers .

This looks so compelling I'm going to propose it as an answer to my own question.

http://incubator.apache.org/thrift/

Thrift is a software framework for scalable cross-language services development. It combines a software stack with a code generation engine to build services that work efficiently and seamlessly between C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk, and OCaml.

From the whitepaper:

...we were presented with the challenge of building a transparent, high-performance bridge across many programming languages. We found that most available solutions were either too limited, did not offer sufficient datatype freedom, or suffered from subpar performance

Also from the whitepaper:

A. Similar Systems The following are software systems similar to Thrift. Each is (very!) briefly described:

• SOAP. XML-based. Designed for web services via HTTP, excessive XML parsing overhead.

• CORBA. Relatively comprehensive, debatably overdesigned and heavyweight. Comparably cumbersome software installation.

• COM. Embraced mainly in Windows client softare. Not an entirely open solution.

• Pillar. Lightweight and high-performance, but missing versioning and abstraction.

• Protocol Buffers. Closed-source, owned by Google. Described in Sawzall paper.

The last part about Protocol Buffer's is out-of-date - its been open sourced

COM (and to a lesser extent Firefox's XPCOM) might be what you are looking for. In COM, you define the API using a language called IDL which can then be compiled into different languages. When using the same language the calls usually degenerate into efficient function calls.

However, COM is a very complex and dying piece of technology that I would never use for a new project.