Alexandru Pănoiu
OSF Distributed Computing Environment (DCE, Mediul de Prelucrare Distribuită) este un pachet de specificatii (Application Environment Specification, AES) ale serviciilor utilizabile de către o aplicatie client-server într-un mediu distribuit si eterogen. Odată cu specificatiile DCE, Open Software Foundation a realizat si un set de produse-program care implementează aceste servicii, facilitează administrarea lor si simplifică elaborarea, testarea si instalarea aplicatiilor care le utilizează. Fiecare producător are libertatea de a utiliza si adapta produsele OSF, sau de a trece la propria sa implementare. Pentru utilizator, si pentru conceptul DCE, nu contează decât asigurarea compatibilitătii.
După specificatiile interfetei grafice cu utilizatorul OSF Motif si sistemul de operare OSF/1, OSF DCE este al treilea rezultat major al efortului Fundatiei. Ca si Motif, DCE reprezintă un strat software destinat pe de o parte simplificării modului de utilizare al unor posibilităti preexistente, si pe de altă parte stergerii diferentelor dintre diferitele calculatoare, retele si sisteme de operare. Americanii îi spun „enabling technology" - tehnologie de acces. După locul care-l ocupă, între aplicatie si resursele oferite de sistemul de operare, DCE este un exponent tipic al produselor-program de nivel intermediar. Conform estimărilor firmei americane INPUT, volumul vânzărilor mondiale de astfel de produse „middleware" va atinge 5,5 miliarde de dolari pe an în 1999, din care o treime (1,7 miliarde de dolari) va fi reprezentată de produse compatibile cu OSF DCE.
Principalul scop al DCE este asigurarea interoperabilitătii între diferitele platforme, asigurându-se posibilitatea distribuirii componentelor client si server ale feluritelor aplicatii, indiferent de arhitectura hardware sau software a calculatoarelor din retea, si, desigur, independent de protocolul de transport sau de mediul fizic de comunicare utilizat.
Prin capacitatea sa de a folosi eficient echipamentele preexistente, DCE oferă administratorului sistemului informatic o mare flexibilitate în dezvoltarea si punerea rapidă în operă a unui sistem client-server. Programatorii dispun de o interfată programată comună, crescându-si pe această bază productivitatea, si având în plus posibilitatea realizării mult doritei portabilităti a utilizatorilor.
Întrucât DCE este implementat peste sistemul de operare al fiecărei masini, aplicatiilor le stau la dispozitie toate facilitătile acestuia, asigurând accesul la datele existente sau programele preinstalate.
DCE este o etapă importantă pe drumul către împlinirea promisiunii sistemelor deschise; aplicatiile construite peste DCE pot colabora deasupra diferentelor care continuă să separe o structură hardware de alta, un sistem de operare de altul, procesorul Intel 80x86 de PA-RISC 7200 sau Microsoft Windows de OpenVMS. Ne aflăm în fata unei noi strategii de abordare a deschiderii informatice: dacă OSF/1 sau POSIX tind la unificarea variantelor UNIX într-un singur sistem, OSF DCE recunoaste varietatea platformelor si tinteste către asigurarea unei coexitente pasnice însotită de o fructuoasă colaborare.
DCE este disponibil astăzi pe o diversitate de platforme; multi fabricanti de echipamente si producători de software văd în DCE un produs strategic. Problema esentială este întotdeauna aplicatia utilizatorului: iar aplicatiile dezvoltate cu DCE vor rula oriunde este disponibil DCE.
Revenind la concretul cotidian, DCE este disponibil pentru:
Uneori, partea client a DCE este livrată odată cu sistemul de operare de bază (HP-UX V10.0, sau Digital UNIX). Din partea unor mari producători de produse-program (Novell, Microsoft) a fost exprimată dorinta de a asigura interoperabilitatea cu DCE, în special cu Serviciul de Nume.
DCE oferă uneltele si serviciile necesare pentru dezvoltarea si executia aplicatiilor distribuite. Pentru dezvoltarea acestora, DCE pune la dispozitia programatorului un set de functii de bibliotecă standardizate, disponibile pe orice platformă care suportă DCE, si un preprocesor care simplifică utilizarea lor. Executia aplicatiilor distribuite se sprijină pe un număr de procese de sistem (demoni); după instalarea si configurarea DCE pe calculatoarele dintr-o retea acesta se transformă într-un vehicul dedicat rulării aplicatiilor distribuite. Fiecare masină poate dispune de componentele software necesare pentru a executa atât partea client cât si partea server a aplicatiei.
Modul în care calculatoarele sunt utilizate pentru prelucrarea datelor se află într-o etapă de profundă transformare, odată cu cresterea rapidă a numărului de calculatoare personale, statii de lucru, retele locale si de arie largă. Utilizatorii doresc, si cer vehement, posibilitatea de a folosi datele, aplicatiile, puterea de calcul si facilitătile disponibile dincolo de limitele masinii în fata căreia se află. Interoperabilitatea în cadrul unei retele eterogene nu mai este un deziderat, ci o necesitate; flexibilitatea este un imperativ dictat de complexitatea zdrobitoare a marilor retele „printre" care lucrăm.
Comunicatia între calculatoare este asigurată de retelele deja implementate, angajate într-un continuu proces de extindere, asemănător cumva cu extinderea retelelor de cale ferată la sfârsitul secolului trecut. Acum o sută de ani problema a fost rezolvată prin adoptarea unor standarde universal valabile (sau, mă rog, cu exceptia Rusiei, care probabil că este un univers aparte). Drept urmare, putem călători pe drumul de fier de la Bucuresti la Paris, cu acelasi bilet si cu acelasi vagon.
Dar interconectivitatea asigurată de TCP/IP (ecartament normal) sau poate de OSI (ecartament larg) nu este suficientă: „distribuit" si „client-server" sunt lozincile noului manifest. Studiile efectuate de OSF si de X/Open au arătat că principala preocupare a utilizatorilor de tehnică de calcul este interoperabilitatea. Aplicatiile distribuite au nevoie de un set de servicii bine definite, de apel, de sincronizare, de acces la date, de nume, de autentificare si validare a drepturilor de acces. Aceste servicii sunt oferite de OSF DCE. Uniformitatea serviciilor oferite fiecărui proces care rulează pe o masină ce participă la efortul de calcul distribuit asigură posibilitatea utilizării optimale a resurselor întregii retele.
DCE se bazează pe un model stratificat, în care sunt identificate serviciile de bază necesare celor mai multe aplicatii distribuite (vezi figura Arhitectura DCE). Aceste cinci servicii (RPC, CDS si GDS, DTS, Security si Threads) formează asa-numitul „nucleu DCE" (secure core), setul minim a cărei existentă este garantată de orice implementare DCE. Pe lângă ele sunt prevăzute servicii de partajare a datelor (DFS, suport pentru calculatoare fără discuri fixe, suport pentru MS-DOS - servicii de fisiere si de imprimare).
RPC (Remote Procedure Call, Apelul de Proceduri la Distantă) este temelia DCE, si în general a constructiei aplicatiilor client-server. Facilitatea RPC este independentă de arhitectura hardware a masinii (32 sau 64 de biti, cu MSB primul sau cu LSB primul), de sistemul de operare si de transportul utilizat. Programatorul descrie interfetele RPC importate sau exportate de aplicatie într-un limbaj generic, IDL (Interface Definition Language), din care un translator special generează declaratii C (sau FORTRAN).
CDS (Cell Directory Service, Serviciul de Nume al Celulei) rezolvă numele simbolice asociate resurselor disponibile într-o celulă DCE; când este nevoie de rezolvarea unui nume din afara celulei, CDS apelează automat GDS (Global Directory Service, Serviciul Global de Nume). GDS implementează întreaga recomandare CCITT X.500 (ISO 9594).
CDS memorează informatiile asociate fiecărui nume într-o bază de date specifică, numită depozit („clearinghouse"); această bază de date poate fi total sau partial replicată, cu scopul cresterii performantelor.
DTS (Distributed Time Service, Serviciul de Distribuire a Timpului) sincronizează orologiile masinilor din întreaga retea de arie largă, cu beneficii evidente pentru utilizatorii sistemului distribuit de fisiere sau al aplicatiilor tranzactionale.
Security Service (Serviciul de Securitate) asigură coerenta autentificării utilizatorilor (bazată pe un Registru de Utilizatori - User Registry - distribuit si pe sistemul Kerberos dezvoltat la MIT în cadrul Proiectului Athena) si a validării diferitelor cereri de acces. RPC utilizează Serviciul de Securitate pentru a asigura confidentialitatea datelor transferate.
Threads Service (Serviciul de Gestiune a Proceselor Usoare) este actualmente o implementare a POSIX 1003.4a (draft 4), care îngăduie lansarea în paralel a unui mare număr de apeluri de proceduri la distantă; si invers, un server care utilizează procese usoare („threads" sau „light-weight processes") poate răspunde simultan la multe cereri ale clientilor. Un proces usor împarte acelasi spatiu de date utilizator (dar nu si aceeasi stivă) cu celelalte procese usoare din cadrul unui proces propriu-zis (numit uneori proces greu, „heavy-weight process").
DCE Threads este utilizat în special de aplicatiile server, pentru a putea lucra cu mai multe procese usoare care împart acelasi spatiu utilizator. Este posibilă (si chiar des întâlnită) situatia în care DCE Threads este numai un strat subtire peste o implementare a proceselor usoare specifică sistemului de operare subiacent. În general câteva sute de procese usoare în cadrul aceleiasi aplicatii server nu pun probleme de performantă.
DFS (Distributed File Service, Serviciul de Distribuire a Fisierelor) oferă o functionalitate asemănătoare cu NFS (celebrul Network File System introdus de Sun). DFS se deosebeste de NFS (cu care este de altfel interoperabil) prin câteva caracteristici importante; astfel:
Un domeniu DCE este format din celule („cells"). Celula este unitatea de bază de administrare si utilizare a DCE (vezi figura Structura unei celule DCE). De obicei o celulă constă din nodurile grupate într-o aceeasi zonă, de obicei o retea locală; dar nu aceasta este caracteristica unei celule.
O celulă DCE este formată din utilizatorii, sistemele de calcul si resursele care au un scop comun si partajează un număr de servicii DCE. În fiecare celulă rulează cel putin CDS (Serviciul de Nume al Celulei), Security Service (Serviciul de Securitate) si DTS (Serviciul de Distribuire a Timpului). Un singur calculator poate forma o celulă DCE, dar o celulă DCE poate contine mii de calculatoare. Dimensiunea celulei este determinată de necesitatea de partajare eficientă a resurselor, a scopurilor, si de necesitatea limitării efortului de administrare.
Fiecare celulă trebuie să aibă un server de securitate si o bază de date de autentificare. Pe de o parte, celulele trebuie să fie suficient de mici pentru ca daunele produse de compromiterea securitătii unei celule să fie limitate, dar pe de altă parte numărul de celule dintr-o organizatie nu poate creste prea mult, pentru a evita complicarea activitătilor de gestiune care se desfăsoară la nivelul întregului domeniu.
Cel putin unul dintre calculatoarele dintr-o celulă rulează serverele serviciilor de Nume, de Securitate si de Timp. Fiecare calculator din celulă trebuie să ruleze clienti CDS, Security si DTS (terminologia originală este „CDS, DTS etc. clerk", adică „functionar").
O resursă partajată trebuie să poată fi identificată printr-un nume pentru a fi utilizatabilă. Depozitul de nume al unei celule DCE este gestionat de Serviciul de Nume al Celulei; dacă acesta nu poate rezolva un nume, se adresează unui intermediar (Agentul de Nume Globale, Global Directory Agent) care transmite cererea de rezolvare fie către Serviciul de Nume Globale (GDS), bazat pe X.500, fie către mai pământeanul Domain Name Service (DOMAIN, RFC 1034 si 1035).
Spatiul de nume DCE este organizat ierarhic, după modelul sistemului de fisiere UN*X; de altfel, sistemele UN*X au utilizat sistemul de fisiere ca dictionar din cele mai vechi timpuri - gânditi-vă ce sunt de fapt „fisierele speciale" si „conductele cu nume" sau „socketurile din domeniul UNIX", decă nu niste asocieri între un nume si valoarea sa, memorate în sistemul de fisiere numai pentru că alt spatiu de nume comun tuturor proceselor nu exista.
Într-un nume global, să zicem
/.../C=US/O=XYZ/OU=Portland/subsys/PriceMax/price_server1
prefixul /... identifică un nume global, C=US/O=XYZ/OU=Portland este numele unei celule (în format X.500; C vine de la Country, O de la Organization, iar OU de la Organization Unit); în fine, /subsys/PriceMax/price_server1 este numele unui server din cadrul respectivei celule.
Un alt exemplu:
/.../abc.com/hosts/asystem
se descompune în /... (prefix pentru nume globale), abc.com (numele unei celule în format DOMAIN - „numele calificat" din adresele de postă Internet), si /hosts/asystem, numele unui sistem din cadrul acelei celule.
Referirile la nume rezolvate în cadrul celulei locale se caracterizează prin utilizarea prefixului /.: în loc de /.../nume_celulă; de exemplu, pentru o aplicatie care rulează în cadrul celulei C=US/O=XYZ/OU=Portland, serverul exemplificat mai sus poate fi reperat prin numele /.:/subsys/PriceMax/price_server1.
Serviciul de Nume poate interoga alte servicii DCE (mai ales Serviciul de Securitate si Serviciul de Distribuire a Fisierelor) prin intermediul unor jonctiuni; o jonctiune este un nume special în CDS - de exemplu /.:/sec este jonctiunea pentru interogarea Serviciului de Securitate. Un nume global de utilizator, de exemplu
/.../loc.org.com/sec/principals/mozart
se descompune în /.../loc.org.com (numele global al unei celule), /sec (jonctiunea cu Serviciul de Securitate) si /principals/mozart, adică mozart din baza de date de principali - Serviciul de Securitate numeste principali sau mandanti („principals") utilizatorii si serverele dintr-o celulă.
În mod similar, un fisier exportat de DFS are un nume global:
/.../loc.org.com/fs/users/mozart/opusnplus1
care poate fi referit local drept
/.:/fs/users/mozart/opusnplus1
sau
/:/users/mozart/opusnplus1
(/.:/fs este jonctiunea cu DFS, dar numele ei poate fi schimbat; prefixul /: se referă întotdeauna la rădăcina sistemului de fisiere exportat de DFS).
În fine, se cuvine să mentionez două nume deosebite: /.:/cell-profile si /.:/lan-profile; acestea identifică fisiere în care sunt înregistrate numele serverelor din celulă, si respectiv din reteua locală (pot exista mai multe retele locale într-o celulă).
Înainte de RPC au fost soclurile („sockets"); apoi modelul Open Network Computing popularizat de Sun a adus conceptul de Apel de Procedură la Distantă (ONC RPC) la îndemâna programatorilor. DCE RPC reprezintă o metodologie rafinată, simplă si totusi suficient de flexibilă pentru a răspunde cerintelor lumii de astăzi.
Într-o retea de calculatoare se observă adesea o disproportie între gradul de încărcare al diferitelor masini; în timp ce unele procesoare stau neutilizate, o multime de utilizatori se plâng de timpul de răspuns enervant de mare al unor biete calculatoare suprasolicitate. Unul dintre principalele obstacole în calea utilizării întregului potential de calcul din retea este varietatea arhitecturilor hardware si software prezente, de regulă incompatibile.
Facilitatea de apel de proceduri la distantă (Remote Procedure Call, RPC) oferită de DCE maschează diferentele dintre diferitele tipuri de calculatoare, convertind automat datele la reprezentarea cerută de fiecare dintre participatii la dialog. O aplicatie care utilizează DCE RPC poate folosi puterea oricărui calculator din retea. Descrierile interfetelor dintre clienti si servere sunt separate de modulele care le utilizează; mai multe versiuni succesive ale specificatiilor de interfată pot fi utilizate simultan în retea, mecanismele RPC asigurând cuplarea fiecărui client cu un server care să-l înteleagă corect.
Mai mult, prin componenta DCE Threads, o aplicatie poate executa simultan apeluri de proceduri la distantă pe mai multe calculatoare din retea, iar un server poate răspunde simultan mai multor clienti, crescând si mai mult gradul de utilizare al resurselor disponibile.
Prin replicarea aplicatiilor importante si a datelor manipulate de ele, DCE ajută la sporirea disponibilitătii retelei; utilizatorii sunt astfel protejati în eventualitatea căderii unui calculator.
Redarea stereoscopică a unui obiect necesită două puncte de vedere diferie: vom examina asadar RPC din punctul de vedere al programatorului care dezvoltă o aplicatie client-server, si apoi din punctul de vedere al sistemului care o execută.
Elementul central al programării interactiunii dintre partea client si partea server a unei aplicatii utilizând DCE RPC este descrierea interfetei folosite. În conceptia DCE, o interfată este un element foarte concret, care apare sub forma unui fisier sursă în limbajul IDL, în care sunt descrise operatiile puse la dispozitie de server. Se spune că serverul exportă interfata, iar clientul o importă.
Fiecare interfată dintr-un domeniu DCE este caracterizată de un număr UUID (Universal Unique Identifier) unic, generat de utilitarul uuidgen, si un număr de versiune; orice apel de procedură la distantă cere potrivirea dintre numerele UUID si versiunile cerute de un client si cele oferite de serverul corespunzător.
Limbajul acceptat de compilatorul IDL este foarte asemănător cu limajul C; singura diferentă marcantă este dată de prezenta unor atribute scrise între paranteze pătrate; asemănarea dintre cele două limbaje nu trebuie să ne ducă la concluzia eronată că limbajul C este singura tintă posibilă pentru IDL: C++ este desigur o optiune - există chiar biblioteci specifice pentru C++, care îmbracă rutinele DCE într-o haină orientată pe obiecte -, iar universalul FORTRAN este si el acceptabil.
Iată cum arată un fisier IDL, în care este descrisă o singură operatie, prin care clientul primeste de la server un sir de caractere reprezentând o formulă de salut (aplicatia din care provine acest text este o variantă distribuită, client-server a faimosului program hello, world!).
/* File name: hello_world.idl */
[
uuid(num{r_hexa_foarte_lung_generat_de_uuidgen) ,
version(1.0)
]
interface hello_world
{
/* Tipuri de date */
const long MAX_STRING = 28 ;
typedef [string] char string_t [MAX_STRING+1];
/* Operations */
void get_hello_world ( [out] string_t
greeting ) ;
}
Din hello_world.idl, compilatorul IDL generează (vezi figura Dezvoltarea unei aplicatii client-server):
În aplicatia client, functia get_ hello_world () poate fi apelată ca orice altă functie:
#include
#include "hello_world.h"
string_t hello ;
main ()
{
printf ("Interoghez serverul prin RPC...\n") ;
get_hello_world (hello) ;
printf ("Serverul mi-a transmis: %s\n", hello) ;
}
Aplicatia server este mai complicată putin; în esentă, ea trebuie să definească functia get_hello_world (), să înregistreze interfata în structurile de date ale bibliotecii DCE, să precizeze transportul utilizat, să exporte numele interfetei către CDS (pentru a putea fi regăsită de către client), să se înregistreze în harta punctelor finale („endpoint map") exploatată de rpcd (RPC Daemon) si să astepte apeluri de la distantă:
#include
#include
#include
#include "hello_world.h"
/* definitia procedurii apelate de la distanta */
void get_hello_world (string_t greeting)
{
strcpy (greeting, "Hello, world!") ;
}
/* programul principal initializeaza serverul */
main ()
{
unsigned32 status ;
rpc_binding_vector_t *binding ;
char entryname [80] ;
char hostname [80] ;
rpc_server_register_if (hello_world_v1_0_s_ifspec,
NULL, NULL, &status) ;
rpc_server_use_all_protseqs (rpc_c_protseq_max_reqs_default,
&status);
rpc_server_inq_bindings (&binding, &status) ;
gethostname (hostname, sizeof (hostname)) ;
sprintf (entryname, "/.:/hello_svr_%s", hostname) ;
rpc_ns_binding_export (rpc_ns_syntax_default,
(unsigned_char_t *) entryname, hello_world_v1_0_s_ifspec,
binding,
NULL, &status) ;
rpc_ep_register (hello_world_v1_0_ifspec,
binding, NULL,
(unsigned_char_t *) "Hello World interface", &status) ;
rpc_binding_vector_free (&binding, &status) ;
rpc_server_listen (1, &status) ;
}
Lucrurile se petrec ca si cum o editare de legături miraculoasă ar fi avut loc între cele două aplicatii, desi una poate rula aici si cealaltă în Antarctica, una pe Alpha AXP sub Digital UNIX si cealaltă pe IBM System/370 sub MVS.
Serverul trebuie lansat înainte de a putea primi cereri de la clienti. De multe ori aplicatiile server sunt lansate în ultima fază a initializării sistemului de operare.
După ce a pornit, prima grijă a unui server este să se asigure că interfetele exportate de el pot fi regăsite de clienti. Pentru aceasta, serverul parcurge următoarele etape:
Dinspre partea sa, aplicatia client are o sarcină mai simplă, mai ales din punctul de vedere al programatorului (si mai ales dacă nu se iau în consideratie posibilitătile de acord fin pentru cresterea performantelor). La apelul rutinei get_hello_world (), functiile din biblioteca DCE RPC constată că nu au nici o informatie despre vreun server care să cunoască interfata cu acel UUID si versiunea corespunzătoare. O cerere de rezolvare este adresată Serviciului de Nume, care răspunde întorcând adresa calculatorului pe care rulează acesta. Biblioteca RPC ia legătura cu demonul rpcd de pe acel calculator, cu cererea de a examina harta punctelor finale în căutarea unei interfete cu un anumit UUID si o anumită versiune. rpcd răspunde cu adresa completă a serverului (de exemplu, pentru o comunicatie prin UDP/IP, adresa de retea a masinii si numărul portului pe care ascultă serverul). Aceste date sunt memorate local de biblioteca RPC de pe masina client, pentru a accelera eventualele apeluri ulterioare.
Biblioteca RPC trece apoi la efectuarea propriu-zisă a apelului la distantă (figura Etapele unui apel de procedură la distantă); parametrii de intrare ai procedurii sunt convertiti la o reprezentare uniformă, independentă de arhitectura hardware („marshalling", aliniere), si trimisi către server; acolo are loc procesul de conversie la reprezentarea specifică arhitecturii hardware a serverului („unmarshalling"), urmat de apelul procedurii definite de server. Parametrii de iesire urmează un traseu analog, de data asta fiind convertiti de server la reprezentarea neutră, emisi pe retea, receptionati de biblioteca RPC a clientului, convertiti la reprezentarea locală si în cele din urmă transmisi functiei apelante.
Mecanismul de apel de proceduri la distantă este quasi-transparent pentru aplicatiile client; în ceea ce-i priveste pe utilizatorii acestora, detaliile de implementare sunt complet ascunse. Administratorul unei celule DCE are rareori motive să modifice manual harta punctelor finale sau numele înregistrate în CDS de aplicatiile distribuite; dacă totusi este nevoie de astfel de actiuni magice, utilitarul rpccp (RPC Control Program) îngăduie utilizatorului cell_admin să efectueze orice manevră.
Serviciul de securitate asigură un mecanism uniform de autentificare a principalilor („principals") - utilizatori, servere sau calculatoare gazdă - în întreaga celulă DCE. Pe baza cheilor secrete (parole) ale principalilor, Serviciul de Securitate eliberează tichete criptate, care pot fi ulterior utilizate ca dovadă a identitătii.
Fiecare principal face parte dintr-unul sau mai multe grupuri si dintr-o organizatie. Drepturile de acces la resursele disponibile în retea sunt memorate în liste de control al accesului (ACLuri). Fiecare aplicatie este responsabilă de interpretarea ACLurilor asociate obiectelor manipulate de ea; de exemplu, DFS contine un manager de ACLuri pentru fisierele din sistemul distribuit de fisiere.
Pentru autentificarea principalilor peste granitele unei celule, serverul de securitate al celulei principalului functionează ca intermediar; prin intermediul său principalul primeste un tichet de autentificare care este valabil în celula de la distantă. Acest mecanism de intermediere prezintă două caracteristici importante pentru administratori: pe de o parte, o singură cheie secretă (parolă) partajată este suficientă pentru cooperarea dintre serverele de securitate din două celule diferite; dar pe de altă parte compromiterea unui server de securitate este automat echivalentă cu compromiterea securitătii tuturor celulelor cu care acesta interopera.
DCE include optiunea de criptare a datelor vehiculate de retea de RPC; algoritmul utilizat este DES, si deci o serie de restrictii de export se aplică asupra utilizării acestei optiuni în afara Statelor Unite.
CORBA (Common Object Request Broker Architecture), un model de programare multi-proces si/sau distribuită orientată pe obiecte, se află în plină evolutie; este poate interesantă o comparatie între aceasta si DCE.
De la prima vedere apare clar faptul că cele două modele se plasează la nivele diferite. În timp ce CORBA accentuează interfata dintre programele de aplicatie si dispecerul de cereri de obiecte („object request broker"), DCE accentuează interfata dintre aplicatie si serverul final. DCE contine componente de securitate, distribuire a timpului si gestiune a proceselor usoare, absente din CORBA. Restul diferentelor sunt relativ putin importante; mai ales cele două limbaje de specificare a interfetelor sunt foarte asemănătoare.
OSF si OMG (Object Management Group, sustinătorul CORBA) cooperează pentru asigurarea interoperabilitătii celor două sisteme. DCE a fost selectat ca unul dintre mecanismele de interoperabilitate între sisteme eterogene bazate pe CORBA 2.0.
OSF DCE AES este un standard pentru realizarea aplicatiilor distribuite, client-server: si are multe sanse de a se impune ca standardul de interoperabilitate. Tehnologia OSF DCE este adoptată de un mare număr de producători, fiind deci atractivă pentru cei care dezvoltă aplicatii distribuite în retele eterogene, sau pentru diferite platforme. DCE continuă să evolueze; o versiune nouă este asteptată în cursul acestui an. Este de asteptat ca OSF DCE să joace un rol foarte important în domeniul aplicatiilor distribuite până la începutul secolului următor.
Microdictionar DCE