NO311387B1 - System for dynamisk kjöretidsfiksering for programvaremoduler i en datamaskinsammenstilling - Google Patents

Description

Oppfinnelsens bakgrunn

En del av beskrivelsen i dette patentdokument inneholder materiale som er opphavsrettbeskyttet. Innehaveren av opp-havsretten har ingen innvendinger mot faksimilereproduksjon av patentdokumentet eller patentbeskrivelsen, som det fore-ligger hos patent- og varemerkemyndighetene, som patent eller registreringer, men reserverer seg ellers alle opphavs-rettigheter overhodet.

Oppfinnelsens område

Oppfinnelsen vedrører modifikasjon av programvare, og særlig utskifting av programvare i et opererende datamaskinsystem hvor det eksisterer både gamle og nye versjoner av modifisert programvare samtidig i datamaskinen og som er samtidig eksekverbare deri.

Beskrivelse av lignende teknikk

Systemet ifølge foreliggende oppfinnelse, en linket prosedyreanropsmekanisme for dynamisk å binde separate og samtidig eksekverbare versjoner av programvare under drift (operasjon) av et datamaskinsystem, for å tillate transparent, bruddfri oppdatering av programvare, kan best forstås ved henvisning til det større problem å inkorporere modifisert programvare i et opererende datamaskinsystem. Et aspekt ved programvare for datamaskiner er at den periodisk må oppda-teres med revisjoner, tillegg og/eller strykninger for å fortsette å gi tilstrekkelig funksjonalitet til brukeren, for å optimisere programvaren og for å rette feil og ulik-heter som oppstår gjennom programvarens livsløp. Ettersom nye ferdigheter adderes til programvare, er det ønskelig å bytte ut den gamle programvaren med den nye versjonen så tidlig og så lettvint som mulig for å forsyne brukeren med ferdighetene til den nye programvaren.

I visse typer datamaskinsystemer, slik som frittstående systemer eller systemer for batch-prosessering, er det få hindringer forbundet med å endre programvare fra en versjon til en annen. Typisk tas datamaskinsystemet bare ned under en periode av dagen hvor det er liten aktivitet og vedlike-holdspersonell er lett tilgjengelig. Den gamle programvare blir da enkelt fjernet og erstattet med den nyere versjon av programvaren. Deretter startes datamaskinsystemet opp igjen og all fremtidig dataprosessering utføres med den nye versjon av programvaren. Denne prosedyre forutsetter selv-følgelig at den nye programvare har blitt tilstrekkelig testet og avluset (debugged) på et frakoblet system slik at programvarepersonellet og de driftsansvarlige stoler på at den adekvat vil utføre de funksjoner den er påtenkt uten utidige brudd som kan kreve stopp av, og så ny start av hele datamaskinsystemet.

I andre typer datamaskinsystemer, slik som moderne lagret programkontroll (SPC, for "stored program control") systemer for telekommunikasjonssentraler (i fagmiljøet vanligvis kalt "svitsjer"), er verken testing av nye versjoner av programvare eller endring av programvare i systemet så enkelt som i frittstående batch-prosesserende systemer. For eksempel kan ikke nye versjoner av programvare effektivt testes uten å settes inn i virkelig drift med å prosessere samtaler. Programvaren må testes i drift for å bestemme om programvaren vil virke adekvat under virkelige driftsfor-hold og om de nye deler vil tilpasses (interface) godt alle de andre programvareblokker som danner en del av et opera-sjonelt SPC-svitsjende system. I tillegg er telekommunika-sjonssvitsjesystemer praktisk talt aldri ute av drift. Ide-elt vil disse systemer gå evig uten avbrekk, på grunn av det kontinuerlige behov for kommunikasjonsservice innen et samfunn. Det vil si at det er en kontinuerlig strøm av te-lekommunikas j onstrafikk som prosesseres gjennom systemet selv ved perioder med lav trafikk på dagen eller natten, og ethvert brudd i driften av svitsjen resulterer i et avbrudd i denne telekommunikasjonstrafikken. Et slikt avbrudd kan være ekstremt ødeleggende for systemets drift og dets ef-fektivitet, så vel som dets aksept blant brukere eller kun-der av systemet.

Disse sanntidskrav på telekommunikasjonssvitsjesentraler setter strenge begrensninger på både testingen av videreut-viklede versjoner av programvaren, eller deler derav, som inneholder ny eller forbedret funksjonalitet, så vel som utbyttingen av programvare som inneholder feilkorreksjoner eller "bug fixes" i en svitsj uten å avbryte eksisterende telekommunikasjonstrafikk som prosesseres av svitsjen. Derfor er det ikke ønskelig å integrere nye versjoner av pro-gramvarekomponenter eller enheter inn i systemet ved bruk av den tradisjonelle fremgangsmåte "edit-compile-link-load-run". Det som foretrekkes er en fremgangsmåte som gir evnen til å modifisere eller utbygge programvaren mens systemet er i drift, uten behov for noe unyttbar tid (downtime) .

Det er gjort forsøk på å løse problemene forbundet med å inkorporere ny programvare i fungerende datamaskinsystemer. For eksempel er det noen avanserte direktekoblede (on-line) , fungerende systemer i bruk i dag som ikke fungerer i frittstående eller batch funksjon, som løser problemet med å bytte ut gammel programvare på en måte som klart er forskjellig fra metoden brukt med frittstående eller batch systemer. Imidlertid bytter slike systemer fremdeles ut programvare manuelt, selv om mer transparent enn i frittstående systemer, ved å kreve at individuelle brukere eller brukergrupper aktivt velger å prosessere ved å benytte den nye eller reviderte versjon av programvaren eller ikke. Dette valg kan utføres av brukere ved å modifisere sammensetningen av programvare som skal benyttes av prosesser som opererer under deres individuelle brukeridenta. Valget forblir tilgjengelig for brukere under en fiksert tidsperiode, vanligvis målt i uker eller måneder, i hvilken tidsperiode programvaren migrerer opp flere nivåer i sammensetnings-strukturen etter vellykket drift på hvert foregående nivå uten motsetninger. Når toppnivået i sammensetningen nås, erklæres programvaren "i drift" og eldre versjoner er ikke lenger tilgjengelige for brukere av systemet. Innsetting av ny programvare i systemet, så vel som dens migrasjon opp de forskjellige nivåer, kontrolleres av en prosess med konfi-gurasjonsstyring - en manuell prosess med rapportering, ak-septering, ettersporing av programvareversjoner på hvert nivå og implementering av aksepterte endringer.

Som med fremgangsmåtene som brukes til å oppgradere programvare på batch- eller frittstående systemer, er det vel-kjente ulemper med å inkorporere ny eller modifisert programvare i et system på denne måte. Det er hovedsakelig et manuelt, arbeidsintensivt system som er komplekst og tid-krevende. Det gir kontrollen over om og i hvilke tilfelle systemet vil operere med visse nye programvarer til brukeren uten noe midler for å utføre gradvis, begrenset, direk-tekoblet bruk slik at feil ikke sprer seg eller umiddelbart påvirker alle pågående operasjoner. Fremgangsmåten for å kontrollere tilgang for ny eller revidert programvare er direkte forbundet og begrenset til den enkelte bruker som eksekverer programmet.

I det typiske kommunikasjonssystem i bruk i dag, er problemet med å bytte programvare eller deler av programvare enda vanskeligere. Selv om slike systemer ikke rett kan kalles

batch- eller frittstående systemer, må driften også stanses når det gjøres en programvareforandring. Den nye programvare blir så lastet opp og dataene, sammen med den gamle programvare, overføres til den nye programvaren. Mens denne

overføring skjer, er systemet fullstendig ute av drift. Denne perioden kan vare så lenge som en time, hvilket gjør det nødvendig å legge programvareendringer til tider med

lav driftstrafikk. Selv da er en time nedtid i et kommuni-kasjonssvitsjesystem en meget lang og kostbar periode fordi ingen samtaler kan prosesseres i denne tiden og ingen behov for nødkommunikasjon i denne perioden kan betjenes.

Problemet med å forandre programvare under eksekvering innen et datamaskinsystem, blir mer komplisert når hele eller en del av programvaren krever linking. Vanligvis må separate deler av programvaren i slike systemer utvikles og re-kompileres separat. Så må alle delene som interopererer re-linkes for eksekvering. Det er også nødvendig å frembringe og opprettholde symboltabeller som tilveiebringer informasjon om alle eksterne symboler brukt av programvaren. Lin-keprosessen frembringer informasjonen for lagring i tabellen og identifiserer uløste henvisninger. Når en del av programvaren av en eller annen årsak modifiseres, må sannsynligvis symbolinformasjonen også endres. Derfor må enhver symbolinformasjon fjernes, eller den vil bringe med seg prosessorfeil forårsaket av ukorrekt symbolhenvisning.

