NO311388B1 - System for implementeringsuavhengig grensesnittspesifikasjon - Google Patents

Description

Oppfinnelsens bakgrunn

En del av fremstillingen av dette patentdokument inneholder materiale som er underlagt "copyright" beskyttelse. Inneha-veren av "copyright"-beskyttelsen har ingen innvendinger mot faksimilereproduksjon av patentdokumentet eller den foreliggende patentfremstilling, slik denne fremkommer hos patentmyndigheter, i patentsaksdokumenter eller journaler, men reserverer seg forøvrig all "copyright"-beskyttelse.

Oppfinnelsens område

Den foreliggende oppfinnelse vedrører spesifikasjon av protokoller og grensesnitt i distribuerte og modulære databe-handlings- eller dataprosesseringssystemer, f.eks. telekom-munikasjonssentraler, og mer spesielt vedrørende spesifikasjonen av applikasjonsnivåprotokoller, dvs. nivå nummer 7 i det protokollstakklager som er betegnet "Open Systems Interconnection" (OSI).

Beskrivelse av relatert teknikk

Et aspekt ved datamaskinsystemer, spesielt nettverksrela-terte eller distribuerte systemer, går ut på at mange kommunikasjonsprotokoller må benyttes for å effektuere kommunikasjon mellom og blant de forskjellige komponenter som systemet er omfattet av. Overvåkning av kommunikasjonen mellom komponenter i et datamaskinstyrt system nødven-diggjør fremskaffelsen av veldefinerte kommunikasjonsprotokoller. Interprosess-kommunikasjon i et datamaskinsystem kommuniserer typisk i termer betegnet forespørsler og svar. Slike systemer har begrensede kommunikasjonsfasiliteter og er bare i stand til å behandle alle forespørsler i den orden som de blir mottatt. De typiske prosess-til-prosessprotokoller tilveiebringer bare denne forholdsvis enkle datatransmisjonsmulighet.

Protokoller blir innlemmet i datamaskinsystemer for å kunne effektuere den ordensrelaterte utveksling av informasjon mellom datamaskinkomponenter. For at datamaskinkomponenter skal kunne kommunisere er det nødvendig med konvensjoner. Det kan benyttes protokoller for å bygge opp en standard kommunikasjonsbane mellom to datamaskininnretninger . Proto-kollkonvensjoner som man er blitt enige om ("agreed-upon protocol conventions") bestemmer typisk egenskapen hos da-tarepresentasjonen, formatet og hastigheten ved denne data-representasjon via en kommunikasjonsbane, samt sekvensen for hvilke som helst styremeldinger som skal sendes. Mens en protokoll utgjør det logiske og konseptuelle sett av regler for kommunikasjoner mellom lignende prosesser, omfatter grensesnitt de sett av regler som eksisterer mellom prosesser av ulike slag, og utgjør ofte heller fysiske enn logiske forbindelser. Protokollprosedyren innebærer en for-håndsbestemt dialog som uten avvik må bibeholdes ved begge ender av en kommunikasjonslink. Ved linknivået vil en protokoll bestå av en mellomkobling av oktetter eller oktett-sekvenser som garanterer styringen og integriteten av en meldingsoverføring.

I tilfelle av prosess-til-prosesskommunikasjon i et dataprosesseringssystem, vil protokoller typisk fremskaffe bare en meget forenklet dataoverføringsmulighet. Data blir mottatt kun i den orden eller rekkefølge som den blir sendt, og den informasjon som passerer mellom prosesser består bare av forespørselen, svaret og eventuelt noe data. Alle data eller forespørsler må bli behandlet av den motagende prosess i serie, idet multiple transmisjoner ikke kan hånd-teres samtidig. Denne type kommunikasjonssystem vanske-liggjør den oppgave å fremskaffe en server eller en annen innretning som skal tillate samtidig håndtering av multiple forespørsler. Et eksempel på denne type system er omtalt i US patentpublikasjon 4.396.983 (Segarra et al.) som omhandler et system for inter-prosess kommunikasjon i et distribuert prosessorsystem.

Man har utviklet noen servere som er i stand til å håndtere multiple forespørsler, men disse er typisk utviklet idet det benyttes en løsningsmåte som begrenser nytten av en

meldingsbasert protokoll. Slike servere fungerer ved å sende bare dataadresser mellom prosessene og ikke selve dataene. IBM Technical Disclosure Bulletin Vol. 23, nr. 5, okto-ber 1980, "Distributed Data Processing System," omhandler

en modifisert versjon av et slikt system. På lignende måte omhandler IBM Technical Disclosure Bulletin vol. 22 nr. 7, desember 1979, "Message-Based Protocol for Interprocessor Communication," en meldingsbasert protokoll for kommunikasjon mellom prosesser som utføres på forskjellige prosessorer som er løst koblet via en felles buss.

US patentpublikasjon 4,649,473 (Hammer et al.) omhandler et system som bruker en inter-prosess informasjonsoverførings-fasilitet for å fremskaffe overføringen av informasjon mellom prosesser som ikke kan dele et felles lager, og som kan være plassert i mer enn én prosessor. I dette system benyttes "noter", som utgjør pakker av informasjon. Hver pakke omfatter en arbeidsforespørsel, slik at serverprosessen kan styre mottagning og behandling av forespørslene og deres tilhørende data etter sitt eget for godt befinnende.

Ankomsten av lavkostnads databehandlingsinnretninger har ført til utviklingen av lokalområdekommunikasjonsnett som kan håndtere et stort antall innretninger som brukes i et enkeltstående forretningsområde. Kapasiteten hos tidligere systemer var begrenset til bruken av en enkeltstående kommunikasjonsprotokoll for forskjellig behandlingssystem. Dette innebar at tillegget av nye innretninger når systemet først var kommet i drift, var vanskelig, om enn umulig, fordi den nye innretning ville bli pålagt å operere med en kommunikasjonsprotokoll som var lik den for de andre innretninger som allerede befant seg i systemet.

Det er nå utviklet mer avanserte lokalområdenettverkssyste-mer som tillater et antall fjernbehandlingsinnretninger som kan tilkobles en vertsprosessor via en kommunikasjonskanal. Tilknyttet hver dataterminalinnretning vil typisk være en kommunikasjonsstyrer med en dreiesvitsj ("rotary switch") som selektivt kan innstilles til å sende ut adressen for styreren. Hver kontroller sender deretter sin adresse til verten. Vertsprosessoren vil ta ut, fra en oppslagstabell som er lagret i prosessoren, de programinstruksjoner som omfatter den kommunikasjonsprotokoll som skal benyttes av styreren for styring av dataoverføringen mellom verten og de spesifiserte fjerninnretninger. Et slikt system er omtalt i US patentskrift 4.787.028 (Finfrock et al.).

En annen ulempe de for tiden tilgjengelige systemer er be-heftet med, beror på det forhold at teknologiske fremskritt har fremskaffet et antall datamaskiner og databehandlingssystemer som fungerer ved forskjellige datahastigheter og med varierende formater. Datamaskinindustrien har ikke utviklet eller fulgt et sett av standardiserte protokoller. Det er derfor ofte umulig for forskjellige datamaskinsystemer å kommunisere og utveksle informasjon med hverandre. Dersom individer som bruker diverse maskinvare i dag ønsker å kommunisere med en sentral datamaskin eller med andre at-skilte datamaskiner, og data blir overført med en hastighet og et format som er forskjellig fra det motagende system, vil dette være uforståelig for den andre eller motagende datamaskin. I de fleste tilfeller vil den andre datamaskin ikke benytte både samme hastighet og samme format som det første eller sendende system.

Det har blitt utviklet systemer for å løse dette problemet, i det minste delvis. F.eks. er det utviklet innretninger der enten et datamaskinprogram eller datamaskinens maskinvare blir benyttet for å analysere innkommende data for å

bestemme den nøyaktige datahastighet og det nøyaktige data-format som blir overført. Slike systemer er imidlertid typisk meget kostbare og komplekse fordi de krever at det utvikles en algoritme hvori et antall datahastigheter og formater er spesifisert. Algoritmen må etter å ha bestemt hastighet og format for de overførte data, utføre de nødvendi-

ge endringer i den motagende datamaskin for å tillate at denne på en enkel måte fortolker de data som den mottar.

En patentfremstilling med tittel "Communication Network for Communicating with Computers Provided with Disparate Protocols", slik det fremgår av US patentskrift 4.688.170, gir anvisning på hvordan noen av de mangler som er omtalt tidligere, kan overvinnes. Patentskriftet omtaler et globalt kommunikasjonsnett mellom forskjellige størrelser og typer av datamaskiner som benytter forskjellige datahastigheter og forskjellige dataformater. Det omtalte system oppnår dette ved at man plasserer et program som inneholder en liste over de datahastigheter og formater som benyttes i alle datamaskinene i det globale nett med hvilket en hvilken som helst av datamaskinene i nettverket kan kommunisere med, i lageret hos en av datamaskinene i nettet. Systemet blir initiert av den individuelle bruker som må selektere et spesifikt kanalnummer som har tilknytning til den datamaskin med hvilken brukeren ønsker å kommunisere. Brukerens datamaskin vil deretter logge inn på destinasjonsdatamaski-nen og bli klar over destinasjonsdatamaskinens datahastighet og format. Imidlertid, dersom sendedatamaskinen er den som inneholder programlisten, så vil den sendende datamaskin, etter å ha konsultert listen, overføre informasjon ved den hastighet og det format som er anvendelig for den motagende datamaskin.

