CORBA incontra Java

Abbiamo tutti avuto accesso a siti Web che ci consentono di interagire con uno script del server tramite l'uso di moduli HTML e Common Gateway Interface (CGI). I siti utilizzano spesso questa tecnica per richiedere a una persona di inserire un nome utente e una password per accedere a un sito. Le variabili Nome utente e Password vengono passate a uno script del server che verifica che un determinato utente possa effettivamente accedere a determinate parti di un sito. Questo processo viene eseguito tramite HTTP, che (come potresti sapere o meno) è uno statelessprotocollo. Ogni volta che viene caricata una nuova pagina, vieni effettivamente disconnesso dal server e non ha alcuna conoscenza di chi sei e cosa stai facendo attualmente. Pertanto, anche dopo l'accesso a tale sito, ciascuna pagina a cui si accede da quel momento in poi deve restituire il nome utente e la password al server per verificare il diritto dell'utente di accedere alla pagina. In altre parole, l'applicazione client (il browser Web) e l'applicazione server (il server Web) non hanno il concetto di variabili locali, chiamate a metodi locali o oggetti.

Subito dopo la decennale lotta della comunità di sviluppo del software per incapsulare il codice mentre gli oggetti sembravano finalmente avere successo, ci siamo ritrovati a precipitare indietro nel tempo verso una modalità di elaborazione "batch" senza stato.

Tuttavia, non è tutto negativo. Il Web ci ha fornito i vantaggi rivoluzionari dei protocolli aperti e basati su standard e dell'indipendenza dalla piattaforma. Sebbene decine di migliaia di siti utilizzino HTTP e CGI per recuperare informazioni sull'utente, eseguire uno script sul server e possibilmente restituire informazioni aggiuntive all'utente, questi siti non possono essere considerati come "applicazioni" effettive, nel senso tradizionale del termine . Inoltre, tutto il codice per questi siti doveva essere scritto da zero a causa delle nuove tecnologie utilizzate (HTTP e CGI). Per adattare le applicazioni software esistenti al Web o per creare nuove applicazioni veramente potenti utilizzando Internet / intranet come spina dorsale di comunicazione, è necessario utilizzare una tecnologia che possieda il seguente "Santo Graal" di attributi:

  • Supporto per codice legacy attualmente esistente in C, C ++ e COBOL (tra gli altri linguaggi)
  • Supporto Java per consentire la creazione di applicazioni mobili, indipendenti dalla piattaforma e orientate agli oggetti
  • Neutralità del fornitore, in modo che le applicazioni possano essere mantenute e possano prosperare nel tempo
  • Scalabilità per gestire un gran numero di utenti
  • Ampio supporto della piattaforma per evitare il "blocco" della piattaforma
  • Un paradigma di sviluppo orientato agli oggetti (a causa dei numerosi vantaggi insiti nell'OOP)
  • Sicurezza end-to-end
  • Ampio supporto del settore

Entra CORBA

Nel corso di questo articolo vedrai che solo una tecnologia, CORBA, soddisfa veramente la nostra lista dei desideri (e anche alcune). Inoltre, vedrai che poiché Java e CORBA sono tecnologie molto complementari, puoi iniziare lo sviluppo di CORBA in Java in modo rapido ed economico.

Una breve introduzione a CORBA

CORBA è una specifica che definisce il modo in cui gli oggetti distribuiti possono interagire. Fino all'esplosione della popolarità del World Wide Web, e in particolare del linguaggio di programmazione Java, CORBA era fondamentalmente una soluzione a oggetti distribuiti di fascia alta utilizzata principalmente dagli sviluppatori C ++.

L'attuale specifica CORBA è controllata dall'Object Management Group (OMG), un consorzio aperto di oltre 700 aziende (incluso il mio datore di lavoro) che lavorano insieme per definire standard aperti per il calcolo degli oggetti. Gli oggetti CORBA possono essere scritti in qualsiasi linguaggio di programmazione supportato da un produttore di software CORBA come C, C ++, Java, Ada o Smalltalk. Questi oggetti possono anche esistere su qualsiasi piattaforma supportata da un produttore di software CORBA come Solaris, Windows 95 / NT, OpenVMS, Digital Unix, HP-UX e AIX, tra gli altri. Ciò significa che potremmo avere un'applicazione Java in esecuzione su Windows 95 che carica e utilizza dinamicamente oggetti C ++ archiviati su Internet su un server Web Unix.

L'indipendenza dalla lingua è resa possibile tramite la costruzione di interfacce per oggetti utilizzando l'IDL (Interface Description Language). IDL consente di descrivere tutti gli oggetti CORBA nello stesso modo; l'unico requisito è un "ponte" tra il linguaggio nativo (C / C ++, COBOL, Java) e IDL. Gli oggetti CORBA comunicano tra loro utilizzando un ORB (Object Request Broker) come intermediario e possono comunicare su molti protocolli di rete popolari (come TCP / IP o IPX / SPX). ORB di diversi fornitori comunicano su TCP / IP utilizzando Internet Inter-Orb Protocol (IIOP), che fa parte dello standard CORBA 2.0 (l'ultima versione).

