Domande per l'architettura con Ruby e Java [chiuso]

JRuby è abbastanza maturo ora, ha prestazioni migliori rispetto al runtime ufficiale di Ruby (se scegli come target Ruby 1.8.x ; il ramo 1.9.x ha imposto molto, e rende le differenze di prestazioni tra i 2 meno rilevanti), e ti dà un accesso molto facile alle librerie Java.

Inoltre, se vuoi impacchettare i file WAR, suppongo che non sarebbe un problema utilizzare un contenitore / server abilitato a Java.

Quindi ti consiglio vivamente di dare un'occhiata più da vicino a JRuby.

E no, JRuby non "ha una JVM". Esegue in cima a una JVM . Quindi puoi sviluppare tutto il tuo progetto in JRuby, se lo desideri (o anche cifrarlo con Ruby e poi chiamare il tuo codice usando JRuby, anche se potresti incontrare alcune sorprese quindi ti consiglio di usare JRuby dall'inizio) e basta usare il Classi Java ogni volta che è necessario.

È abbastanza ben integrato, ha una comunità vivace e amichevole e produce aggiornamenti regolari all'implementazione.

Per quanto riguarda l'ambiente di costruzione, se usi JRuby sarai in grado di chiamare il compilatore da Ant facilmente (come qualsiasi altra cosa, davvero), quindi non sarebbe un problema. Potrebbero esserci anche alcune attività personalizzate già implementate, non conosco lo stato delle cose in quest'area.

Aneddoti su esperienze personali e altro: ho usato JRuby molto per implementare l'imbroglio di test automatizzato qualche anno fa (principalmente intorno al 2007) e non era nemmeno così maturo all'epoca, eppure era già a mio parere un'alternativa molto migliore rispetto all'implementazione ufficiale di Ruby. Inoltre è stato fantastico nel mio caso funzionare sulla JVM perché potevo anche usarlo per testare le classi Java. E sta migliorando costantemente nel tempo.

Il suo unico svantaggio è che, se lo si utilizza per sviluppare piccoli programmi o strumenti standalone, è necessario pacchettizzare la soluzione con una JVM o farla installare dall'utente, e che per i programmi di breve durata il costo di accensione una JVM (specialmente le versioni più vecchie, ora è abbastanza buona) potrebbe essere un trascinamento.

A parte questo, è stata un'ottima soluzione e scrivo ancora script su di esso occasionalmente.

Ho lavorato su un sistema con un lato applicazione Java di grandi dimensioni e un lato Ruby di grandi dimensioni (sia un sito Web Rails che JSON API). Prestare attenzione ai problemi di compatibilità che possono verificarsi quando si conservano due copie di modelli di dominio scritti in due lingue diverse. È necessario pianificare attentamente i rilasci di produzione in modo che un'applicazione non presenti dati nel database che l'altra applicazione riscontra problemi. Quello che stai proponendo è la distribuzione dei tuoi oggetti. Sempre più mi piace ascoltare il consiglio di Martin Fowler qui:

The first rule of distributing your objects is don't distribute your objects!

Fonte: Microservizi e la prima legge degli oggetti distribuiti

Se hai bisogno di una serie di servizi web, devi chiederti "Perché?"

Se hai bisogno di supportare sia le piattaforme mobili web e native, allora potresti avere un caso d'uso per fare ciò che stai proponendo. Se si desidera creare servizi Web perché è necessario utilizzare Java, ma si desidera veramente utilizzare Ruby, si aggiungono livelli di complessità e manutenzione per la comodità di Ruby. Per esperienza personale, non ne vale la pena.

Altro sull'avversione di Fowler per "oggetti distribuiti":

My objection to the notion of distributed objects was although you can encapsulate many things behind object boundaries, you can't encapsulate the remote/in-process distinction. An in-process function call is fast and always succeeds (in that any exceptions are due to the application, not due to the mere fact of making the call). Remote calls, however, are orders of magnitude slower, and there's always a chance that the call will fail due to a failure in the remote process or the connection.

Da un punto di vista dell'architettura, mi piace separare completamente i due livelli, attraverso un livello di comunicazione (servizi web, servizi di riposo ...), come un'architettura SOA standard.

Da quanto ho capito, hai:

• Frontend (Presentation Tier) che intendi realizzare in Ruby
• Backend (Business Tier) che devi implementare in Java

Potresti voler realizzare artefatti separati, in modo che tu possa raggiungere una scala più grande (ad es .: diversi server per Presentation e Business Tier), e puoi separare l'implementazione della business logic al rendering.