Eventi

Struttura e funzionamento di .Net

XML dalla cassetta degli attrezzi

Chiunque, utente o sviluppatore, investa nelle tecnologie e nel sapere si trova a scegliere fra vari produttori e standard. Con .NET di Microsoft, una piattaforma equiparabile al mondo Java, le imprese sono ancora una volta davanti ad un bivio, che non è poi tanto un problema se si è disposti a confrontarsi con XML.

In ritardo, ma pur sempre al momento giusto, Microsoft affianca una propria piattaforma, chiamata .NET, all'imperante Sun che può vantare una lunga esperienza di linguaggio di programmazione a piattaforma indipendente grazie a Java. "Write once, run anywhere" è il motto dell'ultimo decennio e con J2EE e/o Sun Open NetEnviroment (Sun ONE) già da due anni esiste anche un framework simile per lo sviluppo di applicazioni. Per penetrazione del mercato, grado di maturazione e sapere libero, le applicazioni di Java dovrebbero essere innanzitutto ai primi posti, ma a tale ruolo predominante si contrappone quello di Windows che, con la Microsoft, ha già deciso in passato cosa deve girare sul desktop; non a caso, quindi, alla fine dei conti sarà di nuovo una questione di ambiente di sviluppo: .NET oppure Java.

In cosa consiste .NET?

Piattaforma, linguaggio di programmazione, sistema operativo, server framework: cos'è in definitiva .NET? È un ambiente di sviluppo Microsoft (framework) che permette di integrare sistema operativo, server, applicazioni e servizi. Si sviluppano così delle applicazioni che funzionano in tutti i computer con sistema operativo Windows. A ciò si aggiunge che .NET è in gran misura indipendente dal linguaggio di programmazione e si adatta ad architetture Web e sistemi orientati ai componenti.
Volendo semplificare il quadro, è come se sul mercato edilizio A si offrisse una modernissima cassetta di attrezzi universali che vanno bene solo con i componenti dello stesso tipo ossia sono perfettamente sintonizzati gli uni con gli altri. Questi attrezzi funzionano egregiamente nel primo caso, mentre non trovano alcun utilizzo per i componenti dei mercati B, C e D. Pertanto, la limitazione nell'offerta degli articoli del mercato edilizio A deve essere compensata dall'armonizzazione ottimale di tutti i componenti e degli attrezzi. All'opposto di questa più "vecchia e affermata cassetta degli attrezzi" troviamo Java che nella maggior parte dei casi si adatta a tutti i componenti dei mercati: una cassetta, in pratica, i cui componenti sono più o meno liberi.

Similitudini e differenze