Andre løsninger på kommunikasjonsproblemer har benyttet et annet aspekt ved utviklingen i datamaskinarkitektur rettet på fordelte systemer, dvs. den tendens som går mot bruken av separate undersystemer som brukere, ressursdirigering og kommunikasjonsdirigering innenfor et generelt kommunika-sjonsnettverk. Det system som er omtalt i US patentskrift 4.396.983 (Segarra et al.) gjør det mulig for et hvilket som helst slikt lokalsystem å kommunisere med et hvilket som helst annet lokalsystem i nettet uten bruk av et pri-mært eller sentralt system. Det omtalte oppnår dette gjennom en variasjon av kommunikasjonsbegrensninger, samt ved dirigering av kommunikasjonsprotokoller ved bruken av spesialiserte kommunikasjonsmoduler som er plassert i det funksjonelle kommunikasjonslag av det distribuerte system. Dette system er imidlertid begrenset til visse spesifikke typer av de distribuerte systemer.

Andre innfallsvinkler hva angår løsningen av problemer ved-rørende kommunikasjon mellom og i datamaskinrelaterte og databehandlingssystemer innbefatter CCITT anbefalingen for bruk av X.219, "Remote Operations" og ISO 9072-1, "Informa-tion Processing Systems-Text Communications-Remote Operations Model of Open Systems Interconnection for CCITT Applications" som ble utviklet i et tett samarbeidsforhold og er teknisk justert i forhold til hverandre. Nevnte CCITT X.219 anbefaling definerer fjerndriftstjenestene og nota-sjon av det såkalte "Open Systems Interconnection" for CCITT applikasjoner, for å kunne understøtte interaktive applikasjoner i en omgivelse med fordelte åpne systemer. I henhold til nevnte X. 219 anbefaling er imidlertid bare operasjonene formelt spesifisert. Det foreligger ingen formell spesifikasjon vedrørende de aktuelle protokoller eller vedrørende eventuelle interaksjonsbegrensninger. CCITT standarder utgjør anbefalingene i henhold til "Internatio-nal Telegraph and Telephone Consultative Committee". Det er publisert et antall CCITT kommunikasjonsstandarder og disse har oppnådd aksept innenfor datamaskinindustrien. F.eks. har "CCITT V.24" blitt akseptert i vide kretser til bruk i de lavere lag av nettverksarkitektur. Slike standarder er nyttige og nødvendige for å definere de konvensjonelle forbindelser mellom datautstyr og modemer. Slike fysiske standarder skaffer et effektivt, kompatibelt grensesnitt mellom to fra hverandre forskjellige maskinvareinnretninger.

Systemet ifølge den foreliggende oppfinnelse er anvendelig for det applikasjonsnivå, dvs. nivå nr. 7 som vedrører OSI protokollstakklageret, og således vil hoveddelen av de tidligere kjente teknikker, som er omtalt tidligere og relaterer til lavere nivåer eller lag ifølge protokollstakklageret, ikke være direkte relevante. På den annen side vil CCITT X.219 "Remote Operations and Advanced Networked Systems Architecture (ANSA) standarder relatere seg til appli-kas j onsnivåprotokoller og således være relatert til den foreliggende oppfinnelse. Nevnte "Advanced Networked Systems Architecture", ANSA (ISA prosjektet), fremskaffer grensesnitt der grupper av operasjoner er spesifisert. Like-mansprotokoller ("Peer protocols") der to kommuniserende parter er å betrakte som like og hver part kan initiere kommunikasjon, må imidlertid bli bygget ut i fra to forskjellige klientserver-spesifikasjoner som ikke har noen formell forbindelse derimellom. Videre vil grensesnittspesifikasjonene i det minste delvis være integrert med den implementering som bevirker at systemet skal være mindre fleksibelt, mindre modulært og mindre systemuavhengig. Nevnte ANSA system fremskaffer ikke interaksjonsbegrensninger som kan spesifiseres, men fremskaffer bare visse begrensede formål som ikke har å gjøre med selve spesifikasjonen. Den såkalte ANSA "Computational Model" omfatter de struktureringskonsepter som er fremskaffet av ANSA for app-likas j onsprogrammer som skal benyttes ved konstruksjon av distribuerte programmer. Den innbefatter slike hovedkonsep-ter som tjenester, operasjoner, formål, grensesnitt, anrop, typer av grensesnitt, aktiviteter og type konformitetsdata.

En annen relatert arkitektur og spesifikasjon er den såkalte "Common Object Request Broker" utviklet av en gruppe

selskaper, innbefattende blant andre Sun Microsystems Inc., Hewlett-Packard Inc. og Digital Equipment Corporation. Denne spesifikasjonen fremskaffer de organer ved hvilke objek-tene i et system transparent kan generere og overføre fore-spørsler og motta svar. Nevnte "Object Request Broker" er

en klassisk, konkret objektmodell som dessuten fremskaffer interoperasjonsmulighet mellom applikasjoner på forskjellige maskiner i heterogene distribuerte omgivelser, for der-ved å fremskaffe sømløs mellomkobling mellom multiple ob-jektsystemer. Imidlertid vil denne spesifikasjon ikke fremskaffe implementering av spesifikke likeman-til-likemans

protokoller med partene behandlet som likeverdige.

Det vil således være meget nyttig innen telekommunikasjons-industrien å være i stand til å spesifisere visse kommunikasjonsprotokoller og andre grensesnitt i en enkeltstående, separat spesifikasjon som eksisterer for seg selv i forhold til implementeringen av enten en kommunikasjonspart eller - komponent. Det innebærer at det ville være formålstjenlig å ha en fremgangsmåte ved hvilken multiple toparter par i et datamaskinsystem kan beskrive toveis kommunikasjon i den samme felles beskrivelse eller spesifikasjon. Det er ytterligere ønskelig at alle slike protokoller ville være i stand til å beskrive på denne måte hvorvidt de er klient-serverprotokoller eller likemannsprotokoller. Systemet ifølge den foreliggende oppfinnelse fremskaffer et slikt system, dels ved å benytte spesialisert språk betegnet som ELIN. Nevnte ELIN språk, dets konsepter og oppbygning er beskrevet i detalj i publikasjonen "ELIN Language Refe-rence", en kopi av hvilket er vedlagt her som "Attachment A" og som herved innlemmes som referanse.

Sammenfatnin<g> av o<p>pfinnelsen

Systemet og fremgangsmåten ifølge den foreliggende oppfinnelse gir anvisning på den fulle spesifikasjon av applikasjonsnivå kommunikasjonsprotokoller som brukes i et datamaskinsystem, enten det er av simpleks- eller dupleksoppbygd-ning, og hver protokoll blir lagret i et ikke-direkte

("off-line") programvareutviklingssystem. Systemet og meto-den er definert i de vedlagt krav. Videre er protokollspesifikasjonene separate konstruksjonsobjekter som kan brukes som "kontrakter" mellom par av programvaremoduler som implementerer kommunikasjonsparter. Ved systemet ifølge den foreliggende oppfinnelse blir den fulle kommunikasjons-"kontrakt" mellom par av kommuniserende parter, spesifisert kollektivt. Det innebærer at kontrakten kan innbefatte forskjellige aspekter ved mellomvirkning mellom par av parter, innbefattende deres respektive ansvarsfordeling, deres

respektive tillate operasjoner med data og retningslinjer for disse, samt de tillatte ordrer med hensyn til hvordan operasjoner kan sendes mellom respektive parter i paret. Denne fremgangsmåten for å spesifisere protokollen ved bruk av en grensesnittspesifikasjon i et veldefinert, spesialisert, men felles språk, tillater at spesifikasjonen kan brukes på nytt for "kontrakter" også mellom andre kommuniserende par av parter.

Videre vil dette aspekt ved systemet ifølge den foreliggende oppfinnelse øke nivået for modularitet som kan oppnås i et datamaskinsystem, øke standardiseringen over et system, samt gjøre det lettere hva angår et system som skal utvi-des. I tillegg vil det tillate sann uavhengig utvikling og test av datamaskinprogrammer som må samvirke med hverandre. Dette aspekt ved den foreliggende oppfinnelse skaffer den mulighet til på en enklere måte å utføre uavhengig program-vareutvikling og testing selv i meget spredte geografiske lokasj oner.

Ved et annet aspekt omfatter systemet ifølge den foreliggende oppfinnelse en mekanisme for å spesifisere alle in-terne grensesnitt ved applikasjonslaget i et datamaskinba-sert eller databehandlingssystem ved bruk av visse spesielle og veldefinerte konstruksjonsdeler ("constructs"). Disse definerende elementer vil f.eks. tillate at en likemans-protokollspesifikasjon kan utvikles for å inneholde følgen-de komponenter: 1) en formell gruppering av operasjoner som skal brukes i protokollene for de to parter, og 2) spesifikasjonen vedrørende interaksjonsbegrensninger som skal brukes i protokollen. Ved et annet aspekt vil systemet ifølge den foreliggende oppfinnelse også skaffe mulighet for å

spesifisere protokoller av klientserver- eller enveistypen.

Ved nok et annet aspekt omfatter systemet ifølge den foreliggende oppfinnelse bruken av en protokollspesifikasjon for generering av stumpkode ("stubcode") som da sikrer at det oppnås perfekt koordinering mellom to kommuniserende parter. Ved systemet ifølge den foreliggende oppfinnelse blir operasjoner spesifisert ved følgende informasjon: ope-ras j onsklasse, argumenter, resultater og feil. I tillegg vil dette aspekt ved systemet ifølge den foreliggende oppfinnelse fremskaffe interaksjonsbegrensninger som kan spesifiseres som del av grensesnittet eller protokollspesifikasjonen. Dette aspektet ved systemet ifølge den foreliggende oppfinnelse bidrar til at brukeren av en kommuniserende part som bruker protokollen, vil kunne forstå hvilke operasjoner som skal påkalles ved et gitt tidspunkt.

