Can I have a cross-platform cross-technology solution?

Question

Hi ,

We have an old application which has a FORTRAN API to be called from other applications. After some time they built a ( C ) wrapper for the FORTRAN API.Then I'm now building a c++ wrapper , with a little data handling , for the C API.

So I'm thinking what is the best way of building an API that can be called from any programming language.

Now I'm planning to bulde RPC server from my c++ API. Then any client using any programming language can call it.

I found that the XML-RPC is a good one. But it needs HTTP server for connection.

The problem is that the applications that call our API are desktop applications.And I found that XML-RPC can not manipulate complex objects.

Is SOAP a good solution? Can the client side be easily implemented?

So what is the best technical solution for my situation? Which technology should I use?

comment: I do not have a permission for changing the Fortran API and the C API. And I need the c++ API because I'm adding to it new methods , and enhancing the code so the user can call the methods easily.

Best Regards,

Answer 1

Any decent language has a foreign function API. Just call the Fortran functions directly. The compiler documentation will tell you how - calling Fortran in a shared library is very similar to calling C in a shared library, except different compliers may normalise the function names to lower case or not, or may add an underscore. Some FFIs may require some C wrapper code - Java for example - but many can just take a function name and parameter types and the name of the library to load.

Failing that, you can implement a streaming interface to the Fortran (read and write to standard output) and just pipe input to and from it - I've done that when quickly porting interactive ISPF Fortran applications to PC.

---

Since you want to expose the C++ API and extensions rather than the Fortran API, then look at SWIG, which automates the process for a variety of languages, as long as the C++ isn't too complicated.

Answer 2

SOAP, XML-RPC ect are normally used for computer to computer communication, is this what you want? Or is this all just running on one comuputer?

If it's just on one computer, just stick with C API, most systems can use that

If you model the C API as a REST style service, then you can also provide a HTTP service for applications that can't use the C API without, but only have one system to document

Answer 3

The best way is to leave it alone and just use the C API. virtually all programming languages can directly call a C API, so there's no reason to create wrappers unless a particular language's programming model makes more sense a different way.

To clarify what I mean, look at GTK+. It is a C API and is usable in virtually any language. Wrappers exist in object-oriented languages that provide a pure-OOP approach to the GTK+ API because it makes sense for those languages, given the domain of the API.

Does an objectified interface make sense for your application? If not, there is no reason to bother making a C++ wrapper.

As to RPC, why doesn't a simple message-passing interface with shared memory suffice?