Sistemi multipiattaforma, perchè parlarne? Perchè l’evoluzione dei sistemi software enterprise è uno dei temi caldi del momento. In questo ambito, uno dei focus a cui stiamo lavorando negli ultimi anni in smeup è quello del progetto Multipiattaforma. Obiettivo del progetto Multipiattaforma per noi di smeup è aprirsi al mondo del cloud affinché smeup erp funzioni su piattaforme open. Da un punto di vista prettamente tecnico, il progetto multipiattaforma si è basato sulla traduzione da RPG a Java. Ma vediamo più nel concreto di cosa si tratta.
Qual è il modo più efficace, oggi, per sviluppare una nuova APP?
Questa la domanda che ci siamo posti.
Col pensiero laterale!
La nostra risposta.
Le scelte erano fondamentalmente due: riscrivere tutto il codice facendo in modo che quanto scritto dia i risultati sperati e funzioni nella nuova piattaforma, oppure pensare fuori dagli schemi e partire al contrario.
Come esercizio speculativo, ci siamo posti queste due domande:
“Cosa significa riscrivere tutto da zero? Come farei oggi un nuovo gestionale?”
Dopo un’attenta riflessione sono emerse queste caratteristiche necessarie:
- che deve essere basato su web API: con interfaccia web ma in cui le API devono essere esposte e, sebbene ci dovrà essere una separazione tra backend e frontend questi dovranno comunicare attraverso le API
- che oggi si fa un uso più intensivo degli interpreti: tantissimi sono i linguaggi interpretati e che hanno grandi vantaggi. Java stesso ma anche Pyton in realtà sono compilati ma interpretati da una virtual machine, un linguaggio intermedio. Ormai, il concetto di interprete sta diventando sempre più importante dandoci sicurezze sulle performance. Quindi l’interprete era fondamentale.
Sistema multipiattaforma: perché per noi è importante sviluppare questa soluzione?
Vediamo innanzitutto quali sono i due principali svantaggi delle applicazioni legacy:
– il knowledge drain: provoca la perdita di conoscenze sia sulle applicazioni in quanto codice applicativo sia sui linguaggi; conoscenze facilmente rimpiazzabili con le moderne applicazioni ma difficilmente con applicazioni legacy.
La scalabilità dipende più dal sistema che c’è sotto; sebbene AS400 abbia una scalabilità, questa è verticale anziché orizzontale.
– il vendor lock-in: se volessimo azzardare un paragone potremmo definirlo, insieme allo stato, “un socio maggioritario dell’azienda”. Molto dipende dai dettagli certo, ma vendor lock-in nonostante Google lo neghi, bene o male c’è sempre.
Le moderne applicazioni si focalizzano su google cloud platform, e comunemente su piattaforme cloud caratterizzate da maggiore scalabilità e da una maggiore disponibilità online. L’utilizzo di pattern di sviluppo diffusi in ogni parte del mondo, facilita l’incontro con sviluppatori che questi pattern li conoscono.
Perchè gli sviluppatori di smeup vogliono appoggiarsi alle nuove tecnologie e costruire indipendenza?
Una base di sviluppatori molto più ampia e tutte le librerie disponibili open-source, sono una ricchezza preziosa; tuttavia cercare una libreria crittografica per l’RPG, non è così facile come invece cercare quella per lodge Js.
La separazione tra tecnologia e applicazione
Principio fondamentale su cui si basa il nostro sviluppo di Sistemi multipiattaforma è proprio mantenere separate tecnologia e applicazione in modo che sia molto più facile cambiare la tecnologia in seguito alla sua evoluzione, senza che l’applicazione ne sia intaccata.
Attraverso le foundation, smeup mette a disposizione dei suoi incaricati del delivery tutta una serie di strumenti semplici da utilizzare come /copy e API affinché siano in grado di sviluppare, sia nei nostri laboratori sia direttamente presso il cliente, il codice della soluzione applicativa.
Che problemi risolve a noi
- Permette soprattutto di essere liberi da alcuni requisiti stringenti: As400 e RPG hanno diversi requisiti .
Essere svincolati da AS400 consente:
– Maggiore Scalabilità del business: più possibilità
– Nuovi modelli di business
– Fornire delle Mini-app vs grosso erp
Un esempio è quello della Cassa negozio. Grazie al multipiattaforma possiamo realizzare la cassa di un negozio, cosa che prima non era possibile fare perché non era possibile mettere un AS400 in un negozio. - Permette di aver un miglior rapporto costi sviluppo/benefici perché in generale ci consente di coinvolgere molti più sviluppatori, e di conseguenza anche a giovani già formati almeno sulla parte tecnica e valutare anche la possibilità di fare outsourcing all’ esterno . non è necessario avere dei programmatori rpg.
- Consente di avere accesso a software open-source scritto da altri, quindi accedere a numerosi repository, progetti open-source a cui attingere.
Che problemi risolve ai clienti
- Siamo un fornitore più flessibile e rapido, perché ci consente di risolvere molti dei problemi dei nostri clienti
- Hanno un software più moderno: possiamo vendere ai clienti un software più efficiente
- Possiamo fare progetti che prima non era possibile realizzare: Ad esempio erogare delle app in una modalità che non preved l’utilizzo dell’as400 oppure sviluppare delle applicazioni snelle che possono essere realizzate facilmente e velocemente senza il vincolo dell’as400 dietro.
Il nostro interprete: JaRIKo
Cos’è JaRIKo ?
JaRIKo è un interprete del linguaggio di programmazione RPG. Dato che è scritto in Kotlin, JaRIKo gira su una JVM (Java Virtual Machine).
Si tratta di un vero e proprio motore all’interno del multipiattaforma che riceve il codice RPG e una riga alla volta, lo esegue sopra la java virtual machine, ovvero una macchina che usa java ma in questo caso esegue del codice rpg.
Quali sono le peculiarità dei sistemi multipiattaforma?
- Il codice RPG gira ovunque (raspberry, smartphone, ps desktop, server, cloud, data center…): quindi offre molta flessibilità
- Il codice RPG è estendibile (ovvero: possiamo aggiungere nuovi codici operativi, nuovi tipi di variabile, ecc)
- Il codice RPG è sostituibile anche a pezzi con codice Java (singolo programma, singola procedura, singola routine) dando una grandissima flessibilità . E’ possibile prendere ad esempio un pezzo di codice rpg scritto 10 anni fa e metterci dentro dei pezzi di java. Lo schema mostra come sia possibile scrivere il programma 2 in java mentre il programma 1 e 3 rimangono in prg, oppure si possa riscrivere una singola procedura o la singola routine.
- Il codice RPG non ha più i vincoli che ha sull’AS400, che implicano alti costi e potenzialmente rappresentano un blocco (ad esempio le lingue, la lunghezza delle variabili, alfabeti, ecc)
- E’ possibile accedere in modo diretto e nativo a qualunque database. Proprio con l’accesso nativo, quindi con delle istruzioni che oggi sono già nell’rpg che abbiamo scritto. Permette di accedere a questi database in maniera trasparente senza dover svolgere rimappature o altri lavori.
Se ti interessano i sistemi multipiattaforma, scopri anche smeup data platform. Potrebbe interessarti…
Naviga per categoria:
Seleziona una categoria d’interesse dal nostro magazine