En teknikk, beskrevet i US-patentsøknad nr. 5,410,703 & 5,555,418, innlevert 1. juli 1992 i navnet Nilson et al., med tittel "Changing Software During Computer Operations", og overdratt til Telefonaktiebolaget L M Ericsson, herved tatt inn som referanse, beskriver et system og en fremgangsmåte for å vinne over noen av begrensningene ved å endre programvare "på direkten". Dette system tilveiebringer installasjon av ny programvare i lagrene til telekommu-nikas j onssystemet sammen med, og i tillegg til, den gamle programvare. I dette system blir eksisterende trafikk i datamaskinsystemet til å begynne med prosessert av den gamle programvare, og testtrafikk rutes gjennom svitsjen for prosessering av den nye programvare. Deretter, hvis testtrafikken behandles med hell av den nye programvare, blir en del av den virkelige trafikk selektivt rutet gjennom den nye programvare med resten av den virkelige trafikk fremdeles behandlet av den gamle programvare. Skulle den utvalgte trafikk behandles tilfredsstillende av den nye programvare, blir all trafikk svitsjet over til den nye programvare. Så snart prosesseringen av alle samtaler som behandles av den gamle programvare har blitt fullført, blir den gamle programvare ikke lenger benyttet av systemet og kan fjernes.

Dette beskrevne system sørger for velsmurt verifisering av ny og modifisert programvare. Det tillater data å flyte gjennom den nye programvare på en gradvis og kontrollert måte, likevel som en del av det arbeidende operasjonssys-tem. Systemet gir tidlig deteksjon av feil og uoverensstem-melser med liten eller ingen påvirkning av den virkelige drift av et telekommunikasjonssvitsjesystem, fordi dataene som til å begynne med rutes til den nye programvare bare er testdata generert av systemet. Hvis telekommunikasjonssys-temet, ved prosessering av testdata, detekterer en feil, blir det ikke dirigert ytterligere trafikk til den nye programvare, slik at forstyrrelsene til det samlede systems trafikk blir minimalisert, til og med hvis den nye programvare har prosessert virkelige data.

Dette beskrevne system flytter også over trafikk fra den gamle programvare til den nye programvare på en gradvis måte. Det beskrevne system har evnen til å tillate transaksjoner som begynte prosessering med den gamle programvare å fullføre sin prosessering bare med bruk av den gamle programvare. Bare transaksjoner som tok til etter installasjo-nen av den nye programvare, vil bli prosessert av den nye programvare. Dette aspekt ved det beskrevne system resulterer i bare minimal forstyrrelse for brukere under en over-gangsfase fra en viss gammel programvare til dens utbytting eller utbygging med ny programvare. Ytterligere minimalise-rer dette aspekt mengden av data som krever konvertering for og/eller overføring til et annet sett med programvare enn den som den opprinnelig ble prosessert med.

Andre forsøk på å løse i det minste noen av problemene forbundet med å oppdatere programvare i datamaskinsystemer i drift har fokusert på forskjellige aspekter som bare repre-senterer en del av problemet som hele, særlig emnet linking. For eksempel er det i US-patentsøknad nr. 5,297,285 innlevert 19. juli 1991, med tittel "System for Dynamically Linking Modular Portions of Computer Software" inneholdende en oppfinnelse av Anders Abrahamson og Lars Holmqvist og overdratt Telefonaktiebolaget L M Ericsson, beskrevet et system for dynamisk linking av programvare i kjøretid (run-time). Dette system involverer imidlertid et komplekst system av indirekte adressering som krever bruk av enten et spesialisert eller utvidet operativsystem og/eller en spe-sialkompilator. Dette system har flere andre begrensninger, inkludert behovet for et ikke-standard operativsystem. Videre vil dette system ikke arbeide med standard applika-sj onsprogramvare.

Annen lignende teknikk har blitt diskutert i forskjellige publikasjoner. For eksempel en artikkel med tittel "Future Documents" publisert i BYTE MAGAZINE vedrørende objektlin-king og innbygging (embedding), mens US-patent 4.791.550 til Stevenson et al. vedrører linkpekere og US-patent 4.667.54 6 til Freeman et al. behandler inntrengning i ube-skyttede minneområder. Ingen av disse referanser beskriver løsninger på problemene diskutert over.

Det vil derfor være høyst nyttig for telekommunikasjonsin-dustrien å effektivt kunne utføre dynamisk kjøretidslinking mellom separate opplastede programenheter i et datamaskinsystem. Systemet ifølge foreliggende oppfinnelse tilveiebringer en slik fremgangsmåte.

Oppfinnelsen i sammendrag

Systemet og fremgangsmåten i henhold til den foreliggende oppfinnelse kjennetegnes av de trekk som er nevnt i de ka-rakteriserende deler av de uavhengige krav.

Systemet ifølge foreliggende oppfinnelse omfatter et system for dynamisk å binde programvaremoduler mellom to eller flere separate opplastbare programvareapplikasjoner. Dette aspektet ved systemet ifølge foreliggende oppfinnelse omfatter den oppfinneriske kombinasjon av en linket prosedyrekallmekanisme med evnen til å utføre dynamisk kjøretids-binding mellom separat opplastbare programenheter i et datamaskinsystem.

I et aspekt omfatter systemet ifølge foreliggende oppfinnelse en linket prosedyrekallmekanisme som omfatter en trader innen operativsystemkjernen for å tillate et grensesnitt mellom forskjellige programvareenheter. Denne linkede prosedyrekallmekanisme brukes også til å utføre mellomkob-lingen (inter linking) og bindingen av gamle og nye programvareenheter i kjøretid. Ved benyttelse av denne linkede prosedyrekallmekanisme i systemet ifølge foreliggende oppfinnelse, frembringes den nødvendige grensesnittspesifikasjon ved bruk av et annet aspekt ved systemet ifølge foreliggende oppfinnelse, et spesialisert språk referert til som et objektorientert grensesnittbeskrivelsesspråk (ELIN) som beskrevet i ELIN Reference Manual, opphavsrettslig be-skyttet 6. november 1991 av Ellemtel Utvecklings Aktiebo-lag, og i US-patentsøknad nr. 5,546,584, med tittel "System & Method for Establishing Communications Protocols between Application Programs" innlevert 1. juli 1992 i navnet Lun-din et al. og overdratt til Telefonaktiebolaget L M Ericsson, heri inntatt som referanse. Dette språk inneholder spesielle konstruksjoner spesielt laget for utvikling av grensesnitt for det linkede prosedyrekallaspekt ved systemet ifølge foreliggende oppfinnelse. Fordi disse grense-snittspesif ikasj oner inneholder attributter understøttet av et objektorientert paradigma, kan det lett oppnås polymorfisme og dynamisk binding av objekter med en felles basal grensesnittspesifikasjon.

I et annet aspekt omfatter systemet ifølge foreliggende oppfinnelse en mekanisme ved hvilken programenheter kan konstrueres og senere modifiseres separat i et fungerende (running) system uten å forårsake noen forstyrrelse for de pågående operasjoner i datamaskin- eller telekommunika-sjonssystemet som det opererer i. Ifølge dette aspekt konstrueres og kompileres programenhetene separat ved bruk av en språkuavhengig grensesnittspesifikasjon. Dette aspekt tillater programenheter å modifiseres og endres uavhengig så lenge grensesnittene forblir uforandret. Dette aspekt ved systemet ifølge foreliggende oppfinnelse gir den ytterligere fordel av å eliminere behovet for å lagre symbolinformasjon for bruk ved linking siden bindingen skjer i kjø-retid.

Ved enda et aspekt ved systemet ifølge foreliggende oppfinnelse, blir linkede prosedyrekall (LPC) objekter frembrakt og manipulert på en måte som ligner den for objekter av lokale klasser i en objektorientert paradigma. Dette aspekt ved den linkede prosedyrekallmekanisme er transparent for programmererne i systemet. Transparensen oppnås, i dette aspekt av systemet ifølge foreliggende oppfinnelse, gjennom automatisk generering av kode som utfører kjøretidsbinding-en i samsvar med grensesnittspesifikasjonen. Dette aspekt ved foreliggende oppfinnelse gir den fordel at det kan brukes standard språkkompilatorer, uten å kreve noen utvidel-ser, og uten behov for å modifisere LPC-modellen.

Ifølge enda et aspekt, omfatter systemet ifølge foreliggende oppfinnelse et sett av dirigeringspunkter som brukes til dynamisk å dirigere transaksjoner (også kalt "tråder" eller "hendelsesrekker") innen det opererende system til enten

nye eller gamle versjoner av en modifisert programvareenhet. Systemet gjennomfører den dynamiske dirigeringen ved et antall midler, inkludert analyse av meldinger adressert ved funksjonstittel, hvilket gjør det mulig å dirigere meldinger til enten en prosess som eksekverer en ny versjon av en programvareenhet eller til en prosess som eksekverer en gammel versjon. En annen type dirigeringspunkt er dynamisk kjørebinding (f.eks. linkede prosedyrekall) mellom programvareenheter som gjør det mulig innen en prosess å eksekvere en ny eller en gammel versjon av en programvareenhet.

