L’integrazione tra Internet e la
rete aziendale: soluzioni Intranet
e gestione dei Data Base
Maurizio Fermeglia
Riassunto delle lezioni e concetti principali
Sommario
Modulo 1: Evoluzione dei sistemi informativi .......................................................... 2
Obiettivi ................................................................................................................. 2
Riassunto ................................................................................................................ 2
Modulo 2: L’evoluzione delle architetture di rete ..................................................... 4
Obiettivi ................................................................................................................. 4
Riassunto ................................................................................................................ 4
Modulo 3: evoluzione del modo di progettare e scrivere le applicazioni: dalle
applicazioni monolitiche all’informatica distribuita .................................................. 5
Obiettivi ................................................................................................................. 5
Riassunto ................................................................................................................ 5
Modulo 4: il middleware ............................................................................................ 6
Obiettivi ................................................................................................................. 6
Riassunto ................................................................................................................ 6
Modulo 5: Fondamenti e modelli di data base ......................................................... 10
Obiettivi ............................................................................................................... 10
Riassunto .............................................................................................................. 10
Modulo 6: progettazione di un database relazionale................................................ 13
Obiettivi ............................................................................................................... 13
Riassunto .............................................................................................................. 13
Modulo 7: database access from web servers .......................................................... 15
Obiettivi ............................................................................................................... 15
Riassunto .............................................................................................................. 15
L’integrazione tra Internet e la rete aziendale: soluzioni Intranet e gestione dei Data Base
Modulo 1: Evoluzione dei sistemi informativi
Obiettivi
In questo modulo si mostrerà come i cambiamenti strutturali dei sistemi operativi
siano largamente influenzati dall’evoluzione del network e le cause che hanno
comportato ciò.
Riassunto
Il sistema operativo primordiale si basava, in gran parte, sull’hardware e l’utente non
doveva far altro che adeguarsi. In seguito si verifica l’opposto: il software diviene più
importante e, soprattutto, l’utente assume una posizione dominante in quanto, con le
sue conoscenze e le sue aspettative, è in grado di apportare diversi vantaggi. Si
diffonde, inoltre, la libertà dei dati, che permette di fare tutto su internet,
determinando così lo sviluppo del WEB. Parallelamente si modifica lo sviluppo dei
software applicativi, che deve avvenire in termini di Middleware.
Tale evoluzione è resa possibile dai minori costi dei PC e dei Client-Server, da una
maggiore disponibilità di software, da un miglioramento dei collegamenti sul
territorio. Certo non di poco conto per l’evoluzione dei sistemi informativi è il boom
di internet, la globalizzazione dei mercati e la diffusione della new-economy.
Determinante è anche l’aumento degli investimenti che si indirizzano soprattutto su
personal computers di dimensioni medie, su apparecchiature ed infrastrutture di rete,
su collegamenti con data-base relazionali sulla formazione del personale su strumenti
nuovi e, infine, sul middleware.
All’interno di uno scenario di tal genere non può che verificarsi un’evoluzione
architetturale dei sistemi informativi. Inizialmente vi era il Time-sharing,
caratterizzato da terminali main-frame e linee telefoniche a bassa velocità; poi il
Resource-sharing, cioè personal computer e rete locale a bassa velocità; il Clientserver dove vi sono elaboratori sia server che client , reti locali veloci e collegamenti
ad alta velocità (es. : D.B., sistema di posta elettronica e fax, ecc.); e, infine, si giunge
al Multitier approach in cui viene certo il Middleware distinguendo tra livello
applicativo, dati e presentazione (es. : ERP, e-commerce, ecc.).
Tale evoluzione è caratterizzata da diversi vantaggi, tra cui: miglioramento nel
rapporto tra prezzo e prestazione, elevata sicurezza e riservatezza, possibilità di
rapporti B2B (business 2 business).
In seguito a tale evoluzione, sulla base di dati empirici, è stato dimostrato che la
potenza di calcolo e la velocità di connessione sono aumentate e continueranno ad
aumentare in maniera esponenziale.
Da quanto sopra deriva che tutti gli strumenti del personal computer devono avere
compatibilità del 100% e, soprattutto, che gli investimenti periferici sono molto
importanti.
Attualmente, la grande rivoluzione nell’ambito dei sistemi informativi è caratterizzata
dalla tecnologia UMTS, provvista di una banda necessaria a mandare informazione
grafiche che, di certo, avrà uno sviluppo molto rilevante.
A questo punto è utile riportare alcune teorie elaborate agli albori dell’evoluzione
tecnologica che ha caratterizzato i sistemi informativi, ma che, ancor oggi, sono molto
valide; le quali si basano sul fatto che la rivoluzione dell’informatica è passata e
passerà attraverso lo sviluppo dei PC e delle tecnologie di rete:
Legge di Moore: ogni 18 mesi la potenza di elaborazione raddoppia a parità di costo;
2
L’integrazione tra Internet e la rete aziendale: soluzioni Intranet e gestione dei Data Base
Legge di Metcalfe: l’utilità di una nuova tecnologia è funzione del quadrato del
numero di potenziali utenti.
L’evoluzione e la diffusione delle tecnologie informatiche ha fatto sì che negli anni 90
sia stato possibile disporre di un pc connesso in rete su ogni scrivania. Tutto questo al
fine di condividere non solo file e stampanti, ma anche applicazioni fino a motori
SQL. Il livello raggiunto consente una semplice gestione delle informazioni attraverso
motori di ricerca come Altavista o Yahoo, per esempio. L’accesso stesso alle
informazioni è molto semplice ed indipendente dalla loro locazione fisica : basta
digitare un indirizzo Web (www.nomesito.com). Si tratta di informazioni di tipo
diverso (audio, video, etc.) integrate tra loro. A questo punto, però, il pc è visto non
tanto come strumento produttivo, quanto più come strumento di dialogo.
Negli anni 2000 l’informatica continua ad utilizzare le reti diventando così uno
strumento più pervasivo ed invasivo tanto da essere lo strumento principe per la
comunicazione e diffondersi sui sistemi embedded (auto-pc, wallet-pc, Web-tv, etc.).
In questo contesto assumono sempre maggiore importanza i sistemi di gestione della
conoscenza. A tutto questo si affianca il fatto che le aziende, dopo avere sistemato i
propri processi interni, sono pronte ad investire nei processi esterni. Si nota così un
cambiamento nell’economia anche solo osservando la capitalizzazione di mercato,
dove prima nella top ten non compariva alcuna azienda di software ed invece, ora,
molte hanno a che fare con il campo delle telecomunicazioni o basano la loro
conoscenza sul capitale intangibile (Oracle, Microsoft). Sullo sfondo si assiste al
passaggio dalla old economy alla new economy. Mentre la old economy si basa su
concetti come quello di segmentazione ed il suo valore orbita attorno al prodotto.
Nella new economy assumono maggiore importanza concetti come quello di
globalizzazione e di liberalizzazione, il valore è dato dalla conoscenza. Quindi si
passa da un’economia più stabile basata su asset fisici che non trae giovamento dai
progressi tecnologici ad un’economia che si basa su asset intangibili.
Il collaborative commerce tende a sostituire l’e-commerce, non ci sono più partners
precostituiti ma un’azienda deve essere pronta a dialogare con chiunque senza potersi
più chiudere informaticamente e operare sul mercato più ampio possibile. Sono,
quindi, necessari adattatori in grado di risolvere il problema dell’integrazione della
comunicazione dove i tempi di latenza dei flussi informativi devono essere di pochi
secondi.
Il sistema informativo di un’azienda deve consentire la comunicazione e la gestione
delle informazioni tanto al suo interno (tra settore e settore) quanto verso l’esterno
(partners, fornitori, clienti), in un’ottica di integrazione.
Se misurassimo il livello di integrazione in termini di ampiezza (dall'integrazione
all’interno di un dipartimento verso quella con partner sconosciuti) e in termini di
profondità (dalla semplice comunicazione di dati alla gestione in comune di processi),
scopriremmo che ad oggi il livello di integrazione è locale, o coinvolge al più i partner
conosciuti.
Il raggiungimento dell’integrazione globale tra aziende (cioè della combinazione max
ampiezza-max profondità) presuppone infatti l’ottimizzazione dell’integrazione tra
applicazioni. In questo senso i fattori cruciali sono due: la velocità e l’agilità delle
relazioni tra applicazioni.
Se dal primo punto di vista la situazione attuale appare soddisfacente (i tempi
necessari per svolgere numerosi processi aziendali interni e esterni si sono
sensibilmente ridotti), dal secondo punto di vista c’è ancora da lavorare.
E’ necessario, infatti, compiere la trasmigrazione dei sistemi informativi aziendali da
un’integrazione c.d. “a spaghetti” a una c.d. “a lasagne”.
3
L’integrazione tra Internet e la rete aziendale: soluzioni Intranet e gestione dei Data Base
La prima gestisce l’integrazione tra le applicazioni definendo i rapporti tra le relative
interfacce (gestione complessa e costosa per il crescente numero delle relazioni che
essa comporta al crescere delle applicazioni impiegate); la seconda è basata sulla
definizione di un unico sistema con cui tutte le applicazioni devono essere integrate e
che di conseguenza ne garantisce l’interoperabilità.
Ciò è possibile attraverso la definizione di una sorta di “piano regolatore”
(middleware) che detti regole comuni per lo sviluppo integrato delle applicazioni. In
tal modo si evita il problema della gestione dell’interfaccia tra innumerevoli
applicazioni (a spaghetti); infatti ogni nuova applicazione deve preoccuparsi
solamente di essere conforme al piano regolatore.
Come è ovvio laddove esista già un sistema informativo strutturato il passaggio da
un’architettura all’altra comporterà del tempo. Si tratta però di un passaggio
necessario per i “true” e-business, cioè per quelli che sono sopravvissuti al boom e al
successivo crollo delle aspettative su questo mercato. Data prova di solidità, infatti, il
loro processo di ottimizzazione non potrà prescindere dall’adesione a un sistema
integrato tra applicazioni, presupposto per l’appartenenza a un sistema integrato tra
aziende.
Aziende simili potranno infatti stare al passo con una realtà, quella del settore
tecnologico, estremamente dinamica. L’obbiettivo: fornire ciò di cui c’è bisogno in
tempi minimi e con modalità ottimali.
L’elevata frequenza di clock dello sviluppo tecnologico nell’era della comunicazione,
le grandi innovazioni tecnologiche ottenute dunque in tempi brevissimi (aumento
della capacità di calcolo, della velocità delle connessioni, del numero di utenti della
rete, dell’integrazione tra applicazioni, ecc.), il riconoscimento delle risorse IT come
variabile politica e economica strategica fondamentale, l’apertura alla concorrenza del
mercato delle telecomunicazioni, le disponibilità finanziarie investibili, lo stesso
atteggiamento innovativo di porsi verso i fatti consentono infine di fare qualche
previsione sui cambiamenti che tutto ciò porterà nella nostra vita quotidiana: non solo
l’uso massiccio di localizzatori, ma anche la larga diffusione di computer indossabili
sempre accesi e pronti alla comunicazione non è probabilmente molto lontana.
Modulo 2: L’evoluzione delle architetture di rete
Obiettivi
Il presente modulo si pone l’obiettivo di descrivere l’evoluzione nel tempo delle
architetture di rete: vedremo come dal primo modello di rete (time sharing), dove un
unico processo viene condiviso tra alcuni utenti (=terminalisti), si sia passati al
modello multitier, dove almeno tre processi interagiscono tra loro.
Riassunto
In ambiente informatico è possibile distinguere tre diversi livelli di comunicazione:
-fisico: tipologia del media utilizzato (es.:ISDN, Ethernet, ecc.);
-sintattico-sinottico: tipologia del linguaggio utilizzato (es.:TCP/IP);
-concettuale: tipologia del protocollo di comunicazione (es.:http).
TIME SHARING o Modello Primordiale
Il modello di time sharing è costituito da una macchina centrale (=main frame) a cui
sono collegati n terminali. La caratteristica peculiare del modello risiede
nell’accentramento di tutte le operazioni: le informazioni vengono gestite solo dalla
4
L’integrazione tra Internet e la rete aziendale: soluzioni Intranet e gestione dei Data Base
CPU centrale, non esistendo CPU periferiche, e suddivise tra gli n utenti secondo un
criterio temporale.
RESOURCE SHARING o Modello Classico
Dall’implementazione del Time Sharing nasce il resource Sharing: diverse unità
periferiche vengono collegate attraverso una piccola rete locale (LAN). Si parla di
relazione master-slave in termini di risorse: slave è il file server e master sono gli
utenti (=client), ciascuno dei quali dispone di una propria CPU.
MODELLO CLIENT – SERVER
Per alleggerire il lavoro del client viene implementato il modello client – server: in
questo contesto interagiscono due CPU (quella del client e quella del server)
attraverso uno standard di comunicazione (IPC=Inter Process Communication). Un
modello così strutturato prevede però una logica distribuita tra tutti i client.
MODELLO MULTI TIER
Questo tipo di architettura si basa sulla comunicazione tra processi di almeno tre
componenti: il Data Base, su cui opera il sistema di gestione; il Server Web, ove viene
collocata tutta la logica; i client.
Oltre alla distinzione architetturale di cui sopra, in ambiente di rete locale si può
ulteriormente distinguere tra il Modello Server dedicato, il modello Peer to Peer ed il
modello Misto per quanto concerne i ruoli che gli elaboratori ricoprono nella fornitura
dei servizi di rete..
Modulo 3: evoluzione del modo di progettare e scrivere le
applicazioni: dalle applicazioni monolitiche all’informatica
distribuita
Obiettivi
L’evoluzione delle reti informatiche condiziona profondamente la filosofia di
progettazione del software. Le applicazioni devono cioè adattarsi alla tecnologia e alle
macchine su cui vanno ad operare.
Riassunto
Le reti di tipo time-sharing, basate su un unico computer centrale (mainframe) al
quale si può accedere da diverse postazioni (terminali), non consentono l’utilizzo di
applicazioni distribuite. In questo modello si parla necessariamente di “applicazioni
monolitiche” residenti sul mainframe; ognuna di esse svolge tutte le operazioni di
gestione dei dati: archiviazione, modifica e visualizzazione.
La comparsa delle reti client-server, nelle quali le applicazioni o parti di esse possono
girare anche sui terminali (client), ha influenzato in maniera decisiva la filosofia di
progettazione del software imponendo nuove sfide. Ci si riferisce in particolare al
raggiungimento di efficacia/efficienza nello sfruttamento delle risorse di rete (server,
terminali client, periferiche) da parte di più applicazioni e all’integrazione e
comunicazione tra queste ultime, non sempre realizzate dalla medesima softwarehouse e concepite per il medesimo scopo.
Integrazione e snellimento delle applicazioni sono state le direttrici fondamentali del
processo di mutazione che ha interessato e interessa ancora oggi la progettazione del
software.
Nel caso dell’applicazione "monolitica" lo sviluppo del software era
onnicomprensivo. L’applicazione, lungi dal gestire soltanto l’interfaccia utente, era
costituita da numerosi componenti funzionali: le regole logiche (business rules), i
5
L’integrazione tra Internet e la rete aziendale: soluzioni Intranet e gestione dei Data Base
cursori, il motore di interrogazione database (query processor). La comunicazione
dell’applicazione con i database e gli altri processi software (inter-process
comunication) veniva garantita dalla presenza di interfacce proprietarie sviluppate dal
produttore al quale l’azienda si rivolgeva per il software. I difetti di tale struttura sono
evidenti: dipendenza economica da uno o pochi fornitori di software, difficoltà di
mantenimento del sistema elevata e scalabilità molto bassa. Si rischia poi la
proliferazione di interfacce non standard tra applicazioni e basi di dati.
Il modello sopra descritto viene progressivamente abbandonato rendendo più snella
l’applicazione e trasformando alcuni dei suoi componenti in oggetti indipendenti ed
esterni ad essa. Tale processo può beneficiare dell’affermazione di standard comuni di
esposizione e utilizzo delle fonti dati. Tra questi ricordiamo OLE DB (sviluppato da
Microsoft) e JDBC (relativo al mondo Java). Entrambi stabiliscono una serie di
formati e specifiche relativi ad "oggetti" fornitori di dati (data provider) e
consumatori di dati (data consumer). Lo standard di Microsoft, ad esempio, si basa su
un software unitario di accesso ai dati (ADO, Active X Data Object), integrato nei
sistemi operativi Windows a partire dalla versione Windows 95. Tale software si pone
tra l'applicazione e gli oggetti esposti OLE DB e rende possibile agire sugli oggetti
stessi, qualunque tipo di dato essi contengano.
In questa prospettiva è possibile alleggerire notevolmente l'applicazione, ad esempio
creando un query processor unico esterno ad essa e utilizzabile da altre applicazioni.
Tale elemento si configurerà come oggetto OLE DB, al contempo data consumer e
data provider. Quando anche le regole logiche vengono "portate all’esterno"
dell’applicazione come oggetti standard, si raggiunge un modello limite in cui
l'applicazione non svolge altro che la funzione di interfaccia utente (GUI).
Allo stato attuale il passaggio dal modello "monolitico" al modello "distribuito" non si
può dire compiuto. Siamo in molti casi giunti ad avere una struttura a tre livelli (three
tier): interfaccia grafica (coincidente con il browser HTML se l'applicazione è resa
visibile da Internet), regole logiche e livello di accesso ai dati.
In futuro probabilmente si diffonderanno software completamente distribuiti, costituiti
da un oggetto data consumer in grado di interfacciarsi con una gamma molto ampia di
oggetti esposti (i quali potranno avere di volta in volta ruoli di data consumer e data
provider).
Modulo 4: il middleware
Obiettivi
Definire il Middleware e descrivere le sue componenti principali. Esporre a grandi
linee le due principali implementazioni di MW con i rispettivi pro e contro. Fornire
una panoramica generale sulla terminologia e sull’architettura.
Riassunto
Benché originariamente si sia evoluto come supporto esclusivo per il modello di
accesso ai database, l’attuale contesto dell’Information Technology, imperniato su
architetture “three-tier”, individua nel Middleware l’elemento chiave per la
risoluzione dei problemi di integrabilità e di scalabilità delle applicazioni.
Nei modelli “three-tier” il client diviene meno pesante da gestire per l’utente, grazie
anche all’implementazione di interfaccia grafiche di intuitivo utilizzo. Ciò comporta,
altresì, che le problematiche logiche di gestione del sistema vengono spostate
sull’application server. La partizione delle differenti applicazioni distribuite deve
6
L’integrazione tra Internet e la rete aziendale: soluzioni Intranet e gestione dei Data Base
realizzarsi mediante la costruzione di infrastrutture composte da oggetti in grado di
comunicare ed usare i servizi messi a disposizione da altri oggetti. Ed inoltre, la
comunicazione deve avvenire in modo trasparente sia fra oggetti appartenenti allo
stesso spazio di indirizzamento, che a spazi di indirizzamento diverso e perfino tra
macchine diverse.
A tutto ciò assolve il Middleware, che quindi si pone come quella parte di software
che si distribuisce sulla rete interponendosi in generale tra l’utente e i dati, ed in
particolare tra applicazione ed applicazione, mantenendo uniti tutti i componenti di un
sistema distribuito.
Il middleware permette alle varie applicazioni di integrarsi e comunicare attraverso
interfacce standard potendo così disaccoppiare ogni applicazione dai più bassi livelli
di comunicazione, i quali includono i differenti sistemi operativi, le piattaforme
hardware e i protocolli di comunicazione.
Condizione necessaria per lo sviluppo di un sistema middleware è la disponibilità di
un metodo di accesso universale ai dati.
XML (Extended Mark-up Language), l’evoluzione dell’HTML, è lo strumento
standard a livello mondiale che il middleware usa per accedere e trasferire i dati da
una locazione ad un’altra attraverso il protocollo http.
XML permette di definire i tag secondo le preferenze del programmatore e tutto ciò
che si trova tra <tag> e </tag> identifica il determinato oggetto o la determinata
informazione. Segue le stesse regole sintattiche dell’HTML con tre differenze
fondamentali: il tag set è illimitato, ma ogni tag richiede una sua chiusura; i tags non
si possono sovrapporre; i tag XML non descrivono GUI, non c’è livello di
presentazione di default (XML usa solo tag che identificano i dati).
Esistono due implementazioni commerciali di middleware: una nell’ambito Java e una
nell’ambito Microsoft. Non si può fare un confronto assoluto tra le due perché l’esito
dipende dall’istante in cui si analizza la situazione, dato che la realizzazione di release
successive dei due concorrenti si susseguono superandosi di volta in volta.
Considerando la situazione di alcuni mesi fa i sistemi middleware erano Java e MS
DNA (Distibuited Network Application).
In Java l’interoperabilità del codice viene data dalla Java Virtual Machine (JVM) che
è una macchina virtuale che viene mandata in esecuzione nei browsers che supportano
Java. Quando un’applicazione Java viene scaricata su un browser esso riceve un
codice standard denominato bytecode (di tipo precompilato), compatibile per
qualunque piattaforma. L’interpretazione finale del bytecode viene lasciata alla JVM,
che farà da interfaccia tra l’applicazione precompilata ed il particolare sistema
operativo dell’hardaware sul quale risiede. In questo modo ci si può rendere
indipendenti dalla piattaforma hardware usata (infatti non serve più compilare il
codice delle applicazioni per ogni piattaforma, ma basterà precompilarla una volta per
tutte, visto che ad adattare il codice precompilato alla macchina particolare ci penserà
la JVM).
Microsoft fino ad alcuni anni fa rispondeva a Java con una interoperabilità fornita dal
browser. Tutto lo sviluppo veniva basato su oggetti win32, (cioè compilati
completamente) poiché Microsoft non accettava il sacrificio di prestazioni dovute alla
presenza di una macchina virtuale per utenti che comunque avrebbero usato sistemi
Windows. Con questo sistema gli oggetti già compilati chiamati COM o COM+
(Component Object Model) venivano inviati direttamente al browser. Nel caso
l’ambiente fosse stato Windows tale situazione veniva gestita tranquillamente con il
7
L’integrazione tra Internet e la rete aziendale: soluzioni Intranet e gestione dei Data Base
browser che mandava in esecuzione oggetti nativi dell’ambiente. Nel caso di altri
ambienti il browser, invece, doveva prendere l’oggetto binario compilato per
Microsoft e rimapparlo sulle chiamate scritte per il sistema operativo : tale operazione
non ha mai funzionato pienamente.
Risulta evidente come le due diverse logiche, appena esposte, siano figlie delle
diverse business aree generalmente servite da Sun e Microsoft : la prima privilegia
l’elemento hardware, la seconda quello software.
Per entrambe le piattaforme esistono dei linguaggi di scripting lato server denominati
JSP per Java e ASP per Microsoft. Un esempio pratico dell’uso di tali script si
riscontra nel caso in cui si voglia accedere a dei dati che si trovano su un server. Dal
client si interroga una pagina che deve accedere ai dati presenti sul server , il codice di
accesso ai dati viene codificato sul server tramite il linguaggio di scripting scelto. Non
appena la pagina viene richiamata essa manda in esecuzione lo script che preleva i
dati dal database server, li compatta in un certo modo e li rispedisce indietro al client.
Dal browser non si vede dunque la logica di accesso, ma si riceve solo il risultato
della query. In questo caso tutta la logica risiede sul browser: il formato dei dati che
viaggiano è semplice HTML.
Il vantaggio più importante di Java è dato dall’indipendenza dalla piattaforma ed in
effetti i System Integrator che forniscono prodotti su piattaforma multipla l’hanno
scelto principalmente per questo. Il supporto di terze parti è globale perché tutti
supportano Java tranne Microsoft, ed inoltre si riscontrano una crescente popolarità e
grandi investimenti sulle tecnologie. Il contro di rilievo non è tanto rappresentato
dall’immaturità della piattaforma, quanto dal fatto che lo standard si potrebbe
frammentare in futuro. Alcuni episodi hanno già dato forza a tale preoccupazione.
Tempo fa Sun richiese a W3C il riconoscimento di Java come standard. Questo ripose
in maniera positiva ponendo però la condizione che Sun pubblicasse le specifiche e
soprattutto che non pretendesse di usare il nome Java in modo proprietario. Sun
rinunciò a registrare Java come uno standard de iure anche se tuttora lo rimane de
facto, in quanto supportato da un accordo tra IBM, Sun, Oracle ed altri al fine di usare
specifiche comuni. Non è comunque certo che tali accordi verranno rispettati in
futuro: già ora IBM e non solo sta sviluppando delle specifiche Java proprietarie.
Probabilmente vi sarà una tendenza alla diversificazione arrivando alle versioni Java
di Oracle, IBM, ecc. (caso analogo al CORBA).
L’applicazione Java tipica è il Java Ecommerce B2B di fascia alta.
MS ha come pro la facilità d’uso, il fatto che si può raggiungere la produttività in
minor tempo, un supporto terze parti abbastanza elevato ed il contratto che garantisce
assistenza. I contro sono rappresentati dalla scalabilità che è garantita solo dai nuovi
sistemi operativi MS e dalla difficoltà nella transazione di generazione. Ciò decreta la
scarsa validità di una piattaforma di e-commerce in ambiente NT. Sarebbe, dunque,
opportuno adottare Windows 2000, ma il passaggio di versione può rappresentare un
problema in molte aziende.
Altro punto debole del MS DNA è costituito dall’interoperabilità su back end
(mainframe…): essa può venire risolta solo con Biztalk ed HIS che però operano
esclusivamente su piattaforma 2K.
Il punto di forza del sistema Microsoft è il suo Total Cost of Ownership:
l’applicazione costa meno ed è più facile trovare sviluppatori. In ogni caso la scarsa
scalabilità lo fa risultare buono solo per piccole e medie installazioni
L’elementare descrizione degli elementi fondamentali di un Middleware, che il
modulo si propone di offrire, viene operata analizzando Windows DNA
8
L’integrazione tra Internet e la rete aziendale: soluzioni Intranet e gestione dei Data Base
Il modello di sviluppo di applicazioni enterprise di Microsoft si articola su tre tier
(Presentazione, Logica del Business e Dati) correlati a Servizi di Sistema e a Tools.
Il Presentation tier può essere di diverso spessore. Ovvero può essere costituito da un
semplice browser (thin client) o essere molto ricco di logica (rich client). In
quest’ultimo caso esso può accettare download di software, applet, javabeans, active x
od altro, ed addirittura un eseguibile.
Al minimo livello c’è l’HTML, mentre all’estremo c’è il Win API 32 che è un
eseguibile che non gira nel browser. In mezzo ci sono lo SCRIPTING (lato client in
questo caso) che viene interpretato dal browser, i Components che sono oggetti Active
X o COM compilati in versione win32 e salvati sul sistema operativo e il DHTML
che è un modello di documenti ad oggetti avanzato che fornisce maggiore interattività
(dal lato client) e controllo. E’ costituito da librerie dll all’interno di Internet Explorer
(a volte anche su Netscape).
A livello di business logic Win2000 visto come server di applicazioni espone i
servizi: Security ( per la gestione delle password e degli accessi), Directory, Servizio (
fondamentalmente un web server sul quale possono girare script lato server in asp o
altro che volendo possono richiamare oggetti COM che operano nello spazio di
memoria di processo del server.
Vi è inoltre un Transaction Server che gestisce le transazioni (tipicamente bancarie).
Dopo che il sistema ha gestito ciascuna transazione tramite il Transaction Server esso
le accoda perché vengano gestite dal servizio di message queing; esso gestisce
l’asincronocità e invia un messaggio positivo al transaction server. Il transdaction
server chiude effettivamente la transazione quando ha risposte positive da tutti i
message queing. Si può dunque realizzare un sistema a componenti costituito ad
esempio da un Transaction Server ed un certo numero di Message Queing che
gestiscono la comunicazione verso partner di business.
L’accesso ai dati si effettua attraverso ADO (ActiveX Data Objects) che è Accesso
Programmatico Semplificato o attraverso OLDB e si usa XML per la rappresentazione
di dati basata su uno standard.
Tutti i sistemi di middleware hanno anche servizi di sistema (sistema di sicurezza, di
gestione, comunicazione, ecc.).
Negli ultimi mesi Microsoft ha sviluppato DNA eliminando la tecnologia proprietaria
ed introducendo il Common Language Runtime, analogo alla Java Virtual Machine,
che riceve in ingresso codice di livello intermedio e lo interpreta mandandolo in
esecuzione. Il CLR è progettato fin dall’inizio per offrire servizi web, da’ supporto
nativo ad XML e presenta all’interno dei web services. Il nuovo sistema si chiama
.Net (Dot Net). Particolarità rilevante: non è più necessario registrare i componenti.
E’ possibile scrivere un'applicazione .Net in qualsiasi linguaggio di programmazione,
a condizione che esista il compilatore che traduca il codice sorgente in intermediate
Language.
Le Rich class libraries (.net framework) costituiscono una libreria di base per
ADO.Net necessaria per accedere ai database
I windows forms servono per le applicazioni win32 che non necessariamente
debbano girare all’interno di un browser.
Per quanto riguarda le web application il linguaggio di scripting all’interno della
DNA diventa ASP.NET.
Riassumendo i componenti che un middleware dovrebbe avere sono: un sistema
operativo, un enviroment di run time, una libreria standard all’interno della quale ci
sono dei servizi di grafic user interface, Transaction Server, web scripting lato server,
9
L’integrazione tra Internet e la rete aziendale: soluzioni Intranet e gestione dei Data Base
10
accesso ai dati , ecc esposti per applicazioni via browser, servizi web , applicazioni
locali ed altro.
Modulo 5: Fondamenti e modelli di data base
Obiettivi
Definire un data base system e le sue componenti principali: il data base e il DBMS
(Data Base Management System). Chiarire il concetto di indipendenza fisica del dato
dall’applicazione che lo utilizza. Elencare i sistemi di Data Base.
Riassunto
Il sistema informatico può essere definito come la parte automatizzata del sistema
informativo, che a sua volta fa parte del sistema organizzativo del sistema azienda. Un
sistema informatico non può prescindere da quello informativo.
Dal momento che le informazioni si manifestano in molteplici forme, nelle attività
standardizzate nelle quali operano sistemi informativi complessi è stato necessario
introdurre forme di codifica che permettessero di utilizzarle in un modo efficiente ed
efficace (il codice fiscale ne è un esempio per quanto riguarda le informazioni
anagrafiche).
Nei sistemi informatici, in particolare all’interno dei Data Base, le informazioni sono
rappresentate in maniera essenziale attraverso il dato, elemento atomico
dell’informazione e della conoscenza e soprattutto risorsa strategica, perché stabile nel
tempo. È il data base quindi che, all’interno del sistema informatico, assolve la
funzione di raccogliere tutti i dati.
Una prima definizione di Data Base può essere quella di immaginarlo come una
collezione di dati, utilizzati per rappresentare le informazioni di interesse per una o
più applicazioni di un’organizzazione.
Da un punto di vista più tecnico-specifico il Data Base è definito come una collezione
di dati gestita da un DBMS (Data Base Management System). Appare
immediatamente evidente quali siano le due componenti fondamentali: i DATI e il
Sistema che deve gestirli.
Il DBMS è un software in grado di gestire ed organizzare un’insieme di dati che siano
grandi, persistenti e condivisi garantendo, allo stesso tempo, affidabilità, privatezza,
efficienza ed efficacia.
I dati devono essere grandi, cioè le dimensioni del DB devono essere maggiori della
memoria centrale del sistema di calcolo utilizzato.
I dati devono essere persistenti, quindi la durata di vita del dato non deve dipendere
dalla sua frequenza d’uso.
I dati devono poter essere condivisi da più applicazioni e da più utenti. Il data
base deve essere una risorsa integrata e condivisa tra i diversi settori aziendali. Sono
proprio l’integrazione e la condivisione che permettono di ridurre la ridondanza dei
dati e l’inconsistenza, cioè l’incoerenza, fra gli stessi.
Poiché la condivisione non è mai completa (o comunque non opportuna), i DBMS
prevedono meccanismi di definizione della privatezza dei dati e di limitazioni
all’accesso tramite autorizzazioni.
L’efficienza del sistema è sicuramente garantita da bassi tempi di risposta, ma
soprattutto è data dal risultato della qualità del DBMS e delle applicazioni che lo
utilizzano.
L’integrazione tra Internet e la rete aziendale: soluzioni Intranet e gestione dei Data Base
11
La gestione di insiemi di dati grandi e persistenti è possibile anche attraverso sistemi
più semplici. Un primo modo di pensare ad un DBMS è quello di pensare agli ordinari
file system dei sistemi operativi che permettono di realizzare anche rudimentali forme
di condivisione: i file system permettono accessi contemporanei in lettura ed esclusivi
in scrittura.
I DBMS estendono le funzionalità dei file system, fornendo più servizi in maniera
integrata ed efficacie. Nei DBMS c’è maggiore flessibilità: si può accedere
contemporaneamente a record diversi di uno stesso file o addirittura allo stesso record
(in lettura).
Nella gestione dei file, basata su File System, ogni programma contiene al suo interno
la logica di accesso ai dati (sono le istruzioni di dimensione e di campo) che devono
essere messe in testa a tutti i programmi che fanno la open su quel file di dati.
In un sistema come quello descritto, dove la logica di accesso è contenuta
nell’applicazione in un codice (scritto in linguaggio di programmazione, spesso in
COBOL), gli svantaggi nascono laddove sia necessario apportare modifiche alla
struttura della base di dati o effettuare un aggiornamento degli stessi. A tale proposito
l’anno 2000 è stato significativo per l’implementazione di DB dove la logica
d’accesso ai dati non fosse mescolata con l’applicazione che li utilizzava.
Ciò a cui bisogna puntare è l’INDIPENDENZA fisica DEL DATO. Le applicazioni
non fanno riferimento direttamente alla struttura fisica dei dati, che potrà essere
modificata senza la necessità di aggiornare i programmi.
L’indipendenza si ottiene attraverso il cosiddetto modello dei dati che è un insieme di
costrutti utilizzati per organizzare i dati di interesse ed eventualmente per descriverne
la dinamica. Esistono quindi dei meccanismi di strutturazione (o costruttori di tipo):
come nei linguaggi di programmazione esistono meccanismi che permettono di
definire nuovi tipi, così ogni modello dei dati prevede alcuni costruttori; ad esempio,
il modello relazionale prevede il costruttore relazione, che permette di definire insiemi
di record omogenei.
Vediamo ora di definire meglio cos’è un DBS.
Un DBS (Data Base System) è un sistema computerizzato di gestione di records,
deposito di informazioni sul quale uno o più utenti sono in grado di aggiungere,
estrarre, modificare, cancellare dati e file. Esso è composto da tabelle (records e
campi) e da un linguaggio standard che si chiama SQL (Structure Query Language).
Questo linguaggio è strutturato in una serie di istruzioni caratterizzate da una certa
sintassi molto più semplice rispetto al linguaggio di programmazione COBOL.
Un DB System ha le seguenti componenti:
SCHEMA: è la struttura (quante tabelle, quanti campi);
ISTANZA: è il contenuto;
DATI: sono organizzati in record e campi, disponibili su piattaforme diverse,
possono essere mono-utente o multi-utente, devono essere integrati e
condivisi;
HARDWARE
SOFTWARE
o DBMS che si interpone tra l’hardware e l’utente ed è in grado di
interpretare le stringhe SQL; queste istruzioni viaggiano secondo degli
standard di comunicazioni (TCP/IP, OLE DB, ecc…)
o UTILITY;
UTENTI
o Finali; che utilizzano del sistema tramite applicazioni,
L’integrazione tra Internet e la rete aziendale: soluzioni Intranet e gestione dei Data Base
12
o Occasionali; i progettisti del DB e i programmatori che, normalmente,
sono figure esterne all’organizzazione aziendale, o gli
o amministratori del DB che sono figure professionali interne.
Quindi il Data Base è una collezione di dati persistenti che è usata dal sistema di una
certa azienda (organizzazione tecnica, commerciale, scientifica).
I principali vantaggi d’uso di un data base, nel caso della mono-utenza, sono
rappresentati da informazioni più compatte, da un’estrazione più veloce, da una
manutenzione più agile e dalla possibilità di eseguire calcoli. In caso di multi-utenza,
ai precedenti vantaggi si aggiungono: il controllo centralizzato, la consistenza,
l’integrità dei dati e la sicurezza.
In generale, al livello dell’organizzazione che lo utilizza, con un DBMS si possono
ottenere i seguenti vantaggi:
I dati sono considerati come un risorsa comune;
La base di dati fornisce un modello unificato del business;
Permette un controllo centralizzato dei dati consentendo standardizzazione
ed economie di scala;
Riduzione di ridondanze ed inconsistenze;
Condivisione e integrità dei dati;
Sicurezza.
D’altra parte implementare un DBMS comporta elevati costi sia per l’investimento
iniziale che per la gestione della complessità del sistema.
Ad ogni modo, il vero grande vantaggio è dato dall’indipendenza fisica del dato dalle
applicazioni che lo utilizzano.
L’architettura Standard (ANSI/SPARC) a tre livelli per DBMS può essere interpretata
come una rappresentazione di tale enunciato.
L’architettura prevede l’inserimento di tre livelli (=schemi) che si interpongono tra
l’utente che utilizza l’applicazione ed il DB.
Il sistema è composto da n applicazioni che utilizzano i dati contenuti nel data base.
L’applicazione per funzionare deve arrivare al dato, ma per evitare una dipendenza
fisica tra la prima e il secondo vengono introdotti tre schemi:
Uno schema interno, che ha il compito di mascherare i dettagli di scrittura su
disco, in pratica si prende cura di implementare il DB sul sistema operativo e
su una macchina predefinita;
Uno schema logico, che rappresenta la struttura secondo la quale i dati sono
organizzati, definisce, quindi, quali sono le entità e quali sono i campi.
n schemi esterni, che, per mezzo di strutture fisiche di memorizzazione create
ad hoc per l’applicazione che le utilizzano (nei DB relazionali si chiamano
Viste o View), sono una serie di proiezioni dello schema logico. In altre
parole, si tratta di un’esposizione del dato all’esterno; le viste non contengono
dati, ma puntatori a dati fisici.
Quest’architettura rende il sistema espandibile: qualora si rendesse necessario
modificare un’applicazione, sarà sufficiente modificare le viste, su cui essa poggia, e
lo schema logico, senza correre il rischio che la altre applicazioni ne risentano.
Sistemi di basi di dati: I sistemi di basi di dati sono quattro:
L’integrazione tra Internet e la rete aziendale: soluzioni Intranet e gestione dei Data Base
13
file system: dove la logica di accesso ai dati è contenuta all’interno
dell’applicazione;
modello gerarchico: caratterizzato da una struttura gerarchica dei dati del tipo
uno a molti. L’insieme dei dati è strutturato ad albero e tra i dati vengono
stabilite a priori delle relazioni a puntatore fisico del tipo padre-figlio;
modello reticolare (network): nasce da un’implementazione del modello
gerarchico, il cui limite era quello di non poter gestire relazioni molti a molti:
in questo sistema il record partecipa a relazioni padre-figlio multiple. Il
programmatore può navigare nel data base dando anche le direzioni di
movimento. Il limite è rappresentato da una notevole rigidezza, dovuta al fatto
che le relazioni sono definite a priori;
modello relazionale: che sarà oggetto del prossimo modulo.
Modulo 6: progettazione di un database relazionale
Obiettivi
Individuazione delle regole fondamentali per la costruzione di un database
relazionale.
Riassunto
La necessità di rappresentare un insieme di dati attraverso un database relazionale
(DBR) implica un attento sforzo progettuale. Al progettista si chiede di interpretare
una determinata realtà (l’anagrafe di un ente locale, la gestione di un magazzino ecc.)
specificando e progettando le tabelle che andranno a formare il DBR, la loro struttura
(i campi che le compongono) e le relazioni che si instaurano tra di esse. Tali scelte
progettuali guideranno l’intero sviluppo del DBR, dalla fase di modellizzazione fino
all’implementazione pratica.
Un DBR è formato da tabelle e relazioni tra di esse. Ciascuna tabella deve
rappresentare un solo elemento del sistema che si cerca di descrivere, ovvero una sola
entità (sia essa oggetto o evento).
Ciascuna riga della tabella (record) dovrà essere unica, ovvero riferita ad un
oggetto/evento distinto e univocamente identificabile. La garanzia di questa univocità
è data dalla scelta di una chiave primaria (primary key, PK): un campo della tabella
viene cioè dedicato all’identificazione univoca della riga. Una tabella può avere una
sola chiave primaria.
Le chiavi primarie si suddividono in semplici (formate da un unico campo) e
composte (formate da due o più campi). L’utilizzo di PK composte è subordinato
all’effettiva necessità del progettista di legare due o più campi della stessa riga per
consentirne un’identificazione univoca.
Le caratteristiche ideali che le chiavi primarie dovrebbero presentare sono:
minimalità, stabilità e semplicità; per le PK si raccomanda, ove possibile, l’uso di
variabili integer, long integer o counter.
Le chiavi sono fondamentali nella creazione delle relazioni tra tabelle. Queste si
stabiliscono attraverso la specificazione all’interno di una tabella di un campo chiave
esterna (foreign key, FK) che verrà posto in relazione al campo-chiave primaria di
un’altra tabella. Mettendo in relazione la PK di una tabella con la relativa FK di
un’altra si creano le relazioni tra tabelle; a tal fine chiave interna e chiave foresta
devono appartenere allo stesso dominio.
L’integrazione tra Internet e la rete aziendale: soluzioni Intranet e gestione dei Data Base
14
Ecco un piccolo esempio: supponiamo di voler costruire un DBR degli attrezzi della
nostra rimessa costituito da due sole tabelle, “attrezzi acquistati” e “produttori
attrezzi”. Un produttore produce più tipi di attrezzi ma un attrezzo può essere prodotto
da un solo produttore. Onde evitare la ridondanza informativa e semplificare
l’intervento sui dati sarà opportuno inserire nella tabella “attrezzi acquistati” un
campo “id produttore” (FK) da mettere in relazione con il campo chiave primaria
della tabella “produttori attrezzi” (la quale collega univocamente l’identificatore
numerico del produttore al suo nome). E’ bene sottolineare a questo proposito che la
relazione tra le due chiavi non viene costituita attraverso un puntatore fisico. PK e FK
devono inoltre avere lo stesso dominio.
Le relazioni, in base alla loro complessità, si possono classificare in: relazioni uno a
uno, relazioni uno a molti e relazioni molti a molti.
La base di dati deve essere organizzata in modo efficace ed efficiente. Per raggiungere
questo obiettivo si applica un processo che viene definito “normalizzazione”. Si tratta
di una progressione lineare di interventi che conducono gradualmente
all’ottimizzazione del DBR. Naturalmente prima di passare alla normalizzazione
devono essere verificati i requisiti di base del DBR: le tabelle devono descrivere entità
singole e le righe devono essere uniche. Verificato che ogni tabella descriva singole
entità e che sia rispettata la relazionalità del DB attraverso l’assegnazione di un PK, si
può iniziare il processo di normalizzazione.
Le forme che il DBR assume nel processo di normalizzazione sono tre.
La prima forma normale (1NF) implica che tutte le colonne del DBR debbano
essere atomiche. Per ogni colonna è necessario cioè avere un solo tipo di
valore. Non ci devono inoltre essere unità ripetitive.
Seconda Forma Normale: Una tabella è detta in seconda forma normale (2NF)
se risponde ai criteri della prima forma normale e se ciascuna colonna dipende
(in senso stretto) dalla chiave primaria. I dati nelle tabelle devono essere
relativi ad una sola entità, l’entità descritta dalla primary key. Per raggiungere
la seconda forma normale si procede alla cosiddetta decomposizione,
spezzando il DBR in tabelle che descrivano entità separate.
Terza Forma Normale: Una tabella è detta in terza forma normale (3NF), se è
in seconda forma normale e se tutte le colonne sono indipendenti tra loro. E‘
necessario ad esempio eliminare le colonne “calcolate” e cercare di utilizzare
le tabelle di lookup, le quali rappresentano un’ulteriore scissione dei gruppi di
dati in componenti elementari.
In alcuni casi può rendersi necessaria l’operazione di denormalizzazione del database.
È un’ operazione che prevede la rinuncia alla terza (generalmente) forma normale e
talvolta anche alla seconda. Questo può succedere per volontà del committente oppure
quando si deve risolvere un problema di relazione “molti a molti” ricorrendo ad una
tabella di sponda per la quale al chiave primaria risulta essere multipla. Non si ricorre
alla denormalizzazione per ragioni banali ed è sempre utile farlo in maniera
consapevole, soprattutto per quanto riguarda le prestazioni del prodotto finale.
Nella costruzione di un database sono fondamentali le regole di integrità generali,
indicando quelle regole su cui si basa la scelta delle primary keys in ogni tabella e
quelle regole di integrità referenziale che determinano le relazioni tra tabelle. Vi sono
poi anche regole specifiche del database: le business rules . Si tratta di regole di
interità che non coinvolgono campi chiave (es: accetto l’ordine del cliente se ha già
L’integrazione tra Internet e la rete aziendale: soluzioni Intranet e gestione dei Data Base
15
effettuato il pagamento) e basate sull’uguaglianza di valori, tipiche di database
relazionali.
La progettazione di un database può essere inizialmente fatta su carta sin dal momento
in cui si analizzano, insieme al committente, gli obbiettivi della sua realizzazione. È
opportuna la costruzione di bozze dei form di data entry e delle tabelle. Infatti, la
struttura del database deve necessariamente fare riferimento a quello che l’utente
vuole vedere. Si farà riferimento a report esistenti ed in base ai nuovi report verranno
create le tabelle. A questo punto è utile inserire dati reali per capire meglio i domini
dei campi. Ancora su carta, si può iniziare la fase di normalizzazione e di
identificazione delle chiavi. Si stabiliscono i tipi di relazioni, implementando magari
tabelle di sponda per la gestione di relazioni “molti a molti”. Quindi si verifica che
siano soddisfatte le forme normali e si passa ad un’eventuale denormalizzazione dove
ciò sia necessario. Tutto quanto visto fin’ora viene trasferito in tabelle e relazioni su
Access consentendo la creazione di queries, forms e reports, ottenendo un prototipo
che può esere mostrato al cliente. Quindi si torna al progetto aggiungendo le business
rules e facendo le modifiche finali a forms e reports prima del test e della consegna
finale.
Non è ancora stata ottenuta un’applicazione multiutenza, per ottenerla è necessario
effettuare un’operazione di porting del database sotto motore SQL nella direzione di
un’architettura più complessa che prevede un database server gestito da un DBMS che
separi la logica dal front end, l’unica parte che viene lasciata sul client. Allora si
procede alla separazione del prototipo in due file: uno contenente i dati e l’altro
contenente il front end. I due sono collegati attraverso le ink tables. Attraverso
opportuni strumenti di porting i dati sono trasferiti sotto un motore impostando i
driver ODBC/OLEdb che permettono di collegare il front end di Access al motore
mantenendo la struttura creata in partenza. Si implementano i sistemi di sicurezza e
tutte le caratteristiche del motore. Si fa una verifica dell’utilizzabilità del database via
ODBC/OLEdb e quindi si può passare allo sviluppo del front end.
Modulo 7: database access from web servers
Obiettivi
Saper applicare le conoscenze ottenute in merito alla realizzazione di database in un
ambiente multitier focalizzando l’attenzione sui tre elementi: Browser, Logica, Dati.
Illustrare operativamente le modalità di accesso da parte del browser ai dati residenti
su un database remoto, attraverso uno strato di logica scritta sul web server.
Riassunto
Esistono diverse tecnologie per sviluppare applicazioni lato server che consentono lo
scambio di informazioni tra database e browser. Il primo metodo che è stato utilizzato
è quello che ricorreva a una Common Gateway Interface (CGI): presso il web server
viene installato un gateway comune per tutti i siti che risiedono su quel server. Il web
server lancia le applicazioni direttamente nell’URL: la stringa di attivazione nell’URL
passa i parametri all’applicazione, che interroga il database e restituisce i risultati al
browser.
La tecnologia CGI presenta notevoli problemi:
Gira in un processo distinto dal web server; ogni istanza gira in un processo
diverso, con una conseguente moltiplicazione dei processi al crescere del
numero di utenti;
L’integrazione tra Internet e la rete aziendale: soluzioni Intranet e gestione dei Data Base
16
L’applicazione può essere scritta solo con linguaggi complessi come ad
esempio C, C++, Perl, concedendo quindi una scarsa flessibilità nello
sviluppo.
Di più recente implementazione è la tecnologia basata su ISAPI (Internet Server
Application Program Interface): sono interfacce di programmazione specifiche per
programmare in ambiente web. Il servizio è integrato a livello di kernel del sistema
operativo, garantendo un maggior controllo e una maggiore velocità. L’applicazione
gira nello stesso spazio di memoria del web server. Anche in questo caso non è però
previsto un ambiente di scripting per lo sviluppo delle applicazioni, che devono essere
scritte in C o C++. Netscape ha sviluppato l’ambiente NSAPI, del tutto simile
all’ISAPI.
La soluzione Microsoft è rappresentata dall’IIS (Internet Information Server), che gira
su Windows 2000 Server (che garantisce i servizi di trasporto,sicurezza e gestione);
sopra c’è uno strato di API che l’utente non può vedere.
Per consentire la comunicazione tra le applicazioni e le ISAPI, si interpone uno strato
di software di gestione semplice (tranne nel caso di contenuto statico di tipo HTML,
che non abbisogna di API):
Se si tratta di un database, attraverso lo standard ODBC poggerà su un
Database Connector che rimapperà le chiamate al filtro ISAPI;
Nel caso di un server di posta, la stessa cosa avverrà con l’interposizione di un
web connector;
Nel caso di applicazioni Legacy, bisognerà costruire estensioni custom dei
filtri ISAPI, specifiche per quelle applicazioni.
Il meccanismo di funzionamento è il seguente: dal lato utente il browser invia una
stringa in protocollo http al server web che lancia un programma (scritto in CGI,
ISAPI, o altro) nominato nell’URL; esso tenendo conto dei parametri che gli vengono
passati manda le informazioni a un API (ODBC, Oracle OCI, ecc.). Quest’ultimo usa i
dati passati per creare una stringa SQL da inviare al database il quale restituisce dei
dati. Questi vengono ripresi dal programma (ISAPI,CGI, ecc) che li unisce al
contenuto HTML in modo che il web server possa restituirli in formato semplice
all’utente.
In questo caso il codice HTML risulta così inglobato nel codice C, C++ o Perl
rendendo l’editing grafico più difficile in quanto anche una leggera modifica
comporta conoscenze di programmazione non proprio banali.
Un lungo dibattito è sorto dunque dal dilemma tra l’adozione della soluzione che vede
l’aggiunta di html al codice o la codifica in html.
Si è pensato di proporre un ibrido tra le due soluzioni facendo in modo che il
programma scritto ancora in C, C++ o Perl potesse accedere ad un template esterno
scritto in html passandogli i parametri e potesse così presentare le informazioni
richieste sulla base di tale modello. Ciò implicava comunque problemi legati alla
maggiore complessità di gestione dei collegamenti tra i documenti.
Sviluppi più recenti si rifanno al middleware e quindi alla tecnologia Java, MS DNA e
.NET.
In MS DNA si utilizza Active Server Page, uno scripting lato server. Il codice viene
sintetizzato in pochi elementi: un file di testo, una stringa di estrazione del dato, il
nome del server, e del codice html che è necessario per dare un formato alla
presentazione dell’informazione; per accedere ai dati viene usato OLEdb o ODBC.
In ambiente Java cambiano sostanzialmente solo i nomi, ma le tecnologie sono simili:
JSP per lo scripting, EJB e JDBC per accedere ai dati.
L’integrazione tra Internet e la rete aziendale: soluzioni Intranet e gestione dei Data Base
17
In .NET si usa ASPx come linguaggio di scripting, OLEdb.NET per l’accesso ai
database. Il funzionamento di questo sistema middleware è simile a quello descritto
per la soluzione precedente. Esiste sempre un server alla base e dei filtri ISAPI: la
differenza è in questo caso nel fatto che tutti i vari connettori vengono raccolti in un
Framework Runtime che permette di isolare i processi, tracciare gli utenti e lo stato
delle applicazioni.
Il database viene raggiunto in maniera più semplice e diretta. L’enviroment ASP, JSP
o ASPx permette di scrivere semplici scripting che vengono interpretati server side,
evitando i linguaggi che necessitano di compilazione. La connetivitàè ai database è
inoltre nativa attraverso ADO o OLEdb.In questo caso allo sviluppatore viene
richiesto di conoscere solamente il modo di interagire tra server web e ADO.
Esempio di codice:
Per preparare un codice html-Vbscript di accesso ad un database è sufficiente
effettuare semplici operazioni:
- Preparare la form con un editor html
- Selezionare il recordset dal database definendo object id e scripting language e
aprire il recordset rispettando una particolare sintassi.
- Implementare la procedura di visualizzare il dato.
- Implementare i comandi per muoversi nel recordset.
