views:

52

answers:

4

Our business currently revolves around the development of a library, which can be used in a wide spectrum of industries (desktop, mobile, web and embedded). At the moment we only have customers within the desktop and web world and we already see that we are basically having to duplicate our code across multiple languages (c#, java and c++). How is this typically managed in other companies, do we really have to settle for having our middleware written in multiple languages to meet very different industries.

We have tried c# interop along with with java jni but the results where not as good as we had expected and it didn't seem like a good and professional solution.

Anyone have any ideas how we could keep the core in a single language but develop interfaces in different languages allowing for the different industries.

+1  A: 

I have not a lot of ideas when it comes to industry, but I guess that the problem is similar to other not-so-strict scenarios. It is unclear also what do you mean by "middleware". Anyway, I would souggest you to not duplicate code and effectively have, if needed, multiple interfaces to the other languages.

In an ideal scenario, it would be very convenient to have one isolated process with your application logic, written in whatever language you feel more comfortable, and have this process to communicate using some inter-process-communication mechanisms (e.g., pipes, sockets, shared memory, files) with thin client-libraries which could be use by the clients in the other languages. That way, you are forced to create a very clean communication/usage protocol and to have some separation of concerns (because all the communication has to be serialized); you gain in robustness (a fatal error in your application process or in your client does not necessarily means a crash in the other one) and you don't have to use ffi mechanisms, but rather things like sockets and pipes. Even more, if you decide to publish your comm. protocol, then third party developers can create wrappers in their exotic predilect language without need of direct linking/importing to your development components.

This kind of paradigm has been in use with success over the years in the unix world and softwares like Mathematica . In a similar move, the developers of java have made the java plugin to work out-of-browser, in a separated process, to reduce interop complexity.

dignor.sign
A: 

Pick common denominator standards: REST or SOAP/XML over HTTP can be consumed by a lot of languages, including both Java and C#.

You'll be saddled with heavyweight WS-* standards and lots of network latency, but if interoperability is your goal this is one way to achieve it.

duffymo
Sometimes there is no communication to a server, if this wasn't the case then we really wouldn't worry about this whole problem. Just creating a REST and SOAP interface for our customers. Sometimes our code sites on an embedded device and other times it is on an Apple laptop with a connection to a server and other times a fully client side application with again no connection to a server.
anonymouse
If there's no communication to a server, then there's no "middleware". If you have to run in a disconnected way you have no choice but to duplicate services in several languages.
duffymo
+1  A: 

Ah, I forgot, maybe you may use this: ICE (http://www.zeroc.com/overview.html). It is probably the lighter interop layer that you can use to communicate in a clean way java, c++, c#, python and a few others. They even have some embedding solution...

dignor.sign
@dignor You can edit your previous answer to add this
belisarius
ICE looks very cool, but "OP beware": like e.g. Qt used to be, it's dual-licensed, strict GPL or commercial. If you pick GPL you pay no money but you have to make your apps GPL-licensed too (open source, freely redistributable, etc); for the commercial license you'll have to negotiate with zeroc.com about "a license fee that is based on your organization's overall gross annual revenue of all products that use Ice" or other for-pay models -- before you commit to this cool-seeming approach, you'd better find out the costs involved!-)
Alex Martelli
A: 

Might take a look at the HAXE language. It "compiles" to a dozen other languages.

http://haxe.org/

Ian