Newsgroup: it.lavoro.informatica
Titolo: The Future of Java in the Enterprise - InfoQ’s Opinion

https://goo.gl/6JKYk9
 
 
Considerato che, secondo InfoQ, "Java remains a great choice for 
building large-scale enterprise applications, particularly where they 
are expected to remain in production for some time", e` interessante 
notare come l'hype attorno si linguaggi JVM alternativi (Scala e Clojure 
in primis) si sia ridimensionato. Interessante anche il declino di 
JavaEE a favore di soluzioni piu` "snelle" e orientamento ai microservices.
 
-- 
4ndre4


allora mi provochi?!?!
si sono accorti che java è un linguaggio di merda?
Incredibile , l'ho sempre detto...e pensa per te che casino mentale 
quando ti verranno a dire, prima di andare su marte, che alla fine , 
tutto sommato, è meglio se ti impari il COBOL, tu lo sai , la storia è 
fatta di cicli e ricicli. Cicla di qua e cicla di la e alla fine cosa 
resterà? Linux, il c, il cobol...e l'intramontabile assembler.....
 
AH AH AH AH AH AH AH ....spero di avertI perso di vista per quella 
data...AH AH AH AH AH AH AH AH
 
-- 
Ripristinare il trattato di Vienna è imperativo!
W IL LOMBARDO-VENETO.
W LA LIBERTA'.
ONORE E GLORIA A S.M. CARLO D'ASBURGO-LORENA!!!


"In terms of alternative JVM languages we continue to see interest in both Scala and Clojure, but reader interest in Scala suggests the language may have reached an adoption peak;"
Non parlerei di hype, comunque.
 
  ngw

 Non parlerei di hype, comunque.
 
Almeno fino a 4/5 anni fa, Scala veniva promosso da piu` parti come un replacement di Java nel breve periodo. Se ne e` parlato molto ma mi sembra oggi sia usato da pochissimi, ed e` anch'esso abbastanza vecchiotto come linguaggio. 
 
Da quel che scrivono: 
 
"we can trace a small drop in Scala interest amongst readers around the time Java 8 shipped with support for lambda functions. Our instinct on this is that it hasn’t yet “crossed the chasm” in Moore’s parlance, and therefore still sits in the early adopter stage. We don’t currently believe it will reach majority status." [...] Clojure continues to do well, and its data-oriented design places it in a strong position as an alternative to Python in the Data Science world, but again it doesn’t feel like a language likely to see mass adoption."
 
...traspare che l'interesse su quei linguaggi sembra aver raggiunto apici destinati a calare, anche per via delle nuove funzionalita` di Java 9 e 10 che arriveranno presto.
 
Sara` interessante vedere in che modo l'utilizzo di Java evolvera` nel campo dei microservices.

 campo dei microservices.
 
c'è il solito spring, what else?

 c'è il solito spring, what else?
 
Oltre a Spring Boot, ci sono diversi progetti come Wildfly Swarm, TomEE, Payara, Websphere Liberty, e l'iniziativa MicroProfile sembra interessante. 
 

 programming. 
 
Perche` fuffa?


ho sempre avuto la percezione che la jvm sia perfetta per progetti 
monolitici; con l'avvento dei container in uno scenario di microservices 
perde gran parte dei vantaggi e pessimizza le risorse. 

 perde gran parte dei vantaggi e pessimizza le risorse.
 
Tutto da vedere. L'ultimo progetto su cui ho lavorato era basato su cluster Hazelcast di nodi Spring Boot/Tomcat, RESTful con backend NoSQL. Era distribuito e facilmente scalabile. Problemi con una base di 2.5K utenti non ce n'erano. Devo dire che non abbiamo mai implementato dei microservices nello specifico, ma solo per scelta architetturale, non per impossibilita` tecniche.
 


non parlo di impossibilità tecniche, peraltro con docker e swarm 
praticamente qualsiasi cosa è scalabile a piacimento. dico che quando hai 
un applicativo monolitico la jvm ti da dei vantaggi (ottimizzazione 
risorse, thread pooling, memoria condivisa, etc..) che perdi nel momento 
in cui lo suddividi in microservizi. 

E perché lo perderesti?

 E perché lo perderesti?
 
perchè, ovviamente, i servizi girerebbero su jvm distinte...
 

 perchè, ovviamente, i servizi girerebbero su jvm distinte...
 
Non mi convince. Ogni servizio godrebbe degli stessi vantaggi.
 