Ved et annet aspekt omfatter systemet ifølge den foreliggende oppfinnelse en mekanisme for generering av en "proto-kollovervåker" for å overvåke systemet og å detektere når en spesiell implementering oppfører seg unormalt og bryter de spesifiserte regler for interaksjon. Når en regel blir brutt, sørger dette aspektet ved systemet ifølge den foreliggende oppfinnelse for å informere begge parter om brud-det, og å iverksette korrigerende handlinger. Et slikt trekk bør imidlertid bare aktiviseres i tilfellet av en konstruksjonsfeil ved implementeringen av én av de kommuniserende parter. Dette protokollovervåkningsaspekt ved systemet ifølge den foreliggende oppfinnelse vil derfor ha sin primære nytte ved testfasene for systemet og programvareut-vikling .

I henhold til et annet aspekt omfatter systemet ifølge den foreliggende oppfinnelse et organ for spesifisering av in-teraks j onsbegrensninger omfattende et sett symbolske til-stander hver med en liste over tillatte operasjonskomponen-ter. Resultatet av denne interaksjonsbegrensningsspesifika-sjon er en maskin med endelig tilstand ("finite state ma-chine"), dvs. protokollovervåkeren. Hver operasjon blir spesifisert separat og i en operasjonsspesifikasjon, der argumenter, resultater og feil blir spesifisert med navn og datatype noe som på sin side kan være av enten den primiti-ve eller konstruktive type.

Ved et annet aspekt vil systemet ifølge den foreliggende

oppfinnelse benytte et objektorientert grensesnittkonstruk-sjonsspråk, her betegnet som ELIN, hvilket kan utøves for å fremskaffe uniforme, uavhengige grensesnittspesifikasjoner. Nevnte ELIN språk, som omfatter et antall unike og spesialiserte termer og konstruksjoner, fremskaffer en mekanisme for opprettelse av spesifikasjoner til bruk ved toveis kommunikasjon. De resulterende spesifikasjoner kan derfor benyttes ved multiple par av kommuniserende parter for den spesifikke implementering av deres kommunikasjonsgrense-snittprotokoll. Videre vil ELIN språket fremskaffe en mekanisme til å beskrive ikke bare kommunikasjoner av den type der en part styrer datautvekslingene, men også kommunikasjoner der begge parter virker som likestilte og hver kan initiere og/eller styre datautvekslingene.

Ved nok et annet aspekt omfatter systemet ifølge den foreliggende oppfinnelse en mekanisme for grensesnittspesifikasjon som oppnår uavhengighet i forhold til hvilket som helst programmeringsspråk og hvilken som helst spesifikk datamaskinarkitektur. Fra de spesifikasjoner som er opprettet under bruk av nevnte ELIN språk ifølge den foreliggende oppfinnelses system, kan det benyttes verktøy for å generere stumpkode for forskjellige individuelle programmeringsspråk. Dette stumpkodegenereringsaspektet ved systemet ifølge den foreliggende oppfinnelse er vitalt for hele systemet og mekanismen. Konseptet som helhet avhenger av at disse stumpkodegeneratorer fremskaffer et effektivt og in-tuitivt grensesnitt for den spesifiserte protokoll for systemet eller applikasjonsprogrammereren.

Som det lett vil forstås av fagfolk på dette spesielle område vil prinsippene og aspektene ved den foreliggende oppfinnelse også kunne utnyttes med fordel i forbindelse med et antall datamaskinapplikasjoner som er forskjellige fra telekommunikasjonssvitsj esysterner.

Kort omtale av teoninasf icrurene

For forståelse av den foreliggende oppfinnelse og med hensyn til ytterligere hensikter og fordeler ved denne, skal det nå vises til den følgende beskrivelse tatt i forbindelse med de vedføyde tegningsfigurer. Figur 1 er et funksjonelt blokkdiagram som anskueliggjør et tidligere kjent kommunikasjonsnett for kommunikasjon med datamaskiner som har uensartede protokoller. Figur 2 er et blokkdiagram som anskueliggjør et tidligere kjent databehandlingssystem som omfatter et antall fjern-styrte innretninger som hver opererer under forskjellige kommunikasjonsprotokoller ved bruk av kommunikasjonsstyrere som sender ut signaler omfattende adressen for styreren. Figur 3 er et skjematisk oversiktsblokkdiagram over et tidligere kjent multi-prosessystem med en inter-prosesskommunikasjonsfasilitet for styring av kommunikasjon mellom prosesser i et prosessorsystem. Figur 4 er et blokkdiagram som illustrerer hvordan den felles grensesnittspesifikasjon ved systemet i henhold til den foreliggende oppfinnelse blir benyttet for en serverklient-type av grensesnittspesifikasjon som benyttes for dynamisk kjøretidslinking som utøves på en programmeringsspråk-uavhengig måte. Figur 5 er et blokkdiagram som illustrerer hvordan datapro-gramenheter kan adresseres ved hjelp av den som handler eller formidler ("trader") i systemet i henhold til den foreliggende oppfinnelse, idet innsignalet til den som handler genereres fra grensesnittspesifikasjonene og enhetsspesifi-kasj onene. Figur 6 er et illustrativt diagram over hvordan grense-snittspesif ikas j onen kan utnyttes for generering av stumpkode for fasiliteringen og koordineringen av kommunikasjoner i systemet i henhold til den foreliggende oppfinnelse. Figur 7 er et diagram som illustrerer hvordan grensesnitt-spesif ikas j oner blir utnyttet ved systemet ifølge den foreliggende oppfinnelse. Figur 8 er et illustrerende diagram over hvordan et objektorientert grensesnittbeskrivende språk blir utnyttet for implementering av felles grensesnittspesifikasjoner eller protokoller som forenkler kommunikasjon ved systemet i henhold til den foreliggende oppfinnelse.

Detaljert beskrivelse

Systemet ifølge den foreliggende oppfinnelse utnytter, ved noen aspekter, prinsipper i henhold til objektorientert programmering. Objektorientert programmering innebærer ho-vedsakelig fire elementer - klasser, objekter, forekomstva-riable (eller datamedlemmer som implementert i C++), og fremgangsmåter (eller medlemsfunksjoner i C++). En klasse er rett og slett en symbolmal som benyttes for å definere objekter, som utgjør tilfeller av den klasse som de fremskaffes fra. Klasser har to typer av komponenter, - fore-komstvariable og fremgangsmåter. Forekomstvariabler tjener som dataelementer, og fremgangsmåter tjener som funksjoner dvs. de definerer oppførselen hos et objekt. Forekomstvariabler og fremgangsmåter kan kombineres i et eneste felles objekt i utøvelsestid. Dette innebærer at et objekt omfatter en forekomst av de variabler som burde kunne manipuleres ved bruk av fremgangsmåtene. Således vil programmet bli utført med en fokusering på objekter, heller enn på de funksjoner eller oppgaver som skal utføres.

Visse teknikker vedrørende objektorientert programmering, som er velkjent innenfor denne teknikk, blir inkorporert i systemet i henhold til den foreliggende oppfinnelse ved den foretrukne implementering av systemet ifølge oppfinnelsen i programmeringsspråket C++. Slike teknikker innbefatter arv, polymorfi og innkapsling. Arv muliggjør at en ny klasse kan avledes fra en eksisterende klasse, slik at en kode lett kan brukes på nytt, slik at data og kode kan legges til en klasse eller at oppførselen for en klasse kan endres, uten at man trenger å endre den eksisterende klasse. Polymorfi er den egenskap som fremskaffer mulighet for bruk av forskjellige typer objekter på den samme måte, fordi de forskjellige objekttyper deler et felles grensesnitt. Arv av grensesnitt er den egenskap som gjør det mulig å avlede andre objekttyper fra en felles denominator. Endelig går innkapsling ut på en teknikk for kombinasjon av de data og operasjoner som er nødvendige for behandling av alle data under et "tak". Den tillater dessuten muligheten for å be-skytte dataene fra overflødig eller unødvendig aksess og for å skjule detaljene ved dataorganisasjonen.

Ved systemet i henhold til den foreliggende oppfinnelse blir de offentlige grensesnitt som forbinder programvaremoduler til de ytre omgivelsene (med unntak av krysskompila-torer og relaterte biblioteker) alle spesifisert ved bruk av ELIN. Dette tillater at alle programvaremoduler kan spesifiseres med begreper relatert til de grensesnitt med hvilke de er forbundet, idet en slik spesifikasjon driver en stumpkodegenerator. Det som følger er en trinn-for-trinn beskrivelse for utvikling av en programvaremodul ved bruk av ELIN, illustrert i henhold til en foretrukket fremgangsmåte for utvikling av objektlogikk implementert i C++. Andre parallelle prosesser blir benyttet for å utvikle data-basespesifikasjoner, funksjonsenheter og andre elementer i et system. De følgende trinn illustrerer objektblokkutvik-ling (trinn 1 og 2) , objektenhetsutvikling (trinn 3-6) og pakking (trinn 7).

Trinn 1 Grensesnittspesifikasjoner er tilgjengelige, eller nye blir spesifisert i

ELIN.

Trinn 2 En programvaremodul med grensesnitt blir

identifisert.

Trinn 3 C++ topptekstfiler blir generert fra enhetsspesifikasjonen og spesifikasjoner for grensesnitt til hvilke enheten blir forbundet (ADT, PROTOKOLL, PERSISTENT ADT).

Trinn 4 Den håndbearbeidete kode blir skrevet

i .h og .cc filer som om nødvendig innbefatter de genererte .h filer.

Trinn 5 Alle .cc filer blir kompilert med en krysskompilator og en objektfil (.o) blir fremskaffet for hver av .cc filene.

