perché i monitor delle transazioni sono in declino? o sono loro?

0

link

link

Guarda la domanda di programmatori (% di annunci di lavoro in cui viene visualizzata la parola chiave), il primo grafico sotto la tabella. Sembra che la domanda per CICS, Tuxedo è sceso dal 2,5% / 1% rispettivamente a quasi zero.

Per me, sembra strano: ora abbiamo più macchine collegate in rete e abilitate per internet che mai. E la maggior parte di loro sta parlando con qualche tipo di database. Sembra quindi che l'uso di prodotti i cui sviluppatori hanno trascorso gli ultimi 20-30 anni a lavorare sulla distribuzione, il coordinamento e l'ottimizzazione delle transazioni dovrebbero essere in aumento. E sembra che non lo siano.

Posso vedere alcune cause ma non posso dire se sono vere:

  1. abbiamo dimenticato che la concorrenza e la distribuzione sono davvero difficili, e lo stiamo rifacendo tutto da soli, in Java, male.

  2. Erlang li ha uccisi tutti.

  3. Al giorno d'oggi i progetti hanno cambiato carattere, come la maggior parte del software aziendale è già stato creato e stiamo facendo tutti i servizi internet, usando cose come Node.js, Erlang, Haskell. (Ho usato RabbitMQ che è scritto in Erlang, "ma era un piccolo progetto specializzato" di tipo "cosa").

  4. BigData è l'enfasi ora e BigData non ha bisogno di transazioni molto (?).

Nessuna di queste spiegazioni mi sembra particolarmente convincente, ed è per questo che cerco una migliore. Chiunque?

    
posta mrkafk 26.03.2012 - 17:38
fonte

2 risposte

2

I Transaction Monitors sono ancora di moda, solo che "Websphere", "Weblogic", "JBOSS" e "GlassFish" sono ora i marchi dominanti!

O per dirla in altro modo, il declino di CICS e Tuxedo è un sintomo del declino di COBOL e della C semplice come i linguaggi delle applicazioni. L'ascesa di J2EE (i container di applicazioni sono davvero dei monitor di transazione!) È un riflesso dell'ascesa di Java come lingua del grande business.

    
risposta data 04.04.2012 - 10:40
fonte
2

Prima di tutto, ci sono più alternative:

  • MSDTC (Microsoft Distributed Transaction Coordinator) - disponibile da Windows 2000;
  • varie implementazioni su JTA (Java Transaction API), inclusi open-source come JBossTS ;

In secondo luogo, c'è molta più enfasi sulla costruzione di sistemi disaccoppiati e scalabili. Quindi invece della transazione hai code di messaggi. Le transazioni distribuite non si adattano abbastanza bene. Si tratta di teorema CAP di Eric Brewer . Con i tradizionali monitor di transazione, scegli consistenza e amp; disponibilità, mentre i sistemi veramente scalabili necessitano di disponibilità e amp; tolleranza della partizione, sacrificando la coerenza per consistenza finale .

    
risposta data 04.04.2012 - 12:32
fonte