il vantaggio di ottimizzazione lo perdi. ciascun servizio avrà la sua vm, 
con il suo footprint oggettivamente esoso specie se si parla dello stack 
di spring.


https://www.youtube.com/watch?v=i-r9bU3y3Y0&list=PLxU9yM-_yPs9j21E_xHMzaR4EGcCiKssC
 
 
microprofile su docker viene dato a 60 mb, non direi esoso per le 
risorse di oggi.
 
Inoltre molti AS vengono fatti partire con l'opzione -Xms, ma se vai a 
vedere con jconsole e' tutta memoria allocata per niente (per 
ottimizzare la gestione della memoria a dire il vero). Per cui anche 
wildfly, eccetera, secondo me puoi farli partire con meno (specie il web 
profile).
 
Poi se consideri che le ottimizzazioni e performance che ottieni con il 
jit e gc della jvm non so quante piattaforme le implementino, direi che 
il trend microservice non e' sufficiente per farle perdere mercato.
 
Che poi molto ci sarebbe da dire sulla reale necessita' di adottare 
quella architettura...


Da leggere anche il primo commento di Reza Rahman, ex di Oracle e 
fondatore di  JEE Guardian. Per chi non lo conoscesse, e' 
sostanzialmente contrario al trend sui microservice.
 
 


 
Va be,java sarà un linguaggio di merda (parole tue) ma passare al COBOL
Come passare da una utilitaria ad una carrozza trainata da cavalli.
Meglio passare ad una Ferrari.
 


bhe! dai non esagerare! la verità è che piu ad alto livello del cobol 
non c'è niente, forse solo il PL/I che è proprietario. Purtroppo nessuno 
vi ha mai spiegato il cobol e la sua essenza, anche perchè 
all'università non esitevano docenti capaci e competenti , forse perchè 
bisognava rubarli all'industria e l'industria non è mai stata disposta a 
farseli rubare quei docenti.
Se c'è un linguaggio che è IMPOSSIBILE da bucare è proprio il cobol e 
proprio a causa della sua struttura.
Riassumendo, con l'assembler (ti ricordo che anche linux ha bisogno di 
100 istruzioni assembler), il c e col cobol(aggiungerei anche il lisp, 
ma è un capitolo a se) copri a 360 gradi tutto lo scibile della 
ingegneria del processo dei dai. Già i dati questi sconosciuti sommersi 
da milionate di algoritmi, scritti da bamboccioni incompetenti, per il 
90% inutili(gli algoritmi non i bamboccioni ne tantomeno le bamboccine )!



Ho letto le prime parole,alto livello e mi fermo qui.
PS. ti ho gia spiegato un sacco di volte che il COBOL lo conosco 
benissimo come conosco un'altra decina di linguaggi.
E proprio per questo alla parola alto livello mi fermo li.
Il COBOL poteva essere di alto livello negli anni 60,oggi e' solo un 
dinosauro.
 
 

 Meglio passare ad una Ferrari.
 
non so ancora bene cosa, ma voi due nascondete qualcosa.
e non è da oggi che lo penso.


va bhe! rispetto la tua opinione, ma un giorno mi darai ragione!
 
P.S.
speriamo che 4ndre4 adesso non venga qui a scatenare il finimondo, 
speriamo resti a rompere il cazzo su delphi!


 di spring.
 