Trinn 6 Alle objektfiler blir linket sammen med standard biblioteker og den komplette programvaremodul blir opprettet.

Trinn 7 De programvaremoduler i en systemenhet som må allokeres til den samme prosessor blir pakket sammen. Pakkene blir betegnet lastpakker og kan inneholde et sett enheter av varierende type.

Trinn 8 Overføring av pakkene til målsystemet.

Trinn 9 I målsystemet: lagring av pakken

temporært.

Trinn 10 Link/relokalisering og kopiering av lastmodulene fra pakken inn til passende steder i lageret avhengig av typen av informasj on.

På figur 1 er det illustrert et kommunikasjonsnett i henhold til kjent teknikk som muliggjør kommunikasjon mellom datamaskiner med ulike protokoller. Selv om datamaskinene kan benytte diverse datahastigheter og dataformater for mottagning og sending av data, vil de fortsatt være i stand til å kommunisere intelligent med hverandre i det illustrerte nett. Dette kommunikasjonsnett kan f.eks. innbefatte et antall diverse hovedrammedatamaskiner 10, 12, et antall personlige datamaskiner 14, 16, en bærbar datamaskin 18 og en lokalområdenettport 20. Hovedrammedatamaskinene 10 og 12, samt de personlige datamaskiner 14 og 16 kan innbefatte slikt periferutstyr som en skriver 22 og en diskfil 24. Alle datamaskinene kommuniserer med hverandre via uavhengige modemer 26 og et verdensomspennende telefonsystem 27 eller lokal telefonsentral 28.

Imidlertid, fordi de forskjellige datamaskiner som benytter dette kommunikasjonsnett, er programmert til å sende eller motta data som er basert på spesifikke bithastigheter og dataformater, vil kommunikasjon mellom disse forskjellige datamaskiner være umulig hvis ikke hver individuell datamaskin har kjennskap til disse forskjellige bithastigheter og dataformater. F.eks. ville hvert av dataformatene innbefatte en datapakke med en paritetsbit, de ville være av forskjellige ordlengder, de ville innbefatte en syklisk redun-danskontroll og de ville enten være synkrone eller asynkro-ne. Det på figur 1 illustrerte system tillater kommunikasjon mellom disse systemer ved at det fremskaffes et program som blir lagret i et lager med tilfeldig aksess ("RAM") hos minst en av datamaskinene i nettet. Dette program vil inneholde de forskjellige bithastigheter og dataformater som blir benyttet av de forskjellige typer av da-tamaskiner som datamaskinen ønsker å kommunisere med. Ofte vil det program som blir lagret, ikke inneholde disse spesifikke databithastigheter og dataformater, men ville inneholde den informasjon som er nødvendig for å implementere et system for simulering av de forskjellige datahastigheter og dataformater. Ved denne situasjon vil den individuelle bruker kunne bestemme de forskjellige databithastigheter og dataformater som blir benyttet for å kommunisere med de aktuelle datamaskiner, og ville kunne laste inn denne informasjon i selve datamaskinen.

På figur 2 er det vist et tidligere kjent databehandlingssystem som benytter seg av et antall fjerninnretninger som bruker forskjellige kommunikasjonsprotokoller via bruk av kommunikasjonsstyrere som sender ut signaler som gjør vertsprosessoren oppmerksom på deres adresser. Det viste system omfatter et lokalområdenettbehandlingssystem hvori et antall fjernstyreinnretninger, f.eks. sted-for-salg da-taterminaler er forbundet med en vertsprosessor via en kommunikasjonskanal. Til hver av dataterminalinnretningene er det knyttet en kommunikasjonsstyrer, på hvilken det er mon-tert en dreiesvitsjdel som selektivt innstilles til å sende ut binære signaler som omfatter adressen for styreren. Når en "power-up" tilstand opptrer for systemet, vil hver styrer sende en melding innbefattende sin adresse til vertsprosessoren for identifikasjon av styreren. Vertsprosessoren som bruker adressen for styreren som en adresse, vil fra en oppslagstabell som er lagret i prosessoren trekke ut de programinstruksjoner som omfatter den kommunikasjonsprotokoll som vil bli brukt av styreren ved styring av overfø-ringen av data mellom vertsprosessoren og fjernbehandlings-innretningene. Instruksjonene blir lastet inn i et RAM lager som er anordnet i styreren. Adressesvitsjen blir manu-elt innstilt slik at hver styrer vil ha en forskjellig adresse .

Idet det på nytt vises til figur 2, er det her vist et blokkdiagram over et databehandlingssystem der en vertsprosessor 30 er forbundet via en kommunikasjonskanal eller link 32 til et antall fjernbehandlingsinnretninger som kan innbefatte en dataterminalinnretning 34 og en kommunikasjonsstyrer 36 som styrer overføringen av data mellom terminalinnretningen 34 og vertsprosessoren 30. Styreren 36, prosessoren 30 og terminalinnretningen 34 er hver forbundet med kanalen 32 via en uttagningsboks 38 og en buss 40. Slik det vil bli omtalt i mer detalj i det følgende, er hver styrerne 36 i stand til å kunne bli koblet via kommunika-sjonslinjer 42 gjennom modemer 44 eller direkte til en fjernstyrer 46 som på sin side styrer overføringen av data mellom vertsprosessoren 32 og behandlingsinnretninger, slik som dataterminalinnretninger 48 forbundet med fjernstyreren 46. Et diskfil-lager 50 som er forbundet med vertsprosessoren 30 via linjen 54, omfatter en oppslagstabell 52 som inneholder et antall programmer som har tilknytning til forskjellige typer kommunikasjonsprotokoller, f.eks. synkron, bisynkron og bitsynkron, hvilket blir brukt av fjernbehand-lingsinnretningene ved overføring av data via kanalen 32. For en fullstendig beskrivelse av de forskjellige typer kommunikasjonsprotokoller, skal det vises til US patentskrift 4,346,440 meddelt 25. august 1982.

På figur 3 er det vist en oversikt over et tidligere kjent multiprosess-system som bruker en inter-prosess-kommunikasjonsfasilitet for kommunikasjon mellom prosesser i et prosessorsystem. På figur 3 er det med henvisningstall 60 generelt vist en høynivåoversikt over en fordelt pro-sessomgivelse. En prosessor A vist ved henvisningstall 62 er koblet ved hjelp av en fysisk bane vist ved en linje 64, til en prosessor B vist ved henvisningstall 66. Prosessor A er vist som å ha en prosess A vist ved henvisningstall 68 og en prosess B vist ved henvisningstall 70, innlemmet deri. Et lagringsområde 72 har tilknytning til prosess A og prosess B representert ved linjer henholdsvis 74 og 76, for å fremskaffe prosesstyringen for og aksessen til datalagring .

Prosessor B er vist som å ha en prosess C som vist ved henvisningstall 78, og en prosess D som er indikert ved henvisningstall 80, innlemmet deri. Et lagringsområde 82 har tilknytning til prosess C og prosess D som representert ved linjer henholdsvis 84 og 86, for å fremskaffe prosesstyring av og aksess til datalagring.

Prosesser eller utførende programmer i prosessorene trenger å kommunisere med hverandre. I prosessorer av forskjellige

konfigurasjoner, eller i den samme prosessor etter som denne endrer seg over tid, vil to prosessorer som kommuniserer kunne befinne seg på forskjellige relative steder og kan ha forskjellige fysiske baner mellom seg.

Ved det system som er vist på figur 3 er en interprosess-kommunikasjonsfasilitet ("interprocess communication faci-lity" IPCF) anordnet i prosessor A og prosessor B, ved henholdsvis 88 og 90, for å fremskaffe inter-prosesskommunikasjon som er stedtransparent i forhold til kommunikasjonsprosessene. IPCF 88 er koblet til prosess A i prosessor A slik dette er representert ved en linje 92, og til prosess B som representert ved en linje 94. Linjer 92 og 94 representerer grensesnitt mellom prosess A og prosess B til nevnte IPCF 88. Disse grensesnitt tillater kommunikasjon mellom prosess A og prosess B under forutsetning av at passende databaner blir etablert. IPCF 88 er også koblet via en transportmekanisme 96 ved linjen 64 via en transportmekanisme 89 i prosessor B til IPCF 88. IPCF 88 er på sin side forbundet som vist ved grensesnittlinjer 100 og 102 til prosess C og prosess D. Disse grensesnitt med nevnte flerhet av IPCF og transportmekanisme tillater etable-ring av kommunikasjon mellom alle de påpekte prosesser, uten prosesskjennskap til stedet for den prosess som det kommuniseres med.

Ved det system som er vist på figur 3, omfatter transportmekanismene 96 og 98 fortrinnsvis et antall transportmekanismer, f.eks. lokale transportmekanismer til bruk når prosess A og prosess B, eller prosess C og prosess D, kommuniserer med en eneste prosessor. Dersom prosessor A og prosessor B befinner seg i den samme maskin, blir en buss-transportmekanisme brukt for å forenkle kommunikasjon mellom prosesser på prosessor A og prosessor B. For inter-maskinkommunikasjon kan en kommunikasjonsprotokoll, f.eks. SNA passende kunne brukes.

Transportmekanismene 96, 98 er dataoverførere ("data mo-vers"). De er ansvarlige for overføring av bitgrupper av data fra et sted til et annet og forstår ikke meningen av den informasjon som skal forflyttes. Således er lageret 72 i prosessor A forbundet med transportmekanismen 96 slik dette er vist ved en linje 104, og lager 82 i prosessor B er forbundet med transportmekanisme 98 som vist ved en linje 106 for å tillate informasjonsoverføring direkte ved transportmekanismene 96, 98.

