Opendoc mot OLE

---

Alle de store porgramvarehusene er enig om modellen for neste generasjons programvare. Kampen står foreløpig mellom OLE og Opendoc, to vidt forskjellige systemer med hver sine støttespillere. OLE er i salg mens Opendoc lover et smidigere system. Hvem blir vinneren?

---

Opendoc er åpen

En sammenlikning av Opendoc og OLE/COM avdekker enorme forskjeller. Å være konkurransedyktig betyr at man er i stand til å reagere og tilpasse seg raskt, og her er komponentprogramvare avgjørende. Opendoc ble utformet for å bygge fleksible applikasjoner basert på komponenter. På den annen side var Object Linking and Embedding (OLE) og dens Common Object Model (COM) ment å knytte sammen de monolittiske, almenn-orienterte applikasjonene fra en del år tilbake. OLE/COM er slik sett knyttet til en tidligere tidsalder i programvarens evolusjon.

En komponentstandard må utvikles gradvis, ha størst mulig tilgjengelighet og være lett å bruke. Opnedoc er den eneste standarden for programvare-komponenter som oppfyller disse kravene. Den er i dag tilgjengelig for Windows, Mac OS og OS/2. I tillegg planlegger IBM å gjøre den tilgjengelig for Unix, OS/400 og MVS.

Novells Word Perfect, Apple og IBM har levert utviklingsverktøy til mer enn 54 000 utviklere over hele verden. Mange programvareleverandører, herunder Taligent, Adobe, Novell, Apple og IBM, kommer til å levere Opendoc-komponenter og -verktøy i 1995.

Bedriftene har gjerne størst utbytte av et programvaremiljø sammensatt av standardutstyr og spesialenheter. Noen av enhetene kjøper vi rett fra butikkhyllene, andre brukertilpasser vi og noen lager vi på egenhånd. Slike blandede, sammensatte miljøer krever mer fleksible applikasjoner samtidig som kostnadene reduseres. Opendoc er skapt for slike miljøer.

Målestokk

Den viktigste er at objektstyrings-tjenestene i Opendoc er basert på IBMs System Object Model (SOM) som samsvarer fullt og helt med Object Management Groups (OMG) Common Object Request Broker Architecture. Disse tjenestene gjør det mulig å å få tilgang til og beskytte komponenter hvor enn de måtte befinnes seg. Komponenter kan tilføyes eller erstattes etter behov, slik at det til enhver tid er mulig å oppfylle de krav virksomheten stiller.

Opendocs komponenttjenester er dessuten basert på Apples Bento filformat, som brukes i utstrakt grad av Lotus og andre. Disse tjenestene gjør brukerne i stand til å lagre og utveksle komponentdata. Mens en avdeling i en bedrift er i ferd med å utvikle nye forretningsideer, kan en annen kommentere disse umiddelbart. Sammensatte dokument- og automatiseringstjenester, som omfatter Apples Open Scripting Architecture, gjør det enkelt for utviklere å brukertilpasse applikasjoner og reduserer kostnadene til opplæring av brukere.

Opendoc er ment å "vokse" gradvis for brukere og utviklere slik at applikasjoner kan plukke opp nye funksjoner raskt og rimelig. Thomas J. Mowbray, en ledende forsker ved Mitre, kommenterer denne fleksibiliteten i november, 1994-utgaven av bladet Object. Han merker seg at Opendoc, i motsetning til OLE/COM, "er utformet med en arkitektur som kan utvides og som ikke forutsetter omfattende revisjon for å kunne støtte spesialiserte applikasjonskrav." Grunnen til dette er at Opendoc er beregnet på komponenter som kan utvides - virkelige objekter - mer enn applikasjoner.

For eksempel kan Opendocs innkurv raskt utvides til å sortere og filtrere post. Ved hjelp av virkelig objekt-teknologi blir Opendoc-komponenter små, effektive og enkle å utvikle. Til sammenlikning er programmeringen for OLE komplisert og ufleksibel. OLE 1.0, som har 50 unike applikasjonsprogrammerings-grensesnitt (API-er), var vanskelig nok å håndtere. OLE 2.0s 400 API-er er rene bøygen for utviklere, og krever omfattende en omstrukturering av applikasjonene.

OLEs COM, som er metoden OLE-utviklere må bruke for å definere sine komponenter, gjør ikke saken noe enklere. Den er en spesifikasjon (ikke en implementering) som hver utvikler må implementere, likevel hindrer den utviklerne i å utvide komponentene på en effektiv måte gjennom underklassifisering. COM har så mange begrensninger at Digital Equipment har tatt på seg oppgaven med å "pusse den opp".