Slik det lett vil forstås av fagfolk på området, vil prinsippene og aspektene ved den foreliggende oppfinnelse kunne . utnyttes til å forbedre kjøretidskonverteringen av programvare ved et antall datamaskinanvendelser forskjellige fra telekommunikasj onssvitsj esysterner.

Kort beskrivelse av tegningene

For forståelse av foreliggende oppfinnelse og ytterligere trekk og fordeler derved, kan det nå vises til den følgende beskrivelse, satt i sammenheng med de medfølgende tegninger hvor: Fig. IA - IB er skjematiske illustrasjoner av et tidligere kjent system for å kontrollere introduksjonen av ny eller modifisert programvare i et programvaresystem i drift, Fig. 2 er en skjematisk representasjon av måten programvareblokker dynamisk kan linkes ifølge oppfinnelsen i en pa-tentsøknad nevnt ovenfor som er under behandling, Fig. 3 er et flytskjema som illustrerer prosessen med å endre programvare i kjøretid i samsvar med oppfinnelsen i den ovenfor nevnte patentsøknad under behandling, med tit-telen "Changing Software During Computer Operations", Fig. 4 er et blokkdiagram som illustrerer den måte objekt-operasjoner adresseres på i programvaren til systemet iføl-ge foreliggende oppfinnelse, Fig. 5 er et blokkdiagram som illustrerer på hvilken måte programvaren adresseres i systemet ifølge foreliggende oppfinnelse, Fig. 6 er et blokkdiagram som illustrerer den måten programvaren kan adresseres på ved hjelp av traderen i systemet ifølge foreliggende oppfinnelse, Fig. 7 er et illustrativt diagram av den måten et objektorientert grensesnittbeskrivningsspråk brukes til å implementere systemet ifølge foreliggende oppfinnelse, og Fig. 8 er et skjema som illustrerer visse aspekter ved systemet ifølge foreliggende oppfinnelse.

Detaljert beskrivelse

Systemet ifølge foreliggende oppfinnelse benytter i noen aspekter prinsipper fra objektorientert programmering. Objektorientert programmering involverer essensielt fire elementer: Klasser, objekter, eksempelvariabler (eller data-elementer som gjennomført i C++) og metoder (eller elementfunksjoner i C++). En klasse er enkelt en sjablon brukt til å definere objekter, som er eksempler på klassen som de er frembrakt fra. Klasser har to typer komponenter: Eksempelvariabler og metoder. Eksempelvariabler tjener som dataele-menter og metoder tjener som funksjoner, dvs. de definerer et objekts oppførsel. Eksempelvariabler og metoder kan kom-bineres i et enkelt felles objekt ved tiden for eksekvering. Det vil si at et objekt innkapsler et eksempel på va-riablene som kan manipuleres ved å bruke de kombinerte metoder. Slik utføres programmering med fokus på objekter, heller enn på funksjonene eller oppgavene som skal utføres.

Visse teknikker ved objektorientert programmering, vel

kjente på området, er innebygget i systemet ifølge foreliggende oppfinnelse i den foretrukne implementering av systemet ifølge foreliggende oppfinnelse i programmeringsspråket C++. Slike teknikker omfatter arv, polymorfisme og innkapsling. Arv tillater en ny klasse å utvikles fra en eksisterende klasse slik at kode lett kan brukes på nytt, slik at data og kode kan adderes til en klasse eller at oppførselen til en klasse kan forandres, uten å måtte forandre den eksisterende klasse. Polymorfisme er den egenskap som tilveiebringer evnen til å bruke forskjellige typer objekter på samme måte fordi de forskjellige objekttyper deler et felles grensesnitt. Arv av grensesnitt er en egenskap som gjør det mulig å utvikle andre objekttyper fra en felles-nevner. Til slutt, innkapsling er en teknikk for å kombinere dataene og operasjonene som trengs for å prosessere dataene under et "tak". Videre tillater det evnen til å be-skytte dataene fra overhåndtagende eller unødvendig tilgang (access) og til å skjule detaljene ved dataorganiseringen.

Det vises først til Fig. IA, hvor det er illustrert et pro-gramvarekontrollopplegg benyttet i et tidligere kjent system for å bestyre introduksjonen av ny eller modifisert programvare i et programvaresystem i drift. Fig. IA illustrerer et hierarkisk sett av programvarenivåer, hvor innholdet av hvert nivå kontrolleres av medlemmer av et bedømmel-sesråd. Alle endringer av programvaren må godkjennes av dette råd før slike endringer implementeres i systemet. Ingen programvare vil bli integrert i systemet før bedøm-melsesrådet tar en formell avgjørelse om at programvaren behøves, at den har blitt tilstrekkelig testet og at den sannsynligvis ikke vil forårsake skade eller brudd i systemet .

Hierarkiet av nivåer kan bestå av flere separate hierarkier koblet sammen av en individuell bruker som har tilgang til og behov for disse nivåer eller "biblioteker" av programvare for å utfører sin funksjon. På toppen av hierarki 1 er den sanntids driftsprogramvare som typisk er mest utbredt brukt og strengest kontrollert ("AB.D"). Under dette nivå er et endringsbibliotek 2, betegnet med tilleggsbokstaven C i suffikset ("AB.DC"). Lavere nivåer av driftsprogramvare innen hierarkiet kan tilhøre forskjellige grupper av brukere innen systemet og vil bli kontrollert av bedømmelsesråd ved disse nivåer. Ny eller modifisert sanntids programvare entrer systemet, etter godkjenning, ved det laveste passende endringsnivå, dvs. et nivå som ender med bokstaven C som ved 2 og 3.

Når ny eller modifisert programvare entrer systemet, forblir den på inngangsnivået inntil en spesifisert periode har gått og programvaren ikke har produsert noen merkbare feil. Den vil så migrere til det neste, høyere, nivå. I noen tilfeller vil dette kreve forhåndsgodkjennelse av et spesifikt bedømmelsesråd, mens migrasjonen i andre tilfeller vil skje automatisk, som del av en regulær planlagt systemaktivitet. Migrasjonene er transparente for brukerne og programvaren vil være tilgjengelig øyeblikkelig ved migrasjon eller inngang i hierarkiet for brukere som har strukturert deres programvarelinking til å aksessere programvare i bibliotekene inneholdende den nye eller forand-rede programvare.

Som det også er vist i Fig. IA, kan den samme prosess repeteres og oppstå samtidig for ikke-sanntid konstruksjonstype programvare som ligger i det samme system. Den eneste for-skjell i dette tilfelle er at kontrollprosessen bestyres av et annet sett av folk og prosessen behøver ikke være så streng som for driftsprogramvare brukt generelt gjennom systemet for kritiske prosesser. Integrasjonen av programvaren skjer imidlertid på samme måte for denne konstruk-sjonsprogramvare som for driftsprogramvare. Den nye eller modifiserte programvare entrer hierarkiet ved det laveste passende endringsnivå som betegnet med en C som den siste bokstav i suffikset, som ved 4. Den migrerer så i retning oppover med tiden, med de nødvendige godkjennelser, inntil den når toppen 5 av sin del av hierarkiet. Med enten konst-ruksjons- eller driftsprogramvare, når den har migrert til det neste nivå, ligger den ikke lenger på det lavere nivå.

Avgjørelsen om å bruke den nye eller modifiserte programvare som har entret systemets hierarkistiske biblioteker er gitt til den individuelle bruker eller brukergruppe. Brukeren (e) kan velge hvilke nivåer av bibliotekene systemet skal bruke for å sammenkjede programvare for deres bruk. De kan velge å hoppe over lavere nivåer av programvaren fullstendig eller de kan helt enkelt velge å unngå det laveste endringsnivå som inneholder den nyeste og minst testede programvare. Det høyeste nivå av hver del av hierarkiet inneholder selvfølgelig hoveddelen av driftsprogramvaren i bruk.

Fig. IB illustrerer den menneskelige prosess med konfigura-sjonskontroll som pålegges programvarebibliotekshierarkiet illustrert i Fig. IA for å opprettholde kontroll over både grunnlinjen og den nye eller modifiserte programvare som introduseres i systemet daglig. Som nevnt ovenfor, entrer den nye programvare hierarkiet på det laveste passende endringsnivå etter godkjenning av bedømmelsesrådet. Hvis den nye programvaren resulterer i feil eller uoverensstemmel-ser, fjernes programvaren fra hierarkiet og returneres for ytterligere programvedlikeholdsarbeid som ved 6. Når problemene er blitt rettet opp og programvaren har blitt testet på nytt, kan den igjen, ved rådsgodkjenning, integreres i systemet på det laveste endringsnivå. Hvis ingen problemer merkes innen den tillatte faste periode, vil programvaren automatisk migrere til det neste nivå, med mindre det neste nivå krever en annen rådsgodkjenning som ved 7. Ellers vil den migrere etter en fast timeplan etter å ha blitt skikke-lig godkjent. Denne prosess vil fortsette å repeteres inntil programvaren når det høyeste nivå i denne del av hierarkiet, på hvilket tidspunkt den vil bli erklært fullt operasjonell programvare.