Pur con diversi raggi d'azione, le cassette degli attrezzi vantano sempre dei punti in comune: p. es. i linguaggi di programmazione in uso, C# e Java, sono molto simili e anche per quanto riguarda i tempi di esecuzione i designer .NET si sono rifatti a Java. Analogamente: esistono finalità sostanzialmente comparabili nel modello di componenti e oggetti, l'accesso al database scinde fonte dei dati e utente, per la comunicazione distribuita si usa un'architettura simile. Ambedue gli universi perseguono dei principi simili per i "Web service". Tale ambito vede anche la collaborazione in comitati di standardizzazione dei rappresentanti delle imprese: ad esempio, la "Global XML Web Service Architecture"(GXA) che è nata allo scopo di garantire la massima interoperabilità delle applicazioni - superando anche i confini dei sistemi operativi.
Quanto alle differenze, queste non si nascondono solo dietro i fattori comuni di natura tecnica: da un lato, .NET è legato ad un solo produttore che, nell'ambito del proprio mondo di sistemi operativi, ha creato una piattaforma coerente e orientata agli standard, dall'altro lo stesso Java è diventato uno standard aperto che, lasciatosi completamente alle spalle le difficoltà iniziali, senza dubbio è interpretato dagli svariati produttori in modo diverso. Lo scontro qui è tra famiglia di prodotti e prodotto singolo, "connectivity" e standard, framework completo e singoli componenti finiti. Le dichiarazioni dei produttori rispecchiano questo stato di cose.
Secondo Walter Seemayer, Director Developer Group presso la sede Microsoft di Monaco di Baviera, la comunicazione ha un ruolo di primo piano: "Consideriamo .NET come un software per unire processi, uomini e strumenti". In contrapposizione a tale immagine, Sun dà priorità agli standard: "Sun ONE si basa su standard aperti ed è accessibile per prodotti e tecnologie di diverse aziende produttrici", afferma Carsten Müller addetto al marketing del prodotto della Sun.
Le chiavi per l'integrazione e la distribuzione
Dal punto di vista delle esigenze delle architetture software, integrazione e distribuzione sono fattori cruciali. Il futuro panorama dell'applicazione richiede un grado di dinamismo sempre maggiore: informazioni disponibili in modo decentrato, abbinamento variabile dei componenti, una piattaforma indipendente dagli apparecchi e interoperabilità. Ogni volta che ci si trova ad affrontare tali esigenze, entrano in gioco due termini chiave: Web service e XML. Ambedue sono serviti da Microsoft con .NET. Mentre J2EE in meno di un decennio di vita è stato integrato con i servizi Web, Microsoft li ha fin da subito integrati in .NET, facilitando sviluppo e comunicazione. Sia .NET sia Java servono con i Web service una nuova generazione di apparecchi mobili, quali PDA, smart phones e altri. Sebbene siano scritti in tutti i linguaggi .NET, i servizi Web di .NET non sono comunque conformi a ebXML. In questo caso, Microsoft pone il comune supporto strumenti più in alto rispetto agli standard - ed è quindi chiaro il motivo per cui gli utenti di apparecchi mobili preferiscono sempre Java.
Ciò che alla Sun è sempre stato il lavoro con gli standard, alla Microsoft è stato 'incorporato in Windows e in .NET mette a disposizione interfacce XML, per creare il collegamento tra le applicazioni, internamente e fuori degli ambienti di sviluppo. ".NET è pronto per XML" sostiene Walter Seemayer, "per noi questo è un momento di verifica e rendiamo disponibili un numero crescente di interfacce. Anche la connettività interna in futuro funzionerà con le stesse interfacce". In effetti per via degli standard applicati in .NET (SOAP, WSDL, UDDI) e l'impiego del linguaggio di meta descrizione XML una decisione generale sulla piattaforma, abbastanza insolita, è passata in secondo piano: che si adotti .NET oppure Java, le applicazioni comunicano e si comprendono tramite XML.

"Web Service e XML"

I Web service si basano su standard aperti del "World Wide Web Consortium" (W3C) e in pratica sono disponibili su tutte le piattaforme. Con un tale programma software così promettente si possono integrare le applicazioni all'interno oppure al di fuori dell'azienda tramite Internet. XML riveste un ruolo chiave nei Web service in quanto rende possibile sia la strutturazione sia lo scambio di dati e, non da ultimo, il richiamo di componenti software in ambienti eterogenei attraverso LAN, WAN oppure Internet. I servizi Web disponibili si possono rintracciare sulla Rete per mezzo di servizi di elenchi, i cosiddetti repository service, ed essere descritti usando il Web Service Description Language (WDSL). Tramite i protocolli standardizzati e il metalinguaggio XML i Web service potrebbero diventare il percorso integrativo del futuro. 

La piattaforma XML

Grazie a .NET, Microsoft cavalca l'attuale onda di sviluppo: affermazione di XML come linguaggio di descrizione ed estensione del suo utilizzo come "generatore di interfacce" per l'interoperabilità di applicazioni. In questo modo, si andrebbe incontro alle aziende che hanno già adottato XML e, in particolare, per quanto riguarda la documentazione tecnica, dove l'impiego di XML è ormai un fatto abituale per scopi di strutturazione e descrizione dei contenuti. Il valore esatto di .NET per le imprese e per i relativi redattori tecnici è riconoscibile solo a grandi linee: le imprese che hanno acquistato Windows, in ogni caso, non fanno che tutelare i propri investimenti se puntano su .NET. E chi desidera oppure ha bisogno di tutto da una sola fonte, può essere tranquillo delle proprie scelte.