Flerplattform

og OMGs overføringstjenester.

Ifølge Mowbray vil derimot OLE/COM passe utelukkende for Microsofts desktopsystemer og proprietære verktøy. OLE er mer knyttet til Windows fordi COMs API-er er svært avhengige av Microsofts implementering av C++, opplyser han.

Microsoft sier de skal implementere distribuert OLE i Cairo, som nå antas å være forsinket på samme måte som Windows 95.

Opendoc gjør brukerne mer produktive og reduserer opplæringskostnadene på grunn av effektiviteten. OLEs røtter i applikasjons-kobling gjør at OLE-applikasjonene blir store, trege og unaturlige for brukere og utviklere. Eksempelvis kan ingen OLE-komponenter overstige én side, de kan ikke overlappe hverandre og hvert komponent må ha en rektangulær form. Dessuten kan kun én OLE-komponent være aktiv på en gang.

Microsoft har lovet bot og bedring, men selskapets fortid er full av historier om funksjoner som mangler, hyppige og avbrutte oppgraderinger, inkonsekvente implementeringer og oppblåste systemer med svak ytelse.

Slik er altså ståa. Dersom du utelukkende skal bruke Windows, kjøper all programvaren fra butikkhyllene, ikke er tilknyttet noe nettverk og ikke har noe imot å skifte ut programvaren annet hvert år, kjøp OLE.

OLE er i salg

Etter min oppfatning hersker det liten tvil om hvem som går seirende ut av "krigen" mellom OLE/COM og Opendoc. Object Linking and Embedding (OLE) slår ut rivalen både fra et forretningsmessig og teknisk synspunkt, og det i en slik grad at hele denne krigen virker nokså meningsløs.

En av fordelene med å bruke OLE er at det går en klar linje i utviklingen fra dagens mest utbredte personlige produksjonsprogrammer til "komponentware". Og dens Common Object Model (COM) peker mot distribuerte objekter.

Et av formålene med både OLE/COM og Opendoc er å legge forholdene til rette for "komponentware", hvilket i klartekst betyr programvaremoduler fra forskjellige leverandører som kan settes sammen for å lage applikasjoner. Tanken bak er å gi brukerne tilgang til forskjellige applikasjonsverktøy fra samme dokument. I begge teknologier er det benyttet progamvareobjekter og planlagt støtte for distribuerte objekter.

Tilgjengelighet

Et tenkt eksempel: Hvis du var teknisk ansvarlig i en stor brukerorganisasjon, ville du satset på en rykende fersk Opendoc eller OLE, med Microsofts fulle tyngde i ryggen og en installert base av Windows-utviklere? Rundt 60.000 OLE programvare-utviklingspakker var levert før pakkene ble utstyrt med Visual C/C++, og mange flere har gått ut siden det.

OLE 2.0 har dessuten i ryggen hundrevis av uavhengige programvareleverandører som lager brukerprodukter. Microsofts liste over utviklere for høsten 1994 inneholdt 433 selskaper som leverer OLE-applikasjoner.

