Architetture per lo sviluppo di applicazioni distribuite per OS/390

Transcript

1 Università degli studi di Firenze Facoltà di Ingegneria Anno accademico 1999/2000 Corso di Ingegneria del Software Prof. Giacomo Bucci Elaborato di fine corso In collaborazione con la Cassa di Risparmio di Firenze Architetture per lo sviluppo di applicazioni distribuite per OS/390 Aprile 2000 Gerardo Poggiali

2 1. Sommario 1. Sommario 2 2. Introduzione Architetture per applicazioni distribuite OS/ Panoramica delle tecnologie di connessione con OS/ Tecnologie di porting della sola interfaccia utente Tecnologie di collegamento a programmi Tecnologie di trasferimento dati Architetture per lo sviluppo di applicazioni distribuite Modelli di archi tetture Programmazione distribuita per componenti Oggetti e componenti Oggetti distribuiti Business object e application server MS SNA Server / COMTI Os/390 Component Broker Sviluppo di software con componenti distribuiti Definizione di un protocollo standard di comunicazione EDI, UNIMARC, SGML e HTML XML Riuso ed integrazione di applicazioni e codice preesistente Aspetti di ingegnerizzazione del software Conclusioni Bibliografia 32 2

3 2. Introduzione La necessità di comunicazione di ambienti mainframe centralizzati verso ambienti eterogenei (dunque non limitati alla consueta interfaccia terminale 3270) nasce da diverse motivazioni: - Necessità di integrazione con altri prodotti di office automation in ambiente PC (Word, excel, ecc.) - Servizi e-business su Internet - Realizzazione di servizi non applicabili all interfaccia terminale (call center, Fax on demand, servizi business-to-business ecc.) - Miglioramento della produttività e/o appetibilità di servizi precedentemente realizzati. Negli ultimi venti anni sono state sviluppate numerose soluzioni in concomitanza alla rapida evoluzione dell informatizzazione della società, all evoluzione delle reti di telecomunicazione, alla recente esplosione della telefonia mobile. Se da una parte queste hanno permesso uno short time-to-market per le nuove applicazioni, come effetto collaterale hanno introdotto numerose problematiche: - Scarsa scalabilità delle soluzioni proposte - Proliferazione di metodi di interfacciamento diversi - Forte dipendenza dalla piattaforma usata per lo sviluppo - Complessa manutenzione ed integrazione dei servizi In questo testo viene presentata una panoramica dei principali metodi di interfacciamento, vengono approfondite le soluzioni che beneficiano delle recenti tecnologie al fine di tentare di proporre una architettura per lo sviluppo di applicazioni distribuite per ambienti eterogenei che presenti i seguenti requisiti: - Basata su standard - Indipendente dalla piattaforma - Conservativa verso le applicazioni legacy già realizzate - Scalabile Altro aspetto di rilievo richiesto è la facilità di ingegnerizzazione del software, pensando alla necessità di dare in outsourcing parte del lavoro. Nel testo si fa riferimento a soluzioni per ambiente OS/390 di IBM, anche se la forte offerta di mercato in questo ambito permette di comporre soluzioni analoghe per altri ambienti mainframe Architetture per applicazioni distribuite Prima di entrare nel dettaglio della trattazione delle varie metodologie con cui è possibile realizzare applicazioni distribuite conviene cercare di formalizzare meglio il concetto di distributed application architecture. 3

4 Consideriamo dunque un esempio tipico di sistema informativo di una azienda o di qualsiasi altro ente che ne faccia uso. Esso risulta essere composto da: - una serie di unità di elaborazione e di interfacciamento verso l esterno (questi sono naturalmente i computer, ma anche dispositivi di acquisizione e distribuzione dati come strumenti di misura, macchinari programmabili, ed altro) - una rete o un insieme di reti di telecomunicazioni che prevedono uno scambio di informazione fra essi. - Un insieme di software e di protocolli di trasmissione che regolano il funzionamento dell intero sistema. Su un sistema di questo tipo è possibile realizzare servizi attraverso lo sviluppo di applicazioni che risultano dunque distribuite in quanto coinvolgono un insieme di strutture distinte fisicamente e geograficamente. La scelta dei prodotti hardware e software coinvolti determina le caratteristiche del sistema, il suo funzionamento e la sua programmazione, per architettura si intende dunque l insieme di queste informazioni. Notiamo inoltre che la definizione dell architettura del sistema definisce uno o più modelli di programmazione (programming model), ovvero l insieme di operazioni che gli sviluppatori devono svolgere per produrre e mettere in opera una applicazione del sistema. Per chiarire meglio questo concetti è conveniente riferirsi ad un caso concreto come, ad esempio, il sistema informativo di una banca. Mainframe Corporate Business UN/EDIFACT UNIX APPC OS/390 OS/390 OS/390 DRDA MVS SNA/ COMTI Business-to-business Windows NT SNA Terminale 3270 SNA/ MQ Series Filiale WAP Home Banking Cellulari, palmari, PC ecc HTML UNIX Windows NT Oracle PC PC ODBC PC DataWareHouse / OLAP 4