Det vises så til Fig. 2, hvor det er vist en skjematisk representasjon av overføringen av programvaresignalinforma-sjon innen et modulært programvaresystem i samsvar med en tidligere beskrevet oppfinnelse. En blokk av modulær programvare 11, referert til som blokk A, omfatter rekken av seksjoner inkludert programkodelistedel 12, en signalfordelingstabell 13 og en programvaresignalsendingstabell 14. I tillegg omfatter en jobbuffer 15 en rekke registre 16 i hvilke det temporært lagres programvaresignaler som venter på prosessering av den sentrale prosessor, som er nødvendig for å fremme disse signaler til en forespørrende blokk av programvare, for eksempel. En annen programvareblokk, blokk B 17, inkluderer også en programkodelistedel 18 og en signalfordelingstabell 19. Den representerte utførelse av oppfinnelsen inkluderer også en global signalfordelingstabell 20 i hvilken det opprettholdes en listing av alle lokale signalnummer for de bestemte signaler inneholdt i hver blokk av programvare lastet inn i systemet.

Som kort diskutert ovenfor, er den globale signalfordelingstabell 20 et essensielt element for å opprettholde linkingsadressene blant forskjellige moduler av programvare. Den globale signalfordelingstabell 20 opprettholder kryssreferansene mellom de globale signalnummer korresponderende til bestemte signaler som sendes fra en modul eller blokk til en annen, og de lokale signalnummer korresponderende til hvert av disse signaler innen hver individuell blokk i systemet. Når en blokk av programvare lastes inn i systemet, blir den del av den globale signalfordelingstabell 20 som korresponderer til denne blokk skrevet på nytt for å inkludere et lokalt signalnummer for hvert signal som er inkludert i blokken av programvare. Dette gjøres konven-sjonelt ved kombinere det globale signalnummer for dette spesielle signal med blokknummeret til programvareblokken som inneholder dette signal gjennom en eksklusiv-eller-prosess eller en annen teknikk for å kombinere. Når så en programvareblokk fjernes fra systemet, modifiseres eller utvikles på en eller annen måte som resulterer i endringer på de individuelle signaler innen blokken, må denne del av programvaresignalfordelingstabellen skrives på nytt for å reflektere det nye innhold av signaler innen blokken, og en ny beregning av lokale signalnummer for hver av disse signaler innen blokken.

Som videre illustrert i Fig. 2, sendes et programvaresignal Sl fra blokk A 1 til blokk B 17. Blokk B 17 refereres til som den mottagende blokk, mens blokk A 11 vises til som den sendende blokk. Blokknummeret til den mottagende blokk er også vist til som BNR. Systemet skal sende det ønskede signal Sl til den mottagende blokk og først oppnå det globale signalnummer for signal Sl ved å aksessere signalsendings-tabellen 14 av blokk A 11 ved hjelp av dens adresse omfat-tende programstartadressen til blokk A 11 (PSAA) pluss ver-dien til signalsendingspekeren (SSP). Når det globale signalnummer for Sl er funnet, lastes det direkte inn i et re-gister 16 innen jobbuffer 15 og venter på overføring til blokk B i samsvar med prioriteringsprotokollene til den sentrale prosesseringsenhet og prioriteten gitt det bestemte signal som overføres. Under dette tidsrommet ble informasjonen beholdt i form av det globale signalnummer til Sl og blokknummeret til den mottagende blokk. Så snart signal-overføringsoperasjonen har steget til et tilstrekkelig pri-oritetsnivå til at overføringen blir utført, aksesserer systemet den globale signalfordelingstabellen 20 for å hen-te det lokale signalnummer av Sl i blokk B 17. Dette oppnås ved å entre den globale signalfordelingstabell 20 med adressen funnet ved å ta det globale signalnummer og eksklu-siv-eller'ere denne verdi med blokknummeret BNR. I denne tabellen ved denne adresse finnes det lokale signalnummer for Sl i blokk B 17, den mottagende blokk.

Når det lokale signalnummer for Sl i blokk B 17 er funnet, vil så systemet entre blokk B 17 ved å lokalisere instruksjonsadressen, IA 21, i blokk B 17 hvor signalet skal entres. Dette gjøres ved å finne fra signalfordelingstabellen 19 av blokk B 17, ved å ta programstartadressen av blokk B 17, (PSAB) minus det lokale signalnummer i blokk B 17, for å lese instruksjonsadressen 21. Når instruksjonsadressen 21 er funnet, entres signalet Sl inn i blokk B 17 og overfø-ringen er fullført. Deretter begynner instruksjonen lokalisert ved IA 21 å eksekveres.

Et punkt må holdes i mente i forbindelse med bruken av dette beskrevne system. Ved modifisering av kode som påvirker et signalentringspunkt i en blokk, må det holdes i mente at dersom datastrukturene modifiseres, må kall på denne nye eller modifiserte kode nå gamle parameterverdier, f.eks. signaldata medfølgende signalet i jobbufferen som inneholder adresser og/eller data i formatet til datastrukturen som ble benyttet før modifisering. På den annen side, hvis blokken ved tidspunktet for ny opplasting av den nylig modifiserte programvareblokk har returadresser, blir de lokale signalnumre på returadressestakken som har blitt modifisert som mellom den gamle og nye' versjon oppdatert av driftssystemet.

Det vises så til Fig. 3, hvor det er vist et flytskjema som illustrerer den glatte modifiseringsmetode for overføring fra en gammel programvareversjon til en ny programvareversjon. Særlig gjelder det at systemet på forhånd antar at eksisterende programvare aktivt kjører i systemet og begynner ved blokk 30, med innlastingen av en ny versjon av programvaren inn i minnet. Ved 32 kopierer systemet dataene med deres endringer i den nye versjon, og linker dem til den nye programvaren. Ved 34 begynner systemet å kjøre testkall med den nye programvaren, og normal trafikk fortsetter å kjøre i systemet med den gamle programvare og de gamle data. Ved 36 spør systemet "fungerer den nye programvare på testtrafikken?". Hvis ikke, går systemet videre til 38, ved hvilket punkt den nye programvaren og databasen fjernes fra systemet og prosedyren ender ved 40. Hvis den nye programvare fungerer på testtrafikken ved 36, går systemet videre til 42, ved hvilket punkt det kjører prøver på virkelig trafikk med den nye programvare, mens resten av den normale trafikken holdes i gang med den gamle programvare og gamle data. Så, ved 44, spør systemet igjen om den nye programvare fungerer på prøvetrafikken eller ikke. Hvis ikke, går systemet videre til 38 og den nye programvare og database fjernes for å avslutte prosessen. Hvis imidlertid den nye programvaren prosesserer prøvetrafikk vellykket ved 44, går systemet videre til å kjøre alle fremtidige samtaler med den nye programvare og dataene ved 46. Deretter, ved 48, spør systemet igjen om den nye programvaren fungerer eller ikke, og hvis ikke, går det videre til 38 for å fjerne den nye programvare og stopper ved 40. Hvis den nye programvare fungerer ved å kjøre den normale trafikk i systemet ved 48, spør systemet om alle gamle samtaler har blitt fullført eller ikke innen systemet ved 50, og hvis ikke, spør det om tidsbegrensningen for utskiftingen er ut-løpt ved 54, og, hvis ikke, fortsetter å: (1) kjøre alle nye samtaler med den nye programvare og (2) kjøre alle gamle samtaler med den gamle programvare ved 4 6 inntil et ja mottas ved 50 eller tiden har løpt ut ved 54. Hvis tiden har løpt ut ved 54, vil systemet avslutte eller overføre alle gjenværende samtaler til den nye programvare ved 56 og gå videre til 52. Deretter går systemet videre til 52 og den gamle programvare fjernes sammen med de gamle data, og systemet har utført en svitsj under kjøretid fra gammel programvare til ny programvare uten å sette i urimelig fare eller forsinke eksisterende trafikk innen telekommuni-kas j onssvitsj en .

Ved effektueringen av knyttingen av individuelle samtaler til forskjellige blokker av programvare, slik som i eksemplet hvor ny telekommunikasjonsprosesseringsprogramvare, hvis først testet med testsamtaler før normale samtaler re-direktes fra den gamle programvare til den nye, kan systemet ifølge foreliggende oppfinnelse visualiseres som inneholdende en samtaleidentifikasjonskategori (ID for Cali Identification category) og en peker ID kategori. For hver samtaleadresse innen systemet som er en testsamtale, gis det en peker til ny programvare, mens for alle samtale-ID'er inneholdende en normal identifikasjon, gis pekeren til den gamle programvare. Bruken av slike pekere illustrerer metoden ved hvilken systemet ifølge foreliggende oppfinnelse er i stand til korrekt å dirigere både ordinær, virkelig trafikk og testtrafikk til den korrekte versjon av programvaren.