Se hai una struttura distribuita e` chiaro che vi sia un minimo di ridondanza delle risorse. Ma i vantaggi sono quelli, appunto, di un'elaborazione distribuita. 
 

On Tuesday, 28 February 2017 06:37:57 UTC, rootkit  wrote:
 
[...]
Ma ancora scrivono, quei due idioti? Madonna che noia.

 sostanzialmente contrario al trend sui microservice.
 
Non esattamente. Rahman mette solo in guardia contro i rischi dell'hype-driven development e contro un'adozione tout-court, non pensata, dei microservices. E ha ragione. I ms servono a chi ne ha effettivamente bisgogno; il problema e` sapere quando se ne ha effettivamente bisogno. Ci deve sempre essere un trade-off = per niente facile da individuare - tra la complessita` del sistema su cui si lavora e quella introdotta dalla nuova tecnologia. 
 
Lo stesso dice Fowler qui: 
https://martinfowler.com/bliki/MicroservicePremium.html
 
 
"So my primary guideline would be don't even consider microservices unless you have a system that's too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don't try to separate it into separate services." [...] "unless you're faced with that complexity, remember that the microservices approach brings a high premium, one that can slow down your development considerably."
 
So per esperienza che lavorare su un sistema distribuito aumenta esponenzialmente la complessita` di ogni singola operazione, anche la piu` banale, per cui bisogna valutare molto bene se ne valga la pena. Come ho detto, l'ultimo progetto su cui ho lavorato era sostanzialmente un cluster di nodi che condividevano solo la mappa Hazelcast in memoria. Anche solo sviluppare un servizio che registrasse un nome univoco, con nodi che potevano andare su e giu` a piacimento, diventava una sfida; e cosi` anche tutto il sistema di gestione degli eventi. Non era propriamente una MSA, comunque.
 
Comunque, alla fine, tutti tendono a tirare acqua al proprio mulino. Non mi aspetto che Rahman, un JavaEE evangelist, accetti di buon grado che JavaEE venga incasellato come obsolescente.
 

 si lavora e quella introdotta dalla nuova tecnologia.
 
Si, io non ne ho mai implementato uno quindi non ho toccato con mano il 
rapporto costi/benefici. Avendo comunque un'idea di cosa comporti 
lavorare su sistemi distribuiti, posso immaginare la giungla di casini 
cui vai incontro. Deployment compreso.
 
Mi chiedo pero' quanti realmente possano trarre beneficio da un' 
architettura simile. Se non hai milioni di richieste da gestire, se non 
sei FB, Amazon, Netflix, ho come l'impressione che sia il classico 
sparare ad una mosca con il bazooka. E quanti sviluppatori lavorano in 
contesti simili? Una piccolissima parte. Per cui davvero mi sembra 99% 
tutto hype.

>Se non hai milioni di richieste da gestire,
 
Questo è verissimo. È però altrettanto vero che a volte c'è una concentrazione troppo forte sulla struttura monolitica a discapito della distribuibilità delle elaborazioni. Nella mia precedente azienda il prodotto principale era pensato come monolitico (come dice Fowler, è la strada giustamente seguita dalla quasi totalità delle aziende). Ad un certo punto, i commerciali portano dentro un grosso cliente, uno stockbroker che chiede certe caratteristiche di high availability e disaster recovery in un contesto di forte concorrenza (parliamo di decine di migliaia di client simultanei). Facciamo test, per fortuna regge bene, ma non così bene come vorremmo. Non era stato inizialmente  pensato per contesti del genere. In sostanza è stato riscritto da zero. Alla fine era una bomba, ma la riscrittura è costata parecchio. Da un lato credo che non bisogna sovraingegnerizzare ma un occhio alla scalabilità bisogna sempre averlo.


Io nemmeno sto piu' a fare la lista delle cose che qui dentro sono state chiamate hype, perche' sinceramente faccio prima a fare la lista delle cose che invece non si sono meritate questo appellativo.
Si, i sistemi distribuiti sono piu' complessi di quelli monolitici (dai!), eppure spesso sono l'unico modo per scalare servizi che nascono come monolitici ma che devo crescere e servire sempre piu' traffico, e certamente non parlo dei volumi di Amazon o FB, faccio sinceramente fatica a comprendere questa logica binaria per cui o sei una realta' gargantuesca oppure "non ti serve"
Un'applicazione monolitica, per definizione, va scalata quasi esclusivamente verticalmente, come diavolo fai ad affrontare costi del genere se non sei Facebook?
E' chiaro che deployment e implementazione sono piu' complessi, ma i vantaggi penso non siano impossibili da intravedere: anche in soldoni pare evidente che si possono estrarre parti del software e magari migrarle ad altre tecnologie magari piu' adatte, o semplicemente tirarle fuori da un dato framework ad alto livello per, tanto per fare un esempio banale, farle girare su una coda di processi che le fa girare in background e in parallelo, il tutto a prezzi molto piu' bassi che investendo sul ferro.
Io ad esempio non lavoro per Amazon ne per Nerflix ma sto appunto estraendo parti di un grosso software (in Ruby) per farle girare come microservices (in Ruby e Elixir). A breve cambio lavoro e indovina un po', andro' di nuovo a fare la stessa cosa.
E davvero non mi pare siano casi tanto isolati, lo stan facendo circa tutti, infatti se sviluppi in Ruby/Elixir o sei un devops a Londra ti arrivano una dozzina di offerte di lavoro al mese...
 
  ngw

 lo stan facendo circa tutti
 
Appunto. C'e` il rischio che si tratti di questo:
 