5 Aldilà delle sigle dei protocolli e delle tecnologie indicate che saranno specificate più avanti in questo documento si nota come le piattaforme software e hardware ed i prodotti coinvolti siano particolarmente vari. Questo dipende sia dal fatto che il sistema non è stato sviluppato tutto nello stesso momento (servizi come Home Banking e WAP sono relativamente giovani), sia da problematiche particolari di determinati settori (si vede come, ad esempio, la filiale abbia bisogno di un suo server che le garantisca il funzionamento se disconnessa dal mainframe). Il risultato è che tutto ciò richiede numerosi modelli di programmazione diversi, l adozione di protocolli incompatibili fra di loro, una complicazione del flusso dei dati. Ad esempio il programmatore che sviluppa procedure in modalità terminale su mainframe sviluppa codice scritto in formato COBOL/CICS; viceversa il programmatore che sviluppa applicazioni di home banking su Web programma applicazioni ASP che accedono a dati su mainframe attraverso servizi COM. L architettura determina dunque i modelli di programmazione con i quali si sviluppano le applicazioni, i modelli di programmazione determinano le conoscenze e le figure professionali coinvolte nello sviluppo. La formalizzazione di questo scenario ci permette di capire quali siano i problemi che una moderna azienda trova nel definire l architettura del proprio sistema informativo: - E necessario che risponda alle esigenze dell azienda, ovvero deve permettere di realizzare i servizi e garantire adeguate performance - Deve essere dinamica, ovvero adeguarsi alle nuove necessità (nuovi servizi, maggior carico di lavoro) - Deve permettere di realizzare velocemente nuovi servizi - Deve essere economica (costare il meno possibile, garantire nella sua evoluzione gli investimenti fatti) - Deve essere pensata valorizzando figure professionali e risorse già presenti in azienda - Deve essere aperta (Open architetture), ovvero deve permettere il contributo e l integrazione di altri sistemi informativi appartenenti ad altri soggetti coinvolti nel business dell azienda OS/390 OS/390 è una famiglia di sistemi di elaborazione, prodotta da IBM, collocati nella fascia di mercato mainframe. Sono macchine che presentano una elevata capacità di elaborazione nell uso in multiutenza progettate per garantire nel loro funzionamento un alto livello di affidabilità e di disponibilità. Si tratta della diretta evoluzione (come fascia di mercato e di utilizzo) dei precedenti sistemi S/360, S/370 e successivi; ovvero la famiglia MVS. Le ultime realizzazioni prevedono architetture multiprocessore in tecnologia CMOS a metallizzazione in rame a frequenze di oltre 600 Mhz. 5

6 Una complicata infrastruttura di prodotti software permette una gestione ottimale del carico di lavoro sui vari task in esecuzione, funzioni di logging e di recovery per garantire l atomicità delle transazioni, la sicurezza ed una alta disponibilità. Altra prerogativa del sistema è la capacità di clustering di più macchine in modo da poter aumentare le performance generali del sistema e di garantire il funzionamento in caso di blocco di una delle macchine, la connessione ad alta velocità avviene attraverso una tecnologia proprietaria di IBM chiamata Sysplex. Il sistema può essere programmato nei tradizionali sistemi CICS, IMS e DL\I, oppure anche con tecnologie più recenti come C++ e Java. La persistenza dei dati è affidata ai file VSAM, al DBMS DB2. Sono inoltre disponibili file system di vario tipo che permettono l accesso e la condivisione dei file in ambiente UN*X e Windows. 6

7 3. Panoramica delle tecnologie di connessione con OS/390 In questa prima parte viene sviluppata una panoramica delle principali tecnologie di interconnessione verso ambiente host partendo dalle tradizionali fino a quelle che coinvolgono i più recenti trend del mercato. L analisi delle singole metodologie permette infatti di capire pregi e limiti dei vari approcci, per quali motivi determinati prodotti si sono imposti sul mercato e quali limitazioni o benefici hanno prodotto a chi ha sviluppato su di esse il proprio sistema Tecnologie di porting della sola interfaccia utente Fino da quando al semplice terminale è stato sostituito il personal computer i produttori hanno iniziato a trovare tecnologie che permettessero di far parlare i due mondi in modo produttivo. La rapida evoluzione del prodotto PC ha reso l interfaccia terminale anacronistica e poco gradita all utente, la successiva introduzione di Internet ha reso necessario ancora una maggiore cura della veste grafica e semplificazione dell interazione, in modo da ottenere una omologazione al modello di ipertesto offerto dalle pagine Web; a causa di tutto ciò è risultato necessario adeguare l interfaccia utente agli standard di mercato con prodotti specifici. Il funzionamento di questi prodotti segue sempre lo stesso schema: l output del terminale viene trattato in modo da adeguarsi al contesto in cui deve operare. Questo permette di non modificare le applicazioni COBOL CICS o IMS già realizzate e funzionanti e garantisce che tutta la logica applicativa rimanga là dove è sempre stata, nel mainframe. Di contro la scarsa versatilità del sistema costringe i programmatori a trovare escamotàge che possono portare a malfunzionamenti difficili da identificare e rende le applicazioni difficili da mantenere. Si parla di screen scraping indicando solitamente una API che fornisce l accesso ad una mappa (screen image) dei terminali 3270 o 5250 permettendo al programma che gira su PC di recuperare direttamente le schermate fornite dal mainframe. Questa tecnica è diventata particolarmente in voga ultimamente con la necessità di pubblicare servizi già sviluppati su mainframe in modo che essi siano fruibili da browser HTML. La tecnica di funzionamento in questo caso è ancora più semplice in quanto l interazione con il terminale assomiglia molto al tipo di interazione che si svolge con un comune browser. Esistono numerosi prodotti di questo tipo in commercio che differiscono fra loro tra la versatilità delle funzioni offerte e sulle piattaforme di riferimento; per una descrizione dettagliata del funzionamento di prodotti di questo tipo faccio riferimento ad un prodotto della ditta Informatica S.p.A. di Torino di nome Halloweb. 7

8 Come si vede dalla figura il software di emulazione terminale controlla la connessione con il mainframe (in questo caso si tratta di un piccolo applicativo Java sempre attivo sulla macchina). Questo software viene pilotato da un componente del Web server (in questo caso una ISAPI per Microsoft Internet Information Server) che produce le pagine HTML che vengono visualizzate dal Web server. Attraverso una programmazione di tipo script questi prodotti permettono di ottenere un certo tipo di controllo sull output ottenendo soprattutto l effetto di migliorarne la veste grafica in modo che sia omogenea con il sito Web di cui fanno parte; in questo modo è possibile trasformare moduli e menù di programmi COBOL che usano il BMS del CICS in link e form HTML. E evidente come questo sistema renda complicate le modifiche in quanto prevede la stabilità delle applicazioni CICS a monte: infatti ad ogni modifica di quest ultime risulta necessario rivedere gli script che effettuano la trasformazione da output terminale ad HTML. Inoltre le performance di un sistema di questo tipo sono fortemente limitate dall overhead introdotto dall architettura del sistema: per accedere ad una pagina è necessario attivare una sessione del terminale, effettuare l elaborazione per la trasformazione dell output, visualizzare la pagina; questo rende improbabile l uso intensivo di tecnologia di questo tipo. Nonostante queste limitazioni lo screen scraping è ad oggi il modo più usato per pubblicare su Intranet e Internet pagine dinamiche con dati da mainframe. E evidente 8

