Distribuerede objekter overalt - Distributed Objects Everywhere

Distribuerede objekter overalt ( DOE ) var et længe kørende Sun Microsystems- projekt til at opbygge et distribueret computermiljø baseret på CORBA- systemet i 'back end' og OpenStep som brugergrænseflade. Først startede i 1990 og annonceredes kort derefter derefter forblev det vaporware i mange år, før det endelig blev frigivet som NEO i 1995. Det blev solgt i kun en kort periode, før det blev droppet (sammen med OpenStep) i 1996. I stedet for er hvad der er i dag kendt som Enterprise JavaBeans .

Baggrund

I de tidlige 1990'ere var den 'næste store ting' inden for computing at bruge desktop- mikrocomputere til at vise og redigere data, der blev leveret af mainframes og minicomputers . Selvom der allerede eksisterede en række metoder til denne form for adgang, var arbejdsdelingen slet ikke ens. For eksempel krævede SQL , at arbejdsstationen skulle downloade enorme datasæt og derefter behandle dem lokalt, hvorimod brug af terminalemulatorer overlod alt arbejdet til serveren og gav ingen GUI .

Det så ud til, at den rette opdeling af opgaver ville være at have et kooperativt sæt objekter, hvor arbejdsstationen var ansvarlig for visning og brugerinteraktion med behandling på serveren. Stående i vejen for denne form for løsning var de enorme forskelle i operativsystemer og programmeringssprog mellem platforme. Selvom det muligvis er muligt at opbygge et sådant system, der fungerer på en kombination af arbejdsstation og server, fungerer den samme løsning ikke på noget andet system.

Mærkeligt nok var forskellene mellem to programmeringssprog på en enkelt platform næsten lige så store. Hvert sprog havde sit eget format til at overføre parametre til procedurekald , filformaterne, de genererede, var ofte ganske forskellige. Generelt var det ikke altid muligt at skrive forskellige dele af et program på forskellige sprog, skønt det ofte har reel nyttighed. Problemet var ikke så akut for minicomputere og mainframes, hvor sælgeren ofte specificerede standarder for deres biblioteker, men på mikrocomputere blev programmeringssystemerne generelt leveret af en række tredjepartsfirmaer uden interesse for standardisering.

Ikke desto mindre blev dette problem løst i de tidlige 1990'ere gennem introduktionen af ​​forskellige delte biblioteksystemer . Disse var faktisk beregnet til at lette ressourceforbruget på mindre platforme ved at lade et antal programmer, der bruger en fælles ressource, som GUI, dele en enkelt kopi af kode i stedet for at hver indlæser en separat kopi i hukommelsen. Som en bivirkning af, at de kunne kaldes fra mange programmer, definerede disse systemer også en standardmåde til at kalde dem ved hjælp af et grænsefladedefinitionssprog , eller IDL, for at tillade ethvert sprog på platformen at forstå koden inde i biblioteket.

At udvide disse systemer til at understøtte opkald til eksterne procedurer bag kulisserne blev set som en naturlig udvikling, hvilket giver en løsning på klient / serverprogrammeringsproblemet. På det tidspunkt var der en række store projekter til at levere et sådant system, herunder IBM 's System Object Model (SOM / DSOM), NeXT ' s Portable distribuerede objekter , Microsoft 's Component Object Model (COM / DCOM) og mange CORBA smagsoplevelser. Sun, der forsøgte at positionere sig som den fremtidige IBM med hensyn til backoffice-støtte, følte, at de også måtte angribe dette marked.

Forår, DOE, OpenStep, NEO

Suns løsning var baseret på arbejde i deres Spring- operativsystem, der brugte interkommunikationsobjekter til næsten alle programmeringsopgaver. Ændring af dette til at arbejde under en 'traditionel' Unix som Solaris var ikke så svært, selvom Unix antager, at alle programmer kører lokalt, og en grænseflade til fjernadgang måtte tilføjes. Til dette tilføjede DOE en objektforespørgselsmægler (ORB), der kørte på backoffice-serverne, lytter til DOE-anmodninger og overleverede dem til det rigtige program, der skal håndteres. Under udviklingen blev CORBA et vigtigt buzzword i branchen. Dette fik en forsinkelse, mens ORB blev genudviklet til CORBA-støtte. Under CORBA-modellen ville forskellige objekter, som dem fra DOE eller SOM, være i stand til at interagere ved at dele en fælles grænseflade.

Et større problem for Sun er, at de ikke havde nogen integreret programmeringsløsning til desktopobjekter. Selvom C ++ -objektbiblioteker blev almindelige på nogle platforme, var deres eget SunOS (senere kendt som Solaris ) operativsystem og tilknyttede SunView- og X- vinduessystemer 'almindelig C' -baseret, mens deres nyere NeWS- vinduesmiljø var baseret på et netværksudvideligt objekt orienteret dialekt af PostScript .

For at levere en omfattende og fleksibel objektprogrammeringsløsning vendte Sun sig mod NeXT og de to udviklede OpenStep . Ideen var at have OpenStep-programmer, der kalder DOE-objekter på Sun-servere, hvilket giver en backoffice-to-frontoffice-løsning på Sun-maskiner. OpenStep blev ikke frigivet før i 1993, hvilket yderligere forsinkede projektet.

Da DOE, nu kendt som NEO, blev frigivet i 1995, var Sun allerede gået videre til Java som deres næste store ting. Java var nu det GUI, der blev valgt for applikationer på klientsiden, og Suns OpenStep-planer blev roligt droppet (se Fyrtårnsdesign ). NEO blev genopstillet som et Java-system med introduktionen af ​​"Joe" -rammen, men det så lidt til. Komponenterne til NEO og Joe blev til sidst subsumeret i Enterprise JavaBeans .

Selvom distribuerede genstande og især CORBA var den "næste store ting" i de tidlige 1990'ere, var interessen for dem i det andet halvår i det væsentlige forsvundet. Web-baserede applikationer, der kører fuldstændigt på serveren, blev den nye "næste store ting", og behovet for et kraftfuldt displaysystem på klientsiden falmede, stort set erstattet af lette GUI'er baseret på HTML og JavaScript (" Browser User Interfaces ").

Referencer

eksterne links

Shah, Rawn (1. juni 1996). "Distribueret objektberegning med Joe og NEO" . JavaWorld . Hentet 2006-12-13 .