Mens dette er den generelle forenklede fortolkning av hvordan den nye og gamle programvare adresseres innen systemet ifølge foreliggende oppfinnelse, brukes det i virkeligheten detaljerte linkede prosedyrekallmekanismer for å frembringe dynamisk binding under kjøring mellom separat opplastede programenheter. Det vil si at når en programenhet byttes ut i eksemplet diskutert ovenfor, vil gammel og ny versjon av programvaren eksistere sammen i en tid inntil den nye versjon kan verifiseres som korrekt og aktiviteter som eksekveres i den gamle versjon kan avsluttes som beskrevet ovenfor. Systemet ifølge foreliggende oppfinnelse benytter handling (dvs. byttehandel, engelsk trading. OA) som et middel til å aksessere programvaren gjennom et grensesnitt via det linkede prosedyrekall. Ved opplasting offentliggjø-res alle grensesnitt som er tilgjengelige for det linkede prosedyrekall til en traderfunksjon i kjernen. Hvert grensesnitt offentliggjøres med sin identitet og en adresse som refererer til en metode som frembringer et objekt fra grensesnittet. Bindingen mellom programvareversjonene gjøres under kjøring, og hver gang et objekt frembringes for et bestemt grensesnitt, rettes det en anmodning til traderen for adressen til frembringelsesmetoden som så kalles og returnerer en objektpeker til det frembrakte objekt.

Det vises så til Fig. 4 hvori det er vist at hver operasjon på et objekt av klasse X 60 kalles indirekte gjennom objek-tet ved de følgende trinn: (1) objektpekeren 66 adresserer objektets dataområde, (2) på et forhåndsbestemt offset fra begynnelsen av objektområdet, kan adressen til en opera-sjonstabell 68 finnes 62 (denne tabell 68 er felles for alle objekter av én type), og (3) adressen hvor programkoden til operasjonen starter kan finnes i operasjonstabellen 68 på et offset korresponderende til den valgte operasjon. Fordi plasseringen av adressene i operasjonstabellene innen objektdataene og rekkefølgen ved hvilken adressen i operasjonstabellene lagres er fast og kjent, kan operasjoner kalles uten assistanse fra traderen. En slik operasjon på et grensesnitt som kan kalles uten traderen, er en operasjon for å slette et frembrakt objekt.

Bruk av disse operasjonstabeller gir muligheten til å oppnå polymorfisme, et konsept som kan implementeres ved bruk av, for eksempel, programmeringsspråket C++ og dets konstruksjon av virtuelle tabeller. Polymorfisme, som betyr "med mange former", er en teknikk med hvilken oppførselen til en komponent som deles av forskjellige objekter kan endres. Med andre ord, en komponent kan se ut som den samme i alle tilfeller, men kan ha evnen til å opptre på noe forskjellig måte i forbindelse med forskjellige objekter som den er as-sosiert med. Polymorfisme er nyttig ved at det tillater frembringelse av familier av objekter som er beslektet, dvs. de har et felles opphav eller basis, men de kan opptre forskjellig i forskjellige situasjoner. Dette tillater hvert objekt innen en familie å ha metoder eller funksjoner med identiske navn selv om den reelle kode for hvert objekts metoder kan være vidt forskjellig. Systemet ifølge foreliggende oppfinnelse benytter polymorfisme, så vel som andre prinsipper ved objektorientert programmering. Systemet ifølge foreliggende oppfinnelse iverksetter og utvider imidlertid prinsippene på en ny og meget nyttig måte, for å oppnå dynamisk, transparent mellomkobling av forskjellige versjoner av programvare under eksekvering.

Det vises så til Fig. 5, hvori det er illustrert det faktum at den linkede prosedyrekallmekanisme benyttet i foreliggende oppfinnelse uttrykker konseptet av en trader 80 inneholdt innen en kjerne 82 som gir muligheten til et grense-snittforhold mellom et par programvareenheter 84 og 86, som respektivt inneholder en klientklasse 88 og en serverklasse av objekter 90. Fig. 5 illustrerer i detalj de trinn som kreves for å frembringe objekter innen systemet som også vist i Fig. 4 .

Objekter er eksempler i kjøretid på klasser som inneholder definisjoner av både data og funksjoner innen en enkelt pakke eller enhet. Fordi de er i stand til å inneholde både data og kode, kan de fungere som miniatyr, uavhengige programmer. De kan derfor brukes som byggeblokker til å frembringe mer komplekse programmer uten å måtte utvikle på nytt den nødvendige kode for disse funksjoner. Fordi de kan vedlikeholdes og modifiseres uavhengig, blir vedlikehold og revisjon forenklet.

En klasse er en sjablon som brukes til å definere et objekt, og et objekt er et eksempel i en klasse. En klasse inneholder to komponenttyper, eksempelvariabler, dataele-menter og -metoder eller elementfunksjoner. For å under-støtte programmerere som utvikler programmer som spiller klientrollen i datamaskinsystemet, blir en klientklasse au-tornatisk generert gjennom bruk av en grensesnittspesifikasjon. Den genererte klientklasse virker som en type agent for serverklassen. Klienten i systemet kaller operasjoner fra klientklasse objekter for å sikre at kall overføres til programvareimplementeringen som befinner seg i serverklassen. Derfor finnes all kode vedrørende den dynamiske bin-dingsfunksjon i klientklassen.

Klassedeklarasjoner kontrollerer hvordan kompilatoren lag-rer adressene i objektdataene og i hvilken rekkefølge adressene i operasjonstabellene legges frem. Noen klassedek-laras joner genereres automatisk av systemet. Når et objekt skapes innen systemet, kan dets "skapelsesmetode" lokalise-res gjennom en anmodning til traderfunksjonen 8 0 av opera-sjonssystemet lokalisert innen kjernen 82. Traderen 80 inneholder all grensesnittinformasjon for alle klasser innen systemet som er tilgjengelige ved linkede prosedyrekall, dvs. den inneholder informasjon for hvert objekt om hvilke andre objekter det er tilgjengelig for eller til.

Diagrammet i Fig. 6 illustrerer måten en prosess kan linkes under kjøring ved linket prosedyrekall til ved å bruke en

ny eller gammel programvareenhet. Traderen 80 innen kjernen 82 kan rette eksekveringen av programvareenhet 100 mot enten den gamle programvareenhet 102 eller den nye programvareenhet 104. Under utførelsen av utskiftingen, får serverklassene fra både den gamle og den nye versjon hver sitt

grensesnitt offentliggjort i traderen 80. Traderen 80 inneholder to adresseposter for hvert element, en for den gamle programvareenhet 102 og en for den nye programvareenhet 104. Prosesser frembrakt før utskiftingen vil fortsette å bruke den gamle programvareenhet 102 og dens serverklasser, mens prosesser frembrakt under og etter utskiftingen kan dirigeres til å bruke den nye programvareenhet 104 og dens serverklasser.

Etter at utskiftingen er fullført og aktiviteter innen den gamle programvareenhet 102 har opphørt, kan den gamle programvareenhet 102 fjernes fra minnet og grensesnittene offentliggjort av serverklassene i den gamle programvareenhet 102 kan trekkes tilbake. Hvis et forsøk på å trekke tilbake disse serverklasser fra minnet gjøres før alle prosesser innen den gamle programvareenhet er fullført, genererer systemet et unntakskall fra kjernen 82. En unntakshand-lingsprosess i systemet gir så den ikke fullførte prosess anledning til å innrette seg og benytte den nye programvareenhet 104 eller ellers å avslutte.

Oppfinnelsen benytter delt (shared) minne for å lagre den eksekverbare programkode inneholdt i programvareenhetene som gjør det mulig for alle prosesser i prosessorene å eksekvere programkoden i dette delte minne. Dette betyr at aktiviteter innen forskjellige prosesser innen en prosessor ikke må kopiere og relokere programkode når de utfører binding under kjøring. Den dynamiske kjørebinding (eller linket prosedyrekall) er derfor en meget rask og sanntids effektiv mekanisme siden det ikke kreves relokering eller ko-piering i kjøretid.

En av fordelene ved å bruke tradermekanismen for dynamisk binding i kjøretid er at programvaremodulene som inneholder en klientdel av et grensesnitt, ikke må modifiseres når serverdelen inneholdt i en annen programvaremodul blir end-ret. Det vil si at ingen referanser til serverdelen må endres så lenge grensesnittspesifikasjonen er uendret.

Ved definisjon av en unik grensesnittspesifikasjon i gren-sesnittbeskrivelsespråket ELIN, som beskrives nedenfor, blir et unikt nummer generert frakoblet (off-line) det grensesnitt som separerer det fra alle andre grensesnitt. Dette nummeret brukes i sann tid av serverdelen for å of-fentliggjøre et grensesnitt i traderen og av klientdelen ved den dynamiske kjøretidsbinding gjennom tradermekanismen. Bruk av dette nummer istedenfor en streng som inneholder det unike grensesnittnavn gjør algoritmen for å finne serverdelen av et grensesnitt mer effektiv i sann tid. Algoritmen for å finne serverdelen i tradermekanismen kan for eksempel bruke nøkkeltransformering (hash technic) eller oppslagstabell (index table), hvilket gjør den nesten så effektiv som statisk binding av kode, men har den fordel at programvaremoduler kan endres på en enkel måte uten å forstyrre pågående aktiviteter som bruker gammel programvare.

