Conectando linguagens (Java, C/C++, PHP, Ruby, Python, Cobol, VB, ASP, etc)

Sei sobre a polêmica que gera o assunto, mas é algo que muito me interessa no desenvolvimento de um grande projeto,
sempre vi vantagens e desvantagens em várias linguagens de programação,
em um grande projeto temos profissionais com bons conhecimentos em PHP, Java, C++, Ruby, Python, etc,
posso separar o projeto em camadas como GUI, Negócios, Funcional, Utilitária, etc,
enfim sempre me pareceu tentador, utilizar as linguagens que me oferecem as melhores vantagens em cada parte de um projeto.

[size=18]Quais seriam as melhores soluções para desenvolvimento de projetos híbridos, interfaceando as linguagens?[/size]

[quote=DavidUser]Sei sobre a polêmica que gera o assunto, mas é algo que muito me interessa no desenvolvimento de um grande projeto,
sempre vi vantagens e desvantagens em várias linguagens de programação,
em um grande projeto temos profissionais com bons conhecimentos em PHP, Java, C++, Ruby, Python, etc,
posso separar o projeto em camadas como GUI, Negócios, Funcional, Utilitária, etc,
enfim sempre me pareceu tentador, utilizar as linguagens que me oferecem as melhores vantagens em cada parte de um projeto.

[size=18]Quais seriam as melhores soluções para desenvolvimento de projetos híbridos, interfaceando as linguagens?[/size][/quote]
Bom, se você tiver interessado só nas linguagens em si, você poderia usar uma plataforma que tem implementação de várias dessas linguagens, Java, por exemplo, tem o JRuby e o Jython.

Acho que utilizar 5 linguagens em um único projeto é inviável, acho que você deveria manter um número razoável tipo 2-3. Senão vai ser difícil de contratar e manter, por mais que você tenha caras que saibam todas essas linguagens, todos eles dominam todas elas? Qual a necessidade disso? Que ganhos você terá?

Qual o VALOR disso? [kicolobo, 2012]

Se você quiser projetos que se interligam é só você utilizar alguma tecnologia para integração, como web services.

Sobre a “interligação” eu diria WebServices sem dúvida, um server com webservices(REST?) com toda a regra de negócio retornando JSON, e os clientes em suas melhores linguagens e plataformas!

A linguagem mais “onipresente” em plataformas e interfaces com linguagens é o C-ANSI (não o C++).
O jeito mais facil de integrar tudo é usando ela.

A partir do java, você usa o JNI (ou JNA) para acesso de código nativo ©.

Com Python, ruby, PHP, você deve criar bibliotecas (so, dll ou dylib) de extensão. (procure no google por “ruby extension” no google e veja um exemplo.

Já o COBOL também gera código nativo também, e fica acessível ao C se você criar um “header” para a library COBOL.

Usar Webservices também é uma boa idéia, mas aí cada chamada de “método” vai ter um custo MONSTRUOSO em performance, e deve demorar 1milisegundo até 1 segundo cada chamada!

Eu acredito que Lua[1] seja útil para o que você precisa, um dos princípios da linguagem é justamente servi como linguagem de cola.

Você pode dá uma olhada também no Swig[2].

[1] http://www.lua.org/portugues.html
[2] http://www.swig.org/

[],

+1, nesse caso eu iria de webservices sem sombra de dúvidas.

Boa tarde…

Sem sacanagem…depende!!!

Depende se todos os sistemas estão na mesma rede ou não, depende da necessidade de sincronismo entre as aplicações, depende da necessidade de todas as transações compartilharem o mesmo contexto transacional.

Acho legal evoluir o tópico com as características dos sistemas a serem integrados e com a característica as integrações…

Att,

Quanto menos Frankenstein for seu sistema, melhor.

++
Já vi um sistema que era desenvolvido em várias linguagens e era horrível de manter. Isso porque começa a aparecer muita coisa bizarra, como problemas de vazamento de memória, que são uma praga para resolver.

vai usar perl so para fazer um ER?

só consigo ver necessidade dessa conexão se for integração com aplicações legadas.

muito problema pra debugar…

webservices (1 linguagem só)

e os clientes ai tanto faz…

A JVM do Java 7 possui capacidade de executar múltiplas linguagens, mas como disseram, não adianta utilizar muitas porque você certamente terá problemas para interoperá-las desde conseguir manter o mapa do técnico do projeto, fazer debugs e até mesmo desempenho quando a linguagem não for fortemente tipada.

Me lembro de ter abandonado o .Net porque ele oferecia na época suporte a linguagens compiladas como Visual Basic, C#, C++, J# e Asp.Net mas o resultado da compilação gerava um formato apenas denominado assembly para ser executado pela CLR (Common Language Runtime).

Isso foi em 2002, tinha terminado um curso de C#, mas pensei que não tinha sentido aprender C# se o Visual Basic resultava praticamente no mesmo e o CLR era apenas para Windows. Mas do ponto de vista de convergência, a Microsoft fez certo porque permitia uma rápida migração de programadores de muitas linguagens para o .Net.

Acredito que a JVM hoje se assemelha ao CLR do .Net, mas a comparação termina aqui porque Java é portável e JVM é para bytecodes Java aproveitada em relação a sua evoluída engenharia para suportar outras linguagens que realmente merecem promoção (JRuby, Scala, Clojure entre outras).

wiliamps

Conectar várias linguagens é sempre um desafio.

Ao meu ver não existe bala de prata. WebService(SOAP) e REST são mais comuns, mas não significa que resolve todos os problemas.

Trabalho em um projeto que interliga linguagens de várias plataformas distintas. Em casos como esse é importante lembrar da questão de desempenho da aplicação, relacionado à necessidade de negócio.

Dessa forma é adequado vc informar mais detalhar dos requisitos não funcionais da sua aplicação e para cada caso a comunidade poderá apresentar suas sugestões.

Com certeza para uma solução com muitas linguagens e plataformas distintas uma única solução não vai atender todas as necessidades. Podem falar em barramento de serviços, por exemplo, mas mesmo o barramento de impactos em desempenho, por exemplo, além de outras questões que devem ser levadas em conta como custo de solução (que nem sempre é $$$), conhecimento da equipe, facilidade de manutenção, necessidade ou não de contexto transacional unificado, e até mesmo avaliação de custo benefício de acoplar mais ou menos a solução.

O mundo real nem sempre é igual ao mundo teórico, principalmente pelas restrições de projeto.