Microsoft (og Windows' de facto standard) er nå så godt etablert at det er vanskelig å se for seg at man skulle kaste alt man har investert i for å satse på ferskingen Opendoc. Økonomisk ville det være helt bak mål.

Teknisk sett er OLE en drøm. Objektteknologien som ligger til grunn for OLE, Digital og Microsofts COM, er langt mer konstant enn den som benyttes i Opendoc. Hvert OLE-objekt er per definisjon et COM-objekt. Og nettverksdistribusjon av objekter som i dag eksisterer bare lokalt, har vært et av hovedmålene i utformingen av COM.

Så langt har Opendocs alpha-utgaver benyttet C++-biblioteker til objektstøtte. Senere utgivelser kommer til å bruke IBMs System Object Model og deretter Distributed SOM (DSOM). Med andre ord, et mareritt for utviklere, som må lære seg tre forskjellige programmeringsmodeller ettersom de går fra C++ til SOM til DSOM. COM, derimot, er og blir det samme, også i nettverksmiljøer.

OLE har altså ikke bare kommet lenger i retning komponentware og distribuerte objekter, men har også valgt en langt klarere bane.

Et vesentlig aspekt ved komponentware er å kunne fastlegge et objekts funksjoner uten forkunnskaper om objektet. COMs innebygde kapasitet for "spørre"-grensesnitt er tiltenkt slike oppgaver og utformet for å fungere effektivt i et distribuert miljø.

Opendoc har podet fram en liknende mekanisme i sine C++-biblioteker: man kaller opp et objekt og spør om det støtter en utvidelse. Hvis svaret er nei, får man beskjed. Hvis svaret er ja, peker objektet på en ny utvidelse som har den anmodede funksjonen. Høres ikke det omtrent ut som "spørre"-grensesnittfunksjonene i COM? Det snodige er at selv om tilhengere av SOM/DSOM rakker ned på denne COM-kapasiteten, er planen å inkludere noe liknende i SOM/DSOM-iterasjonen av Opendoc.

Uheldigvis vil Opendocs "spørre"-grensesnitt-liknende funksjon bli langt mer komplisert, og fordi den ikke er innebygd vil SOM/DSOM kreve en uant mengde ekstra nettverkstrafikk for at den skal få støtte.

Freidig

Enkelte av de "revolusjonære" aspektene ved Opendoc tåler ikke sammenlikning med OLEs tilsvarende tilnærminger.

For det første fremhever Opendoc sin "på vrangen" objektaktivering, som innebærer at alle objekter må aktiveres før brukeren kan se dokumentet. Dette fører til lange oppstartstider. Enkelte brukere setter kanskje pris på at det tar så lang tid å åpne et dokument (de får tid til å hente kaffe), men neppe de fleste. Og dette er når objektene er lokale. Tenk hvor lang tid oppstartingen kan komme til å ta når objektene må hentes fra nettverket.

"På vrangen"-aktivering krever dessuten en del-editor eller fremviser for hver type objekt. Selv om Component Integration Laboratories (Opendoc-koordinatorselskapet) oppmuntrer Opendoc komponentutviklere til å gi bort gratis fremvisere, er ikke det noen garanti. Dersom den lokale editoren/fremviseren ikke er tilgjengelig, sitter brukeren med skjegget i postkassa. Objektet kan ikke vises i det hele tatt, og etterlater et hull i dokumentet.

OLE støtter objektaktivering etter behov (selv alle samtidig, hvis du ønsker det). Den viser et siste bilde av et objekt slik at enhver applikasjon kan vise et fremmed objekt som en synlig, kjent enhet, selv om den ikke kan redigeres lokalt.

OLE ble bygget for å integrere applikasjoner. OLE-kontroller legger opp til utviklingen mot komponentware. Dette fordi en OLE-applikasjon kan kjøres for seg selv eller som en del av en samling komponenter, etter hva som er mest formålstjenlig. Opendoc-deler fungerer utelukkende i Opendoc-miljøet, slik at brukere av dagens applikasjoner ikke kommer noen vei.

Opendoc-tilhengerne har innsett at OLE brukes for sammensatte dokumenter overalt i dag, og det kommer nå løfter om at OLE-støtte skal tilføyes. Dette er meget interessant. Desverre vil tilføying av OLE-støtte kun bety enda et lag med programvare for å oppnå tilgang til OLE/COM-grensesnitt. Og hvem skal betale for det? Sannsynligvis den som investerer i eller kjøper Opendoc.

Glem Opendoc. OLE/COM gir langt bedre kapasitet i dag.

OPENDOC: I Opendoc får du et blankt ark eller en mal med enkelte ferdigimporterte komponenter. Etterhvert som man bruker de nødvendige komponentene, forandrer menyene seg.

KOMPATIBEL: Opendoc vil kunne bruker OLE-komponenter. På samme måte som I OLE-programmer kan du velge hva slags komponent du ønsker.

OLE: De fleste nyere Windows-program er OLE 2.0 kompatible. Du må velge et program som utgangspunkt (her Word) og deretter hente inn OLE-objekter (et Excel-regneark). Dobbelklikker du på Excel-regnearket bytter menyene til Excel, men du er fremdeles i Word-dokumentet.

VELGE: I et OLE 2.0-kompatibelt program kan du plukke fra en liste hva slags OLE-objekter du vil hente inn.

FORSINKET: Opendoc er forsinket -- en samlet lansering for Windows, Mac, OS/2, AIX og Windows NT er utsatt til høsten. Utviklerne får de nødvendige komponentene i løpet av våren.

Artikkel automatisk generert, 24/02-95, kl. 10.34 cw@oslonett.no