https://blog.daftcode.pl/hype-driven-development-3469fc2e9b22#.alrhgs3qy
 

 risorse di oggi.
 
 
beh con un hello world si può fare di molto meglio:
 
nodejs, 30mb: 
https://ibb.co/jW7oJv
 
 
golang, 7mb: 
https://ibb.co/fLLVWF
 
 
i test fatti in questo modo lasciano un po' il tempo che trovano; sta di 
fatto che altre tecnologie, a differenza di java, riescono a tenere un 
profilo basso anche nel mondo reale.


A parte isolati casi, che per qualche recondito motivo non vengono 
intaccati dall'evoluzione dell'informatica, chiunque sia abbastanza 
vecchio per aver iniziato la propria carriera partendo dal COBOL (me, ad 
esempio), magari non e' arrivato alla Ferrari, ma qualche salto di 
qualita' l'ha comunque fatto. Sottolineo, quei casi isolati a parte.
 
 
---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
 
 


Ma e' poi cosi' importante? Come ho scritto, in realta' non conosco bene 
l'argomento. Quanti microservizi servono per un applicazione media?

 l'argomento. Quanti microservizi servono per un applicazione media?
 
Non si puo` rispondere alla tua domanda. Gli ambienti che lavorano con microservizi hanno strutture molto eterogenee, e in termini di numero di team che ci lavorano, e in termini di linee di codice per microservizio, e in termini di numero di microservizi. La maggioranza dei microservizi hanno un numero di linee tra i 2000 e i 4000 e Fowler suggerisce di cominciare a pensare ad un'architettura del genere quando ci si avvicina a 50 persone che lavorino sullo stesso progetto. Il footprint di cui parla rootkit non credo sia rilevante, se si decide di passare ai microservizi. Cio` che e` importante e` l'architettura distribuita, che offre tanti vantaggi, a discapito di complessita` del sistema e maggior difficolta` operativa.

 offerte di lavoro al mese...
 
A dire il vero una dozzina/mese mi arrivano anche con il buon vecchio 
java e senza microservice di mezzo.
 

 
https://blog.daftcode.pl/hype-driven-development-3469fc2e9b22#.alrhgs3qy
 
 
La ricostruzione della discussione dul TDD di DHH e' totalmente cannata, ma si, conosco il pattern. 
A me pero' onestamente pare che anche qui non si diano grandi soluzioni alternative.
Ok, estrarre servizi per scalare e' hype, quindi che si fa, si resta con un software monolitico che non scala a sufficienza? Cioe' qual'e' l'alternativa? Perche' estrarre servizi e farli comunicare in qualche modo e' una cosa che a diversi livelli si fa da nmila anni, tolto il nome fancy, e non vedo alternative nel momento in cui un'app e' monolitica allo scalare verticalmente, ma magari mi sono perso qualcosa di fondamentale.
 
  ngw

 java e senza microservice di mezzo.
 
Buon per te, ma io rispondevo alla tua domanda su quanti sviluppatori lavorano in quei contesti fuori da Amazon o Netflix.
La risposta e' "parecchi".
 
  ngw

 "parecchi".
 
Ma non vorrei fosse hype, come dice 4ndre4. Detto questo, visto il 
mercato che hai citato, forse e' il caso di darci almeno un'occhiata 
approfondita.
 

 qualcosa di fondamentale.
 
Molto spesso e' sufficiente un load balancer.

 Ok, estrarre servizi per scalare e' hype
 
No, l'hype non e` quello. L'hype e` sull'adozione dei microservices, nello specifico. Una MSA ha delle caratteristiche precise, ma non e` l'unica strada per la scalabilita` di un monolite.

 eccetera eccetera.
 
Spring e` sicuramente un ottimo framework ma Rahman ha ragione nel dire che non e` niente di nuovo e che certe caratteristiche di JEE sono probabilmente piu` innovative. A me gli EJB non sono mai andati giu` e devo dire che non li ho quasi mai visti usare per le loro caratteristiche peculiari. Ne` veniva usato il remoting, quasi sempre erano oggetti locali con logica di persistenza; ne` venivano usati in maniera concorrente. Mi sembra che, nella storia di JEE, siano stati un buco nell'acqua, ma aspetto di vedere cosa riservi JavaEE 8 (se mai verra` fuori...)

 l'argomento. Quanti microservizi servono per un applicazione media?
 