Poche novità per la documentazione tecnica?
Per la documentazione tecnica e lo sviluppo di sistemi di help cambia poco, a parte il fatto che XML diventa sempre più inevitabile. Così MS Help 2.0, come ha annunciato Microsoft da alcuni mesi, diventerà disponibile appena nel 2005 con il Longhorn Server di Microsoft per .NET. In questo modo, Microsoft tiene conto delle esigenze per cui lo sviluppo di uno degli help standard, integrato nel sistema operativo e funzionante in tutti i calcolatori, non rappresenterebbe una soluzione transitoria. Fino alla distribuzione di Longhorn, sono quindi validi HTMLHelp 1.x, Visual Studio .NET e l'Help Compiler Workshop e tutti i canali d'integrazione oppure i tool di terzi produttori. E naturalmente i programmi di help che supportano MS Help 2.0. Da non sottovalutare è il fatto che .NET si rivolge ad una categoria di apparecchi mobili che, oltre ad essere riservata a Java, finora ha sfruttato l'intelligenza locale disponibile del cliente per una cosiddetta "richer interface", alimentata con i dati tramite i Web service. È proprio questo il terreno di scontro diretto tra Microsoft e Java, e sarà interessante vedere quali applicazioni nell'ambito degli help online per apparecchi mobili ne verranno fuori.

Riflettere su XML piuttosto che su .NET

Questi tempi di calma relativamente piatta sarebbero pure l'occasione giusta per le aziende di occuparsi di XML sulla scia di .NET. Si potrebbe approfittare della lieve pressione a 'emigrare' per mettere alla prova compiti e dimensionamento dei propri uffici di documentazione tecnica. Inoltre XML sarebbe il punto di contatto di sviluppo e documentazione con cui questi potrebbero crescere insieme. In definitiva si utilizza la stessa tecnologia di base per interfacce, scambi dei dati e della configurazione di applicazioni, così come per la strutturazione di informazioni. Chi migliora l'interoperabilità delle proprie applicazioni grazie a MXL può capire meglio le necessità del Cross-Media-Publishing e viceversa. In molti casi, infatti, le aziende possiedono solo delle isole XML, dove, ad esempio, in un reparto specializzato confluiscono tecnologia e utilizzo, senza che però in tutta l'azienda esista un consenso al riguardo.
Il consiglio alle imprese che decideranno per Windows oppure Java, è di non cambiare assolutamente niente. Su ambedue le piattaforme si possono sviluppare applicazioni che funzionano con i Web service e che sono "mission critical", ossia applicazioni critiche per l'attività. Per le aziende che adottano Windows, nel prossimo futuro, .NET sarà la piattaforma su cui si fonderanno lo sviluppo e il funzionamento delle applicazioni. Questa volta, tra l'altro, non si tratta di un fastidioso passaggio, bensì di un vero e proprio guadagno. Le prime applicazioni .NET dimostrano una chiara riduzione di costi per sviluppo e funzionamento. Java continuerà lo stesso a vantare il maggiore pool di developer, tool e applicazioni e ad essere veramente indipendente.
Ad una certo punto ci potrà essere anche un equilibrio delle due realtà di mercato senza nuocere ad alcuno, poiché per l'integrazione e la comunicazione di dati ci sono degli standard, quali, per l'appunto, XML.

Print-Magazine, E-Mags e Communities:

www.dotnetpro.de
www.dotnetadvisor.net
www.aspnet-professional.de
www.entwickler.com < http://www.entwickler.com >
www.drdobbsjournal.com < http://www.drdobbsjournal.com >
www.aspheute.com < http://www.aspheute.com >
www.dotnetframework.de
www.dotnetexperts.at
Microsoft:
www.msdn.microsoft.com/msdnmag/ < http://www.msdn.microsoft.com/msdnmag/ >
www.microsoft.com/
germany/msdn/
www.microsoft.com/
germany/ms/
entwicklerprodukte/
Link:
www.advanceddevelopers.de/links/netsites.htm 


Marcus Kesseler (51), laureato in informatica, è fondatore e amministratore di SCHEMA GmbH di Norimberga, dove è responsabile del settore Ricerca Sviluppo.