Attualmente, sono disponibili ORB di terze parti per i linguaggi di programmazione più popolari (inclusi C ++, Smalltalk, Java e Ada95). Con la crescente popolarità di altre lingue, i fornitori di CORBA rilasceranno senza dubbio ORB anche per quelle lingue.

L'OMG ha originariamente definito l'architettura di gestione degli oggetti (OMA) nel 1990 per descrivere il modo in cui le applicazioni potevano interagire. Come sottoinsieme di questo obiettivo, era necessario impostare uno standard per articolare il modo in cui i pezzi, o gli oggetti, all'interno delle applicazioni potevano interagire - da qui la nascita di CORBA. OMA definisce quattro parti principali che possono costituire un'installazione CORBA:

  1. L' Object Request Broker funge da bus software per l'intercomunicazione degli oggetti.
  2. CORBAServices definisce i servizi a livello di sistema che vengono aggiunti all'ORB, come sicurezza, denominazione e transazioni.
  3. CORBAFacilities definisce servizi a livello di applicazione, come documenti compositi e altre strutture verticali.
  4. Gli oggetti Business descrivono oggetti e applicazioni del mondo reale, come un aeroplano o un conto bancario.

Pratica: sviluppo CORBA in Java

Per costruire un'applet Java distribuita che accede agli oggetti del server utilizzando CORBA, utilizzeremo un popolare ORB commerciale e utilizzeremo l'IDL per definire le interfacce ai nostri oggetti. Il

Risorse

La sezione alla fine di questo articolo fornisce le informazioni di contatto per diversi noti fornitori di CORBA. Per l'applet di esempio che costruiremo, ho scelto di utilizzare Visigenic VisiBroker per Java. Questo ORB è stato concesso in licenza da diverse società, tra cui Oracle, Netscape e Novell, ed è incluso in Netscape Navigator 4.0.

Nota: è possibile eseguire questa applet in un browser diverso da Netscape Navigator 4.0. L'applet si avvierà un po 'più lentamente perché diversi file di classe Java aggiuntivi devono essere scaricati sul client.

Creeremo un semplice applet Java che istanzia un oggetto server utilizzando CORBA. Per semplicità, anche questo oggetto server verrà scritto in Java. L'oggetto server memorizzerà una serie di informazioni sui vari fornitori di ORB CORBA e sui loro prodotti. L'applet client creerà un'istanza dell'oggetto e interrogherà l'array per aggiornare lo schermo. Un esempio più completo (e vi incoraggio a considerare) sarebbe memorizzare le informazioni sull'ORB in un database relazionale e utilizzare JDBC (o qualche altro mezzo di accesso al database) sul server per recuperare le informazioni richieste. Questo approccio creerebbe una vera applicazione a tre livelli utilizzando CORBA.

Prima di iniziare la costruzione dell'applicazione, esamineremo più in dettaglio l'ORB e l'IDL utilizzati per definire l'interfaccia con l'oggetto.

L'Object Request Broker in dettaglio

La parte più importante dell'architettura di gestione degli oggetti è l'ORB. L'ORB è l'unica parte di CORBA che deve essere presente per creare un'applicazione conforme a CORBA. Molti ORB vengono spediti senza alcun servizio CORBAS o CORBAFacilities ed è necessario creare (o acquistare) gli oggetti Business da soli. Tuttavia, senza l'ORB, un'applicazione CORBA non può funzionare.

La funzione più visibile di un ORB CORBA è rispondere alle richieste dalla tua applicazione o da un altro ORB. Durante il ciclo di vita della tua applicazione CORBA in esecuzione, al tuo ORB potrebbe essere chiesto di fare molte cose diverse, tra cui:

  • Cerca e crea istanze di oggetti su macchine remote
  • Effettua il marshalling dei parametri da un linguaggio di programmazione (come C ++) a un altro linguaggio (come Java)
  • Gestisci la sicurezza attraverso i confini locali della tua macchina
  • Recupera e pubblica metadati sugli oggetti sul sistema locale per un altro ORB
  • Richiama metodi su un oggetto remoto utilizzando il richiamo del metodo statico descritto da uno stub scaricato
  • Richiama metodi su un oggetto remoto utilizzando il richiamo del metodo dinamico
  • Avvia automaticamente gli oggetti che non sono attualmente attivi e in esecuzione
  • Instrada i metodi di callback all'oggetto locale appropriato che sta gestendo

Il bello dell'ORB è che quasi tutti i dettagli di implementazione per tutti questi compiti sono nascosti allo sviluppatore del software. Fornire semplicemente gli "hook" appropriati nel codice per inizializzare l'ORB e registrare la tua applicazione con l'ORB apre la tua applicazione a una vasta galassia di oggetti distribuiti.