Nevnte IPCF av prosessen som forsøker å kommunisere, velger transportmekanismen for kommunikasjon. Kommunikasjonspro-sessen trenger ikke å være klar over den mekanisme som benyttes. Den prosess som prøver å kommunisere vil fremskaffe navnet på målprosessen, slik dette er kjent for den prosess som forsøker å kommunisere, til nevnte IPCF som bruker en passende katalogtjeneste til å plassere nevnte. Nevnte IPCF selekterer deretter den passende transportmekanisme og bruker systemtilførte tjenester for å sette opp forbindelsen mellom prosessen på en standard måte. IPCF kan benyttes ved alle nivåer av prosesser, fra applikasjoner til grunnleg-gende systemtjenester, f.eks. som en personsøker administ-rator .

For å tillate bruken av mange forskjellige transportmekanismer, hver med forskjellige muligheter og egenskaper, vil nevnte IPCF innbefatte et generisk transportmekanismegren-sesnitt for hver prosess. Grensesnittet definerer et sett av funksjoner for etableringen av forbindelser og for utveksling av informasjon mellom prosesser. De definerte funksjoner blir avbildet på de transportmekanismer som brukes av IPCF. Programmer som er skrevet til grensesnittet, er uavhengig av transportmekanismen, og derfor uavhengig av deres relative plasseringer ved kommunikasjon.

Kommunikasjon mellom prosesser kan uttrykkes i termer for sending og mottagning av meldinger via en forbindelse mellom dem slik dette er etablert ved IPCF. Meldingene inneholder arbeidsforespørsler og/eller data. I forhold til en spesiell arbeidsforespørsel vil en prosess anta rollen som en forespørrer eller en server. Forespørreren initierer en arbeidsforespørsel ved å sende en forespørsel til en server som utfører nevnte. Forespørslene inneholder en arbeidsfo-respørsel (en kommando og dennes parametere) og eventuelt noen data. Både forespørselen og dataene er av variabel lengde.

På figur 4 er det vist det forhold at den mekanismen som oppretter og relaterer klasser og hendelser av klasser benytter konseptet av en formidler ("trader") 120 som er in-neholdt i en kjerne 122 i operasjonssystemet, noe som mu-liggjør et grensesnittforhold mellom et par av programvaremoduler 124 og 126, som henholdsvis omfatter en klientklasse av objekter 128 og en serverklasse av objekter 130. Figur 4 illustrerer i detalj de trinn som er nødvendige for å fremskaffe objekter innenfor systemet, samt hvordan opprettede objekter kan oppkalles eller manipuleres ved hjelp av den kode som rommes av serverprogramvaren plassert i "server" programvaremodulen 130.

Objekter utgjør forekomster av klasser som er språkkonst-ruksjoner inneholdende både data og kode eller funksjoner i en eneste pakke eller enhet. Fordi de er i stand til å inneholde definisjoner vedrørende både data og funksjoner i en eneste pakke eller enhet, kan de virke som miniatyriser-te, uavhengige programmer. De kan derfor brukes som bygge-blokker ved opprettelse av mer komplekse programmer uten at man trenger å utvikle på nytt den kode som er nødvendig for disse. Fordi de kan vedlikeholdes og modifiseres uavhengig vil programvedlikehold og revisjon bli forenklet.

En klasse utgjør en mal som blir benyttet for å definere et objekt, og et objekt vil derfor utgjøre en forekomst av en klasse. En klasse inneholder to komponenttyper, forekomstvariabler og datamedlemmer og fremgangsmåter eller medlemsfunksjoner. For å kunne understøtte programmerere som ut-vikler programmer som spiller klientrollen i datasystemet, blir en klientklasse automatisk generert ved bruken av en grensesnittsspesifikasjon. Den genererte klientklasse virker som en type agent for serverklassen. Klientprogramenhe-tene for systemet oppkaller operasjoner fra klientklasseob-jektene for å sikre at anrop eller oppkallinger blir over-ført til den programvareimplementering som rommes av serverklassen. All kode som har relasjon til den dynamiske bindefunksjon vil derfor bli funnet i klientklassen, selv om den er skjult for brukeren av klientklassen. Brukeren av klientklassen får det inntrykk at serveren blir manipulert.

Klassedeklarasjoner styrer hvordan kompilatoren vil lagre adressen i objektdataene og i hvilken rekkefølge adressene i operasjonstabellene vil bli fremsatt. Noen klassedeklarasjoner blir automatisk generert av systemet. Når et objekt blir opprettet i systemet, vil dets "opprettelsesfremgangsmåte" kunne plasseres ved hjelp av en forespørsel til den del av formidleren 120 i operasjonssystemet som er plassert i kjernen 122. Formidleren 120 inneholder informasjon, dvs. lageradresser for lokasjonene av alle implementeringer av grensesnitt. Når programvaremoduler blir lastet inn i data-maskinsystemet, vil det bli publisert visse informasjoner om systemets aksessibilitet til andre enheter, nemlig i formidleren 120. Adressene til de funksjonsfrembringende objekter av denne type blir også publisert i formidleren 120 i en adresse 134 som peker på frembringelsesfremgangs-måten 136 i serverklassen 130.

For at programvaremodulen 124 skal kunne frembringe et nytt objekt av en viss type må den først spørre formidleren 120, for å fremskaffe informasjon om den klasse for hvilken et nytt objekt er ønsket. Ved hjelp av et unikt antall genererte ikke-direkte koblede "X" svarende til grensesnittspesifikasjonen 132, vil den kunne motta adressen for den riktig frembrakte fremgangsmåte 136 som blir benyttet for å kalle opp denne funksjon. Det som blir returnert, er adressen for det nylig frembrakte objekt eller forekomsten av

den ønskede klasse.

Den mekanisme som er anskueliggjort på figur 4, blir brukt som en del av en "Linked Procedure Cali" mekanisme slik dette er omtalt i samtidig innlevert US-patentsøknad nr. 5,339,430 med tittel "System For Dynamic Run-Time Binding of Software Modules in a Computer System", innlevert 1. juli 1992, i navnet K. Lundin et al, overdratt til Telefonaktiebolaget L M Ericsson, og herved innlemmet som referanse. Nevnte "Linked Procedure Cali" mekanisme implementerer et system for dynamisk kjøretidsbinding av separate innlastete programvaremoduler. Spesielt er dette av nytte innenfor den teknikk som vedrører et system for endring av programvare under datamaskinoperasjoner der både gamle og nye versjoner av programvare vil eksistere samtidig for en viss periode i systemet. Et slikt system for oppdatering eller endring av programvare under drift, er omtalt i samtidig innlevert US-patentsøknad nr. 5,410,703 og 5,555,418 med tittel "System for Changing Software During Computer Operations", innlevert 1. juli 1992, i navnet Nilsson et al, overdratt til Telefonaktiebolaget L M Ericsson, og herved innlemmet som referanse. I henhold til dette system blir formidling benyttet for å aksessere et grensesnitt under bruk av nevnte "Linked Prosedure Cali". De nødvendige data er tilgjengelige i formidleren 120 fordi, ved innlast-ningstidspunktet, alle grensesnitt som er tilgjengelige via den nevnte "linked procedure call" mekanisme blir publisert til formidleren 120 ved operasjonssystemkjernen 122.

Diagrammet på figur 5 illustrerer hvordan programenhetens gamle programvare 150 og nye programvare 152 blir inter-linket og bundet under kjøretiden via den tidligere omtalte "Linked Procedure Call" mekanisme. Formidleren 120 i kjernen 122 kan dirigere utøvelsen av programvaremodulen 154 mot enten den gamle programvaremodul 150 eller den nye programvaremodul 152. Når utskiftningen gjøres vil serverklassene fra både den gamle og den nye versjon hver ha sitt grensesnitt publisert i formidleren 120. Formidleren 120 inneholder to adresseinnganger for hver gang, på inngang 156 for den gamle programvaremodul 150 og en inngang 158 for den nye programvaremodul 152. Prosesser som er opprettet før utskiftningen vil motta en adresse som peker til den gamle programvaremodul 150 og dennes serverklasser, mens andre prosesser kan motta adresser til nye versjoner av serverklassen.

Etter at utskiftningen er blitt komplettert og aktiviteter i den gamle programvaremodul 150 har opphørt, kan den gamle programvaremodul 150 bli fjernet fra minnet og grensesnit-tene som ble publisert av serverklassene i den gamle programvaremodul 150, kan trekkes tilbake. Dersom det gjøres et forsøk på å trekke tilbake disse serverklasser fra minnet før alle prosesser i den gamle programvaremodul er blitt komplettert, vil systemet generere et unntaksopprop fra kjernen 122. En unntakshåndteringsprosess i systemet vil da tillate den ikke-kompletterte prosess muligheten for å opprette seg selv på nytt og utnytte den nye programvaremodul 152 eller ellers å avsluttes.

Som en del av bruken av nevnte "Linked Procedure Call" mekanismen, blir grensesnittspesifikasjonen for systemet i henhold til den foreliggende oppfinnelse skrevet i et objektorientert grensesnittbeskrivende språk betegnet ELIN, hvis språkreferansemanual er gitt "copyright" beskyttelse 6. november 1991 ved Ellemtel Utvecklings Aktiebolag. I -dette språk foreligger det spesielle konstruksjoner, betegnet som abstrakte datatyper ("abstract data types" ADTs), som er spesielt målrettet mot spesifikasjonen for "Linked Procedure Call" grensesnitt. I en ADT i nevnte ELIN språk er en spesifikasjon av det grensesnitt som fremskaffes ved objekter av visse typer. Disse objekter er vel egnet til å kunne implementeres som forekomster av en klasse dersom det benyttes et objektorientert programmeringsspråk. En spesifikasjon for et "Linked Procedure Call" grensesnitt i ELIN språk vil innbefatte følgende informasjon:

a) et navn på spesifikasjonen,

b) andre grensesnitt som brukes som en basis for dette grensesnitt, c) en eller flere konstruktører (brukt for opprettelse av forekomster), og d) null eller flere fremgangsmåtespesifikasjoner, idet hver av disse omfatter et fremgangsmåtenavn,

argumenter, returtype og unntak.

I det følgende vil det i kode bli fremsatt et eksempel på en grensesnittspesifikasjon som kan brukes som del av en "Linked Procedure Call" mekanismen, og som beskriver et grensesnitt mot objekter av typen "Stack":

© 1992 Telefonaktiebolaget L M Ericsson

Denne grensesnittspesifikasjon definerer en ADT betegnet "Stack", idet basisen betegnes "TelecomObject" . Objekter i denne basis kan akseptere prosessanrop fra de listete funk-sjonsmedlemmer. Å ha en basisidentifisert indikerer at det foreligger en annen spesifikasjon av denne typen som er betegnet "TelecomObject". Denne basis har også visse spesifiserte fremgangsmåter som den aktuelle, som en avledet ADT fra basisen ADT vil arve. De funksjonselementer eller fremgangsmåter som er spesifisert i den tidligere nevnte ADT definisjon forekommer i tillegg til dem som er spesifisert i basis ADT. I sum omfatter den nevnte kode en ADT spesifikasjon som er av en type grensesnittspesifikasjon som kan opprettes i systemet.

Et grensesnitt kan avledes fra et annet grensesnitt som da blir betegnet basisgrensesnittet for det avledede grensesnitt. Grensesnitt kan avledes fra mer enn et grensesnitt, idet det avledede grensesnitt arver fra operasjonene for hvert av sine basisgrensesnitt. Det avledede grensesnitt kan i tillegg fremsette sine egne ytterligere operasjoner, selv om den ikke definerer operasjoner med det samme navn som dem som er arvet fra basisgrensesnittene. Det skal forstås at arv bare påvirker grensesnittnivået av vedkommende klasse, ikke implementeringsnivået.

Slik det fremgår av figur 6 innbefatter systemet ifølge den foreliggende oppfinnelse et stumpkodegenereringsverktøy 170 som blir brukt til å sertifisere koordineringen mellom brukeren og serveren som ikke nødvendigvis er linket sammen. I stedet kan binding finne sted dynamisk under driftstiden

ved bruk av den stumpkode som er blitt generert for hver

side av grensesnittspesifikasjonen 172. Grensesnittspesifikasjonen 172 er spesifisert på en språkuavhengig måte, selv om det benyttes objektorientert paradigma. Stumpkodegenere-ringsprosessen sikrer at en kartlegging (mapping) til et av flere programmeringsspråk oppnås og i de følgende avsnitt

vil det gis en kort beskrivelse av hvordan en slik kartlegging kan utføres ved bruk av språket C++.

Idet det på nytt henvises til figur 6, er det der vist hvordan en grensesnittspesifikasjon 172 benytter stumpgene-reringsverktøyet 170 i forbindelse med et sett genererte filer 174 i systemet ifølge den foreliggende oppfinnelse. Figur 6 viser spesielt den totale oppbygning av nevnte C++ kartlegging som implementert i dette språk. En grensesnitt-spesif ikas j on som er skrevet i det objektorienterte grense-snittbeskrivelsesspråk, ELIN, slik dette benyttes i systemet ifølge den foreliggende oppfinnelse, er lik en klassedefinisjon som brukes i programmeringsspråket C++. På lignende måte vil mekanismen for aksesseringsoperasjoner via objekter være i likhet med hvordan programmeringsspråket C++ håndterer reelle elementfunksjoner. Derfor vil den kartleggingen på C++ vist på figur 6 være instruktiv hva angår operasjonen ved denne side av systemet ifølge den foreliggende oppfinnelse.

Stumpgenereringsverktøyet 170 genererer to filer for både brukerside og serverside, en med indeks ".h" (topptekst) og en med indeks ".cc" (kode). For brukeren vil nevnte ".h" eller topptekstfil inneholde to klassedefinisjoner. En klasse er en kompatibel kopi av den korresponderende klasse i serverens ".h" eller topptekstfil hva angår de reelle elementfunksjoner og hendelsesvariabler. Dette sikrer kompatibilitet mellom brukeren og server, og gjør det mulig for brukeren å oppkalle objekter som er opprettet av serveren. Denne klassekonstruktører er imidlertid privat, slik at klassen ikke kan brukes til å opprette automatiske objekter på stakklageret. Den andre klasse er den som skal brukes ved den bruker som virker som en smart peker gjennom hvilken objekter opprettet av serveren kan aksesseres.

For serversiden vil de to ".h" (topptekst) og ".cc" (kode) filer genereres av stumpgenereringsverktøyet 170. Innholdet i nevnte ".h" fil består av en klassedefinisjon som vil sikre kompatibilitet med brukeren. Dette er den klasse som blir brukt som en basis for implementering. Implementeringer kan være basert direkte på den genererte klasse, eller den genererte klasse kan brukes som en basis fra hvilken det kan avledes andre klasser. Nevnte ".cc" fil inneholder en stamme for nevnte "opprettelsesfremgangsmåte" og kode som utfører publiseringen av adressen for opprettelsesfremgangsmåten. Hoveddelen for opprettelsesfremgangsmåten er ansvarlig for å opprette et objekt som er kompatibelt med den genererte klasse, og å returnere en peker til det nylig opprettede objekt.

Det foreligger mange grunner for å generere forskjellige, men likevel kompatible klassedefinisjoner for bruker- og serversidene heller enn en delt klassedefinisjon. For det første, vil det fremskaffes forskjellige nivåer av synbar-het for elementer eller medlemmer hos brukeren og serveren. For eksempel vil en konstruktør være offentlig i serveren, men trenger ikke nødvendigvis være offentlig dersom nevnte holder til hos brukeren. For det annet kan bruker- og ser-verprogrammene være linket sammen for testformål uten at man støter på problemet vedrørende navnekollisjoner dersom forskjellige klasser blir benyttet.

På figur 7 er det vist et spesielt arrangement over flyt-skjemaer som viser eksempler på visse spesifikasjoner og klassedefinisjoner, samt deres relasjon i forhold til hverandre slik de benyttes ved systemet ifølge den foreliggende oppfinnelse. Figur 7 illustrerer logikk-oppbygningen av visse genererte filer og skrevne spesifikasjoner idet disse kan implementeres i systemet ifølge den foreliggende oppfinnelse. Ved det høyeste nivå definerer "Common Interface Specification 180" en ADT "X" og de fremgangsmåter for hvilke klassen vil akseptere anrop. Logisk subordinert til denne ADT, ved det neste nivå av definisjonen, finnes en spesifikasjon for en brukerenhet 182 ifølge nevnte "Common Interface Specifiaction 180" og en spesifikasjon for en fremskafferenhet 184 for nevnte "Common Interface Specification 180". Brukerenheten er spesifisert til å være en klient av ADT X, mens fremskafferenheten er spesifisert til å være en server av ADT X.

Ved det neste logikknivå under enhetsspesifikasjonene 182

og 184, blir det generert klassedefinisjoner for henholdsvis brukere og fremskaffere. Den genererte klassedefinisjon for XUser 186 illustrerer visse brukerklasser som er definert for både offentlig og privat bruk. Den genererte klassedefinisjon for XProvider 188 illustrerer visse offentlige og private definisjoner for fremskafferdata og funksjoner.

Idet det til slutt henvises til figur 8, er det her vist et beskrivende diagram over hvordan en protokollspesifikasjon blir brukt for generering av stumpkode, noe som sikrer perfekt koordinering mellom to kommuniserende parter. Konst-ruksjonen av stumpkoden er vist på figur 8 og innbefatter en brukerskrevet kode 200, generert kode 202 og kjernekode 204. I forbindelse med distribuerte og modulære datamaskinsystemer, i hvilke et telekommunikasjonssystem er et eksempel, blir mange applikasjonsnivåprotokoller brukt til å forenkle kommunikasjon i og blant forskjellige deler av systemet.

Protokoller kan ses på som en samling kontrakter mellom par av parter i systemet, idet disse er enige om å kommunisere på en spesiell måte og med spesielt format. Noen protokoller kan beskrives som bruker-, serverprotokoller der bare en part er initiator. Andre protokoller som er betegnet likemans-protokoller, tillater begge parter å initiere kommunikasjon. Ved systemet ifølge den foreliggende oppfinnelse, ulikt andre eksisterende systemer, blir hele avtalen eller protokollen mellom par av parter spesifisert i en eneste grensesnittsspesifikasjon som er atskilt fra den spesifikke implementeringen av partene. Det innebærer at "kontrakten" mellom par av parter kan innbefatte forskjellige aspekter ved interaksjonen mellom parene av parter, innbefattende deres respektive ansvar, deres respektive tillatte operasjoner med data og retningslinjer for disse, samt de tillatte ordrer hva angår hvordan operasjoner kan sendes mellom respektive parter i paret. Dette innbefatter derfor at denne eneste spesifikasjon kan tjene som en generisk avtale som kan brukes på nytt i forbindelse med avtaler mellom hvilke som helst av parpartene i systemet.