Ved benyttelse av den linkede prosedyrekallmekanisme ifølge foreliggende oppfinnelse, skrives grensesnittspesifikasjonen i et objektorientert grensesnittbeskrivelsesspråk (ELIN). I dette språk er det en spesiell konstruksjon (ADT) som er særlig rettet mot spesifikasjon av linkede prosedyrekallgrensesnitt. En ADT i ELIN-språket er en spesifikasjon av grensesnittet tilveiebrakt av objekter av bestemte typer. Disse objekter er vel egnet til å implementeres som eksempler av en klasse hvis det benyttes et objektorientert programmeringsspråk. Spesifikasjonen av et linket prosedyrekallgrensesnitt i ELIN-språk omfatter den følgende informasjon:

(a) et navn på spesifikasjonen,

(b) andre grensesnitt brukt som basis for dette navn, (c) en eller flere konstruktører (brukt til å skape

dette navn), og

(d) null eller flere metodespesifikasjoner, som hver består av et metodenavn, argumenter, returtype og unntak.

Angitt nedenfor, i kode, er et eksempel på en grensesnitt-spesif ikasj on som kunne brukes som del av denne linkede prosedyrekallmekanisme og som beskriver et grensesnitt til objekter av en type kalt Stack:

ADT Stack IS

BASE

TelecomObj ect;

METHODS

CONSTRUCTOR (IN size Int) ;

push (IN data Int);

pop () RETURNS Int;

END ADT Staes-

te) 1992 Telefonaktiebolaget L M Ericcson

Denne grensesnittspesifikasjon definerer en ADT kalt stack, idet basis-ADT'en kalles "TelecomObject". Objekter av denne ADT kan akseptere prosesser eller meldingskall fra de lis-tede funksjonselementer. Å ha en basis identifisert for denne ADT indikerer at det er en annen spesifikasjon av denne type ADT som kalles TelecomObject. Denne basis-ADT har også visse spesifikke metoder som den aktuelle ADT, som et eksempel på basis-ADT'en, vil arve. Funksjonselementene eller metodene spesifisert i ADT-definisjonen over er i tillegg til de spesifisert i basis-ADT'en. I sum omfatter ovenstående kode en ADT-spesifikasjon som er en type gren-sesnittspesif ikasj on som kan skapes innen systemet.

Et grensesnitt kan utledes fra et annet grensesnitt som da kalles basisgrensesnittet til det utledete grensesnitt. Grensesnitt kan utledes fra mer enn ett annet grensesnitt, hvor det utledede grensesnitt arver fra operasjonene av hvert av dets basisgrensesnitt. Det utledede grensesnitt kan i tillegg deklarere sine egne tilleggsoperasjoner, selv om det ikke kan definere operasjoner som har samme navn som de som er arvet fra basisgrensesnittene. Det understrekes at arv bare påvirker grensesnittnivået, ikke gjennomfø-ringsnivået.

Som vist i Fig. 7 inkluderer systemet ifølge foreliggende oppfinnelse også et stubbkodegenereringsverktøy 112 som benyttes til å sertifisere koordineringen mellom klienten og serveren som er sammenkoblet dynamisk under kjøring gjennom et grensesnitt. Grensesnittet er spesifisert på en språkuavhengig måte, men med bruk av det objektorienterte paradigma. Stubbkodegenereringsprosessen sikrer at det oppnås en kartlegging til et av flere programmeringsspråk og i de følgende seksjoner er det en kort beskrivelse av hvordan en slik kartlegging i C++ kan utføres. Det vises til Fig. 7 hvor det er illustrert en måte som en grensesnittspesifika-sj on 110 benytter stubbgenereringsverktøyet 112 på i sammenheng med et sett av genererte filer 114 i systemet iføl-ge foreliggende oppfinnelse. Fig. 7 illustrerer spesielt den overordnede struktur av C++ kartleggingen som iverksatt i det språket. En grensesnittspesifikasjon, skrevet i språket (ELIN) som benyttes i systemet ifølge foreliggende oppfinnelse, ligner en klassedefinisjon som brukes i programmeringsspråket C++. Likeledes er mekanismen for å aksessere operasjoner gjennom objekter lignende måten som programmeringsspråket C++ behandler virtuelle funksjoner på. Derfor er kartleggingen på C++ illustrert i Fig. 7 instruktiv for operasjonen av dette aspekt av systemet ifølge foreliggende oppfinnelse.

Stubbgeneringsverktøyet 112 genererer to filer for både klientsiden og serversiden, en med suffikset ".h" (header) og en med suffiks ".cc" (code). For klienten inneholder ".h" eller "header"-filen to klassedefinisjoner. Én klasse er en eksakt kopi av den korresponderende klasse i serve-rens ".h"- eller "header"-fil. Dette sikrer kompatibilitet mellom klient og server og gjør det mulig for klienten å kalle objekter frembrakt av serveren. Denne klassekonstruk-tøren er imidlertid privat, så klassen kan ikke brukes til å frembringe automatiske objekter på stakken. Den andre klasse er den som skal brukes ved klienten som fungerer som en agent gjennom hvilken objekter frembrakt av serveren kan aksesseres.

For serversiden blir de korresponderende to ".h" (header) og ".cc" (code) filer generert av stubbgenereringsverktøyet 112. Innholdet av ".h"-filen består av en klassedefinisjon som vil sikre kompatibilitet med klienten. Dette er klassen som brukes for en basis for implementeringen. Implementeringen kan være basert direkte på den genererte klasse, eller den genererte klasse kan brukes som en basis til å utvikle andre klasser fra. ".cc"-filen inneholder et skjelett for "skapelsesmetoden" og en generert tabell med en post for hvert linkede prosedyrekallgrensesnitt hvis skapelses-metodeadresse bør registreres i traderen. Kroppen til skapelsesmetoden er ansvarlig for å skape et objekt som er kompatibelt med den genererte klasse og returnerer en peker til det nylig skapte objekt som også illustrert i Fig. 4.

Det er flere årsaker for å generere forskjellige men kompa-tible klassedefinisjoner for klient- og serversidene heller enn én delt klassedefinisjon. For det første gir det forskjellige nivåer av synliggjøring for elementer i klienten og serveren. For eksempel må en konstruktør være offentlig i serveren, men bør ikke nødvendigvis være offentlig hvis han befinner seg i klienten. For det andre kan klient- og serverprogrammer linkes sammen for testformål uten å møte problemet med navnekollisjoner hvis forskjellige klasser benyttes.

Det vises så til Fig. 8 hvor det er vist et bestemt arrang-ement av skjemaer som illustrerer visse eksemplifiserende kodeblokker og deres forhold til hverandre som benyttet i systemet ifølge foreliggende oppfinnelse. Fig. 8 illustrerer den logiske struktur av visse genererte filer og skrev-ne spesifikasjoner slik de kan implementeres i systemet ifølge foreliggende oppfinnelse. På høyeste nivå definerer felles grensesnitt spesifikasjon 120 (Common Interface Spe-cification) en ADT "X", og metodene eller operasjonene som er mulig å aksessere for objekter av denne ADT. Logisk un-derordnet denne ADT, på neste definisjonsnivå, er en spesifikasjon for en brukerenhet 122 av grensesnittspesifikasjonen 120 og en spesifikasjon for en bidragsenhet 124 av felles grensesnittspesifikasjon 120. Brukerenhetspesifikasjo-

nen 122 definerer en klient av det felles grensesnitt, ADT X. Bidragsenhetsspesifikasjon 126 definerer en server av

ADT X.

På neste logiske nivå under enhetsspesifikasjonene 122 og 124 er de genererte klassedefinisjoner respektivt for brukere og bidragsytere. Den genererte klassedefinisjon for XUser 126 illustrerer visse brukerklasser som er definert for både offentlig og privat bruk. Den genererte klassedefinisjon for XProvider 128 illustrerer visse offentlige og private definisjoner for bidragsyterdata og

-funksj oner.

Som illustrert over, gjør systemet ifølge foreliggende oppfinnelse det mulig med inkludering eller linking under kjø-ring innen en prosess til enten ny programvare eller gammel programvare på en måte som gjør det mulig for programvaren både å testes effektivt i sann tid, så vel som å erstattes glatt og transparent i et telekommunikasjonsnettverk og svitsjesystem uten oppbrudd av telekommunikasjonstrafikken innen nettverket.

Det antas følgelig at driften og konstruksjonen av foreliggende oppfinnelse vil være åpenlys fra den foregående beskrivelse. Mens den viste og beskrevne fremgangsmåte, appa-rat og system har blitt karakterisert som foretrukket, vil det fremgå klart at forskjellige endringer og modifikasjo-ner kan gjøres derpå uten å fravike ånden og hensikten med oppfinnelsen som definert i de følgende krav.

Claims (32)