Descrivere oggetti usando IDL

Affinché CORBA mantenga la sua posizione neutrale rispetto al fornitore e al linguaggio, deve esserci un intermediario tra il codice del server CORBA C ++, ad esempio, e un client CORBA Java. Questo intermediario, come sai, è l'IDL. I metodi e le proprietà correlati supportati da un oggetto sottostante sono raggruppati in un'unica interfaccia utilizzando IDL. Una volta che l'interfaccia IDL è completa, può essere compilata nella lingua di tua scelta sotto forma di codice stub e skeleton. I compilatori IDL sono inclusi in tutti gli ORB. Ad esempio, un compilatore Java / IDL è incluso con Visigenic VisiBroker per Java ORB, mentre un compilatore C ++ / IDL è incluso con Visigenic VisiBroker per C ++ ORB.

Si noti che è molto più facile lavorare con IDL rispetto a un linguaggio di programmazione orientato agli oggetti standard perché IDL non può essere utilizzato per specificare l'effettiva implementazione delle classi o dei metodi al loro interno. Invece, IDL viene utilizzato solo per descrivere l' interfaccia agli oggetti sottostanti.

Dopo aver letto questa sezione, avrai abbastanza familiarità con la lingua per comprendere gli esempi presentati più avanti nell'articolo. Per una presentazione più approfondita su IDL, visitare il sito Web OMG. (Vedere la sezione Risorse di seguito.)

Proprio come proprietà e metodi sono raggruppati in classi correlate in Java, questi elementi sono contenuti nei moduli in IDL. Ci possono essere una o più interfacce definite all'interno di ogni modulo IDL. Il Listato 1 mostra un semplice modulo IDL denominato TheModule che contiene un'interfaccia di base denominata TheInterface. Questa interfaccia contiene una singola variabile (TheVariable, ovviamente) definita come un valore intero.

Listato 1: il modulo IDL più semplice possibile

Modulo TheModule {interfaccia TheInterface {long TheVariable; }; };

Se compili questo modulo IDL usando un compilatore da IDL a Java (come idl2java di Visigenic), otterrai l'interfaccia Java mostrata nel Listato 2.

Listato 2: l'equivalente Java di TheModule

pacchetto TheModule; interfaccia pubblica TheInterface {public int TheVariable; }

L'applet ORBQuery

Ora che hai una conoscenza di base di un ORB e IDL, siamo pronti per costruire la nostra applet ORBQuery. L'applet client consisterà in una GUI Java standard e creerà un'istanza di un oggetto CORBA remoto. Una volta che questo oggetto è stato istanziato, i suoi metodi possono essere chiamati per determinare le informazioni su uno specifico ORB CORBA. Sul lato server, dobbiamo definire cinque metodi per recuperare le seguenti informazioni su un particolare ORB: nome, fornitore, sistema operativo, lingue e URL. Pertanto, dobbiamo costruire un'interfaccia IDL che definisca cinque metodi per recuperare queste informazioni. Questa interfaccia,

ORBInfo

, è definito nel listato 3.

Listato 3: l'interfaccia IDL ORBInfo

module ORBQuery { interface ORBInfo { string GetName(in long index); string GetVendor(in long index); string GetOS(in long index); string GetLanguages(in long index); string GetURL(in long index); }; }; 

The VisiBroker installation includes an IDL compiler, idl2java, that you can use to generate the necessary Java code required to implement this interface. Once you've installed the package, simply execute the following command to generate the code:

idl2java ORBInfo.idl

This operation will create a subdirectory named ORBQuery (corresponding to the ORBQuery Java package). Within this directory, there are eight files: ORBInfo.java, ORBInfoHolder.java, ORBInfoHelper.java, _st_ORBInfo.java, _sk_ORBInfo.java, ORBInfoOperations.java, _tie_ORBInfo.java, and _example_ORBInfo.java. As you might have guessed, the ORBInfo.java file contains the Java version of the ORBInfo interface declaration, but what do the other Java classes do?

The ORBInfoHolder.java file contains a holder class used when passing parameters, while the ORBInfoHelper class defines various utility functions. The _st_ORBInfo class defines the client stub, while the _sk_ORBInfo class defines the server skeleton class. The ORBInfoOperations and _tie_ORBInfo classes are used to implement a tie mechanism, a VisiBroker feature designed to allow the implementation class to inherit from a class other than the skeleton class. We will not use these classes directly within this example. Finally, _example_ORBInfo contains a sample server object that can be extended to build the server application.

Se non l'hai ancora messo insieme, le otto classi Java create dal compilatore IDL ci hanno fornito un framework (sotto forma di classi helper, uno stub, uno scheletro e un'interfaccia) per costruire il nostro client / server CORBA applicazione in Java.

Creazione dell'applicazione server