9 che i limiti di manutenibilità e di scalabilità rendono questa soluzione sufficiente solo a piccole applicazioni fuori dal core business dell azienda. Tecniche simili sono impiegate da numerosi software di emulazione terminale che permettono di automatizzare determinate operazioni, anche in questo caso l elaborazione viene guidata da linguaggi di tipo script. Uno standard in questo senso sono le HLLAPI (High Level Language API) definita nel 1984 da IBM Tecnologie di collegamento a programmi Là dove la semplice trasformazione dell interfaccia terminale non può bastare è necessario stabilire una connessione più avanzata tra client e mainframe. Una prima possibilità è data dalle tecniche che permettono la comunicazione tra programmi residenti su host diversi: alcune di queste sono nate sono specifiche dell ambiente IBM (APPC LU6.2), altre sono state importate dai sistemi Unix (RPC). A queste si sono recentemente aggiunti i protocolli CORBA e DCOM i quali entrambi mirano a risolvere il problema della comunicazione tra programmi adottando un paradigma object oriented. Prodotti come Microsoft SNA Server e IBM OS/390 Component Broker si rivolgono appunto a questo mercato, dato che però questi introducono soluzioni che coinvolgono tutta l archiettura del sistema verranno trattati in dettaglio più avanti. Rispetto al solo porting dell interfaccia utente tutte queste tecniche prevedono che i programmi sul mainframe siano scritti in modo diverso: questi non prevedono più mappe a carattere (CICS-BMS) ma stringhe di dati che comunicano da e verso i client; questo può richiedere dunque la riscrittura di parte del software. Di contro soluzioni di questo tipo sono di gran lunga più efficienti ed è possibile realizzare sistemi con una architettura più complicata: a titolo di esempio basta notare come una applicazione basata su tecniche di porting dell interfaccia terminale non possono funzionare se disconnesse dal mainframe, è invece possibile fare applicazioni che continuino ad operare senza collegamento con tecniche di connessione diretta ai programmi. APPC Advanced Program-to-Program Comunication (APPC), conosciuto anche come LU 6.2, è un protcollo che permette la comunicazione tra programmi situati da computer differenti; è disponibile per molte piattaforme da i PC ai mainframe, compresi gli ambienti Macintosh e UNIX. APPC essendo progettato per lavorare su rete SNA sposa completamente la sua logica di funzionamento, comprendendo le LU (Logical Units) e la gestione delle transazioni. 9

10 RPC RPC (remote procedure call) nasce su ambienti UNIX e prevede la comunicazione remota tra host connessi con rete TCP/IP. RPC è implementato nella stragrande maggioranza delle piattaforme e per molto tempo ha rappresentato l unico vero standard per questo tipo di problematiche. Il limite di adattabilità di RPC ad ambienti mainframe IBM sta nella non implementazione delle transazioni, per questo APPC è risultato comunque vincente in gran parte dei casi. Là dove la collaborazione con il mondo Unix rende preferibile l uso di RPC sono state sviluppate delle estensioni di RPC per supporto delle transazioni e un prodotto di nome Encina che implementa questo servizio su OS/ Tecnologie di trasferimento dati Là dove è possibile trasferire parte della logica applicativa al di fuori dell ambiente host può risultare conveniente effettuare un collegamento diretto ai dati piuttosto che ai programmi; in questo modo si sfruttano le proprietà di affidabilità e di sicurezza dell ambiente mainframe solo per quanto riguarda la conservazione dei dati, il compito dell elaborazione e della distribuzione viene invece riservate ad host esterni. Queste unità (Windows, Unix, MS-Dos, ecc.) di solito garantiscono una maggiore flessibilità e facilità di adeguamento ma presentano maggiori limiti nella garanzia del servizio e nella sicurezza. Esistono poi una serie di soluzioni in cui la duplicazione dei dati, per motivi di funzionamento fault tolerant o di ripartizione del carico tra DBMS, per cui queste tecniche diventano insostituibili. File Transfer Si tratta del primo e più semplice metodo di condivisione dei dati: in pratica si preparano programmi, detti talvolta estrattori, i quali elaborano informazioni e le impacchettano in file secondo una sintassi definita in fase di progetto, trasferiti dal mainframe verso l esterno con i servizi offerti dal sistema operativo (tipicamente protocollo FTP su TCP/IP). Si tratta di un modo di lavoro tipicamente asincrono dunque applicabile solo ad un limitato gruppo di casi; risulta in particolare adatto per la pubblicazione di informazioni contenute sull host verso altri sistemi. DRDA DRDA (Distributed Relational Database Architetture) è la tecnologia di riferimento sviluppata da IBM per accedere ai suoi prodotti DBMS su mainframe MVS, AS400 e altre piattaforme. In pratica si tratta di una serie di comandi che permettono di eseguire transazioni sul DMBS (tipicamente DB2) garantendo l integrità dei dati e la sicurezza. 10