1. Fremgangsmåte for dynamisk å binde en første programvaremodul (84) til en andre programvaremodul (86) i et datamaskinsystem som har et felles dataminne, en kjerne (82), den første programvaremodul og den andre programvaremodul er inkludert i henholdsvis et første programvareapplikasjonsprogram og et andre programvareapplikasjonsprogram, karakterisert ved følgende trinn: - å implementere en linket prosedyreanropsmekanisme for å rute signaler eller meldinger mellom nevnte første og andre programvaremodul, nevnte linkede prosedyreanropsmekanisme er knyttet til en traderfunksjon (80) som inkluderer en informasjonsdatabase vedrørende alle grensesnitt som er tilgjengelig for nevnte linkede prosedyreanropsmekanisme ved lasttid (loadtime), nevnte traderfunksjon er videre en del av datamaskinsystemets kjerne, - å tilveiebringe et klientgrensesnitt, nevnte klientgrensesnitt er i stand til å aksessere nevnte traderfunksjon for å skaffe til veie bindingsinformasjonen som er nødven-dig for operativ kommunikasjon med andre moduler, - å tilveiebringe et servergrensesnitt, nevnte servergrensesnitt er i stand til å aksessere nevnte traderfunksjon for å skaffe til veie bindingsinformasjon som er nødvendig for operativ kommunikasjon med andre moduler, - å sette nevnte klientgrensesnitt inn i nevnte første programvaremodul , - å sette nevnte servergrensesnitt inn i nevnte andre programvaremodul , - å laste nevnte første programvaremodul inn i nevnte felles dataminne til nevnte datamaskinsystem, nevnte første programvaremodul inneholder nevnte klientgrensesnitt, - å laste nevnte andre programvaremodul inn i nevnte felles dataminne til nevnte datamaskinsystem, nevnte andre programvaremodul inneholder nevnte servergrensesnitt, og nevnte andre programvaremodul blir lastet asynkront og uavhengig av nevnte første programvaremodul, - å sette minneadressen til nevnte servergrensesnitt inn i nevnte traderfunksjon, - å aktivere nevnte klientgrensesnitt ved å eksekvere nevnte første programvaremodul, - å aktivere nevnte servergrensesnitt ved å skaffe til veie en bestemt implementering av en signalprotokoll fra nevnte traderfunksjon ved å bruke nevnte isolerte grensesnitt, og - å substituere nevnte servergrensesnitt i nevnte første programvaremodul som erstatning for nevnte aktiverte klientgrensesnitt i løpet av eksekveringen av nevnte første programvarevaremodul, for derved dynamisk å binde sammen nevnte første og andre programvaremoduler.

2. Fremgangsmåte ifølge krav 1, karakterisert ved at den videre omfatter-følgende trinn: - å generere nevnte klientgrensesnitt og nevnte servergrensesnitt fra en felles grensesnittspesifikasjon som kommuniseres til nevnte traderfunksjon ved eller i forkant av lasttiden.

3. Fremgangsmåte ifølge krav 2, karakterisert ved at den videre omfatter følgende trinn: - å opprette nevnte felles grensesnittspesifikasjon som kommuniseres til nevnte traderfunksjon ved eller i forkant av lasttiden ved å bruke et objektorientert grensesnittbeskrivelsesspråk.

4. Fremgangsmåte ifølge krav 3, karakterisert ved at nevnte trinn med å generere nevnte klientgrensesnitt og nevnte servergrensesnitt fra en felles grensesnittspesifikasjon som kommuniseres til nevnte traderfunksjon ved eller i forkant av lasttiden videre omfatter følgende trinn: - å generere med et frakoblet stubbgenereringsverktøy, en eller flere klientobjekter og en eller flere serverobjekter fra nevnte felles grensesnittspesifikasjon, nevnte frakoblede stubbgenereringsverktøy er i stand til å bruke nevnte felles grensesnittspesifikasjon for automatisk å generere en kode for å tilveiebringe koordinasjon mellom nevnte en eller flere klientobjekter og nevnte en eller flere serverobjekter.

5. Fremgangsmåte ifølge krav 4, karakterisert ved at nevnte trinn med å generere, med et frakoblet stubbgenereringsverktøy, et eller flere klientobjekter og et eller flere serverobjekter fra nevnte felles grensesnittspesifikasjon som kommuniseres til nevnte traderfunksjon ved eller i forkant av lasttiden videre omfatter følgende trinn: - å generere en klientfil som inneholder i det minste et klientobjekt, og - å generere en serverfil som inneholder i det minste et serverobj ekt.

6. Fremgangsmåte ifølge krav 5, karakterisert ved at nevnte trinn for å generere en klientfil som inneholder i det minste et klientobjekt videre omfatter følgende trinn: - å generere en klientfil som inneholder et klientobjekt som kan kommunisere i overensstemmelse med nevnte felles grensesnittspesifikasjon med et tilknyttet serverobjekt i nevnte genererte serverfil som inneholder i det minste et serverobj ekt.

7. Fremgangsmåte ifølge krav 3, karakterisert ved at nevnte trinn med å opprette en felles grensesnittspesifikasjon som kommuniseres til nevnte traderfunksjon ved eller i forkant av lasttiden ved å bruke et objektorientert grensesnittbeskrivelsesspråk videre omfatter følgende trinn: - å opprette nevnte felles grensesnittspesifikasjon som kommuniseres til nevnte traderfunksjon ved eller i forkant av lasttiden fra nevnte basisgrensesnitt, nevnte felles grensesnittspesifikasjon overtar en eller flere bestemte fremgangsmåter for nevnte basisgrensesnitt.

8. Fremgangsmåte ifølge krav 3, karakterisert ved at trinnet med å opprette nevnte felles grensesnittspesifikasjon som kommuniseres til nevnte traderfunksjon ved eller i forkant av lasttiden ved å benytte et objektorientert grensesnittbeskrivelsesspråk videre omfatter følgende trinn: - å navngi nevnte felles grensesnittspesifikasjon, - å identifisere et eller flere grensesnitt som benyttes som baser for nevnte navngitte felles grensesnittspesifika-sj on, - å opprette i det minste en konstruktør, nevnte konstruk-tør spesifiserer den foretrukne teknikk for å opprette eksempler på objekter som forespør andre objekter ved å bruke nevnte navngitte felles grensesnittspesifikasjon, og - å opprette i det minste en fremgangsmåtespesifikasjon for å utføre funksjoner i nevnte navngitte felles grensesnitt-spesif ikas j on, nevnte fremgangsmåtespesifikasjon inneholder et fremgangsmåtenavn, argumenter, returtype og unntagelser.

9. Fremgangsmåte ifølge krav 3, karakterisert ved at trinnet med å tilveiebringe et klientgrensesnitt videre omfatter følgende trinn: - å tilveiebringe et klientobjekt, nevnte klientobjekt er i stand til å aksessere nevnte traderfunksjon.

10. Fremgangsmåte ifølge krav 3, karakterisert ved at nevnte trinn med å tilveiebringe et servergrensesnitt videre omfatter følgende trinn: - å tilveiebringe et serverobjekt, nevnte serverobjekt er i stand til å aksessere nevnte traderfunksjon.

11. Fremgangsmåte ifølge krav 10, karakterisert ved at det videre omfatter følgende trinn: - å laste, inn i nevnte datamaskinsystem, en tredje programvareapplikasjon som inneholder en tredje programvaremodul, nevnte tredje programvaremodul inneholder serverobjekter som alternerende kan kommunisere med nevnte serverobjekter satt inn i nevnte andre programvaremodul, og - å sette lokasjonen til nevnte serverobjekter som er med i nevnte tredje programvaremodul inn i nevnte traderfunksjon.

12. Fremgangsmåte ifølge krav 11, karakterisert ved at den videre omfatter følgende trinn: - å rute signaler eller meldinger originert fra en prosess som ble opprettet før lasting av nevnte tredje programvaremodul, til nevnte andre programvaremodul ved å skaffe til veie en bestemt implementering av en signaleringsprotokoll basert på nevnte felles grensesnittspesifikasjon fra nevnte traderfunksjon i nevnte kjerne.

13. Fremgangsmåte ifølge krav 11, karakterisert ved at den videre omfatter følgende trinn: - å rute signaler eller meldinger originert fra en prosess som ble opprettet i etterkant av lasting av nevnte tredje programvaremodul, til nevnte tredje programvaremodul ved å skaffe til veie en bestemt implementering av en signaleringsprotokoll basert på nevnte felles grensesnittspesifikasjon av nevnte traderfunksjon i nevnte kjerne.

14. Fremgangsmåte ifølge krav 1, karakterisert ved at nevnte informasjonsdatabase vedrørende alle grensesnitt tilgjengelig for nevnte linkede prosedyreanropsmekanisme som er inkludert i nevnte traderfunksjon videre inkluderer lastadressene til hver av nevnte grensesnitt.

15. Fremgangsmåte ifølge krav 14, karakterisert ved at den videre omfatter følgende trinn: - å generere et unikt tall som identifiserer både nevnte klientgrensesnitt og nevnte servergrensesnitt.

16. Fremgangsmåte ifølge krav 15, karakterisert ved at den videre omfatter følgende trinn: - å sette nevnte genererte unike tall i nevnte traderfunksjon, og - å sette minneadressen til nevnte servergrensesnitt inn i nevnte traderfunksjon.

