.NET or J2EE – Choosing the Right Web Services Framework
Inoltre, l’adozione di tale modello può avere un costo d’ingresso relativamente basso. Le sue interfacce XML basate sul testo sono un’evoluzione delle precedenti soluzioni proprietarie e dipendenti dalla piattaforma elaborativa, come CORBA e COM IDL (Interface Definition Language).
Le informazioni dell’impresa scambiate tramite i servizi web sono conformi alle transazioni verticali e ai dati standard tipici dei diversi settori economici come finanze, assicurazioni, industria manifatturiera, salute, farmaceutici e altro.
Questi standard sono espressi anche in XML, per cui sono accessibili da parte di qualsiasi sistema in grado di comprendere testi e di collegarsi al Web.
La competizione tra i venditori , in quest’area, è sulla fornitura di software di applicazione dei servizi web che tragga beneficio da questo modello.
La loro offerta è basata su due modelli applicativi: .NET di Microsoft e J2EE di Sun.
Anche se ciascuno offre una configurazione iniziale relativamente semplice e a basso costo, l’onere di uscita – ovvero il prezzo da pagare per passare dall’una all’altra soluzione è molto alto e, quindi, il management dell’impresa e il responsabile IT debbono considerare il forte valore strategico della scelta.
In questo articolo, confronteremo i due ambienti, definiti framework, esaminando le loro caratteristiche di interoperabilità, discuteremo i fattori critici della scelta e, infine, parleremo di alcuni problemi aperti sia per .NET e J2EE, sia in termini generali che specifici dell’approccio allo sviluppo dei servizi web.
Cos’è un servizio web
Un servizio web è un’applicazione modulare completamente autonoma. Lo scopo è di potenziare la sua interoperabilità e reusabilità per l’impresa e per il mondo esterno.
L’applicazione può essere descritta, allocata e invocata su protocolli di rete standard, come HTTP. I servizi web consentono di integrare vecchie e nuove applicazioni usando XML. Per inciso, i servizi web non rappresentano un’alternativa alle tecniche di EAI (Enterprise Application Integration).
L’interoperabilità dei Servizi Web è basata su ambienti e standard open XML.
Le applicazioni dei servizi web sono progettate con la tecnica SOA (Service Orientented Architecture). Il principio fondamentale SOA è il collegamento molto stretto per ottenere l’integrazione dinamica delle applicazioni, degli oggetti e dei programmi.
Per consentire la costruzione dinamica delle applicazioni future, esiste la necessità di rendere pubbliche le risorse che, inoltre devono essere disponibili tramite una directory. Per rendere più largamente utilizzabili le applicazioni, è necessaria la personalizzazione delle interfacce, per ciascun utente.
Questa architettura definisce tre ruoli principali (vedi fig. 1).
Il provider dei servizi crea e pubblica le interfacce e ne assicura l’implementazione corrente. Questo ruolo può essere assunto da qualsiasi società, impresa, dipartimento o altra entità.
Il Service Broker registra e suddivide in categorie i servizi forniti dai diversi Service Provider, offrendo servizi aggiuntivi, come la ricerca. Il Service Requester è l’utente dei servizi web. L’utente scopre i servizi web mediante una ricerca nel repository (mantenuto dal Broker) e invoca i servizi comunicando con il provider.
Tutto questo può avvenire su Internet, tra imprese, oppure su intranet, all’interno dell’impresa.
In generale, esistono due tipi di servizi web. Quelli finalizzati all’utente sono progettati per migliorarne la capacità, fornendo personalizzazione delle applicazioni e delle interfacce, oltre al supporto di più linguaggi. Per questi servizi, risulta critico separare la presentazione, ad es. HTML, dal contenuto, ad es. XML.
Un servizio web finalizzato all’applicazione, invece, integra le applicazioni dell’impresa con quelle B2B. Questi servizi collegano tra di loro i processi dell’impresa, superando i vincoli imposti dalle infrastrutture, piattaforme e sistemi operativi proprietari.
Per creare, riutilizzare o integrare i servizi web, abbiamo bisogno di un ambiente che supporti XML, l’interoperabilità a livello di rete, l’architettura SOA e i servizi specifici sia per l’utente che per le applicazioni.
Questo è il ruolo di .NET e di J2EE: fornire linee guida per lo sviluppo, diffusione, attivazione, gestione e utilizzo standard dei Servizi Web.
Che cos’è un framework applicativo di servizi web?
Un ambiente applicativo (Application Framework) è un insieme di linee guida e di specifiche per piattaforme, strumenti e ambienti di programmazione, dedicato alla progettazione, integrazione, controllo delle prestazioni, sicurezza e affidabilità di applicazioni distribuite multilivello.
Si tratta di un forte insieme di responsabilità elaborative che ci è già familiare con il software per i server applicativi Java o COM, come WebSphere di IBM oppure Transaction Server di Microsoft.
Il supporto di base alle applicazioni deve comprendere servizi di presentazione, elaborazione dal lato server, gestione delle sessioni, un framework per la logica dell’impresa, funzioni di cache per i dati applicativi, logica delle applicazioni, persistenza, transazioni, sicurezza e servizi di log.
In un ambiente di impresa reale, il termine framework identifica una piattaforma per lo sviluppo e l’esecuzione di applicazioni per servizi web.
Deve, quindi, fornire servizi di sviluppo e di run-time per la gestione delle transazioni, la sicurezza, la gestione dello stato dei sistemi, l’integrazione delle applicazioni, l’amministrazione, i collegamenti remoti, la messaggistica e la gestione dei processi dell’impresa.
Poiché le persone debbono collegarsi ai servizi web da ogni luogo e in ogni momento, il framework deve supportare varie GUI (Graphic User Interface), compresi i browser sul Web e le apparecchiature wireless (collegamenti via radio e telefonia cellulare).
I framework applicativi vengono implementati come strumenti e server costruiti al di sopra dei servizi web che forniscono l’accesso alle applicazioni (vedi fig. 2).
Questo modello di programmazione supporta sia i servizi web verso le applicazioni che i servizi web verso gli utenti.
Differenze tra J2EE e .NET
Sia J2EE che .NET forniscono un framework applicativo per i servizi web, ma differiscono tra di loro oltre che per il tipo di soluzione e di supporto, anche per tipo di implementazione, prezzo, portabilità, strumenti e server, sostegno del venditore, maturità e popolarità.
Progettazione e servizi
Il framework .NET ha tre componenti principali. .NET Platform comprende gli strumenti e l’infrastruttura forniti per costruire il software relativo ai servizi .NET e alle apparecchiature .NET.
I prodotti e i servizi .NET sono forniti da un insieme di servizi per l’impresa basati su .NET, che supportano il framework.
Questi comprendono BizTalk Server, SQL Server, Windows.NET, Visual Studio.NET e Office.NET. Venditori terze parti forniscono servizi web .NET costruiti sulla piattaforma .NET (Il framework J2EE (vedi fig. 4), risponde a questi requisiti con un set completo di standard, compresi Enteprise JavaBeans (EJB), J2EE Connector Architecture (JCA), Java Database Connectivity (JDBC), JavaServer Pages Standard Tag Library (JSTL), Servlets, le Java Transaction API (JTA), Java Messaging Services (JMS), Java Name and Directory Interface (JNDI), Java Remote Method Invocation (RMI), RMI/Inter-Orb Operability Protocol (RMI/IIOP), Java Authentication and Authorization Service, (JAAS), JavaMail, e le Java API for XML (JAXP).
La differenza fondamentale è che J2EE supporta i servizi web tramite API Java, mentre i servizi web .NET sono costruiti direttamente sulla piattaforma.
Implementazione
I servizi web J2EE sono implementati tipicamente mediante Enterprise Java Beans, anche se le applicazioni standard Java possono operare nel medesimo modo.
La scelta dipende da come sono progettati e realizzati i livelli logici delle applicazioni e dei dati dell’impresa.
I servizi .NET sono tipicamente implementati mediante componenti gestiti dalla piattaforma .NET, comprendendo classi gestite e componenti COM o COM+. Inoltre, .NET supporta Managed C++, JScript.NET, VB.NET e C#, una versione per i servizi web di C++. Il framework J2EE, naturalmente, è limitato a Java.
Prezzi
J2EE è più costoso rispetto a .NET, ma se un’impresa già possiede un server applicativo basato su J2EE come Silverstream, WebLogic, oppure WebSphere, è sensato continuare a utilizzarlo, poiché il costo incrementale dei servizi J2EE, in questo caso, risulta inferiore.
I server .NET hanno un costo molto inferiore rispetto ai server J2EE.
Portabilità
La codifica Java J2EE può essere portata su sistemi operativi multipli ma, in termini generali, non su server diversi.
Lo standard adottato consente ai venditori tipo IBM e BEA Systems di creare server applicativi compatibili J2EE, per supportare EJB che usano funzionalità proprietarie del venditore.
Queste applicazioni non possono essere portate tra server applicativi senza modifiche.
Tuttavia, è possibile portare l’intero contenitore delle applicazioni (una sezione dello stesso server applicativo) tra piattaforme diverse, con grande vantaggio nel caso di ambiente di impresa esteso multipiattaforma.
.NET si rivolge primariamente ai sistemi operativi Windows. Tuttavia, le applicazioni .NET non vengono eseguite direttamente nel codice nativo di macchina, ma sono compilate ogni volta in MSIL (Microsoft Intermediate language).
La codifica in MSIL viene compilata in codice nativo al momento dell’esecuzione tramite un compilatore just-in-time e, quindi, i programmi girano su di una macchina virtuale chiamata CLR (Common Language Runtime).
Questo approccio tipo Java è stato implementato, fino ad oggi, solamente in Windows, anche se è possibile che possa essere supportato in futuro su altre piattaforme, come C# ratificato da ECMA e CLR, indicate come standard ufficiali del settore a partire da dicembre 2001.
Strumenti, server e supporto dei venditori
I venditori di J2EE come IBM, BEA Systems, Oracle, Hewlett-Packard, e Sun Microsystems hanno già iniziato a supportare la creazione, diffusione ed esecuzione di servizi web.
Ma il livello di sofisticazione e di aderenza agli standard è diverso.
Molti venditori non hanno aspettato XML, la tecnologia di base per i servizi web, per acquistare rapidamente popolarità, risultando così impreparati per la richiesta generale del mercato.
I venditori J2EE sono messi in difficoltà dall’eccessivo numero di standard per i servizi e dal conflitto per definire quelli comuni a tutto il settore, così come dalla necessità di differenziare le rispettive offerte da quelle dei concorrenti che aderiscono al medesimo standard.
J2EE fornisce un framework per prodotti concorrenziali, senza creare alcun monopolio. Questa è una sfida, sicuramente non nuova.
Il principale ambiente di sviluppo integrato di Microsoft, IDE (Integrated Development Environment), è Visual Studio .NET, che ha già superato i concorrenti nel supporto dei servizi web.
Microsoft si è mossa in anticipo per fornire supporto ai servizi web a livello dei componenti, con la propria suite di server specifici come BizTalk. .NET è controllato da una singola società e, mentre non è in questione la stabilità, qualità e impegno verso i servizi web di Microsoft, le imprese utenti debbono valutare il significato completo dell’impegnarsi con un singolo venditore, in un’area strategica, oltre che per il lungo termine.
Maturità e Popolarità
J2EE è un’architettura robusta, scalabile e matura, che supporta le applicazioni delle imprese da molti anni.
A questo punto, il supporto ai servizi web non è che un’altra funzionalità aggiunta a questo modello flessibile di framework. .NET ha ereditato molte funzioni dall’architettura DNA di Windows. Il 79% delle risposte fornite a un’indagine effettuata da ZDNet nel dicembre del 2001, ha rilevato una pianificazione in atto dell’adozione di J2EE, contro un 21% per .NET.
Tre mesi dopo, nel febbraio 2002, Microsoft ha rilasciato alcuni strumenti e server di sviluppo fondamentali e, quindi, questo numero potrebbe cambiare radicalmente in favore di .NET.
Ad esempio, “My Services” di .NET, fornisce un supporto alla personalizzazione e alle preferenze dell’utente molto più ampio rispetto a J2EE.
Adottare la decisione giusta
Esistono diversi fattori di decisione principali da considerare nella scelta di una strategia, rispettivamente .NET oppure J2EE.
Tra questi, sono fondamentali il framework applicativo e l’infrastruttura IT esistenti, sia a livello impresa che al livello di unità di business, il ROI (Return On Investment) previsto, la strategia IT e quella generale dell’impresa, l’esperienza degli sviluppatori, la conformità con gli standard, la scalabilità e i requisiti di integrazione, le necessità di sicurezza, aggregazione e personalizzazione e, infine, il supporto delle terze parti.
Framework e infrastruttura IT esistenti
Qual è il framework esistente? Molte imprese si stanno muovendo in avanti per estendere le proprie piattaforme.
Gli utenti COM, ad esempio, tendono all’uso di .NET, mentre un utente di WebSphere può scegliere di continuare ad usare J2EE.
Se, come nel caso di molte imprese, il vostro ambiente elaborativo comprende sia J2EE che Microsoft, considerate la possibilità di un mix e adottate la decisione più favorevole al livello di ogni singolo progetto applicativo.
Usando gli standard XML per i servizi web, è possibile integrare (oppure almeno interfacciare) applicazioni .NET e J2EE, utilizzando informazioni di collegamento standard WSDL (Web Services Definition Language) e una directory privata UDDI (intranet).
Quale framework può essere supportato facilmente nell’ambito dell’infrastruttura IT esistente?
Minori costi di supporto portano ad una probabile diminuzione del TCO (Total Cost of Ownwership), perché quest’ultimo è la somma dei costi di implementazione e di manutenzione, riferiti all’arco temporale del periodo di vita dell’applicazione.
Esperienza e specializzazione degli sviluppatori
Questo è probabilmente uno dei fattori più importanti per qualsiasi impresa.
Se la maggior parte o la totalità degli sviluppatori sono esperti Microsoft, l’introduzione di J2EE sarà una decisione attuabile con difficoltà. Al contrario, gli sviluppatori J2EE si adattano bene a creare applicazioni .NET.
I fattori che influenzano questo aspetto della decisione pongono l’attenzione sul fatto che un uso corretto delle applicazioni è spesso molto più importante della scelta della tecnologia.
In altre parole, usare bene qualunque framework è un fattore critico di successo più della scelta di quello “giusto”.
Il futuro degli standard
Quali prodotti sono soggetti a una rapida evoluzione e secondo quali standard?
Questa è un’area difficile da identificare e quantificare, perché gli standard sono ancora in via di definizione. Molti sono ancora in conflitto nel termine breve, come WSIL (Web Services Interface Language) e UDDI.
In effetti, secondo un’indagine condotta da SalCentral nel gennaio di quest’anno, il 67% delle richieste a directory pubbliche di servizi web UDDI (Universal Description, Discovery and Integration) creano problemi di funzionalità, oppure descrivono implementazioni inesistenti.
Nel febbraio 2002, Microsoft ha rilasciato Visual Studio .NET e i server per l’impresa basati su .NET.
Con questa mossa, Microsoft si è posta avanti a tutti i prodotti per framework J2EE, compreso WebLogic di BEA Sistems, oltre a WebSphere di IBM. Nel breve termine, questo vantaggio potrà essere ridotto dal rilascio di nuove versioni di J2EE.
Robustezza e sicurezza
Quali prodotti risultano maggiormente robusti e scalabili, oltre a corrispondere alle necessità degli utenti, presentando la minore complessità posibile?
J2EE è più robusto e scalabile, ma questa caratteristica è importante per un’impresa medio-piccola o per una divisione o un singolo dipartimento?
.NET è meno complesso da sviluppare, diffondere e mantenere. Questa stessa semplicità è un fattore di robustezza e di scalabilità.
Quali prodotti sono più sicuri?
Entrambi I prodotti in gara lo sono. .NET, tuttavia, è basato sul ruolo, scelta che può costituire un vantaggio, considerata la naturale affinità dei servizi web con il protocollo RBAC (Role Based Access Control).
Supporto dei fornitori di software
La maggior parte dei fornitori di server applicativi hanno iniziato a fornire supporto per i servizi web, mentre un supporto completo sarà presto inevitabile da parte di tutti.
Esiste una forte probabilità che un’impresa sia in grado di utilizzare la sua infrastruttura d’integrazione EAI e B2B corrente per attivare e diffondere servizi web, a prescindere da quale framework venga prescelto.
Quali prodotti risultano più flessibili nell’integrare servizi di venditori terze parti?
La logica tradizionale è che un’architettura aperta incoraggi il supporto delle terze parti. Questo ci porterebbe a concludere che J2EE sia superiore in quest’area.
Dopo tutto, J2EE è un’architettura aperta. Questa affermazione però è solamente teorica. Il vincitore in quest’area dipende dal tipo di servizio di cui avete bisogno.
Tutti i maggiori fornitori di applicazioni a pacchetto hanno annunciato il supporto per entrambi i framework.
Una lezione che abbiamo già imparato nelle guerre dei componenti (COM contro J2EE) è che, per un venditore, è più semplice supportare un prodotto (di Microsoft) piuttosto che supportare molti prodotti basati su di uno standard (J2EE). Rimane da vedere se questa affermazione risulterà veritiera per .NET.
Tutti I maggiori fornitori di pacchetti applicativi fanno a gara per fornire interfacce e supportare i servizi web, con riferimento ai prodotti ERP (Enterprise Resource Planning), SCM (Supply Chain Management e CRM (Customer Relationship Management).
L’attuale trend del settore è di restare neutrali, supportando entrambe le soluzioni. Ad esempio, SAP ha annunciato un’implementazione dei servizi web per J2EE e .NET, usando il proprio Web Application Server.
Conclusioni
Entrambi gli ambienti J2EE e .NET forniscono un pieno supporto alle applicazioni multilivello di servizi web, comprendendo, per questi ultimi, la progettazione, sviluppo, diffusione, esecuzione e monitoraggio.
Poiché entrambe le tecnologie supportano bene i servizi web, la guerra dei framework continuerà ancora per anni. Questa competizione migliorerà la tecnologia dei servizi web in termini di strumenti, standard, scalabilità e costo.
Non è ancora chiaro, tuttavia, quanti problemi importanti siano ancora da risolvere, in entrambi i campi.
Anche se il supporto per la sicurezza, la gestione operativa, il workflow, le regole dell’impresa e l’integrità delle transazioni è fornito dai venditori dei framework J2EE e .NET, gli standard in quest’area non sono stati ancora definiti, o almeno non completamente identificati.
Questa situazione riduce l’interoperabilità in termini generali, poiché i venditori sono obbligati a creare soluzioni “proprietarie”.
Uno specifico fattore di costo è molto importante. Può risultare molto economico iniziare con questi framework, ma state attenti – i costi di uscita sono estremamente alti.
Sviluppare una strategia e un’architettura di servizi web, oggi, richiede molta prudenza e una corretta valutazione dei rischi.