11 I servizi di DRDA possono essere usati direttamente attraverso opportune API disponibili per numerose piattaforme, oppure attraverso altri layer generici alcuni dei quali object oriented come ODBC, JDBC, OLEDB. DRDA è usato da IBM per permettere anche la rappresentazione locale di viste di tabelle situate in sistemi remoti. ODBC Si tratta della tecnologia di accesso dei dati dominante in ambiente PC. Consiste in una API che permette di eseguire comandi SQL verso basi di dati relazionali (indipendentemente dalla piattaforma e dalla loro localizzazione sulla rete). La presenza di driver ODBC per la stragrande maggioranza di prodotti di DBMS e la possibilità di usare queste API facilmente in molti ambienti di sviluppo ha reso questa tecnologia estremamente diffusa e notevolmente affidabile. La realizzazione dei driver ODBC per piattaforme mainframe di IBM viene realizzata tramite i servizi di DRDA, ne esisto in commercio realizzazioni di vari produttori, come ad esempio Walldata ( e IBM stessa. OLE DB Può essere considerata come uno sviluppo di ODBC verso una interfaccia orientata agli oggetti, in pratica è molto di più; invece di usare una API viene usata una collezioni di classi che permette una migliore gestione delle interrogazione e dei dati di risposta. Questa tecnologia risulta anche adattabile a sistemi di database che non sono relazionali, come i file sequenziali VSAM. Nella pratica anche ODBC permette di trattare gli archivi VSAM attraverso comandi SQL fittizi che vengono poi tradotti in comandi di accesso ai file sequenziale, ma nel caso di OLEDB le prestazioni sono decisamente migliori. OLEDB è una tecnologia piuttosto giovane nonostante Microsoft punti molto su di essa: il suo miglior pregio sta nella capacità di accedere a qualsiasi tipo di dato, sia che sia contenuto in un grande DBMS che in un foglio EXCEL. D altra parte la pratica ha dimostrato che prodotti come questi hanno bisogno di un certo tempo per stabilizzarsi, in effetti ODBC ha raggiunto adesso la sua piena maturità dopo quasi dieci anni dalla sua introduzione. Nelle ambizioni di Microsoft OLE DB vuole essere qualcosa di più di un semplice metodo per chiamare in remoto query SQL: OLE DB si propone come meccanismo standard per la trasmissione di dati strutturati all interno di applicazioni distribuite su base Microsoft, in questo senso è prevista anche la trasmissione dei dati (i recordset) anche in formato XML. Un altro aspetto molto interessante di OLE DB è la capacità di usare in maniera avanzata eventuali servizi offerti dal middle tier: nel caso in cui dopo la lettura dei dati avviene una sconnessione dal data server è possibile ancora modificare i dati, al momento della nuova connessione questi saranno inviati e verranno gestiti i conflitti di le modifiche contemporanee di più client sulle stesse informazioni. 11

12 I driver OLEDB per mainframe IBM sono disponibili nella suite di connessione con Windows NT di nome Microsoft SNA Server. 12

13 4. Architetture per lo sviluppo di applicazioni distribuite 4.1. Modelli di architetture L evoluzione dell informatica ha permesso di sviluppare soluzioni diverse al problema di garantire un controllo centralizzato e contemporaneamente un più ampio possibile accesso ai dati: sono state così realizzate architetture che possono essere uniformate in modelli con complessità crescente che si sono susseguiti storicamente dall introduzione commerciale del computer fino ad oggi. Negli anni sessanta lo stato d arte dell elaborazione dell informazione consisteva in una unica e costosa macchina che eseguiva una solo programma alla volta. L introduzione intorno al 1970 del time sharing e dei minicomputer permise di aumentare l accessibilità. In letteratura ci si riferisce a questa architettura come single-tier o mainframe. Il nome sottintende alla struttura monolitica di questo modello in quanto interfaccia utente, logica applicativa e dati risiedono in un'unica unità di elaborazione. L inserimento sul mercato del primo personal computer nel 1980 e la sua rapida diffusione nell'industria produsse un approccio diverso al controllo dell informazione: l uso personale del computer infatti fornisce all utente la possibilità di gestire con maggiore autonomia il mezzo informatico aumentando la produttività individuale. Di contro vengono così introdotte numerose isole di informazione con scarsa capacità di collaborazione le quali diventano rapidamente inconsistenti l una con le altre; risulta così difficile garantire la sicurezza dei dati. Il primo client/server nasce proprio per risolvere questi problemi: l interfaccia utente e la logica applicativa viene eseguita sul client in un ambiente più flessibile capace di collaborare con altre applicazioni stand-alone, il database viene mantenuto sul server là dove può essere condiviso da più utenti e dove è possibile gestire il backup ed il recovery in caso di guasto. Questa struttura prende il nome di two tier ed è tuttora molto diffusa anche se nel tempo ha mostrato di avere alcuni difetti: - Risulta essere difficile da aggiornare e da mantenere - L elaborazione dei dati viene in parte eseguita dal client dunque in un ambiente difficile da rendere sicuro. Il modello two tier non è mai riuscito ad inserirsi nelle grandi strutture (aziende, banche, enti pubblici) se non in settori esterni al core business; su questo aspetto concorrono vari fattori come la presenza di sistemi mainframe già presenti e funzionanti o come lo scarso interesse di determinate aziende di riferimento in questo mercato (IBM, Bull). Forse però più di tutti ha pesato la scarsa affidabilità e scalabilità di questo tipo di soluzioni. 13

14 L informatica nella seconda metà degli anni 90 si è operata per superare questi limiti revisionando il modello client/server introducendo il concetto di middleware ed il modello three tier. L idea è quella di rimuove dal client la logica applicativa lasciando su esso la sola funzione di presentazione dei dati; la logica applicativa viene spostata in un ambiente condiviso in cui sia garantita la consistenza, il recovery e la sicurezza dei dati. DataBase DataBase DataBase Middleware Transaction Processing Monitor Logica Applicativa Client Client Client L introduzione del middleware rende l architettura più scalabile in quanto il transaction processing monitor (uno dei tanti servizi che può fornire al sistema un middleware) permette non solo di garantire l accesso a più database, ma anche di bilanciare le richieste dei client su più server e, in caso di guasto di uno di essi, continuare il lavoro con quelli rimasti. In generale la stratificazione dell architettura permette una maggiore flessibilità ed interoperabilità dei sistemi; si parla dunque di n-tier come la generalizzazione di un sistema three tier in cui ogni strato produce servizi per i livelli superiori ed inferiori. Dobbiamo inoltre pensare che un modello come questo può rappresentare solo un sottoinsieme di una struttura più grande che ad una visione più ampia può risultare enormemente più complicata Programmazione distribuita per componenti Contemporaneamente all evoluzione che ha portato alla definizione del modello three tier si sono affermate le metodologie di sviluppo del software orientate agli oggetti (Object Oriented Analysis & Design); la successiva introduzione sul mercato di protocolli standard per la comunicazioni con oggetti remoti (DCOM, RMI e CORBA) ha permesso di applicare compiutamente il modello OOA/OOD anche alle applicazioni distribuite. Una stratificazione dei livelli del sistema è tanto più efficace quanto meglio si riescono a mantenere indipendenti le parti di codice e quanto la progettazione e lo sviluppo 14

15 risulta ordinato: in questo l adozione di un metodi di sviluppo orientati agli oggetti è di grande beneficio. Ma non solo, la possibilità di sviluppo di componenti riusabili e combinabili facilmente per creare rapidamente nuovi servizi ha portato alla definizione di un nuovo concetto: l application server. Vediamo in dettaglio tutti questi argomenti Oggetti e componenti Seppur in molti casi vengono usati come sinonimi vale la pena di discutere della differenza che sussiste tra questi due termini: un componente, differentemente da un oggetto, è una entità funzionale che produce un servizio compiuto di per sé stesso. In questo senso si parla di modello di programmazione per componenti: i componenti possono essere venduti come prodotto a sé stante e possono essere usati in strumenti di sviluppo di alto livello che permettono di concentrarsi sulle funzioni piuttosto che sui dettagli implementativi. In un certo senso dunque la programmazione ad oggetti è un dettaglio implementativo, mentre la programmazione per componenti ha fini più economici e di progetto: riduzione dei costi e rendere più rapido lo sviluppo. D altra parte è anche importante osservare che, seppur possibile, è molto più difficile adottare un modello di sviluppo del software per componenti senza usare linguaggi e metodi di programmazione orientati agli oggetti Oggetti distribuiti Se una applicazione distribuita è un insieme di oggetti posti su macchine diverse che comunicano tra loro risulta dunque necessario definire un meccanismo che garantisca la comunicazione tra essi. E possibile che il programmatore si faccia carico di sviluppare autonomamente un servizio di questo tipo: in effetti da parecchio tempo esiste una tecnologia nota come RPC (remote procedure call), o alternativamente possono essere usati direttamente i servizi di protocolli di comunicazione come il TCP/IP. Sul mercato sono presenti prodotti che sollevano il programmatore da questa responsabilità fornendo una architettura standard. Uno di questi è DCOM, l estensione di COM per oggetti distribuiti. Il modello COM di Microsoft permette di assegnare ad una parte di codice una interfaccia, questa interfaccia viene registrata nel sistema cosicché qualsiasi applicazione che supporta questo modello può usufruire dei servizi esposti; l insieme del codice e dell interfaccia definisce un oggetto COM. 15

16 E importante notare che l oggetto COM non è un oggetto propriamente tale in quanto esso supporta sì l incapsulamento e una certa forma di polimorfismo, non supporta tuttavia l ereditarietà. Secondo il modello COM gli oggetti devono risiedere nella stessa macchina; viceversa DCOM estende COM per oggetti che risiedono su macchine diverse. Questo fa capire come DCOM nasca da meccanismi e necessità relative allo sviluppo su ambiente Windows per il quale offre ottima adattabilità e prestazioni notevoli. Alcune società di software come AG e IONA si sono poste l obbiettivo di permettere l interfacciamento con il mondo UNIX e la cooperazione con oggetti CORBA. CORBA viceversa è uno standard che mira a far cooperare piattaforme hardware e software diverse. Corba nasce dagli sforzi di OMG, un gruppo di lavoro di cui fanno parte molte aziende (tra cui Sun, IBM e Digital), che da circa sette anni lavora alla definizione di una architettura standard finalizzata alla creazione di applicazioni ad oggetti distribuiti. CORBA prevede che gli oggetti possono essere scritti e sviluppati su qualsiasi piattaforma per quale sia stato sviluppato un ORB (object request broker), sarà infatti CORBA ad occuparsi dei dettagli quale rintracciare l oggetto richiesto nella rete e trasformando la rappresentazione dei dati per adattarla alla piattaforma di destinazione. L obbiettivo successivo di OMG è quello di cercare di standardizzare anche i servizi di più alto livello quali ad esempio fornire un supporto per gli agenti mobili, l internazionalizzazione delle applicazioni e la gestione di un workflow dinamico fra oggetti. La possibilità di avere un oggetto facilmente accessibile e sfruttabile da qualsiasi programma offre due notevoli vantaggi: - nessuna ridondanza di codice - facilità di sviluppo Facciamo un esempio: in un ipotetico sistema informativo più programmi eseguono il controllo di correttezza del codice fiscale. Supponiamo adesso che lo Stato Italiano decida di introdurre una nuova codifica del codice per le persone nate dopo il 2002: sarà dunque necessario cambiare uno ad uno tutti i programmi. Se viceversa nel nostro sistema informativo avessimo avuto un solo oggetto che offre questo servizio sarebbe necessario modificare soltanto quello, tutti i programmi si adeguano di conseguenza. Supponiamo inoltre che lo Stato Italiano con enorme lungimiranza decida di offrire esso stesso un oggetto, che comunica in standard CORBA, per il controllo del codice fiscale. In questo caso nei programmi basterebbe fare riferimento a questo oggetto; in 16

17 questo caso lo Stato Italiano potrebbe introdurre qualsiasi modifica in qualsiasi momento dato che l adeguamento risulterebbe immediato. Questo esempio semplicistico descrive l impatto che soluzioni di questo tipo possono avere in un contesto di relazioni business-to-business, ottenendo così un sistema informativo con straordinarie doti di flessibilità Business object e application server Come visto uno dei concetti base nell uso del middleware risulta essere lo spostamento della logica applicativa fuori dal client per collocarla in un ambiente condiviso. Nel contesto del modello three tier gli oggetti che compongono la logica applicativa vengono chiamati business objects. I business objects sono il cuore dell applicazione in quanto ne rappresentano le funzionalità: altri oggetti si occupano della presentazione dell informazione (interfaccia utente) oppure della persistenza e dell ottimizzazione dell accesso ai dati. Inoltre grazie ai benefici della OOP lo sviluppo dei business objects è semplificato dalla possibilità di ereditare da oggetti standard che hanno già implementato le funzioni caratteristiche del middleware: - interfacciamento con il database - comunicazione con oggetti remoti - recovery - transazionalità L obbiettivo è dunque quello di sviluppare i business objects in un ambiente che già offra tutti questi servizi pronti da usare: si parla dunque di application server. La possibilità di definire degli standard tra application server permette ai produttori di software di fornire componenti pronti che possono essere applicati ad architetture molto diverse ma che condividono lo stesso application server. MTS (Microsoft Transaction Server) è la parte di Microsoft DNA (Distribuited Network Architecture) che meglio corrisponde al concetto di application server. Può essere visto come un contenitore di oggetti DCOM, per i quali offre anche un servizio di gestione delle transazione, di load balancing su più piattaforme. L interfacciamento alle base di dati è invece completamente demandato al modello OLE DB. Enterprise Java Beans è la soluzione l offerta da Sun nell ambito degli application Server. Più propriamente le EJB Specification sono un insieme di standard che specifica come scrivere Business Object in Java, Sun chiama queste entità Enterprise Java Beans, ovvero componenti scritti in Java per application server. In pratica descrive i modi con cui un EJB opera in ambito client/server, descrive come un EJB comunica con i vari client, come deve essere ottenuta la compatibilità con CORBA e le responsabilità dei vari componenti del sistema. 17

18 EJB sceglie dunque CORBA come ORB, inoltre essendo sviluppato completamente in Java rende i componenti completamente indipendenti dalla piattaforma, non è dunque necessario ricompilare o fornire i sorgenti per distribuirli su piattaforme diverse. Molte aziende hanno prodotto application server compatibili con EJB, in questo campo IBM è estremamente attiva con la sua serie di prodotti WebSphere. Si vede bene dunque come l application server è il naturale complemento ad un meccanismo di comunicazione tra oggetti distribuiti: esso infatti fornisce un framework sul quale sviluppare le applicazioni per componenti; così i componenti si possono comprare o sviluppare in proprio, si possono combinare per ottenere servizi più complessi, si possono trasferire o duplicare per rispondere a maggiori richieste MS SNA Server / COMTI Dopo aver introdotto il concetto di component broker e di application server è possibile introdurre con maggiore dettaglio i prodotti rivolti ad OS/390 per lo sviluppo di applicazioni distribuite secondo questi modelli. Microsoft SNA Server è una suite di prodotti per Microsoft Windows NT il cui obbiettivo è permettere una totale collaborazione tra reti Windows-based e mainframe della serie MVS e AS/400. In questo senso prevede una suite di strumenti di connessione che va da dal semplice emulatore di terminale fino a sistemi per condividere il modello di transizioni del mondo Windows a quello dei mainframe MVS. Di particolare interesse è il software COMTI (COM Transaction Integrator for CICS and IMS): si tratta di un prodotto che permette di trasformare programmi CICS o IMS in oggetti COM e di integrare le applicazioni sviluppate con MTS con le transazioni CICS. Per spiegare meglio le sue funzionalità può essere utile la descrizione dei task che conducono alla trasformazione di un programma su mainframe in un oggetto COM. Si parte dall analisi del programma CICS, esso non deve contenere logica per la rappresentazione su terminale, se così non fosse è necessario agire su di esso per renderlo conforme. A questo punto interviene il tool Component Builder: questo ha il compito di trasformare i tipi di dati COBOL negli equivalenti tipi del protocollo COM e definire il supporto transazionale. Se si vuole sviluppare un componente COMTI che supporti le transazioni il programma incapsulato sul mainframe deve supportare le richieste in modo transazionale (Sync Level 2 e Sync Level 0). Adesso il programma CICS può essere visto nel mondo Windows come un qualsiasi oggetto COM, per il programmatore che ne faccia uso non è possibile notare nessuna differenza da un oggetto COM sviluppato su direttamente per piattaforma Windows. 18

19 Tutto questo avviene sotto il controllo di MTS e di DTC (Distribuited Transaction Control), ovvero il rollback di una transazione tra oggetti remoti viene distribuito a tutti gli oggetti coinvolti e propagato fino al mainframe. Per Microsoft dunque una architettura distribuita è una collezione di oggetti di DCOM che interagiscano tra di loro: questi possono essere sviluppati con i tradizionali strumenti di sviluppo Microsoft come Visual Basic, Visual C++ ed altri. Si tratta di strumenti RAD che permettono di trattare gli oggetti DCOM con grande semplicità: una volta registrato un oggetto posto su una macchina remota non si notano particolari differenze nel suo uso rispetto a quelli locali, inoltre la gestione e l amministrazione della rete risulta estremamente rapida grazie agli strumenti forniti. Di contro questi servizi si basano profondamente sulle strutture dei sistemi operativi Microsoft tanto da rendere praticamente impossibile la loro implementazione su sistemi operativi diversi. Altro aspetto di interesse riguarda l evoluzione del sistema a lungo termine: via via che i programmi Cobol vengono integrati all interno di oggetti COM appare naturale spostare la logica applicativa fuori dal mainframe: in effetti perché continuare a sviluppare business object in Cobol per poi incapsularli in oggetti COM? Appare molto più proficuo il progressivo passaggio all uso di strumenti di sviluppo più rapidi come quelli offerti sul mondo Windows. In certe realtà, dove la garanzia del servizio è un fatture cruciale tutto ciò può risultare un limite: i risultati ottenuti in ambito mainframe in quanto ad affidabilità e continuità del servizio possono essere difficili da ottenere in ambiente Windows Os/390 Component Broker Component Broker è un application server per OS/390. Prevede la creazione di componenti con linguaggi Java e C++, inoltre attraverso questi linguaggi è possibile creare adapter o wrapper che incapsulano codice COBOL CICS o IMS per riusare il codice esistente. La programmazione di componenti in Java è inoltre compatibile con le specifiche di Enterprise Java Beans, in particolare per questo standard IBM prevede tools che coprono l intero ciclo di sviluppo: il componente può essere sviluppato con strumenti RAD che girano su ambiente Windows (in particolare Visual Age for Java), può essere testato su versioni di Component Broker realizzate per ambiente Windows, successivamente può essere spostato su mainframe IBM (non c è bisogno di ricompilarlo in quanto le classi Java prevedono codice multipiattaforma) e reso operativo. Component Broker è a tutti gli effetti un ORB compatibile con CORBA, dunque i componenti che lavorano sotto il suo controllo sono compatibili con le specifiche di questo protocollo. E naturalmente possibile sviluppare coponenti CORBA direttamente in C++ senza l uso dei servizi dell application server, indubbiamente però il modello di sviluppo offerto da EJB risulta avere una produttività estremamente maggiore. 19

20 E importante rimarcare come i componenti nel caso di Component Broker vengano eseguiti sul mainframe, possono così beneficiare di tutti gli strumenti e le strutture presenti su questo (data storage, recovery, cluster di macchine ecc.), differentemente il modello di Microsoft prevede che i componenti risiedano su macchine Windows NT/2000 fuori dal server. Altro aspetto importante è che in quasto caso componenti e procedure COBOL condividono lo stesso modello transazionale e gli stessi strumenti di manutenzione del sistema: questo permette di non richiedere figure professionali diverse rispetto a quelle già presenti per la gestione del mainframe Sviluppo di software con componenti distribuiti Nei paragrafi precedenti ho cercato di dare un impostazione formale al concetto di architettura distribuita mettendo in risalto come i modelli Corba e DCOM rendano uniforme la comunicazione in tutto il sistema ottenendo che nella rete ogni componente collabori liberamente con tutti gli altri. Un primo risultato di questa impostazione si ottiene nella realizzazione di nuovi servizi: lo sviluppatore si trova davanti ad uno scenario di componenti che realizzano già determinate microfunzioni, se queste sono state sviluppate correttamente è estremamente probabile che il suo lavoro si limiti a far collaborare queste in modo opportuno. Non è più necessario entrare nel merito dell implementazione dei componenti di cui si fa uso: le specifiche di cui si ha bisogno si limitano alla descrizione dell interfaccia delle classi e la conoscenza del loro comportamento esterno. In pratica è come se fosse già disponibile parte del progetto; rappresentando questo nel formalismo UML si vede come il lavoro parta dall avere una class view parzialmente riempita: Business Logic Biz_Class_A <interface> Presentation New_Ui_Class_A <interface> Biz_Class_B <interface> New_Biz_Class <interface> New_Ui_Class_B <interface> E probabile dunque che la messa in opera del servizio richieda solo la scrittura dei componenti di presentazione, è anche possibile che per l attuazione sia necessario 20

21 scrivere della logica applicativa che può essere utile anche per altri scopi: questo fa parte della naturale evoluzione del sistema. Il punto focale sta nella possibilità offerta al programmatore di astrarsi dall implementazione del sistema: non è necessario che egli conosca in quale maniera sono implementati i componenti di cui fa uso, non deve preoccuparsi di come vengono usate le risorse in quanto è compito dell application server occuparsi che il dialogo tra il nostro sistema e l ambiente avvenga nella maniera più corretta e efficiente (transazionalità, recovery, accesso alle risorse, fault tollerance). E interessante esaminare questo scenario dal punto di vista del gestore del sistema: egli vede un insieme di componenti che deve essere messo in grado di operare alla massima efficienza. Può dunque concentrarsi sul singolo componente per ottenere il risultato in vari modi (migliorare la capacità di connessione alle risorse di cui fa uso, duplicarlo, spostarlo là dove è più usato ecc..); in tutto questo non interviene nessuna modifica del codice. Si può obbiettare sul fatto che una impostazione di questo tipo è tutt altro che ottimizzata: ad esempio una operazione implementabile con una query che trasferisce i dati da una tabella ad un'altra viene qui realizzata con la comunicazione via rete tra oggetti Corba, anche se posti sulla stessa macchina del data server (per inciso: sarà comunque compito dell application server di rendere ottimale il funzionamento in questa situazione). Rappresentare però tutto un servizio in una query introduce molti problemi: la logica applicativa viene mischiata con quella di accesso ai dati, inoltre il servizio viene vincolato a quella rappresentazione dei dati nelle tabelle del DBMS. Tutto questo introduce una serie di legami nella futura evoluzione del sistema a cui ci è naturale pensare ma che, di fatto, rendono complicato lo sviluppo Definizione di un protocollo standard di comunicazione Una volta resa possibile la libera circolazione dell informazione nel sistema (e anche fuori da esso) è necessario che essa sia codificata in modo da essere facilmente interpretata ed elaborata da tutti i componenti. Sistemi come DCOM e CORBA risolvono buona parte del problema in quanto prevedono già le opportune conversione tra i tipi di dati e tabelle di caratteri permettendo un uso trasparente in sistemi operativi diversi, questo però da solo non è sufficiente. Consideriamo il caso in cui si abbia un componente remoto Fatture, supponiamo che con il metodo getfatturabycode si possa ottenere la possibilità di accedere alla fattura dal suo codice progressivo. 21

22 E possibile che l implementazione sia ottenuta attraverso CORBA, il metodo allora potrebbe restituirmi un riferimento ad un altro oggetto remoto myfattura che nei suoi attribuiti contenga i vari campi del documento. Per quanto interessante, questo metodo può risultare inefficiente in molti casi: devo sempre far riferimento alla macchina remota e lavoro sempre sul dato originale; in pratica si tratta di un concetto del tutto analogo al passaggio dei dati per riferimento ad una procedura, certe volte è più utile e opportuno passare i dati per valore! In alcuni casi è infatti necessario che l informazione diventi indipendente dalla sua origine in modo da essere liberamente trasportabile nel sistema e tra sistemi diversi. Pensiamo ad esempio ai servizi di Electronic Data Interchange (EDI): in quel caso un ordine spedito ad un fornitore è una entità a sé stante: il fornitore deve essere in grado di elaborare la sua copia indipendentemente dall originale, anche quando la connessione con il sistema origine è assente. La soluzione più naturale in questo caso è prevedere che l oggetto remoto Fattura mi fornisca una codifica di essa, come stream di caratteri, in modo che così rappresentata posso trasmetterla, memorizzarla o distribuirla come meglio credo. Non è banale determinare una codifica adeguata per l informazione. Supponiamo di decidere di adottare una codifica in un formato ASCII con campi delimitati da virgolette e tabulazioni: questo formato è sicuramente adatto a trasferire una tabella di un database, non è però altrettanto adatto a trasferire qualcosa di più articolato come una fattura. Sarebbe desiderabile che la codifica avesse le seguenti proprietà: - Universalmente adottata: dovrebbe essere usata in tutto il sistema e anche al di fuori di esso per qualsiasi trasferimento di informazione: in questo modo non ho bisogno di traduttori che cambino la codifica e quindi posso riorganizzare i flussi e far collaborare i componenti liberamente. Sarebbe infatti inutile essersi sforzati a usare CORBA o DCOM per poi parlare lingue diverse. Inoltre usare la stessa codifica per comunicazioni interne ed esterne rende meno netta la separazione tra i sistemi favorendo la collaborazione tra soggetti diversi. - Facile da implementare: vorrei che fosse facile da usare nei programmi, meglio se qualcuno ha già fatto qualcosa che posso comprare ed usare subito. Dovrebbe essere disponibile per tutte le piattaforme così da non avere limiti nel suo uso. - Versatile: devo poterci rappresentare qualsiasi cosa; deve essere quindi sufficientemente elastica da rappresentare dati che hanno strutture molto diverse: una tabella, un albero, un grafo o una combinazione di tutti questi. - Efficiente: veloce da trasmettere e da decodificare - Standardizzata rispetto al contenuto: sarebbe bello se in tutto il mondo codificassero le stesse cose nella stessa maniera: ad esempio ogni azienda codifica le fatture nello stessa forma in modo da usare tutti lo stesso formato. 22

23 - Leggibile dall uomo: sarebbe utile che l informazione fosse leggibile dall uomo anche in forma codificata EDI, UNIMARC, SGML e HTML La codifica dell informazione strutturate per lo scambio non è un problema recente anche se adesso con l affermazione di Internet è diventato enormemente più rilevante. Vale la pena dunque di dare uno sguardo a quello che è stato fatto in passato. EDI Le prime applicazioni di EDI risalgono agli anni 70. Le prime soluzioni erano realizzate con reti private che collegavano le aziende con i fornitori più importanti. Con l aumento dell interesse si formarono comitati con l obbiettivo di formalizzare la codifica di trasmissione tra cui la più nota è EDIFACT, creato negli Stati Uniti specificatamente a transizioni business-to-business. EDIFACT stabilisce che i dati devono essere trasmessi in forma compressa, usando identificatori di campo prestabiliti, secondo una precisa sequenza non modificabile, ogni pacchetto può essere contrassegnato come obbligatorio o opzionale. Un messaggio EDIFACT può essere visto come una serie di pacchetti accompagnati da uno speciale pacchetto chiamato dizionario che definisce il contenuto dei campi. Le realizzazioni software costruite attorno ad EDIFACT hanno trovato molti problemi per la maggior parte determinati dalla rigidità nella struttura dei dati. In pratica solo le grandi multinazionali trovarono un effettivo beneficio in EDI ed esso non è mai riuscito a sostituire completamente i processi manuali. Nonostante questo EDI presenta numerosi pregi: fornisce con il dizionario un sistema per ottenere una analisi facile dei dati inviati, sia da un operatore umano che in maniera automatica, inoltre è efficace nel metodo di compressione tanto che EDIFACT viene anche usato al di fuori di operazioni business-to-business quando si deve trasferire in maniera veloce dati strutturati su un canale. Per quanto concerne i risultati che EDI si era proposto la pratica ha dimostrato che è stato un notevole e clamoroso insuccesso. UNIMARC Contemporaneamente alle prime implementazioni di EDI le biblioteche americane e di seguito quelle di tutto il mondo sentirono la necessità di scambiarsi i record bibliografici in modo da rendere il proprio catalogo fruibile da tutta la comunità bibliotecaria. 23

24 Nel 1977 nasce quindi la codifica UNIMARC per opera della associazione internazionale in campo bibliotecario IFLA. UNIMARC in pratica specifica la struttura del record bibliografico tramite tag separatori, indicatori e codici di sottocampo: mediante questa struttura è stato possibile ampliare il formato mantenendolo consistente con le versioni precedenti e rendendolo di fatto aperto all inserimento di altre informazioni aggiuntive. In questo caso l adozione dello standard è stato un successo: ormai gran parte delle biblioteche aderiscono allo standard, questo ha permesso anche una razionalizzazione dello sviluppo dei sistemi informativi: ha permesso la centralizzazione dell informazione creando cataloghi internazionali (ISBN) e nazionali (SBN) e la collaborazione di soggetti pubblici e privati in un unico sistema. UNIMARC di certo non è così ottimizzato come EDIFACT però nella sua specificità e nella sua relativa dinamicità ha permesso l adozione generalizzata nel suo campo. SGML e HTML non sono propriamente delle codifiche di informazione in quanto sono dei linguaggi orientati alla rappresentazione dei dati, il primo nato per fini tipografici il secondo per la compilazione di ipertesti. D altra parte l eccezionale sviluppo del World Wide Web ha trasformato Internet nel più grande database esistente, questo ci spinge dunque a considerare HTML comunque un mezzo di codifica dell informazione. Questa codifica risulta ottimale per la consultazione umana ma pessima per quanto riguarda il trattamento automatico (basta osservare i problemi che incontra un motore di ricerca), ciò accade perché informazione (ovvero ciò che contiene il documento) e la sua presentazione (cioè come appare il documento) sono mischiati insieme. HTML però dimostra bene i pregi di un markup language (i linguaggi delimitati da tag): essi rappresentano semanticamente una struttura ad albero (è facile mostrare che quasi tutte le strutture dati possono essere rappresentate in un albero), semplice da codificare e decodificare, è facile da leggere anche in forma codificata XML XML nasce dallo stesso consorzio che si occupa della standardizzazione dell HTML ma con obbiettivi del tutto diversi: XML è un linguaggio per la codifica di informazioni strutturate in sequenze di caratteri delimitate da tag che racchiudono sottoinsiemi logici nell informazione. In questo senso un file XML assomiglia molto ad un file HTML, ma le finalità sono completamente diverse. HTML descrive come un documento deve essere rappresentato: 24