Systemet ifølge den foreliggende oppfinnelse implementerer nevnte enkeltstående grensesnitt/protokollspesifikasjon for par av parter til en kommunikasjonskontrakt i det rettig-hetsbeskyttede objektorienterte grensesnittbeskrivelses-språk kjent som ELIN. Spesifikasjonen i et slikt språk, av typen likemannsprotokoller, som et eksempel, innbefatter følgende komponenter: 1) en formell gruppering av operasjoner i protokoller, idet hver protokoll omfatter to parter, og 2) en spesifikasjon av interaksjonsbegrensninger. Likemannsprotokollspesifikasjonen eksisterer atskilt fra de implementeringer som benytter protokollen til å utøve sine kommunikasjoner. Likemannsprotokollspesifikasjonen er orga-nisert i henhold til følgende format: 1) protokollnavn, 2) første parts navn og dennes aksepterte operasjonsliste, 3) andre parts navn og dennes aksepterte operasjonsliste, 4) interaksjonsbegrensninger (valgfritt).

I det følgende er det i kode fremsatt et eksempel på en protokollspesifikasjon for et par av parter med interaksjonsbegrensninger. Den informasjon som er innlemmet i en slik protokollspesifikasjon kan brukes til generering av stumpkode:

© 1992 Telefonaktiebolaget L M Ericsson

Logikkoppbygningen av en part som kommuniserer med systemet er også vist på figur 8. Slik det fremgår av figur 8, vil den spesialiserte terminologi og oppbygning som omfatter ELIN bli benyttet for å beskrive kommunikasjon mellom prosesser og prosessorer gjennom systemet, så vel som datatyper som blir benyttet i systemet. Til forskjell fra andre tidligere kjente systemer vil dette aspekt ved systemet ifølge den foreliggende oppfinnelse fremskaffe muligheten for å lokalisere all grensesnittinformasjon til bruk i hele systemet ved en enkeltstående ikke-direkte lokasjon. Videre vil de protokoller som blir benyttet og definert ved dette aspekt ifølge den foreliggende oppfinnelse, tillate at innretninger virker som likestilte, idet hvilken som helst part kan initiere kommunikasjon. Partene er ikke forhåndsdefinert som enten en hovedstasjon eller en slavestasjon for kommunikasjonsformål. Dette aspekt ved systemet ifølge den foreliggende oppfinnelse tillater systemer som blir utviklet og operert ved forskjellige og fjerntliggende plas-ser til lett å kunne inkorporeres, så lenge hver blir utviklet under bruken av de enkeltstående spesifiserte grensesnitt. Protokollspesifikasjonene ved dette aspekt ved systemet ifølge den foreliggende oppfinnelse er separate og forskjellige fra eventuell applikasjonsimplementering i systemet.

Slik det videre fremgår av figur 8, vil den brukerskrevne kode 200 virke som en part i kommunikasjonsprotokollen, som kan både sende og motta signaler, dersom signalene oppfyl-ler protokollspesifikasjonen. Datamottagningsverktøyene 206, 208 og 210 håndterer innkommende signaler som ankommer protokollen. Datasendeprosedyrene 212, 214, 216 omfatter kode som automatisk genereres av stumpgenereringsverktøyet for opprettelse og sending av signaler ut på systemet i henhold til protokollspesifikasjonen. Reaksjonene på mottagning av signalene 218 og på sending av signalene 220 blir alle dirigert via en grensesnittformidler 222, som ut-gjør en del av den genererte kode 202. Denne grensesnitt-spesif ikasjon 222 er den nødvendige del av den genererte kode 202 og må foreligge for at grensesnittet og protokol-

lene skal fungere riktig.

Tidsklareringsprogrammet ("dispatcher") 224 er en prosedyre som blir generert av stumpgenereringsverktøyet, og som blir anropt for hvert innkommende signal for denne spesielle implementering av spesifikasjon. Tidsklareringsprogrammet 224 mottar signalet, dekoder signalet, separerer signal-identifisereren fra hoveddelen av signalet, og distribuerer deretter dette som vist ved 226 til den prosedyre som skal skrives i denne implementering.

Protokollovervåkeren 228, som utgjør en valgbar del av den genererte kode 202 tjener til å overvåke trafikk og å bestemme hvorvidt de to kommuniserende parter på et hvilket som helst tidspunkt holder seg til grensesnittreglene ved sending eller mottagning av signaler. Protokollpolitiet 228 opererer som en statusmaskin hva angår å overvåke lydighe-ten overfor protokollreglene. Logikken ved tilstandsmaski-nen er uttrykt ved den tidligere fremskaffede eksempelkode.

I kjernekoden 204, slik dette er vist på figur 8, er det innlemmet en kommunikasjonsport 230. Denne kommunikasjonsport 230 blir betraktet av adresseringsmekanismen i systemet ifølge den foreliggende oppfinnelse, som et passivt støtteorgan. Kommunikasjonsporten 230 er ikke klar over den protokoll som blir ført gjennom den, men tjener til å gjøre kommunikasjon lettere. Kommunikasjonsstøtten 232 er den ge-nerelle kommunikasjonsstøtte som eksisterer i operasjonssystemet. Det kan operere mellom prosesser i den samme prosessor eller mellom prosesser i forskjellige prosessorer. Dersom det opererer mellom prosessorer, vil kommunikasjons-støtten 232 utgjøre en maskinvarekommunikasjonslink. Speil-avbildningen av hele den illustrasjon som er i figur 8, ville representere de motsvarende aktiviteter som opptrer i støtten og operasjon av en andre kommuniserende part i systemet .

Slik det er blitt anskueliggjort tidligere, gjør det foreliggende system det mulig for spesifikasjonen av felles protokoller eller grensesnitt, til gjennomgående bruk i et datamaskin- eller dataprosesseringssystem, å bli generert og lagret ved en enkeltstående ikke-direkte lokasjon. Det vil dessuten under bruk av spesialisert terminologi og konstruksjoner som tillater at spesifikasjonene lett og generisk kan formuleres og opprettes på en språkuavhengig måte. En slik løsningstanke øker ikke bare enkeltheten ved bruk, men også modulariteten og utvidbarheten ved det system som omfatter disse aspekter ifølge den foreliggende oppfinnelse. Videre vil systemet ifølge den foreliggende oppfinnelse tillate at spesifikasjonene kan klones for spesifikke implementeringer og til å bli brukt av visse stump-genereringsverktøyer for opprettelse av språkspesifikke implementeringer. De felles grensesnittspesifikasjoner ifølge den foreliggende oppfinnelse kan dessuten benyttes for å utføre dynamisk binding av programvaremoduler og driftstidsendring av programvare ved at det fremskaffes pe-kerinformasjon som har relasjon til publiserte eller akses-serbare grensesnitt og programvaremoduler.

Det er å forstå at virkemåten og oppbygningen av den foreliggende oppfinnelse er tilkjennegitt fra den foregående beskrivelse. Idet fremgangsmåten, apparatet og systemet som er vist og beskrevet, er tilkjennegitt som foretrukket, så skal det uten videre være klart at forskjellige endringer og modifikasjoner kan utføres uten at man avviker fra grunnidéen og omfanget av oppfinnelsen slik denne er definert i de vedføyde patentkrav.

Claims (24)

1. Fremgangsmåte for å generere og overvåke interaksjonen av et antall dynamisk varierende sett med programvaremoduler i et datamaskinsystem som har en eller flere prosessorer, hvori hver av nevnte programvaremoduler er i stand til interaktivt å fremskaffe og manipulere objekter som tilhø-rer en eller flere objektklasser, idet hver av nevnte objektklasser genereres automatisk fra en grensesnittspesifi-kasj on, karakterisert ved at fremgangsmåten omfatter følgende trinn: - å definere en datamaskinspråkuavhengig grensesnittspesifikasjon (172) til å regulere interaksjonen av nevnte antall programvaremoduler over en eller flere prosessorer ved hjelp av følgende trinn: - å tilveiebringe et unikt navn for nevnte grense snittspesifikasjon (172), - å tilveiebringe en liste over en eller flere forekomstvariabler som definerer karakteristikken for en objektklasse, - å tilveiebringe null eller flere interaksjons-variabler som spesifiserer den offentlige eller private interaksjon for en gruppe av nevnte objekter, og - å spesifisere begrensninger, hvis det finnes noen for interaksjonen av nevnte programvaremoduler, - å konvertere nevnte datamaskin språkuavhengige grense-snittspesif ikas j on (172) til en datamaskinspråkspesifikk grensesnittimplementasjon for et bestemt datamaskinsystem som bruker i det minste følgende informasjon: - et navn på en kommunikasjonsprotokoll som skal brukes i utvekslingen av data mellom nevnte programvaremoduler, - en identifikasjon av programvaremodulene som må utveksle data for interaktivt å fremskaffe og manipulere objekter, - et operasjonelt kommandosett for hver slik programvaremodul, og - begrensningene, hvis det er noen, for interaksjonen av nevnte programvaremoduler, - å fremskaffe et antall funksjonelle programvaremoduler som er i stand til interaktivt å kommunisere med hverandre ved å bruke nevnte datamaskinspråkspesifikke grensesnittimplementasjon, og - å eksekvere nevnte antall programvaremoduler på nevnte datamaskinsystem ved å bruke nevnte datamaskin programvare-spesifikke grensesnittimplementasjon for å kommunisere data mellom nevnte programvaremoduler.

2. Fremgangsmåte som angitt i krav 1, karakterisert ved at nevnte trinn vedrø-rende å definere nevnte datamaskinspråkuavhengige grense-snittspesif ikas j on (172) for å regulere interaksjonen av nevnte antall programvaremoduler over en eller flere prosessorer videre omfatter følgende trinn: - å tilveiebringe navnet på en foreldrespesifikasjon når nevnte grensesnittspesifikasjon er basert på nevnte foreldrespesifikasj on.