secondo me è una domanda fallace.
i servizi rest sono stateless, in più docker / swarm / kubernetes 
facilita in modo determinante la parte deploy, che è la parte di cui mi 
occupo da un po' di tempo a questa parte (ma anche quella su cui impatta 
più la scelta). conviene progettare  microservizi distribuiti? in linea 
di principio imho sì, è una possibilità almeno da valutare. da quello che 
ho potuto vedere non è una scelta che grava sullo sviluppo che una volta 
entrato nell'ordine delle idee procede persino più spedito. 
 


Ma cosa vuoi che nascondiamo
Non ci conosciamo neanche,di persona intendo
 


 
 
 
 
Certamente,anche io inizia con il COBOL
Poi sono passato a unix ed il C.
E poi altro ancora.
 
 


da sempre quelli di java conepiscono l'enterprise come un application 
server che fa tutto: servizi web, front-end, container per la logica di 
business, messaging system, scheduler, ldap, etc... 
quindi stiamo parlando di microservizi, ma su java la discussione è 
ancora un passo indietro. si sta ancora cercando di capire quanto abbia 
senso distribuire i ruoli, figuriamoci i servizi.
 
mi sento dire: ma così è logico, tiri su l'as e l'applicazione ha tutto 
quello che gli serve. eh ho capito, ma così come cazzo la scali? magari 
il servizio rest ti fa comodo moltiplicare le istanze, ma la coda dei 
messaggi una deve essere. ti metti a configurare il cluster jms? questa 
sì che è una inutile menata...
 

 sì che è una inutile menata...
 
Perche' una per forza?
 
In ogni caso non e' difficile configurare in modo da avere una coda e N 
application server.

 application server.
 
è una menata. almeno con jboss qualche anno fa dovevi avere un repository 
in comune, ciascun nodo doveva essere configurato per presentarsi agli 
altri, e poi in cluster manco funzionava bene. 

 quello che gli serve. eh ho capito, ma così come cazzo la scali? 
 
Questa, per esempio, e` una strada:
 
http://wildfly-swarm.io/
 

 application server.
 
E se usi tecnologie come Hazelcast o Infinispan, e` probabile che la coda neanche ti serva.

 lo stesso lavoro enne volte.
 
Questo pero` e` un problema che hai anche con una coda sola:
 
http://www.enterpriseintegrationpatterns.com/patterns/messaging/CompetingConsumers.html
 

 Non sono d'accordo. Non vedo come avere piu` code impedisca di scalare.
 
non lo stai facendo nel modo giusto.
 

 Non sono d'accordo. Non vedo come avere piu` code impedisca di scalare.
 
Mi sono un po' pentito dell'esempio :p
La coda comunque dovrebbe essere una parte di infrastruttura che fa girare del codice generico per fare "qualcosa" in background magari integrato con uno scheduler, non vedo l'utilità di avere piu' code, va a finire che crei una tonnellata di rumenta custom per nessun motivo apparente.
 
  ngw

 non lo stai facendo nel modo giusto.
 
