Poiché
l’AS/400 è una realtà di mercato ben nota per le applicazioni
gestionali delle aziende italiane di modeste dimensioni, risulta centrale
nella soluzione descritta in quanto archivia i dati commerciali per le
varie rielaborazioni successive. La prima applicazione di ecommerce che
occorre realizzare deve, nel caso più semplice, consentire di creare
(e modificare) un catalogo prodotti, di presentarli all’utente e permettergli
di inviare l’ordine.
Gli aspetti
di presentazione e di marketing sono di dominio di grafici, pubblicitari
e webmaster e non li tratteremo qui. Supponiamo invece che il cliente sia
giunto alla fase in cui desidera comporre l’ordine. L’applicazione avrà
dunque le seguenti caratteristiche:
-
nel contesto di
un sito che presenta il catalogo prodotti, l’utente Web arriva alla pagina
per effettuare l’ordine di alcuni dei prodotti presentati nel catalogo
(figura riportata qui di seguito). Il listino dei prodotti viene
mantenuto nel database dell’AS/400
-
l’utente compone
l’ordine e lo invia. Il nuovo ordine verrà notificato al personale
commerciale (per esempio tramite l’invio di un messaggio di posta elettronica);
-
dopo la ricezione
dell’ordine, l’addetto può consultare il dettaglio dell’ordine,
verificare le generalità del cliente, eventualmente contattarlo
ed infine decidere se dare corso all’ordine;
-
poiché i
prodotti in vendita possono variare nel tempo, il sistema consente di variare
il listino senza dover modificare le pagine HTML (Figura 2). Il catalogo
presentato può infatti essere facilmente modificato e le modifiche
apportate al catalogo sono immediatamente operative online.
Utilizzando l’AS/400
per memorizzare il catalogo prodotti e gli ordini, sono possibili numerose
integrazioni del sistema di e-commerce con le applicazioni preesistenti.
Per esempio:
-
il catalogo può
essere collegato alla gestione del magazzino, in modo da avere online una
vetrina di merce realmente disponibile;
-
la raccolta ordini
può essere collegata alla fatturazione e alla contabilità,
in modo tale che un ordine accettato venga immediatamente fatturato e contabilizzato;
-
integrando il sistema
di commercio elettronico con l’archivio clienti è possibile consentire
al personale commerciale sia immediate verifiche sul cliente, sia nuove
possibilità di indagini di marketing.
In sintesi si può
dire che un sistema di commercio elettronico può essere visto come
una naturale evoluzione del sistema gestionale esistente.
Architettura
Abbiamo delineato
il funzionamento del sistema dal punto di vista dell’utente. Tuttavia,
siccome siamo interessati anche agli aspetti tecnici, ne esaminiamo l’architettura
e la tecnologia. Il panorama sistemistico è piuttosto variegato,
ma rispecchia la realtà odierna. Discuteremo in seguito la motivazioni
delle varie scelte:
-
Il catalogo prodotti
e l’archivio ordini vengono memorizzati sull’AS/400;
-
L’applicazione di
commercio elettronico è eseguita su una macchina presso la sede
del provider, sotto sistema operativo Unix o Windows NT, a cui l’AS/400
è collegato tramite una linea dedicata CDN (Circuito Diretto Numerico,
vedi sotto);
-
L’applicazione server
è realizzata in linguaggio Java;
-
Il personale commerciale
gestisce gli ordini utilizzando un client dedicato in ambiente Windows
95/98 sviluppata in Delphi.
Tale architettura
è sintetizzata in figura seguente: esaminiamo le ragioni tecniche
delle varie scelte.
Riteniamo che
tale architettura sia la più comune e realistica considerando l’offerta
commerciale e il panorama tecnologico del mercato italiano attuale. La
scelta al punto 1 è assolutamente naturale sia perché normalmente
sull’AS/400 risiedono tutte le informazioni dell’azienda, ma anche e soprattutto
in vista delle possibili integrazioni del catalogo con il gestionale.
La ragione della
scelta al punto 2 è più complessa. Bisogna dire innanzitutto
che l’AS/400 rappresenta di per sè una buona soluzione come Web
Server. Tuttavia quando su tale macchina risiedono anche informazioni vitali
per l’azienda (come è del tutto naturale) occorre riconsiderare
con molta cautela la scelta di esporre la macchina ad Internet. Infatti,
nonostante la macchina in sé possa essere considerata sicura, può
essere sempre violata non necessariamente per motivi tecnici ma anche (e
soprattutto) per motivi legati al fattore umano. È infatti nota
la difficoltà con cui (purtroppo) si riesce ad educare il personale
ad osservare le necessarie misure di sicurezza. Per questo motivo è
molto meglio non correre rischi e non esporre direttamente la macchina
ad Internet.
Meglio invece
mantenere la macchina protetta dietro un firewall e far girare l’applicazione
di e-commerce in una macchina presso un provider che si occuperà
anche della necessaria manutenzione. Tale manutenzione è sufficientemente
complessa da consigliare un outsourcing invece di gestirla in casa. Si
provvederà invece ad attivare una linea diretta al provider e consentire
una sola interazione, molto più facilmente controllabile, tra l’applicazione
di e-commerce e l’AS/400. L’interconnessione con il provider utilizzerà
una linea a Circuito Diretto Numerico, che è lo standard proposto
da Telecom Italia per le connessioni dati permanenti. Questo tipo di linee
sono utilizzate per le connessioni permanenti della maggior parte degli
Internet Service Provider, ed hanno un costo che continua a diminuire,
anche per effetto della recente deregulation nelle telecomunicazioni.
Per quanto riguarda
le ragioni della scelta al punto 3, dobbiamo considerare innanzitutto che
i provider utilizzano generalmente Web Server con sistemi Unix o Windows
NT. Questo requisito porta alla necessità di utilizzare un linguaggio
compatibile sia con Unix che con Windows NT, che disponga di una buona
connettività all’AS/400. Fino a qualche tempo fa si sarebbe ricorso
ad un mix di linguaggi (Visual Basic, C++ e RPG) e alla rassegnata consapevolezza
di dover riscrivere l’applicazione quando da Unix si desideri passare a
Windows NT, a un Domino con AS/400 o altre piattaforme (per esempio per
cambio di provider o potenziamento dell’applicazione). Queste problematiche
hanno un ovvio impatto sui costi. Oggi, grazie a Java è finalmente
disponibile una soluzione ottimale:
-
innanzitutto l’applicazione
è realmente portabile tra NT, Unix e AS/400;
-
la connettività
tra l’AS/400 e le applicazioni Java è eccellente grazie all’AS/400
Toolbox di IBM;
-
Il linguaggio è
sempre più supportato da terze parti, viene insegnato nelle scuole
e guadagna consensi sia nella comunità dei programmatori Visual
Basic che C++;
-
Ultimo ma non meno
importante fattore, Java è considerato il linguaggio designato per
applicazioni di commercio elettronico e Internet in generale, per cui è
il più supportato sia in termini di librerie che di integrazione
con tool esistenti. Per esempio basta considerare il fatto che tutti i
principali Web Server (Domino compreso) supportano l’integrazione con Java.
Consideriamo infine
la scelta al punto 4. Una volta costruita l’applicazione è opportuno
dotare gli addetti al trattamento degli ordini di un applicativo user-friendly
per la loro gestione. Generalmente in ambito client la portabilità
è un requisito meno stringente rispetto alla facilità d’uso
e alla integrazione con gli strumenti di produttività individuale.
Tra gli strumenti di sviluppo disponibili specificamente per AS/400, si
è utilizzato il Borland Delphi /400 per la realizzazione del trattamento
degli ordini. In questo articolo comunque ci concentriamo sul lato server
ed esaminiamo le tecnologie Java utilizzate.
Tecnologie
e strumenti
L’intera applicazione
è scritta in linguaggio Java. Java è considerato un linguaggio,
ma in realtà è un insieme di tecnologie che hanno nella Java
Virtual Machine (che garantisce la portabilità) il loro punto di
incontro e integrazione.
Per realizzare
il sistema abbiamo fatto ricorso a diverse tecnologie Java. Innanzitutto
abbiamo scritto un programma che si collega al DB/2 per memorizzare i dati,
sfruttando la tecnologia di database di Java nota come JDBC (Java Data
Base Connectivity).
JDBC tuttavia
non è sufficiente, in quanto si tratta di una tecnologia generica,
mentre occorre un driver specifico per collegarsi al DB/2. Questo driver
è fornito dal kit di IBM per la connessione a database, noto come
AS/400 Toolbox. Il Toolbox include il driver JDBC, ma fornisce anche numerose
altre funzioni necessarie per interfacciare i programmi in Java con l’AS/400.
Infine, l’applicazione viene invocata da un Web Server quanto l’utente,
seguendo i link, chiama l’applicazione. Come esistono le tecnologie Java
per l’integrazione con i database e l’AS/400, così ne esiste un’altra,
nota come servlet, che consente appunto di sviluppare applicazioni integrate
con i WebServer che producono pagine Web dinamiche. Notiamo che, allo scopo
di garantire la massima fruibilità dell’applicazione, non abbiamo
utilizzato applet: queste ultime vengono talvolta considerate (erroneamente)
l’aspetto di punta della tecnologia Java.
Servlet
L’applicazione
viene invocata da un utente quando, navigando nel sito aziendale, decide
di seguire un link che lo porta alla pagina degli acquisti on-line. Molte
pagine presenti sul sito sono statiche, ma alcune sono in realtà
interattive, generate dinamicamente da un programma. Infatti il nostro
modulo d’ordine presenta un listino che può variare. Sebbene possa
essere praticabile modificare la pagina degli ordini quando varia il listino,
si perde in tal modo la possibilità di integrazione con il magazzino
prodotti. Questo richiede ogni volta l’intervento di un programmatore HTML
invece di un semplice operatore. Generando invece la pagina con un programma,
questo può consultare il magazzino e presentare un listino che rispecchi
situazione corrente. Inoltre quando l’utente ha formulato il suo ordine,
questo deve essere catturato, memorizzato sul database e notificato al
personale. Anche questo è compito di un programma. Le richieste
inviate al Web Server vengono passate ad un programma Java detto servlet.
Java è famoso per consentire di scrivere applet, piccoli programmi
che attraversano la rete e vanno in esecuzione "dentro" il browser.
Le servlet sono
in un certo senso l’equivalente lato server: sono programmi che vengono
eseguiti sul server contestualmente alle richieste che invia l’utente.
L’applicazione che raccoglie l’ordine è appunto una servlet. Le
servlet sono supportate da numerosi Web Server: innanzitutto, Domino Go
WebServer, e numerosi altri. Per i Web Server che non supportano le servlet
nativamente, esistono dei "motori" per l’esecuzione di servlet: per esempio
il Servlet Express di IBM o il Jrun di Live Software. Oggi sono disponibili
le servlet praticamente per ogni Web Server esistente, Microsoft IIS, IBM
Domino e Apache compresi. Le servlet consentono anche di scrivere applicazioni
indipendenti non solo dalla piattaforma ma anche dal Web Server. Per esempio
l’applicazione mostrata in queste pagine è stata sviluppata su un
sistema NT con IIS, ma è stata posta online in un provider che utilizza
Unix con Apache. Non è stato necessario cambiare una sola riga di
codice né ricompilare l’applicazione.
JDBC
La nostra servlet
deve interagire con il database sia per conoscere il listino corrente,
sia per memorizzare l’ordine. È noto che le applicazioni Windows
sono in grado di colloquiare con i database sfruttando ODBC. Il JDBC ha
la stessa funzione per le applicazioni Java: è la tecnologia di
interfaccia a database della piattaforma Java. Il JDBC è un sistema
generale che consente di accedere a qualsiasi tipo di database. Le applicazioni
che sfruttano il JDBC sono indipendenti dal database utilizzato. Comunque
se il JDBC rende le applicazioni portabili, per accedere ad uno specifico
database occorre un "driver".
Quindi una applicazione
che usa il JDBC può girare su Oracle utilizzando il driver per Oracle,
su Informix utilizzando il driver per Informix, e su DB/2 utilizzando il
driver per il DB/2. Fortunatamente i driver JDBC, per tutti i tipi di database
(noti e meno noti), sono generalmente forniti insieme al database. Per
collegarci a DB/2 abbiamo utilizzato il driver JDBC per AS/400 fornito
insieme all’AS/400 Toolbox.
AS/400 Toolbox
La strategia
Java di IBM si muove su due filoni principali: il primo è il supporto
di Java sull’AS/400 per applicazioni server, il secondo è lo sviluppo
di applicazioni client dell’AS/400 in Java. Abbiamo utilizzato quest’ultimo
nell’applicazione presentata. L’AS/400 Toolbox è una libreria vasta,
completa e attivamente supportata da IBM che permette di sviluppare applicazioni
che sfruttano a fondo le tecnologie dell’AS/400.
Nel nostro caso
l’aspetto determinante è stato il driver JDBC per la connessione
a DB/2. Abbiamo anche utilizzato l’AS/400 Toolbox per altre operazioni
di routine. In particolare, abbiamo utilizzato la CommandCall per invocare
comandi sull’AS. Questa funzione è necessaria nella manipolazione
del database, poichè la creazione di tabelle richiede anche l’inizializzazione
del Journaling, operazione che viene effettuata eseguendo dei comandi sull’AS/400.
In realtà l’aspetto entusiasmante del Toobox è offerto dalle
possibilità di integrazione con le applicazioni esistenti. Per esempio
supponendo di avere applicazioni sviluppate per generare vari prospetti,
queste possono essere collegate al Web tramite l’utilizzo di semplici applicazioni
che invocano comandi sull’AS/400, catturano l’output e ripresentano i dati
sul server. Allo stesso modo, avendo moduli di immissione dati, è
possibile portarle sul Web presentando delle form che invocano tali programmi
riempiendone i campi. Tutto questo utilizzando una interfaccia basata sul
Web che può essere usata sia su una intranet che su Internet. L’aspetto
sicurezza non va trascurato, ma i problemi sono contenuti in quanto si
riesce ad eseguire queste operazioni senza dare l’accesso all’AS/400 ad
alcun utente esterno.
Conclusioni
Questo articolo
ha illustrato come sia possibile mettere al lavoro Java e l’AS/400 per
una soluzione immediatamente utile all’azienda. In realtà si tratta
solo del primo passo, perché il commercio elettronico ha numerosi
aspetti che devono essere accuratamente considerati quando il business
cresce, ad esempio la protezione delle connessione per la riservatezza
dell’ordine, l’accesso a parti del catalogo e a particolari offerte ad
una clientela selezionata, le transazioni di pagamento sicuro (SET), il
marketing che richiede una accurata analisi delle registrazioni per la
verifica degli interessi della clientela e così via. |