3. Fremgangsmåte som angitt i krav 1, karakterisert ved at nevnte trinn vedrø-rende å definere en datamaskinspråkuavhengige grensesnitt-spesif ikas j on (172) videre omfatter følgende trinn: - å gruppere operasjoner for nevnte grensesnittspesifikasjon i et antall toparts kommunikasjonsprotokoller, hver av nevnte toparts kommunikasjonsprotokoller spesifiserer kommunikasjonen mellom et par av programvaremoduler som er parter i en kommunikasjonskontrakt, og - å spesifisere begrensningene, hvis det finnes noen, for interaksjonen for hver av parene med programvaremoduler som er parter i nevnte kommunikasjonskontrakt.

4. Fremgangsmåte som angitt i krav 3, karakterisert ved at spesifikasjonen av hver av nevnte topartsprotokoller videre omfatter: - et navn på nevnte toparts kommunikasjonsprotokoll, navnet på en første programvaremodul, et operasjonelt kommandosett for nevnte første programvaremodul, navnet på en andre programvaremodul, et operasjonelt kommandosett for nevnte andre programvaremodul, og begrensningene, hvis det finnes noen, for interaksjonen av de to programvaremodulene som er parter i nevnte kommunikasjonskontrakt.

5. Fremgangsmåte som angitt i krav 1, karakterisert ved at nevnte trinn vedrø-rende å konvertere nevnte datamaskinspråkuavhengige grense-snittspesif ikas j on (172) til nevnte datamaskinspråkspesifikke grensesnittimplementasjon gjennomføres av et stubbko-degenereringsverktøy (stumpcode generation tool) (170) uavhengig om nevnte programvaremoduler er linket statisk eller dynamisk.

6. Fremgangsmåte som angitt i krav 1, karakterisert ved at de funksjonelle programvaremoduler fremskaffet fra nevnte grensesnittspesifikasjon (172) inneholder en grensesnittformidler (222).

7. Fremgangsmåte som angitt i krav 6, karakterisert ved at nevnte grensesnittformidler (222) i tillegg omfatter en dispatcher (224) som mottar et signal fra en kommunikasjonspart, omformer nevnte signal til en adresse og en melding, skiller nevnte adresse fra nevnte signal og distribuerer nevnte melding fra nevnte signal basert på nevnte adresse til en mottager programvaremodul .

8. Fremgangsmåte som angitt i krav 1, karakterisert ved at de funksjonelle programvaremoduler fremskaffet fra nevnte grensesnittspesifikasjon (172) i tillegg inneholder en protokollkontrollør (228) som fungerer som en tilstandsmaskin som kontrollerer om protokollreglene forhåndsdefinert i nevnte grensesnitt-spesif ikas j on overholdes.

9. Fremgangsmåte som angitt i krav 1, karakterisert ved at interaksjonen for par i nevnte programvaremoduler for å fremskaffe og manipulere objekter reguleres på en slik måte at en hvilken som helst av nevnte antall programvaremoduler har lov til å initiere eller respondere på kommunikasjon fra en hvilken som helst annen programvaremodul.

10. Fremgangsmåte som angitt i krav 1, karakterisert ved at interaksjonen for hvert par av nevnte programvaremoduler for å fremskaffe og manipulere objekter reguleres på en slik måte at bare ett av hvert par med programvaremoduler har lov til å initiere kommunikasjon med det andre, og den andre programvaremodulen har bare lov til å respondere for forespørsler fra den initierende programvaremodul.

11. Fremgangsmåte som angitt i krav 1, karakterisert ved at informasjonen om alle grensesnitt som har blitt implementert for programvaremoduler i nevnte datamaskinsystem er lagret sentralt i en formidlermodul (120) som er en del av kjernen (122) i ope-ras j onssystemet i nevnte datamaskinsystem.

12. Fremgangsmåte som angitt i krav 1, karakterisert ved at nevnte datamaskinsystem er et distribuert eller modulært datamaskinsystem av typen som vanligvis brukes i telekommunikasjonsomgivelser.

13. System for å generere og monitorere interaksjonen av et antall dynamisk varierende sett med programvaremoduler i et datamaskinsystem som har en eller flere prosessorer, hvori hver av nevnte programvaremoduler er i stand til interaktivt å fremskaffe og manipulere objekter som hører til et eller flere objektklasser, hver av nevnte objektklasser genereres automatisk fra en grensesnittspesifikasjon, karakterisert ved: - midler for å definere en datamaskinspråkuavhengig grense-snittspesif ikas j on (172) for å regulere interaksjonen av nevnte antall programvaremoduler over en eller flere prosessorer ved hjelp av følgende trinn: - å tilveiebringe et unikt navn for nevnte grense-snittspesif ikas j on (172), - å tilveiebringe en liste over en eller flere forekomstvariabler som definerer karakteristikken i en obj ektklasse, - å tilveiebringe null eller flere interaksjons-variabler som spesifiserer den offentlige eller private interaksjon for en gruppe av nevnte objekter, og - å spesifisere begrensninger, hvis det finnes noen, for interaksjonen av nevnte programvaremoduler, - midler for å fremskaffe et antall funksjonelle programvaremoduler som er i stand til å interaktere eller kommunisere med hverandre ved å bruke nevnte datamaskinspråkspesifikke grensesnittimplementasjon, - midler for å eksekvere nevnte antall programvaremoduler på nevnte kommunikasjonssystem ved å bruke nevnte datamaskinspråkspesifikke grensesnittimplementasjon for å kommunisere data mellom nevnte programvaremoduler.

14. System som angitt i krav 13, karakterisert ved at nevnte midler for å definere datamaskinspråkuavhengig grensesnittspesifikasjon (172) for å regulere interaksjonen av nevnte antall programvaremoduler over en eller flere prosessorer omfatter: - midler for å tilveiebringe navnet på en foreldrespesifikasjon når nevnte grensesnittspesifikasjon er basert på nevnte foreldrespesifikasjon.

15. System som angitt i krav 13, karakterisert ved at nevnte midler for å definere en datamaskinspråkuavhengig grensesnittspesifikasjon (172) omfatter: - midler for å gruppere operasjonene i nevnte grensesnitt-spesif ikas j on (172) til et antall toparts kommunikasjonsprotokoller, hver av nevnte toparts kommunikasjonsprotokoller spesifiserer kommunikasjonen mellom et par med programvaremoduler som er parter i en kommunikasjonskontrakt, og - midler for å spesifisere begrensningene, hvis det finnes noen, for interaksjonen for hver av nevnte par med programvaremoduler som er parter i nevnte kommunikasjonskontrakt.

16. System som angitt i krav 15, karakterisert ved at midlene for å spesifisere hver av nevnte toparts kommunikasjonsprotokoller omfatter : - midler for å tilveiebringe et navn for nevnte toparts kommunikasj onsprotokoll, - midler for å tilveiebringe navnet på en første programvaremodul , - midler for å tilveiebringe et operasjonelt kommandosett for nevnte første programvaremodul, - midler for å tilveiebringe navnet på en andre programvaremodul , - midler for å tilveiebringe et operasjonelt kommandosett for nevnte andre programvaremodul, og - midler for å spesifisere begrensningene, hvis det finnes noen, for interaksjonen i de to programvaremodulene som er parter i nevnte kommunikasjonskontrakt.

17. System som angitt i krav 13, karakterisert ved at nevnte midler for å konvertere nevnte datamaskinspråkuavhengige grensesnittspesifikasjon (172) til nevnte datamaskinspråkspesifikke gren-sesnittimplementas j on omfatter et delkodegenerasjonsverktøy (172) uavhengig av om nevnte programvaremoduler er linket statisk eller dynamisk.

18. System som angitt i krav 13, karakterisert ved at nevnte midler for å fremskaffe funksjonelle programvaremoduler fra nevnte gren-sesnittspesif ikas j on (172) omfatter en grensesnittformidler (222) .

19. System som angitt i krav 18, karakterisert ved at nevnte grensesnittformidler (222) i tillegg omfatter en dispatcher (224) som mottar et signal fra en kommunikasjonspart, omformer nevnte signal til en adresse og en melding, skiller nevnte adresse fra nevnte signal og distribuerer nevnte melding fra nevnte signal basert på nevnte adresse til en mottaksprogramvare-modul.

20. System som angitt i krav 13, karakterisert ved at nevnte midler for å fremskaffe funksjonelle programvaremoduler fra nevnte gren-sesnittspesif ikas j on (172) i tillegg inneholder en proto-kollkontrollør (228) som fungerer som en tilstandsmaskin som kontrollerer om protokollregler forhåndsdefinert i nevnte grensesnittspesifikasjon overholdes.

21. System som angitt i krav 13, karakterisert ved at nevnte midler for å definere nevnte datamaskinspråkuavhengig grensesnittspesifikasjon (172) tillater at et hvilket som helst av nevnte antall programvaremoduler initierer eller responderer på kommunikasjon fra en hvilken som helst annen programvaremodul.

22. System som angitt i krav 13, karakterisert ved at nevnte midler for å definere nevnte datamaskinspråkuavhengig grensesnittspesifikasjon (172) tillater bare et av hvert par med programvaremoduler å initiere kommunikasjon med den andre, og den andre programvaremodul tillates bare å respondere på fore-spørsler fra den initierende programvaremodul.

23. System som angitt i krav 13, karakterisert ved at den videre omfatter sentrale lagringsmidler i en formidlermodul (120) som er en del av kjernen (122) av operasjonssystemet i nevnte kommunikasjonssystem for å lagre informasjon om alle grensesnitt som har blitt implementert for programvaremodulene i nevnte datamaskinsystem.

24. System som angitt i krav 13, karakterisert ved at nevnte datamaskinsystem er et distribuert eller modulært datamaskinsystem av typen som vanligvis brukes i telekommunikasjonsomgivelser.