Probabilmente non ho ben compreso quel che intendi, ma non vedo come avere una coda o piu` code impedisca di scalare un sistema. 
 
Qui, per esempio, si dice:
 
"Scaling the Messaging System. In a large-scale solution, a single message queue could be overwhelmed by the number of messages and become a bottleneck in the system. In this situation, consider partitioning the messaging system to direct messages from specific producers to a particular queue, or use load balancing to distribute messages across multiple message queues."
 
https://msdn.microsoft.com/en-gb/library/dn568101.aspx
 

 lo stesso lavoro enne volte.
 
E' un altro tipo di scaling, non per forza migliore. Ad esempio se la 
singola coda va giu' i consumer se la incartano. Con l'altra soluzione no.
 

 perde gran parte dei vantaggi e pessimizza le risorse.
 
Sping Boot + Cloud, grazie allo stack messo a disposizione da Netflix, 
più prodotti come Apache Kafka, persistence layer a piacimento (sempre 
grazie a qualche progetto Spring) e perfetta integrazione con tool CI 
(Bamboo + docker), Java va benissimo per un'architettura basata su 
microservices. Stiamo rimpiazzando roba legacy con moduli Java 
configurati con non più di 128MB di memoria l'uno. Qualche dubbio lo 
nutro su Eureka, mi piacerebbe avere pareri su eventuali alternative.
 
Progetti nuovi monolitici, se intendi roba che "fa tutto in uno" e 
richiede un'application server standalone per girare (Wildfly & C.), ne 
vedo sempre meno. Per fortuna...
 
Per motivi di lavoro mi sto studiando Scala (e a seguire Akka + Play)... 
per favore non mi dite che già non tirano più :-)
 
Se dovessi / volessi trovare un'alternativa a Java, in ambito 
microservice, al momento... l'unico canditato che vedo è Golang. Ma 
addio JVM.
 
 

 "Scaling the Messaging System. In a large-scale solution, a single message queue could be overwhelmed by the number of messages and become a bottleneck in the system. In this situation, consider partitioning the messaging system to direct messages from specific producers to a particular queue, or use load balancing to distribute messages across multiple message queues."
 
Forse state facendo confusione fra il concetto di queue/channel e 
topic... Non tutti i sistemi supportano il concetto di topic, per cui 
"partitioning" significa per forza avere più queue/channel. E in ogni 
caso non vedo quale sia il problema di avere più queue: mi sembra 
ragionevole avere almeno una coda per "funzionalità" (es. coda richieste 
in entrata, coda notifiche interne, coda notifiche esterne, ...) invece 
che una "codona" unica dove mescoli i messaggi che appartengono a 
sotto-domini diversi.


probabilmente non mi sono spiegato bene.
 
io mi riferivo ad una architettura canonica in cui hai una applicazione 
web (magari restful) che usa un provider jms come producer e dei 
consumer, tutti nello stesso application server. un esempio che mi sembra 
realistico di come è finora concepita una architettura enterprise in java.
 
ora se io questa architettura la voglio scalare, supponendo con un altro 
nodo, ottengo un'altra istanza di application server in cui 
l'applicazione web accede al provider dei messaggi di *quella* istanza, 
indipendente e isolato rispetto alle altre istanze. questo vuol dire che 
ho scalato correttamente l'applicazione web, ma il resto no, perché non 
ho un corretto bilanciamento di carico: se un nodo per una qualsiasi 
ragione produce più messaggi non distribuisco il lavoro sui consumer 
degli altri nodi.
 
tu mi dirai: configura i provider jms in un cluster. eh ho capito, ma a 
parte la menata gratuita è proprio una operazione che non ha senso: una 
applicazione web che deve avere tempi di risposta certi ha bisogno di una 
scalabilità diversa rispetto ad una risorsa che non ha questa esigenza, e 
magari ne ha altre.
 
la critica di base era al modo classico di concepire l'architettura 
enterprise da parte di java, con l'application server "monolitico" che 
implementa tutto lo stack. 


 
Ora mi e' chiaro cosa intendevi. Avresti anche ragione, tuttavia
 
1. puoi fare a meno di usare  il provider jms dell'application server
 
2. avere necessita' di questo tipo e' abbastanza raro.
 
Nella mia (sicuramente limitata, su questo fronte) esperienza e' sempre 
bastato tenere AS + JMS provider assieme (che se la cantano e la suonano 
come hai scritto in precedenza), visto che tendenzialmente il numero di 
messaggi prodotti va di pari passo con il carico sull'appliactivo web.
 
Poi se hai esigenza diverse e particolari, ci sta a mio parere che tu 
debba configurare AS e code diversamente.

 bastato tenere AS + JMS provider assieme
 
Il problema non e` Java, come detto. Il problema e` il monolite risultante. La critica mi sembrava rivolta a Java, nello specifico, ma se scrivi un backend monolitico in C++ hai lo stesso problema. Come lo scali se non creando piu` istanze dello stesso backend e trovando un modo di farle comunicare? Con Java, puoi anche usare un message broker (e.g. ActiveMQ). 

 qualita' l'ha comunque fatto. Sottolineo, quei casi isolati a parte.
 
Tipo? Che tipo di auto hai? Un'utilitaria od una SW?
 
 
 
 
 

 Tipo?
No, mai avuta una Tipo. E tu? Una Duna forse?
 
 
---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
 
 

 contavano sulle dita di una mano monca. 
 
questo fino a quando nota compagnia 
dell'aerospace non ti chiede di aiutarla 
nell'analisi automatica di suoi vecchi 
sorgenti in... JOVIAL. risate registrate 
assicurate

 dell'aerospace
 
Io ho conosciuto una societa` che progettava cockpit di elicotteri, non molti anni fa, e avevano ancora codice ADA.