17 . System for dynamisk å binde en første programvaremodul (84) med en andre programvaremodul (86) i et datamaskinsystem som har et felles dataminne, en kjerne (82), den første programvaremodulen og den andre programvaremodulen befinner seg henholdsvis i et første programvareapplikasjonsprogram og et andre programvareapplikasjonsprogram, karakterisert ved: - middel for å implementere en linket prosedyreanropsmekanisme for å rute signaler eller meldinger mellom nevnte første og andre programvaremoduler, nevnte linkede prosedyreanropsmekanisme er knyttet til en traderfunksjon (80) som inkluderer en informasjonsdatabase vedrørende alle grensesnitt som er tilgjengelig for nevnte linkede prosedyreanropsmekanisme ved lasttid, nevnte traderfunksjon er videre en del av datamaskinsystemets kjerne, - middel for å tilveiebringe et klientgrensesnitt, nevnte klientgrensesnitt er i stand til å aksessere nevnte traderfunksjon for å skaffe til veie bindingsinformasjon som er nødvendig for operativ kommunikasjon med andre moduler, - middel for å tilveiebringe et servergrensesnitt, nevnte servergrensesnitt er i stand til å aksessere nevnte traderfunksjon for å skaffe til veie bindingsinformasjon som er nødvendig for operativ kommunikasjon med andre moduler, - middel for å sette nevnte klientgrensesnitt inn i nevnte første programvaremodul, - middel for å sette nevnte servergrensesnitt inn i nevnte andre programvaremodul, - middel for å laste nevnte første programvaremodul inn i nevnte felles dataminne til nevnte datamaskinsystem, nevnte første programvaremodul inkluderer nevnte klientgrensesnitt, - middel for å laste nevnte andre programvaremodul inn i nevnte felles dataminne til nevnte datamaskinsystem, nevnte andre programvaremodul inkluderer nevnte servergrensesnitt, og nevnte andre programvaremodul blir lastet asynkront og uavhengig av nevnte første programvaremodul, - middel for å sette minneadressen til nevnte servergrensesnitt inn i nevnte traderfunksjon, - middel for å aktivere nevnte klientgrensesnitt ved å eksekvere nevnte første programvaremodul, - middel for å aktivere nevnte servergrensesnitt ved å skaffe til veie en bestemt implementering av en signalprotokoll fra nevnte traderfunksjon ved å bruke nevnte isolerte klientgrensesnitt, og - middel for å substituere nevnte servergrensesnitt i nevnte første programvaremodul som erstatning for nevnte aktiverte klientgrensesnitt, i løpet av eksekveringen av nevnte første programvaremodul, for dermed dynamisk å binde nevnte første og andre programvaremoduler.

18. System ifølge krav 17, karakterisert ved at det videre omfatter: - middel for å generere nevnte klientgrensesnitt og nevnte servergrensesnitt fra en felles grensesnittspesifikasjon som kommuniseres til nevnte traderfunksjon ved eller i forkant av lasttiden.

19. System ifølge krav 18, karakterisert ved at den videre omfatter: - middel for å opprette nevnte felles grensesnittspesifika-sj on som kommuniseres til nevnte traderfunksjon ved eller i forkant av lasttiden ved å bruke et objektorientert grensesnittbeskrivelsesspråk.

20. System ifølge krav 19, karakterisert ved at nevnte middel for å generere nevnte klientgrensesnitt og nevnte servergrensesnitt fra en felles grensesnittspesifikasjon som kommuniseres til nevnte traderfunksjon ved eller i forkant av lasttiden videre omfatter: - middel for å generere, med et frakoblet stubbgenererings-verktøy, et eller flere klientobjekter og et eller flere serverobjekter fra nevnte felles grensesnittspesifikasjon, nevnte frakoblede stubbgenereringsverktøy er i stand til å bruke nevnte felles grensesnittspesifikasjon til automatisk å generere en kode for å tilveiebringe koordinering mellom nevnte et eller flere klientobjekter og nevnte et eller flere serverobjekter.

21. System ifølge krav 20, karakterisert ved at nevnte middel for å generere, med et frakoblet stubbgenereringsverktøy, et eller flere klientobjekter og et eller flere serverobjekter fra nevnte felles grensesnittspesifikasjon som kommuniseres til nevnte traderfunksjon ved eller i forkant av lasttiden videre omfatter: - middel for å generere en klientfil som inneholder i det minste et klientobjekt, og - middel for å generere en serverfil som inneholder i det minste et serverobjekt.

22. System ifølge krav 21, karakterisert ved at nevnte middel for å generere en klientfil som inneholder i det minste et klientobjekt videre omfatter: - middel for å generere en klientfil som inneholder et klientobjekt som kan kommunisere i overensstemmelse med nevnte felles grensesnittspesifikasjon med et tilknyttet serverobjekt i nevnte genererte serverfil som inneholder i det minste et serverobjekt.

23. System ifølge krav 19, karakterisert ved at nevnte middel for å opprette en felles grensesnittspesifikasjon som kommuniseres til nevnte traderfunksjon ved eller i forkant av lasttiden ved å bruke et objektorientert grensesnittbeskrivelsesspråk videre omfatter: - middel for å opprette nevnte felles grensesnittspesifikasjon som kommuniseres til nevnte traderfunksjon ved eller i forkant av lasttid fra nevnte basisgrensesnitt, nevnte felles grensesnittspesifikasjon tar over en eller flere bestemte fremgangsmåter i nevnte basisgrensesnitt.

24. System ifølge krav 19, karakterisert ved at nevnte middel for å opprette nevnte felles grensesnittspesifikasjon som kommuniseres til nevnte traderfunksjon ved eller i forkant av lasttid ved å bruke et objektorientert grensesnittbeskrivelsesspråk videre omfatter: - et navn for nevnte felles grensesnittspesifikasjon, - middel for å identifisere et eller flere grensesnitt som brukes som baser for nevnte navngitte felles grensesnitt-spesif ikas j on, - middel for å opprette i det minste en konstruktør, nevnte konstruktør spesifiserer den foretrukne teknikk for å opprette eksempler på objekter som forespør andre objekter ved å bruke nevnte navngitte felles grensesnittspesifikasjon, og - middel for å opprette i det minste en fremgangsmåtespesifikasjon for å gjennomføre funksjoner i nevnte navngitte felles grensesnittspesifikasjon, nevnte fremgangsmåtespesifikasjon inkluderer et fremgangsmåtenavn, argumenter, returtype og unntagelser.

25. System ifølge krav 19, karakterisert ved at nevnte middel for å tilveiebringe et klientgrensesnitt videre omfatter: - middel for å tilveiebringe et klientobjekt, nevnte klientobjekt er i stand til å aksessere nevnte traderfunksjon.

26. System ifølge krav 19, karakterisert ved at nevnte middel for å tilveiebringe et servergrensesnitt videre omfatter: - middel for å tilveiebringe et serverobjekt, nevnte serverobjekt er i stand til å aksessere nevnte traderfunksjon.

27. System ifølge krav 26, karakterisert ved at det videre omfatter: - middel for å laste, inn i nevnte datamaskinsystem, en tredje programvareapplikasjon inneholdende en tredje programvaremodul, nevnte tredje programvaremodul inneholder serverobjekter satt inn i nevnte andre programvaremodul, og - middel for å sette lokasjonen til nevnte serverobjekter som er med i nevnte tredje programvaremodul i nevnte traderfunksjon.

28. System ifølge krav 27, karakterisert ved at det videre omfatter: - middel for å rute signaler eller meldinger som er originert fra en prosess som ble opprettet i forkant av lasting av nevnte tredje programvaremodul, til nevnte andre programvaremodul ved å skaffe til veie en bestemt implementering av en signaleringsprotokoll basert på nevnte felles grensesnittspesifikasjon fra nevnte traderfunksjon i nevnte kj erne.

29. System ifølge krav 27, karakterisert ved at det videre omfatter: - middel for å rute signaler eller meldinger som er originert fra en prosess som ble opprettet i etterkant av lasting av nevnte tredje programvaremodul, i nevnte andre programvaremodul ved å skaffe til veie en bestemt implementering av en signaleringsprotokoll basert på nevnte felles grensesnittspesifikasjon fra nevnte traderfunksjon i nevnte, kj erne.

30. System ifølge krav 17, karakterisert ved at nevnte informasjonsdatabase vedrørende alle grensesnitt tilgjengelig for nevnte linkede prosedyreanropsmekanisme som er inkludert i nevnte traderfunksjon videre inkluderer lastadressene til hver av nevnte grensesnitt.

31. System ifølge krav 30, karakterisert ved at det videre omfatter: - å generere et unikt tall som identifiserer både nevnte klientgrensesnitt og nevnte servergrensesnitt.

32. System ifølge krav 31, karakterisert ved at det videre omfatter: - å sette nevnte genererte unike tall inn i nevnte traderfunksjon, og - å sette minneadressen til nevnte servergrensesnitt inn i nevnte traderfunksjon.