NO331943B1 - Tilgjengelighet og skalerbarhet i et meldingssystem pa en mate som er transparent for applikasjonen. - Google Patents

Abstract

Fremgangsmåter, systemer og dataprogramprodukter som tilveiebringer en meldingsformidlings-kjøreinfrastruktur som abstraherer sende- og mottaksoperasjoner for å utveksle meldinger med et partner-endepunkt. Meldingsformidlings-infrastrukturen øker tilgjengelighet og skalerbarhet i en meldingsapplikasjon ved å bedre tilgjengeligheten og skalerbarheten til de underliggende meldingstransportene. Spesielt forbedres tilgjengelighet og skalerbarhet ved å forbinde meldingsapplikasjonen under kjøring med et hvilket som helst antall meldingstransporter, uten at meldingsapplikasjonen spesifiserer en transport under utvikling/kompilering. Meldingsformidlings-infrastrukturen mottar instruksjoner fra meldingsapplikasjonen som spesifiserer ende-til-ende leveringsgarantier. Infrastrukturen anvender transporter for å oppfylle den spesifiserte leveringsgarantien og oppretter en link mellom meldingsapplikasjonen og transportene for anvendelse til utveksling av meldinger. Sesjonsstatuslagring kan opprettholdes i et pluggbart lager, som for eksempel kan være et persistent databaselager eller et applikasjonsminnelager.

Description

Foreliggende oppfinnelse vedrører generelt pålitelige meldingssystemer. Mer spesifikt tilveiebringer foreliggende oppfinnelse systemer, fremgangsmåter og dataprogramprodukter for å bedre tilgjengelighet og skalerbarhet for pålitelige meldingssystemer for kommunikasjon mellom to parter på en slik måte at forbedringene er transparente for applikasjonen.

Meldingssystemer blir stadig mer populære som middel for å kommunisere. Disse kommunikasjonssystemene spenner fra epost-systemer til sikrede transaksjoner, fra samtalerom til forskjellige web-tjenester så som Internett-shopping. Disse systemene og applikasjonene har vidt forskjellige krav vedrørende meldingsformid-lingens pålitelighet, sikkerhet, ytelse, tilgjengelighet og skalerbarhet. Eksisterende systemer tilbyr del-løsninger som adresserer spesifikke, begrensede kombinasjoner av de mer generelle kravene.

Tradisjonelle meldingssystemer fra tidligere teknikk tilbyr typisk begrenset fleksibilitet med hensyn til leveringsgarantier (f.eks. levering eksakt én gang), meldingsutvekslingsmodeller (f.eks. énveis kontra forespørsel/respons eller fullt toveis) og meldingsformidlingsgrensesnitt-funksjonalitet (f.eks. transaksjonsbasert bufring av meldinger). Hvert av disse meldingssystemene adresserer typisk et begrenset sett av skalerbarhets- og tilgjengelighetskrav, og tilbyr enten få muligheter til å utvide systemet for å øke den generelle skalerbarheten eller tilgjengeligheten, eller krever omfattende involvering av applikasjonene.

Betrakt for eksempel følgende kommunikasjonsmodeller for kommunikasjon mellom to parter. Datagram-baserte systemer tilbyr typisk enveis sesjonsløs utveksling av meldinger med send-avgårde-og-glem-pålitelighet, og gir liten direkte støtte for skalerbarhet og tilgjengelighet. Disse systemene gir utviklere maksimal frihet og fleksibilitet til å bygge alt selv.

TCP tilveiebringer full toveis sesjonsorientert kommunikasjon. Den har et mer omfattende, men fast sett av leveringsgarantier (levering av bit-oktetter eksakt én gang og i rekkefølge). Forbindelsens status opprettholdes i volatile, minnelagrede datastrukturer, og forbindelser er ute av stand til å overleve system- og prosessfeil og mange nettverksfeil, noe som begrenser tilgjengeligheten.

RPC tilveiebringer en semi-toveis utvekslingsmodell, idet noen systemer begrenser dette til enkeltvise forespørsel/respons-vekselvirkninger og noen tilveiebringer dialogsesjoner. I begge tilfeller blir endepunktsstatus typisk opprettholdt i minnet, og har således tilgjengelighetsbegrensninger tilsvarende TCP. Selv om de sesjons-løse forespørsel/respons-systemene noen ganger kan oppnå god skalerbarhet (for eksempel HTTP-baserte webfarmer), tilveiebringer disse typisk ikke "maks-én-gang"-behandling av forespørsler, noe som begrenser deres anvendbarhet for idempotente forespørsler. Sesjons baserte RPC-systemer kan tilveiebringe gjenforsøk av fore-spørsler med "maks-én-gang"-behandling, noe som til en viss grad øker tilgjengeligheten. I noen tilfeller er de underliggende transportforbindelsene styrt av kjøremiljøet, noe som muliggjør multipleksing med en viss økning av skalerbarheten.

Endelig tilveiebringer meldingskøingssystemer generelt semantikk for "eksakt-én-gang"-levering. I motsetning til datagram-, TCP- og RPC-modellene, påtvinger køer bufring mellom de to kommuniserende partene, hvilket muliggjør ytterligere ti I— koplbarhet og fleksibilitet for tidsplanlegging. Mange meldingskøingssystemer tilveiebringer persistent lagring av status, og tilveiebringer således ytterligere tilgjengelighet ved å tåle prosess- og systemfeil. Enkelte køingssystemer har også transaksjons-støtte, og denne modellen kan bedre påliteligheten og tilgjengeligheten ved automatisk å tilbakegjøre delvis utførte jobber og muliggjøre automatisk gjenforsøksproses-sering. Disse systemene påtvinger i alminnelighet begrensninger i valg av lagring, for eksempel ved å kreve anvendelse av en proprietær, persistent lagringsenhet, og har transportavhengigheter som begrenser nettverksstrukturen eller -konfigurasjonen.

Følgelig eksisterer det et behov for et meldingssystem som muliggjør økt fleksibilitet til å tilpasse applikasjoner til spesielle kjøreforhold og -krav, så lenge applikasjons-bemyndigede garantier er oppfylt. Videre eksisterer det et behov for et meldingssystem med den ovennevnte fleksibiliteten som kan bli anvendt for å tilpasse en applikasjons tilgjengelighet og skalerbarhet til behovene for en spesifikk anvendelse eller installasjon, på en måte som er transparent for applikasjonsprogrammet.

WO 00/41365 angår fremgangsmåter og systemer for å kontrollere dataflyt mellom en sender og en mottaker inkluderer kredittlister til senderen. Kredittlistene inkluderer kreditter indikative på mottakerbufferstørrelse som kan aksesseres av senderen og som er i stand til å motta data. Senderen transmitterer datapakker til mottakeren. Datapakkene er foretrukket ikke større i størrelse enn kredittene spesifisert i kredittlisten. Når senderen bruker alle kredittene, avstår foretrukket senderen fra å sende datapakker til mottakeren inntil tilførselen av kreditter er etterfylt av mottakeren. Fordi dataflyt mellom sender og mottaker er regulert ved bruk av kreditter, redu-seres sannsynligheten for dataoverflytfeil og kommunikasjonseffektivitet økes.

I et første aspekt tilveiebringer oppfinnelsen en fremgangsmåte, som utføres i en meldingsformidlings-kjøreinfrastruktur som abstraherer sende- og mottaksoperasjoner for å utveksle meldinger med et partner-endepunkt over én eller flere tilgjengelige meldingstransporter, for å bedre tilgjengeligheten og skalerbarheten til en meldingsapplikasjon ved å velge minst én av den ene eller de flere meldingstransportene å forbinde med meldingsapplikasjonen under kjøring, idet fremgangsmåten omfatter det å: motta én eller flere instruksjoner fra meldingsapplikasjonen som spesifiserer én eller flere ende-til-ende meldingsleveringsgarantier som skal benyttes til valg av minst én passende meldingstransport under kjøring, uten at meldingsapplikasjonen spesifiserer den minst ene passende meldingstransporten under utvikling/kompiler-ing, idet den ene eller de flere ende-til-ende meldingsleveringsgarantiene omfatter minst én av følgende: levering av meldinger minst én gang, levering av meldinger maksimalt én gang, levering av meldinger i den rekkefølgen de ble sendt og sesjonens levetid,

velge den minst ene passende meldingstransporten fra den ene eller de flere tilgjengelige meldingstransportene for å oppfylle den ene eller de flere ende-til-ende meldingsleveringsgarantiene spesifisert i den ene eller de flere instruksjonene mottatt fra meldingsapplikasjonen, og

opprette en forbindelse i meldingsformidlings-infrastrukturen mellom meldingsapplikasjonen og den valgte minst ene passende meldingstransporten for å utveksle meldinger mellom meldingsapplikasjonen og partner-endepunktet.

I et andre aspekt tilveiebringer oppfinnelsen et dataprogramprodukt, i en meldingsformidlings-kjøreinfrastruktur som abstraherer sende- og mottaksoperasjoner for å utveksle meldinger med et partner-endepunkt over én eller flere tilgjengelige meldingstransporter, som omfatter ett eller flere datamaskinlesbare medier som bærer datamaskin-eksekverbare instruksjoner som implementerer en fremgangsmåte for å bedre tilgjengeligheten og skalerbarheten til en meldingsapplikasjon ved å velge minst én av den ene eller de flere meldingstransportene å forbinde med meldingsapplikasjonen under kjøring, idet fremgangsmåten omfatter det å: motta én eller flere instruksjoner fra meldingsapplikasjonen som spesifiserer én eller flere ende-til-ende meldingsleveringsgarantier som skal benyttes til valg av minst én passende meldingstransport under kjøring, uten at meldingsapplikasjonen spesifiserer den minst ene passende meldingstransporten under utvikling/kompiler-ing, idet den ene eller de flere ende-til-ende meldingsleveringsgarantiene omfatter minst én av følgende: levering av meldinger minst én gang, levering av meldinger maksimalt én gang, levering av meldinger i den rekkefølgen de ble sendt og sesjonens levetid,

velge den minst ene passende meldingstransporten fra den ene eller de flere tilgjengelige meldingstransportene for å oppfylle den ene eller de flere ende-til-ende meldingsleveringsgarantiene spesifisert i den ene eller de flere instruksjonene mottatt fra meldingsapplikasjonen, og

opprette en forbindelse i meldingsformidlings-infrastrukturen mellom meldingsapplikasjonen og den valgte minst ene passende meldingstransporten for å utveksle meldinger mellom meldingsapplikasjonen og partner-endepunktet.

I et tredje aspekt tilveiebringer oppfinnelsen en fremgangsmåte, som utføres i en meldingsformidlings-kjøreinfrastruktur som abstraherer sende- og mottaksoperasjoner for å utveksle meldinger med et partner-endepunkt over én eller flere meldingstransporter, for å bedre tilgjengelighet og skalerbarhet i en meldingsapplikasjon ved å velge minst én av den ene eller de flere meldingstransportene å forbinde med meldingsapplikasjonen under kjøring, idet fremgangsmåten omfatter de trinn å: bestemme under kjøring minst én passende transport, uten at meldingsapplikasjonen spesifiserer den minst ene passende transporten under utvikling/kompiler-ing, blant den ene eller de flere transportene, som oppfyller én eller flere ende-til-ende leveringsgarantier spesifisert av meldingsapplikasjonen, idet den ene eller de flere ende-til-ende transportgarantiene omfatter minst én av: levering minst én gang, levering maksimalt én gang, levering i rekkefølge og sesjonens levetid, og

forbinde meldingsapplikasjonen og den bestemte minst ene passende transporten for å utveksle meldinger mellom meldingsapplikasjonen og partner-endepunktet.

I et fjerde aspekt tilveiebringer oppfinnelsen et dataprogramprodukt, i en meldingsformidlings-kjøreinfrastruktur som abstraherer sende- og mottaksoperasjoner for å utveksle meldinger med et partner-endepunkt over én eller flere transporter, som omfatter én eller flere datamaskinlesbare medier som bærer datamaskin-eksekverbare instruksjoner som implementerer en fremgangsmåte for å bedre tilgjengelighet og skalerbarhet i en meldingsapplikasjon ved å velge minst én av den ene eller de flere meldingstransportene å forbinde med meldingsapplikasjonen under kjøring, idet fremgangsmåten omfatter de trinn å: bestemme under kjøring minst én passende transport, uten at meldingsapplikasjonen spesifiserer den minst ene passende transporten under utvikling/kompiler-ing, blant den ene eller de flere transportene, som oppfyller én eller flere ende-til-ende leveringsgarantier spesifisert av meldingsapplikasjonen, idet den ene eller de flere ende-til-ende leveringsgarantiene omfatter minst én av: levering minst én gang, levering maksimalt én gang, levering i rekkefølge og sesjonens levetid, og

forbinde meldingsapplikasjonen og den bestemte minst ene passende transporten for å utveksle meldinger mellom meldingsapplikasjonen og partner-endepunktet.

I et femte aspekt tilveiebringer oppfinnelsen et dataprogramprodukt, for en meldingsformidlings-kjøreinfrastruktur som abstraherer sesjonsstatuslagring og sende- og mottaksoperasjoner for å utveksle meldinger med et partner-endepunkt over én eller flere meldingstransporter, som omfatter ett eller flere datamaskinlesbare medier som inneholder datamaskin-eksekverbare instruksjoner som implementerer en fremgangsmåte for å bedre tilgjengelighet og skalerbarhet i en meldingsapplikasjon ved å velge minst én av den ene eller de flere meldingstransportene å forbinde med meldingsapplikasjonen under kjøring, idet fremgangsmåten omfatter det å: motta én eller flere instruksjoner fra meldingsapplikasjonen som spesifiserer sesjonsstatuslagring, idet sesjonsstatusen holdes i et pluggbart lager som omfatter minst ett av et daemon-prosesslager, et persistent databaselager og et applikasjonslager,

motta én eller flere instruksjoner fra meldingsapplikasjonen som spesifiserer én eller flere ende-til-ende leveringsgarantier som skal benyttes til valg av minst én passende meldingstransport under kjøring, uten at meldingsapplikasjonen spesifiserer den minst ene passende meldingstransporten under utvikling/kompilering, idet den ene eller de flere ende-til-ende leveringsgarantiene omfatter minst én av følgende: levering av meldinger minst én gang, levering av meldinger maksimalt én gang, levering av meldinger i den rekkefølgen de ble sendt og sesjonens levetid,

velge minst én passende meldingstransport fra den ene eller de flere tilgjengelige meldingstransportene for å oppfylle den ene eller de flere ende-til-ende meldingsleveringsgarantiene spesifisert i instruksjonene mottatt fra meldingsapplikasjonen, og

opprette en forbindelse i meldingsformidlings-infrastrukturen mellom meldingsapplikasjonen og den valgte minst ene transporten for bruk til å utveksle meldinger mellom meldingsapplikasjonen og partner-endepunktet.

I henhold til eksempler på utførelsesformer av foreliggende oppfinnelse over-vinnes de ovenfor identifiserte mangler og ulemper ved dagens meldingssystemer. For eksempel tilveiebringer utførelseseksempler en kjøreinfrastruktur for meldingsformidling som abstraherer sende- og mottaksoperasjoner for å utveksle meldinger med et partner-endepunkt over et antall meldingstransporter. Foreliggende oppfinnelse bedrer tilgjengelighet og skalerbarhet i en meldingsapplikasjon ved å forbedre tilgjengeligheten og skalerbarheten til den underliggende meldingstransporten. For eksempel forbedres tilgjengeligheten ved å maskere mange feil, tilveiebringe støtte for persistent opprettholdelse av status, støtte for klynger, tjeneste-redundans, konfigurerbare tidsavbrudd og konfigurerbare bufferstørrelser, alt usynlig for applikasjonen. Skalerbarhet oppnås ved konfigurerbare bufferstørrelser og duplisering av tjenester, f.eks. tjenestefarmer.

Spesielt forbedres tilgjengeligheten og skalerbarheten ved å velge én av meldingstransportene å forbinde med meldingsapplikasjonen under kjøring. En meldingsformidlings-infrastruktur ifølge foreliggende oppfinnelse mottar instruksjoner fra meldingsapplikasjonen som spesifiserer ende-til-ende meldingsleveringsgarantier, så som levering av meldinger minst én gang, levering av meldinger maksimalt én gang, levering av meldinger i den rekkefølgen de ble sendt og en sesjonslevetid. De valgte garantiene anvendes ved valg av en passende meldingstransport under kjøring, uten at meldingsapplikasjonen spesifiserer den passende transporten under utvikling/kompilering. Infrastrukturen velger minst én transport som oppfyller ende-til-ende meldingsleveringsgarantiene, og oppretter en forbindelse mellom meldingsapplikasjonen og den valgte transporten for bruk ved utveksling av meldinger mellom meldingsapplikasjonen og partner-endepunktet.

I henhold til andre eksempler på utførelsesformer av foreliggende oppfinnelse, kan infrastrukturen motta instruksjoner fra meldingsapplikasjonen som spesifiserer lokale meldingspålitelighetstrekk, så som lagring av en sesjonsstatus, en meldings levetid og transaksjonsbasert bufring av meldinger. Det lokale meldingspålitelighetstrekket med lagring av en sesjonsstatus kan være opprettholdt i et pluggbart lager, som for eksempel kan være et daemonprosess-lager, et persistent databaselager eller et applikasjonsminnelager. Valget av lagringsenhet definerer sesjonstatusens persistens, som gir mulighet for gjenoppretting fra forskjellige former for feil (f.eks. applikasjonskrasj, nodekrasj etc), som i sin tur gir økt tilgjengelighet. Tilsvarende kan et diskbasert lager være i stand til å lagre flere meldinger enn et minnebasert lager, og således forbedre både skalerbarhet og tilgjengelighet.

Blant annet kan det lokale meldingspålitelighetstrekket også omfatte følgende: en bufferkvote som definerer det maksimale antall meldinger som vil bli bufret av meldingsformidlings-infrastrukturen, et send-tidsavbrudd som avblokkerer sende-operasjonen når send-tidsavbruddet utløper, et prioritetsvalg der meldinger med høy-ere prioritet blir sendt før meldinger med lavere prioritet, samt et konfigurerbart meld-ingskorrupsjonstrekk der antallet ganger en meldingsleveranse blir avbrutt er konfigurerbart for å avgjøre når meldingen må anses å være korrupt.

Ytterligere særtrekk og fordeler ved oppfinnelsen vil bli vist i beskrivelsen som følger, og vil delvis være åpenbare fra beskrivelsen eller kan læres gjennom praktisering av oppfinnelsen. Særtrekkene og fordelene ved oppfinnelsen kan realiseres og oppnås ved hjelp av de redskaper eller virkemidler og kombinasjoner som spesifikt er utpekt i patentkravene. Disse og andre særtrekk ved foreliggende oppfinnelse vil tydeliggjøres bedre av den følgende beskrivelsen og kravene, eller kan læres gjennom praktisering av oppfinnelsen som vist i det følgende.

For å beskrive hvordan de ovenfor angitte og andre fordeler og særtrekk ved oppfinnelsen kan oppnås, vil en mer detaljert beskrivelse av oppfinnelsen som kort beskrevet ovenfor bli gitt med henvisning til spesifikke utførelsesformer av denne som er illustrert i de vedlagte figurene. Idet man forstår at disse figurene kun viser typiske utførelsesformer av oppfinnelsen, og derfor ikke skal anses som begrensende for dens ramme, vil oppfinnelsen bli beskrevet og forklart mer spesifikt og detaljert ved hjelp av de vedlagte figurene, der: Figur 1 illustrerer stakker for pålitelig meldingsformidling i henhold til eksempler på utførelsesformer av foreliggende oppfinnelse, Figur 2 illustrerer en meldingsformidlingsstruktur i henhold til eksempler på ut-førelsesformer av foreliggende oppfinnelse, Figur 3 illustrerer en livssyklus for en forbindelse mellom en applikasjon og en transport i henhold til eksempler på utførelsesformer av foreliggende oppfinnelse, og Figur 4 illustrerer et eksempel på system som tilveiebringer et egnet driftsmiljø for foreliggende oppfinnelse.

Foreliggende oppfinnelse omfatter fremgangsmåter, systemer og datapro-gram produkter for å forenkle utvikling av applikasjoner for pålitelig meldingsformidling ved å tilveiebringe en enhetlig programmeringsmodell for å aksessere og anvende et antall forskjellige meldingstransporter under utvikling av én eller flere applikasjoner. Utførelsesformer av foreliggende oppfinnelse kan omfatte en spesialinnrettet eller generell datamaskin som omfatter forskjellig maskinvare, som beskrevet mer i detalj nedenfor.

Figur 1 illustrerer en høynivå representasjon av stakker 100a og 100b for pålitelig meldingsformidling. I en meldingsformidlingsstakk uten en pålitelig meldingsformidlingsprotokoll 125 ville applikasjonen 105, når den ønsker å sende en melding, f.eks. til et annet applikasjonslag 185, sende en melding eller en serie av meldinger 115 direkte til datagram-meldingslaget 140. (Merk at applikasjonen 105 kan være en hvilken som helst type applikasjon, så som for eksempel en tjeneste, og skal generelt være underforstått å omfatte et applikasjonsrammeverk.) Ettersom datagrammer ikke er pålitelige, vil meldingen(e) 115 kunne bli duplisert, forsinket og/eller kastet. For eksempel, i en mindre pålitelig datagram-protokoll med send-avgårde-og-glem pålitelighet, vil en eller flere meldinger 115 kunne bli kastet av en hvilken som helst grunn, foreksempel ved et mellomledd 135 mellom transporter 160 og 165. Følgelig ville applikasjonen 185 ved partner-endepunktet aldri motta meldingen(e) 115, og avsender-applikasjonen 105 ville ikke vite at meldingen(e) 115 ikke ble mottatt.

I henhold til eksempler på utførelsesformer av foreliggende oppfinnelse, er imidlertid de pålitelige meldingsformidlingsstakkene 100a og 100b tilveiebragt med en pålitelig meldingsformidlingsprotokoll 125. Følgelig kan for eksempel den pålitelige meldingsformidlingsstrukturen 120 (eller alternativt 180) sikre at meldingen(e) 115 sendt fra applikasjonen 105 ankommer korrekt ved sine destinerte endepunkter. Dersom for eksempel applikasjonen 105 ønsker å sende én eller flere meldinger 115 til applikasjonen 185, kan applikasjonen 105 sende (ved hjelp av funksjonen Send()) meldingen(e) 115 til den pålitelige meldingsformidlingsstrukturen 120, der de blir overdratt til sesjonen og gitt meldingssekvensnumre. En sesjonsidentifikator svarer til sesjonskommunikasjonen mellom applikasjonen 105 og applikasjonen 185. Med andre ord refererer en sesjon til toveis-konversasjonen mellom de to applikasjonene 105 og 185. Sekvensnummereringen svarer til den spesifikke meldingen innenfor sesjonskommunikasjonen. For eksempel kan det bli kommunisert flere meldinger innenfor én enkelt sesjon mellom de to applikasjonene 105 og 185, og hver melding blir nummerert sekvensielt i den rekkefølgen de sendes av applikasjonen. I tillegg kan det være etablert flere sesjoner mellom applikasjonene 105,185 og eventuelt andre applikasjoner (hver etablerte sesjon kan ha samme eller forskjellige leveringsgarantier). Følgelig ville hver melding bli tilordnet et sesjons- og et sekvensnummer som entydig identifiserer den konkrete sesjonen og sekvensrekkefølgen til meldingene innenfor sesjonen.

Etter skriving av en sesjons- og sekvensheader til en melding 191 og utførelse av annen nødvendig kanalprosessering, blir meldingen 191 lagret i sesjonsstatus 190 i et sendebuffer. Senere blir en kopi av meldingen 191 transportert ned gjennom datagram-meldingstjenesten 140, som letter ende-til-ende overføring av meldingen 191 ved for eksempel å legge inn rutingsheadere. Meldingen 191 blir deretter over-ført, muligens via ett eller flere mellomledd, f.eks. mellomleddet 135, som letter ende-til-ende overføring av meldingen 191 som en serie av punkt-til-punkt overføringer. En utvidbar meldingsoppsnappings-mekanisme kan bli anvendt for å implementere opp-førsel eller funksjonalitet så som ruting, filtrering, kriteriestyring og sikkerhet. Det bemerkes at transportene 145, 170, 155 og den funksjonaliteten som er tilgjengelig ved endepunkter i meldingsformidlende endepunkter og mellomledd 140, 175, 150 kan være etablert enten programmatisk eller gjennom konfigurering.

Dersom garantien om "minst-én-gang"-levering (beskrevet mer i detalj nedenfor) er spesifisert for applikasjonen 105, forventer den pålitelige meldingsformidlingsstrukturen 120 å motta kvitteringer fra den pålitelige meldingsformidlingsstrukturen 180 som angir hvilke meldinger som er korrekt mottatt. Meldingen 192 inneholder en bekreftelse av at meldingen 191 (f.eks. melding 5 i en sekvens) ble mottatt. Med jevne mellomrom, dersom en kvitteringsmelding 192 ikke mottas av den pålitelige meldingsformidlingsstrukturen 120, enten fordi en kopi ikke har blitt korrekt mottatt av den pålitelige meldingsformidlingsstrukturen 180 eller fordi ingen av kvitteringene fra 180 har blitt mottatt av 120, blir meldingen 191 sendt om igjen. Følgelig, dersom meldingen 191 ble kastet, forsinket eller feilsendt, foreksempel ved mellomleddet 135, fortsetter den pålitelige meldingsformidlingsstrukturen 120 (innenfor en tidsavbrudds-periode som er beskrevet senere) periodisk å sende meldingen 191 i et forsøk på å sikre at minst én kopi av meldingen 191 blir korrekt mottatt av den pålitelige meldingsformidlingsstrukturen 180. Det skal imidlertid bemerkes at av tilsvarende grunner som de beskrevet ovenfor med hensyn til meldingen 191, kvitteringen 192 vil kunne bli kastet, forsinket eller feilsendt. Som sådan tilveiebringer foreliggende oppfinnelse pålitelig levering av kvitteringsmeldingen 192 som beskrevet nedenfor.

Når den pålitelige meldingsformidlingsstrukturen 180 på korrekt måte mottar en kopi av meldingen 191, sender den kvitteringsmeldingen 192 til den pålitelige meldingsformidlingsstrukturen 120. Ved mottak av kvitteringsmeldingen 192, sletter den pålitelige meldingsformidlingsstrukturen 120 kopien av meldingen 191 fra sitt sesjonstatus(sende)-buffer 190 og sender den ikke flere ganger. Tilsvarende registre rer den pålitelige meldingsformidlingsstrukturen 180 i sin sesjonstatus 195 at den har mottatt en kopi av meldingen 191, slik at eventuelle duplikatmeldinger mottatt av den pålitelige meldingsformidlingsstrukturen 180 kan kastes, uavhengig av hvorvidt meldingene allerede har blitt levert til applikasjonen 185. Deretter kan applikasjonen 185 hente fra sesjonsstatus(mottaks)-bufferet 195 den mottatte meldingen ved hjelp av sin mottakskommando (Motta()). Dersom den pålitelige meldingsformidlingsstrukturen 120 ikke mottar kvitteringen 192 fordi den har blitt kastet, forsinket eller feilsendt, vil da gjensendingen av meldingen 191 fortsette, og med det forårsake at den pålitelige meldingsformidlingsstrukturen 180 sender en ny kopi av kvitteringen 192. Denne prosessen kan fortsette inntil minst én kvittering 192 er mottatt av den pålitelige meldingsformidlingsstrukturen 120 eller inntil den pålitelige meldingsformidlingsstrukturen 120 gir opp gjensendingsforsøkene og sender en feilangivelse til applikasjonen 105.

De pålitelige meldingsformidlingsstrukturene 120 og/eller 180 kan hver være innrettet som en dialog 200 (figur 2) i henhold til foreliggende oppfinnelse, og som beskrevet mer i detalj i forbindelse med figur 2. Dialog 200 er en abstraksjon av et meld-ingsrammeverk der tjenester (eller instanser av applikasjoner) anvender dialog 200 for pålitelig sesjonsorientert kommunikasjon med andre tjenester. Programmerere kan anvende en dialogkanal 220 for å aksessere dialoger. Videre tilveiebringer dialog 200 en pålitelig infrastruktur for formidling av meldinger og en enhetlig programmeringsmodell hvor meldingsleveringsgarantiene for applikasjonene er konfigurerbare. Disse pålitelighetsgarantiene må være oppfylt, ellers oppstår en sesjonsfeil. Designet av dialog 200 gir en motsvarende kjørende implementasjon fleksibilitet til å tilby ytterligere trekk eller funksjonalitet under forutsetning av at de garantiene (korrekthetsbe-tingelsene) som er lovet for applikasjonsimplementasjonen overholdes. Spesielt kan en applikasjon gis forskjellig grad av tilgjengelighet og skalerbarhet transparent for applikasjonsimplementasjonen. Videre kan disse sesjonskommunikasjonene mellom applikasjonene 105 og 185 være realisert over ulike transporttyper (f.eks. TCP/IP 160 og HTTP 165), transportforbindelsesinstanser og nettverkstopologier.

Pålitelighetsgarantiene tilveiebragt av dialog 200 omfatter levering minst-én-gang (ALO), maks-én-gang (AMO) og i-rekkefølge (IO). En ytterligere levetids(TTL)- garanti for en sesjon er også tilveiebragt. AMO-garantien garanterer at for en hvilken som helst gitt melding sendt av avsender-applikasjonen, meldingen vil bli levert til mottaker-applikasjonen maksimalt én gang. Ettersom dialog 200 er en abstraksjon, avlastes applikasjonen fra det å måtte detektere og forkaste duplikatmeldinger dersom duplikatmeldinger ville forstyrre applikasjonens semantikk. Tilsvarende sikrer ALO-garantien at alle meldinger sendt av avsender-applikasjonen blir mottatt av mottaker-endepunktet, noe som avlaster applikasjonene fra det å måtte detektere tapte eller feilsendte meldinger og koordinere gjensending av disse. IO-garantien sikrer at meldinger blir levert til mottaker-applikasjonen i den rekkefølgen de ble sendt av avsender-applikasjonen. Dette avlaster applikasjonen fra det å måtte håndtere meldinger som mottas i uordnet rekkefølge.

Dialog 200 tilveiebringer også en sesjonslevetidsgaranti som krever at dialogsesjonen mellom partner-endepunktene er avsluttet før sesjonslevetiden utløper. Dersom sesjonslevetiden utløper før dialogsesjonen er avsluttet, blir dialog-kanalene satt i en feiltilstand, og en varsling av feilen blir gitt til applikasjonene. Applikasjonene kan forlenge sesjonslevetiden gjennom reforhandling.

Dialoger gjør at disse meldingsleveringsgarantiene kan anvendes enten enk-eltvis eller i en hvilken som helst kombinasjon for å imøtekomme de spesifikke kravene fra en gitt applikasjon og anvendelse. For eksempel tilveiebringer kombinasjonen av de tre AMO-, ALO- og IO-garantiene den eksakt-én-gang, i-rekkefølge leveringen som er typisk forde fleste pålitelige kommunikasjonsmekanismer, så som TCP/IP. I motsetning til vanlige kommunikasjonsmekanismer og deres motsvarende programmeringsmodeller kan imidlertid disse garantiene bli tilpasset individuelt uten endring av den programmeringsmodellen som applikasjonen anvender.

Dialog 200 muliggjør ikke bare konfigurerbare garantier, men gjør også at lokale meldingspålitelighetstrekk kan bli valgt og konfigurert uavhengig av hverandre og uavhengig av de valgte garantiene. Disse lokale meldingspålitelighetstrekkene faller innunder to forskjellige kategorier: de som er integrert i programmeringsmodellen og de som vedrører brukertilpasning uavhengig av applikasjonsprogrammet. For eksempel kan integrerte lokale trekk omfatte: transaksjonsbasert bufring, som gir konsistens-, isolerings- og atomisitetsfunksjonalitet for applikasjonen, eller en profil- referanse, som assosierer en profil med en sesjon for å muliggjøre uavhengig til-pasning. Brukerdefinerbare lokale trekk kan omfatte: konfigurering av sesjonstatus-lagring, bufferkvoter, send-tidsavbrudd, konfigurerbar meldingslevetid, sesjonspriori-tetsmeldinger eller terskler for deteksjon av korrupte meldinger, som beskrevet nedenfor.

I henhold til eksempler på utførelsesformer av foreliggende oppfinnelse, tilveiebringer dialog 200 lagring av sesjonsstatus og meldinger som en utbyttelig kompo-nent kalt dialoglager 260. Ettersom dialoglager 260 er utbyttelig, kan tredjeparter uavhengig utvikle og distribuere implementasjoner av dialoglager 260. Systemansvarlige kan plukke ut og velge hvilke dialoglagre som faktisk blir anvendt i en gitt installasjon. Følgelig tilveiebringer denne mekanismen en enorm fleksibilitet til å oppnå mål ved-rørende persistens, ytelse, selvstyring og administrasjon. Dialoglager 260 kan være et pluggbart lager som har minst én av lagring i minne, persistent lagring på disk, lagring i en daemon-prosess, lagring i ikke-volatilt minne, lagring i optisk medium, lagring i magnetbånd, nettverkstilknyttet lagring, eller flyttbar lagring. Videre kan dialoglageret være eksternt eller fjernlokalisert.

I henhold til et eksempel på utførelsesform av foreliggende oppfinnelse, er en minnebasert realisering av et dialoglager (f.eks. dialoglager 260) tilveiebragt som holder all status i applikasjonsminnet. Dette lageret tilveiebringer veldig rask tilgang til status, imidlertid til den pris at all status går tapt dersom applikasjonens prosesskontekst tapes (f.eks. dersom applikasjonen blir terminert av brukeren eller blir terminert av operativsystemet, f.eks. som følge av en applikasjonsfeil, eller dersom systemet der applikasjonen kjører feiler).

I henhold til et annet eksempel på utførelsesform holder en realisering av et dialoglager (f.eks. dialoglager 260) statusen i minnet til en separat dedikert daemon-prosess. Dette dialoglageret sikrer at status overlever en applikasjonsprosessfeil, imidlertid til den pris at den må foreta prosesskontekst-skifter for å opprettholde statusen. Dersom daemon-prosessen feiler eller operativsystemet eller datamaskinen feiler, vil da all status for de sesjonene som den har ansvar for gå tapt.

I henhold til nok en annen utførelsesform av dialoglager-implementasjonen (f.eks. dialoglager 260), blir sesjonsstatus-informasjon opprettholdt på en persistent måte i en database, for eksempel en SQL (Structured Query Language)-tjener. Denne persistente statusen kan overleve datamaskin- eller operativsystemfeil, imidlertid til den pris at det må skrives til disk for å opprettholde status. Én fordel med å anvende et databasesystem så som en SQL-tjener for opprettholdelse av status er at installasjoner allerede vil kunne ha verktøy, teknikker og prosesser på plass for å ut-føre jevnlig oppbakking og gjenoppretting av viktig applikasjonsstatus.

Foreliggende oppfinnelse tillater også at enkelte dialoglagere kan være innrettet for å kjøre på den lokale datamaskinen, eller på en annen node. For eksempel kan et persistent dialoglager, så som en SQL-tjener, være konfigurert for å anvende en lokal tjenerdatabase eller en på en annen node. Den andre noden kan være del av et klyngesystem, og således ha meget høy tilgjengelighet.

Foreliggende oppfinnelse tillater også at flere lagre (eller lagerstrukturer) kan eksistere samtidig for å imøtekomme de spesifikke anvendelseskarakteristika for én eller flere applikasjoner. Videre kan en applikasjons konfigurasjon bli modifisert til å anvende forskjellige lagre (eller lagerstrukturer) for å tilpasse for endringer så som krav til økt belastning eller kapasitet, for å dra nytte av nye lagringsmuligheter eller for å adressere andre hensyn vedrørende anvendelsesmiljøet. Videre kan forskjellige kommunikasjonssesjoner innenfor samme applikasjon ha forskjellige krav til konfigurasjon. En dialog tillater individuell konfigurering av hver sesjon. For eksempel kan noen sesjoner innenfor en applikasjon fungere best med persistent lagring av status, mens andre sesjoner kan fungere best med volatil lagring av status. Et dialoglager kan konfigureres via en profil (beskrevet nedenfor) eller spesifiseres i applikasjonskode.

Et annet konfigurerbart trekk som tilbys av dialog 200 er en bufferkvote. Dialog 200 bufrer meldinger ved avsender- og mottaker-applikasjonene. Denne bufringen øker selvstyringsevnen til de to applikasjonene, og gjør det mulig for begge sider å sende eller motta meldinger til eller fra sine lokale bufre selv om den andre parten ikke kjører eller ikke kan nås, f.eks. som følge av en nettverkstilstand. For eksempel kan applikasjon 205 fortsette å sende meldinger selv om den andre parten er midlerti-dig utilgjengelig, dvs. ikke kjører eller ikke kan nås. Dette oppnås ved å akkumulere meldinger i det lokale sendebufferet 250 inntil de kan bli overført. Tilsvarende kan applikasjon 205 motta meldinger som har vært bufret i mottaksbufferet 245 selv om den applikasjonen som har sendt dem ikke kjører på det aktuelle tidspunktet. Dialog 200 tilveiebringer en konfigurerbar bufferkvote som definerer det maksimale antall meldinger (avhengig av meldingens størrelse) som vil bli bufret av systemet. Følgelig begrenser dette minneplassen som opptas av dialogstatus 235 og begrenser de lokale ressurser som kan bli konsumert av det andre endepunktet. Dette gjør også at meldingssystemet kan reservere tilstrekkelig plass til at applikasjonen kan bufre det spesifiserte antallet meldinger lokalt. Dialog 200 tilveiebringer også en minste bufferkvote som definerer et minste reservert antall meldinger som vil bli bufret av meldingsformidlings-infrastrukturen, som i kombinasjon med en maksimal meldings-størrelse definerer et minste antall bit-oktetter som vil bli bufret av meldingsformidlings-infrastrukturen. Bufferkvoten kan konfigureres via en profil (beskrevet nedenfor) eller spesifiseres i applikasjonskode.

Dialog 200 muliggjør også konfigurering av et send-tidsavbrudd. Når en melding sendes, blir den plassert i dialoglager 260 / sendebufferet 250. Dersom bufferet er fullt, dvs. dersom bufferkvoten er fylt, blir da kallet på send-metoden 210 blokkert inntil enten send-tidsavbruddet utløper eller det blir ledig plass til meldingen i bufferet. Plass frigjøres i bufferet når meldinger er overført til og kvittert for av mottaker-endepunktet og ikke lenger er nødvendige ved det lokale endepunktet for gjensending. Dersom plass blir tilgjengelig før send-tidsavbruddet utløper, fullfører send-metoden 210 normalt. Dersom send-tidsavbruddet utløper før det blir ledig plass, blir et unntak trigget som varsler applikasjonen om at meldingen ikke kunne bli bufret (opptatt). Følgelig kan applikasjonen forsøke igjen senere. Det konfigurerbare tidsavbruddet gjør det mulig for applikasjoner å velge graden av mottakelighet fremfor enkelheten ved blokkering. Send-tidsavbruddet kan konfigureres via en profil (beskrevet nedenfor) eller spesifiseres i applikasjonskode.

Som tidligere nevnt støtter dialog 200 en ende-til-ende sesjonslevetid-garanti. Dialog 200 tilveiebringer også en valgfri meldingslevetid som er konfigurerbar som et lokalt valg. Meldingslevetiden krever at sendte meldinger må være korrekt mottatt ved mottaker-endepunktet innenfor et tidsrom spesifisert i levetiden, ellers blir en feil sendt opp til applikasjon 205. Dialog 200 tilveiebringer også en konfigurerbar forleng- else av meldingslevetiden. Følgelig, når levetiden utløper, blir avsender-applikasjon 205 varslet. Applikasjon 205 kan da velge å terminere dialogen eller forlenge meldingens levetid. Tilsvarende som send-tidsavbrudd kan levetider settes av applikasjonskode eller konfigureres indirekte via en profil.

Et annet trekk som tilveiebringes av dialog 200 er tildeling av eventuelle prioriteter. Alle meldinger innenfor en dialog 200 har samme prioritet. Når meldinger fra

flere dialoger er tilgjengelige for overføring, gis imidlertid dialoger med høyere prioritet fortrinnsrett fremfor dialoger med lavere prioritet ved sending av meldingene. Tilsvarende, når meldinger er tilgjengelige for "levering" til mottaker-applikasjonen, blir meldinger med høyere prioritet mottatt før meldinger med lavere prioritet. Prioriteter kan settes av applikasjonskode eller indirekte ved anvendelse av profiler som beskrevet i nedenfor.

Dialog 200 tilveiebringer også eventuell transaksjonsbasert bufring av meldinger. Når en dialog blir anvendt med transaksjoner, tjener de lokale sende- og mot-taksbufrene som transaksjonsressursstyrere. I dette tilfellet blir meldinger mottatt under en transaksjon betraktet som foreløpig levert (slettet fra mottaksbufferet) med forbehold om transaksjonsresultatet. Tilsvarende blir meldinger sendt under en transaksjon foreløpig opptatt (lagt til i sendebufferet) med forbehold om transaksjonsresultatet. Dersom transaksjonen blir bekreftet, blir disse foreløpige meldingsopptakene og -leveransene gjort permanente. Dersom transaksjonen blir avbrutt, blir disse fore-løpige operasjonene tilbakegjort som om de aldri hadde forekommet. I likhet med andre transaksjonsressursstyrere er dialoglagrene ansvarlige for å tilveiebringe tran-saksjonsisolering for tentative bufringsoperasjoner (f.eks. er ikke opptatte meldinger synlige utenfor transaksjonen) og transaksjonsatomisitet med fullførelse av transaksjoner under styring av en transaksjonsstyrer.

Transaksjonsbufring letter utvikling av korrekt fungerende meldingsapplikasjo-ner (som f.eks. foretar korrekte tilstandsoverganger også ved feil eller samtidig aktivi-tet). Applikasjoner kan anvende dette trekket for å koordinere utveksling og lokal behandling av meldinger. For eksempel vil en applikasjon kunne motta og behandle en melding innenfor rammen av en transaksjon. Denne meldingsbehandlingen kan omfatte det å lese fra og oppdatere én eller flere transaksjonsdatabaser så vel som det å sende én eller flere meldinger gjennom dialoger omfattet i transaksjonen. Dersom transaksjonen avbrytes, blir hele jobben kansellert. Spesielt blir de meldingene som ble foreløpig sendt forkastet — dvs. at sesjonspartnere ikke vil se disse delresultat-ene — og den mottatte meldingen forblir tilgjengelig for levering. Dette siste gjør at meldingen kan bli prosessert innenfor rammen til en ny transaksjon. Når en transaksjon bekreftes, blir all denne aktiviteten gjort permanent, omfattende slettingen av den mottatte meldingen og bufringen av sendte meldinger. Resultatet er "eksakt-én-gang"-behandling av meldinger. Transaksjonsbufring er et lokalt trekk ved en dialog, i det at hvorvidt applikasjonen anvender denne funksjonaliteten eller ikke er helt transparent for dens sesjonspartner-applikasjoner.

I henhold til utførelseseksempler, og som beskrevet nedenfor med henvisning til figur 2, blir meldingen, ved avsender-endepunktet når sendefunksjonen 210 blir anropt, foreløpig plassert i dialoglager 260. Dersom transaksjonen bekreftes, blir meldingen bekreftet i lageret 260 og gjort tilgjengelig for overføring til partner-endepunktet. Dersom transaksjonen avbrytes, blir meldingen kastet. Ved mottakeren, når mottaks-funksjonen (Motta()) 215 (eller en slettingsfunksjon) blir anropt, blir meldingen forelø-pig slettet fra dialoglager 260. Dersom transaksjonen bekreftes, blir meldingen permanent slettet fra lageret 260. Dersom transaksjonen avbrytes, forblir meldingen i lageret 260 og er tilgjengelig for ny levering. Transaksjonsbasert mottak muliggjør "eksakt-én-gang"-behandling av meldinger.

Det skal bemerkes at selv om transaksjonsbasert bufring er vanlig i køingssys-temer, disse systemene i alminnelighet krever et persistent lager. Dialog 200 tilveiebringer denne samme transaksjonssemantikken uavhengig av persistensen til dialoglager 260, noe som gir samme programmodell i alle tilfeller. For eksempel tilveiebringer den minnebaserte lagringen transaksjonssemantikk ved å delta som en transak-sjonsressursstyrer. Dialog 200 gjør imidlertid at applikasjonsimplementasjonen kan isoleres fra anvendelsesdetaljene, omfattende detaljene vedrørende transport- og konnektivitetsegenskaper, ruting av meldinger og administrering av endepunktets status.

Et annet trekk tilveiebragt av dialog 200 er en valgfri funksjon for å håndtere korrupte meldinger. Som nevnt tidligere, når en melding mottas og behandles under en transaksjon og denne transaksjonen blir avbrutt, forblir meldingen i dialoglager 260 og er tilgjengelig for senere levering til applikasjonen. Noen ganger er problemet som forårsaker at transaksjonen blir avbrutt forbigående, f.eks. et tidsavbrudd som følge av "deadlock", og levering og behandling av meldingen lykkes i neste forsøk. Dersom forsøk på levering av en gitt melding forårsaker avbrudd gjentatte ganger, betraktes meldingen som "korrupt". Dialog 200 tilveiebringer en måte å konfigurere hvor mange ganger en meldingsleveranse kan bli avbrutt før meldingen blir betraktet som korrupt. Når en korrupt melding detekteres, blir en feil sendt opp til applikasjonen, og ytterligere forsøk på å behandle meldingen stanses inntil applikasjonen retter opp problemet. Dette sikrer at prosesseringsressurser ikke blir kastet bort på jobber som ikke er gjennomførbare eller som kun er gjennomførbare etter en intervensjon. Deteksjon av korrupte meldinger kan bli konfigurert via en profil (beskrevet nedenfor) eller være spesifisert i applikasjonskode.

Det valgfrie trekket med profiler tilveiebringer et navnet sett av konfigurerings-valg for en dialog. Som beskrevet ovenfor er det mange konfigurerbare trekk ved dialoger, så som bufferkvoter, tidsavbrudd, lagre, etc. Videre tilveiebringer dialog 200 konfigurerbare meldingsleveringsgarantier, f.eks. ALO, AMO og IO, slik at applika-sjonskoder uavhengig kan spesifisere et laveste nivå av ønsket leveringsgaranti som om ønsket kan økes gjennom konfigurering. En profil tilveiebringer en måte å grupp-ere vanlige dialog-innstillinger og referere til disse ved navn. Videre muliggjør implementasjonen av dialog 200 valg av profiler via applikasjonskonfigureringsfiler, slik at systemansvarlige har kontroll over innstillingene under bruk og installering. Når de oppretter eller aksepterer dialoger, referer applikasjoner til profilen ved navn, og alle innstillingene som er spesifisert i profilen blir anvendt ved opprettelse av dialog 200. Innstillingene kan være etablert direkte som del av et applikasjonsprogram, som kode, eller som andre programmeringskonstruksjoner. Profiler kan bli tilknyttet et pro-gram indirekte ved hjelp av referanser i kode eller andre programmeringskonstruksjoner, slik at profilverdier kan bli satt uavhengig av applikasjonsprogrammene. Profilverdier som er etablert direkte gjelder foran profilverdier satt indirekte via profil-referanser.

Ettersom dialog 200 støtter en hvilken som helst kombinasjon av disse trekkene og garantiene uavhengig av hverandre, kan dialog 200 bli konfigurert til å imøte-komme en hvilken som helst forbindelsesstruktur eller -konfigurasjon fra tett koplede programmeringsmodeller tilsvarende de til TCP (Transmission Control Protocol) og RPC (Remote Procedure Cali), til løst koplede programmeringsmodeller tilsvarende datagram og køer. I tillegg støtter dialog 200 de forskjellige punkt-til-punkt meldingsutvekslingsmodeller (MEP, message exchange pattern) så som énveis, semi-toveis (fra én enkelt forespørsel/respons til mer kompliserte modeller) og de mest kompliserte fullt toveis vekselvirkningene. Følgelig muliggjør dialog 200 forening av pro-grammeringsmodellene for kommunikasjon mellom to parter.

Figur 2 illustrerer de operasjonelle trekkene ved en dialog 200 i henhold til eksempler på utførelsesformer av foreliggende oppfinnelse. Et dialogkanal-API 220 er tilveiebragt som en abstraksjon av applikasjon 205. Som beskrevet tidligere anvender dialog 200 en meldingsformidlingsprotokoll, så som WS-RM (Web Services Reliable Messaging), som definerer en sekvens av meldinger. En sekvens definerer et enveis-rettet sett av meldinger i en sesjon. To slike sekvenser kombineres for å danne en dialog, én sekvens i hver retning mellom de to kommuniserende partene. Når kanalen 220 sin send-metode 210 anropes, blir meldingen, som sendes som parameter til send-metoden 210, lagret i sendstatus 250 og entydig merket med et monotont økende meldingssekvensnummer i henhold til den rekkefølgen i hvilken meldingen ble sendt.

Meldinger 255 blir bufret i sendstatus 250 for å opprettholde status for de indi-viduelle meldingene 255 i en sekvens. På dette tidspunktet sies meldingene å være "opptatt" i status 250 og send-metoden 210 returnerer til applikasjonen. Mer spesifikt tar send-metoden 210 én melding som parameter. Det er denne meldingen som blir sendt til sendebufferet 250 for å bli merket med et sekvensnummer og deretter eller samtidig plassert i lageret 260. Det er på dette tidspunktet som meldingen anses å være "opptatt", og send-metoden 210 returnerer. Gjentagelse av dette anropet med andre meldinger resulterer i en sekvens eller delsekvens av meldinger 255.

Dialogstatus 235 omfatter sende- og mottaksbufre henholdsvis 250 og 240. Dialogstatus 235 styrer og lagrer invariant informasjon så som dialog-identifikatoren, garantiene spesifisert av applikasjonen og partner-endepunktets adresse. Dialogstatus 235 styrer også sesjonsinformasjon så som neste utgående sendings sekvensnummer og kvitteringsstatus. Videre blir konfigurasjonsdata så som dialogens levetid, tidsavbrudd, lagerets lokasjon, etc. opprettholdt i dialogsesjonsstatus 235.

Når en melding er opptatt, kan da protokoll 270 behandle og sende den opptatte meldingen, f.eks. meldingen 275, gjennom en port 285. Programmeringsmodellen og kjøreinfrastrukturen for dialog 200 tilveiebringer en fleksibel og effektiv ende-punktsidentifiseringsmodell.

Modellen sikrer, som et minimum, at de to endepunktene er tilstrekkelig identi-fisert til at pålitelig utveksling av meldinger er mulig. Spesielt kan protokoll 270 sikre, før den leverer den første meldingen i en dialog til behandling, at begge endepunktene innehar en referanse som er tilstrekkelig til å garantere endepunktets entydighet og korrekt korrelasjon av meldinger gjennom dialog 200 og dens tilhørende sesjon. Dette er for eksempel nødvendig for å sikre at en melding blir pålitelig levert til én enkelt sesjonspartner, for å sikre "maks-én-gang"-levering. Denne endepunktsidentifi-seringen kan være basert på flere faktorer, omfattende en identifikator som identifiserer partner-applikasjonen (f.eks. en URI (Universal Resource Identificator)) anvendt av den som opprettet dialog 200, lokal konfigurasjon, rutingsdata i meldingsheadere, mellomledd-konfigurasjoner og mål-applikasjonens konfigurasjon.

Det er viktig å merke seg at applikasjonsimplementasjonen 205 ikke trenger å bry seg med detaljene ved identifisering av dialog-endepunkter. Infrastrukturen for dialog 200 utfører en identifiseringsprosess for å koordinere med det initierende endepunktet for å sikre at det er det entydig valgte peer-endepunktet for sesjonen. Dette gjøres som nødvendig og er transparent for applikasjons-

implementasjonen 205.

Identifiseringen av endepunkter for en dialog under kjøring kan også være ti I—

veiebragt for å sikre oppnåelse av meldingsleveringsmål, samtidig som det gis fleksibilitet til å oppnå korrekt eksekvering over et bredt spekter av nettverksstrukturer eller

-konfigurasjoner. Dette trekket støtter fleksibel anvendelse av applikasjoner i forskjellige konstellasjoner for å adressere krav til skalerbarhet, tilgjengelighet, sikkerhet (så som brannvegger) og ytelse. Arbeidskonstellasjoner omfatter for eksempel applika-

sjonsfarmer (f.eks. "oppskaleringsdupliseringer") og applikasjonsoppdelinger (f.eks. for å dele opp prosessering etter kundenummer eller geografisk område). Applika-sjonsfarmer og -oppdelinger kan anvendes separat eller sammen. For eksempel kan en applikasjon bli iverksatt for å anvende dataavhengig ruting til en applikasjonsopp-deling, som i sin tur er omfattet av en farm av applikasjonstjenere.

Protokoll 270 bestemmer også hva slags type ende-til-ende garanti og lokale

trekk som er spesifisert av applikasjon 205, uavhengig av fremgangsmåten for identifisering av endepunkter beskrevet ovenfor. Dersom applikasjon 205 spesifiserer ALO-garanti, beholder protokoll 270 en kopi av meldingen 275 i dialogens sendebuffer 250 til protokoll 270 mottar en positiv bekreftelse fra mottakeren (ikke vist) om at meldingen 275 er korrekt mottatt. Når protokoll 270 mottar en positiv bekreftelse fra mottakeren, registrerer den dette i sesjonsstatusen 235 og sletter meldingen fra sendebufferet 250. Dersom protokoll 270 ikke mottar en positiv bekreftelse i løpet av et spesifisert gjenforsøks-tidsavbrudd, sender protokollen en ny kopi av den samme meldingen 275 med samme meldingssekvensnummer. Dialog 200 kan gjenta denne prosessen et antall ganger, og kan anvende gjenforsøkstid-forlengelsesstrategier for å unngå ytterligere kødannelse i nettverket. Dersom en kvittering ikke mottas i løpet av tiden spesifisert av meldingens levetid, blir da en feilmelding sendt opp for å inform-ere avsender-applikasjon 205 om at garantien ikke kunne bli oppfylt.

Når det mottas en dialogmelding 280, kopierer protokoll 270 meldingen i mottaksbufferstatus 240. Protokoll 270 registrerer også det neste forventede meldingssekvensnummeret. Når en melding 280 mottas, dersom garantiene til dialog 200 omfatter AMO, blir meldingssekvensnummeret til den ankommende meldingen 280 sammenliknet med settet av meldingssekvensnummere som tidligere har ankommet, som som tidligere nevnt er lagret i mottaksbufferstatus 240. Dersom settet allerede inneholder et sammenfallende sekvensnummer, blir meldingen 280 betraktet som et dup-likat og kastet, ellers blir meldingen 280 plassert i det lokale mottaksbufferet 240 for fremtidig referanse.

Dersom garantiene omfatter ALO, sender da protokoll 270 en ikke-sekvensert komplett, selektiv positiv bekreftelse, ved mottak av meldingen 280, til partner-endepunktet for dialogen. Denne bekreftelsen må omfatte sekvensnumrene til alle meldinger som har blitt mottatt så langt i sesjonen. En forkortelse som omfatter et sett av sekvensintervaller kan anvendes for å spare meldingsplass.

Dersom de spesifiserte garantiene ikke omfatter IO, blir da meldingen 280 umiddelbart gjort tilgjengelig for "levering" til mottaker-applikasjon 205 gjennom mot-takskanalen 220. Spesielt blir det sendt et varsel til applikasjon 205 om at en melding er tilgjengelig for mottak. Applikasjon 205 kan da anrope mottak-metoden 215, hvorpå den neste meldingen tilgjengelig for levering blir sendt til applikasjon 205, og "levering" sies å skje.

Dersom IO-garantien er spesifisert, blir sekvensnummeret til den ankommende meldingen 280 sammenliknet med det neste forventede sekvensnummeret. Dersom sekvensnummeret er lavere enn det neste forventede sekvensnummeret, blir den ankommende meldingen 280 forkastet. Dersom de sammenfaller, blir den ankommende meldingen 280 umiddelbart gjort tilgjengelig for levering til mottaker-applikasjon 205, og det neste forventede sekvensnummeret blir satt til nummeret til den neste manglende meldingen. Dersom sekvensnummeret er høyere enn det neste forventede sekvensnummeret, avhenger da oppførselen av hvorvidt eller ikke ALO-garantien også er spesifisert. Dersom ALO-garantien ikke er spesifisert, blir da meldingen 280 umiddelbart gjort tilgjengelig for levering til mottaker-applikasjon 205, og det neste forventede sekvensnummeret blir satt til én høyere enn sekvensnummeret til den ankommende meldingen 280. Dersom ALO-garantien er spesifisert, blir ikke meldingen 280 gjort tilgjengelig for levering til mottaker-applikasjon 205, men forblir i mottaksbufferet 240. Følgelig, dersom de ikke sammenfaller, antas det at minst én annen melding med et lavere sekvensnummer enda ikke har blitt mottatt. Når alle slike manglende, lavere nummererte meldinger har ankommet, blir da det kontinuerlige intervallet av meldinger gjort tilgjengelig for levering til mottaker-applikasjonen i den korrekte sekvensen, og det neste forventede sekvensnummeret blir satt til nummeret til den neste manglende meldingen.

Som nevnt ovenfor, når meldinger er tilgjengelig for levering til mottaker-applikasjon 205, blir en varsling sendt til mottaker-applikasjon 205. Mottaker-applikasjonen kan da anrope mottak-metoden 215 på dialogkanalen 220 for å akseptere levering av den neste tilgjengelige meldingen. Mottak-metoden kan bli anropt flere ganger for å motta alle tilgjengelige meldinger etter tur. For å sikre en ordnet rekke-følge blir hendelsesvarslingene levert serielt. Følgelig, når en melding er tilgjengelig for levering til applikasjon 205, blir én enkelt hendelsesvarsling gitt applikasjon 205 ved å anrope applikasjonskode som tidligere har blitt registrert hos en hendelsesbe-handler i eller for dialog 200. Før dette kallet til applikasjonskoden returnerer, vil ingen andre kall til denne applikasjonskoden bli gjort selv om andre meldinger er/blir tilgjengelige for levering. I denne applikasjonskoden vil applikasjon 205 typisk anrope dialogens mottak-metode 215 for å oppnå den neste tilgjengelige meldingen.

Også som beskrevet ovenfor, når send-metoden 210 anropes, blir det antallet meldinger som befinner seg sendebufferet 250 sammenliknet med den spesifiserte bufferkvoten. Dersom dette antallet overstiger kvoten, blir den anropende send-metoden 210 blokkert på en hendelse enten til det blir ledig plass eller til send-tidsavbruddet har forløpt. Når plass blir ledig i sendebufferet 250, sjekker bufferet om det er noen som venter på å sende meldinger. I så fall avblokkerer send-metoden 210, og kan igjen sende meldinger.

Alle statuser for dialog 200 — inklusive de i meldingsbufrene 250 og 240, de i kanalen 220 og de i protokoll 270 — kan befinne seg i dialoglager 260 samtidig. Dialoglager 260 bør inneholde den mest oppdaterte informasjonen. Dette garanterer at dialogstatus 235 innehar persistensegenskapene til dialoglager 260 og gjør at alle funksjonstrekk kan fungere uavhengig av hva slags lager 260 som anvendes. For eksempel kan det å plassere en melding 280 i mottaksbufferet 240 involvere disk-skriving til lageret 260. For at garantiene skal være oppfylt, blir ikke kvitteringer sendt før etter at meldingen har blitt lagret i lageret 260. Dette sikrer for eksempel at enten avsenderen eller mottakeren alltid har en kopi av meldingen. Tilsvarende, på avsend- ersiden, vil send-metoden 210 ikke returnere før etter at meldingen er lagret i lageret 260.

Som tidligere nevnt kan dialoglager 260 være et pluggbart lager, noe som gir en veldig fleksibilitet til å imøtekomme mål vedrørende persistens, ytelse, selvstyring og administrasjon. For eksempel kan et lager 260 være valgt fra ett av flere lagre innenfor ett enkelt rammeverk, omfattende følgende: en minnebasert dialoglager-implementasjon som lagrer all status i applikasjonens minne; en dialoglager-implementasjon som lagrer status i minnet til en separat dedikert daemon-prosess; eller en persistent databaselager-implementasjon, så som en SQL-tjener. Forskjellige dialoger innenfor samme applikasjon 205 kan anvende forskjellige lagre. Videre tillater foreliggende oppfinnelse også at enkelte dialoglagere 260 kan være innrettet for å kjøre på den lokale datamaskinen eller på en annen node.

Fordi dialog 200 opptrer som en agent på vegne av applikasjon 205, er applikasjon 205 isolert fra endringer av konnektiviteten. Dette muliggjør for eksempel satsvis-type prosessering der en applikasjon starter, sender og mottar noen meldinger og deretter terminerer uten at den trenger å vente på at det andre endepunktet svarer eller blir tilgjengelig. Videre kan leveringen av meldinger bli planlagt på en meget fleksibel måte, kun betinget av at de forskjellige leveringsgarantier og lokale trekk, f.eks. meldingens eller sesjonens levetid, er oppfylt. Avhengig av leveringsgarantier kan for eksempel dialog 200 fordele store meldingsbelastninger over et gitt tidsrom (lastbalansering) eller på annen måte forsinke levering av meldinger til et mer beleilig tidspunkt, vente på at en ressurs skal bli tilgjengelig, ta hensyn til meldings-eller dialogprioritet, etc, uavhengig av applikasjon 205.1 tillegg gir lageret 260 mulighet for terminering og omstart av applikasjon 205. Mulighet for satsvis prosessering og tidsplanlegging, så vel som terminering og omstart av applikasjoner øker system-ets tilgjengelighet og skalerbarhet.

I tillegg, og som antydet ovenfor, kan applikasjon 205 spesifisere at sende-210 eller mottak- 215 operasjonene skal være transaksjonsbasert med hensyn til dia-logbufrene 250 og 240. Dette gjør det for eksempel mulig for applikasjonen å motta en melding, sende et antall meldinger gjennom én eller flere dialoger og oppdatere en applikasjonstabell, alt innenfor én enkelt transaksjon. I denne anvendelsen av transaksjoner er de kun en lokal egenskap, og overføres ikke til det andre endepunktet.

Dialog tilveiebringer også oppretting av feil under kjøring, som automatisk kan rette opp (maskere) mange feil 265 uten å berøre applikasjonsimplementasjonen. En applikasjon kan stole på å motta de lovede egenskaper (dvs. de lovede garantier og trekk) gjennom levetiden til dialog 200. Dersom infrastrukturen til dialog 200 eller protokoll 270 detekterer at de lovede egenskapene ikke lenger kan oppfylles, blir dialogen satt i en feiltilstand og en feil-hendelse blir aktivert, som muliggjør asynkron oppretting av feil uavhengig av normalflyten til applikasjonskoden eller til og med uavhengig av applikasjon 205. Dersom feilen 265 kan bli korrigert (opprettet), kan dialogen settes tilbake i bruk. Uopprettelige feil, dvs. feil som ikke kan korrigeres, kan resultere i terminering av dialog 200 og varsling av applikasjonen. Et slikt design føl-ger "fail-fast"-modellen, som er fundamental for utvikling av pålitelige applikasjoner.

Overlevbare feil kan omfatte følgende: korrupte, tapte, dupliserte eller forsinkede meldinger; transport- og nettverksfeil; prosesseringsfeil; feil i mellomledd og systemfeil. Som nevnt over, ettersom dialog 200 tilveiebringer en abstraksjon av applikasjonen og opprettholder sine egne bufre og lagre, støtter dialog 200 også applikasjoner og miljøer med tidvis konnektivitet. Dialoger kan også innrette seg etter endrende miljøer, så som endringer av nettverkstopologi, omforhandlede sikkerhetskontekster eller flytting av endepunkter.

Dialog 200 kan automatisk forsøke å rette opp disse feilene på egenhånd, for eksempel ved å sende en melding på nytt. Alternativt, eller i tillegg, kan dialog 200 sende en forespørsel til en tredjepart, f.eks. en systemoperatør eller diagnostiserende kode, og be om hjelp til å rette opp feilen. Denne hjelpen kan for eksempel være enkel menneske-intervensjon for å reparere en brutt forbindelse i et nettverk, eller muligens en automatisert reparasjonsprosess. I alle tilfeller kan dialog 200 fortsette å sende meldinger etter at feilen er utbedret. Disse, i kombinasjon med andre tilgjenge-lighetstrekk, muliggjør dialoger med lang levetid. Dersom imidlertid en feil ikke kan rettes opp av dialog 200 eller gjennom intervensjon fra en tredjepart, bør en feilmelding bli sendt opp til den applikasjon 205 som etablerte dialogen.

Applikasjoner kan bli konfigurert til å anvende dialoglagre 260 som muliggjør opprettholdelse av dialoger ved feil i og omstart av applikasjonsprosesser. Enkelte lagre 260 kan i tillegg overleve feil i og omstart av systemet.

Andre overføringsfeil kan bli håndtert automatisk av en kombinasjon av domene-spesifikke feilbehandlere og grunnleggende støtte for gjensending av meldinger som beskrevet ovenfor. Eksempler omfatter feil som er et resultat av at sikker-hetsakkreditiver eller -kriterier har utløpt. Dersom en melding sendt gjennom en sikret sesjon feiler som følge av utløp av et akkreditiv, kan dialog 200 reforhandle sikker-hetsakkreditivene og slette dialogfeilen. Når dialogprosesseringen fortsetter, vil de bufrede meldingene bli sendt på nytt med de oppdaterte akkreditivene ved hjelp av en standard gjenforsøksprosess.

Også som nevnt ovenfor, gjør designet av og den korresponderende infrastrukturen for dialog 200 det mulig for kjøremiljøet å dynamisk tilpasse en dialog 200 etter et endrende eksekveringsmiljø. Dette kan være tilveiebragt transparent for applikasjonsimplementasjonen og muliggjør lengelevende dialoger og meget tilgjengelige applikasjoner.

De ovenfor beskrevne kombinasjoner av feilbehandlere (som kan være pluggbare), gjenforsøk av overføring og levering og feil- og opprettingsmodellen gjør at dialoger kan tilpasse seg mange miljømessige endringer. Slike endringer omfatter, men er ikke begrenset til kriterieendringer (f.eks. meldingers fortrolighet), protokollendrin-ger (f.eks. støtte for nye sikkerhetsprotokoller), endringer i nettverkstopologien (f.eks. tillegging eller fjerning av rutere eller brannvegger), endringer av en installert applikasjon for å håndtere økt belastning (f.eks. introduksjon av en applikasjonsfarm og/eller -oppdeling) og flytting eller skifte av et dialog-endepunkt og assosiert status (f.eks. gjenoppretting etter sammenbrudd). Dette muliggjør også skalerbare installerings-valg, som omfatter støtte fra de veldig små til de veldig store. For eksempel støtter dialog 200 oppskalering, utskalering, duplisering eller oppdeling av applikasjoner, igjen transparent for applikasjonsimplementasjonen.

Figur 3 illustrerer livssyklusen og statusene eller tilstandene til dialog 200. Dialog 200 kan være i én av to hovedtilstander, aktiv 320 eller inaktiv 360. Dersom dialog 200 er aktiv 320, befinner dialogkanal-objektet 220 seg i minnet, ellers er dialog 200 inaktiv 360, og dialog 200 eksisterer kun i dialoglager 260. Styringen av systemres-surser foregår gjennom en deaktiveringsprosess 350 og en reaktiveringsprosess 340, som kan bli trigget manuelt eller automatisk. For eksempel kan deaktivering 350 fore-gå manuelt dersom applikasjonen anroper "Dispose", eller automatisk som følge av

en inaktiv periode, der det har gått en gitt tid uten at noen meldinger har blitt utvekslet over dialogkanalen. En slik kanal kan bli deaktivert (de motsvarende objektene slettet fra minnet), slik at minneressurser frigjøres for annen bruk.

Reaktivering 340 kan bli trigget manuelt dersom en applikasjon etterspør kanalen fra dialogstyreren (ikke vist), eller reaktivering 340 kan bli trigget automatisk dersom en ny melding ankommer for sesjonen. Hver dialog blir tildelt en unik identifikator av dialogstyreren under opprettelsen 310 av dialogen. Denne identifikatoren blir sendt av applikasjon 205 til dialogstyreren ved en forespørsel om reaktivering 340, og dialogstyreren anvender identifikatoren til å lokalisere dialogtilstanden og reinitiere kanalen. Grensesnittene for deaktivering 350 og reaktivering 340 gjør at systemet kan be-grense prosesseringsressursene assosiert med dialoger som ikke aktivt blir anvendt for å sende utgående meldinger eller behandle innkommende meldinger. Dette gjør at infrastrukturen kan ta tilbake relaterte ressurser bortsett fra de assosiert med dialoglager 260. Videre muliggjør dette designet fordeling av ressurser, omfattende: planlegging av meldingsoverføringer basert på prioritet eller tilgjengelighet av ressurser; gruppering av meldinger for mer effektiv overføring; planlegging av meldingsleveran-ser basert på prioritet eller tilgjengelighet av ressurser; og gruppering av meldings-leveranser for mer effektiv behandling.

Opprettelse 310 av en dialog er styrt av dialogstyreren og kan bli initiert av den applikasjonen som anroper opprettingsfunksjonen 310. Alternativt kan meldingssystemet initiere dialog-opprettelsen 310 etter mottak av en melding fra et annet endepunkt som angir behov for en ny dialog. I dette tilfellet varsler systemet applikasjon 205 om at det er bedt om en dialog. Applikasjon 205 kan da anrope en "Aksepter"-metode på dialogstyreren for å akseptere dialogforespørselen og forårsake opprettelse 310 av en dialog, eller den kan anrope en "Avvis"-metode på dialogstyreren for å avvise fore-spørselen. Dialogstyreren styrer også "Nedrivning"-metode 330, som kan bli initiert av en rekke mulige årsaker. Én årsak kan være at sesjonen fullfører med suksess, dvs. at begge sider er ferdige med å sende og det ikke gjenstår flere meldinger. En annen årsak til nedrivning 330 kan være at dialog 200 blir terminert, f.eks. ved at applikasjonen anroper en termineringsfunksjon eller ved at en angivelse av terminering blir mottatt fra partner-endepunktet. Når én side terminerer dialogen, blir en melding sendt til den andre siden for å angi dette. Ingen pålitelighet er tilveiebragt for denne meldingen, den er bare et forsøk på å fortelle den andre siden at dialogen har blitt terminert. Terminering impliserer at ingen ytterligere meldinger vil bli utvekslet over den aktuelle dialogsesjonen.

Selv om beskrivelsen av oppfinnelsen definerer dialogen som en toveis kom-munikasjonsmekanisme der applikasjonsmeldinger kan bli sendt og mottatt av begge sesjonens endepunkter, omfatter et annet utførelseseksempel en énveis-modell. I en slik utførelsesform vil ett sesjons-endepunkt kun sende applikasjonsmeldinger og ikke motta applikasjonsmeldinger fra sitt partner-endepunkt, og dette partner-endepunktet vil kun motta applikasjonsmeldinger og ikke sende applikasjonsmeldinger. De samme konfigurerbare garantier og konfigurerbare lokale endepunktstrekk gjelder som i dialogen. Implementasjonen endrer seg i det at det i avsender-endepunktet ikke er nød-vendig med et mottak-buffer 240 og at det i mottaker-endepunktet ikke er nødvendig med et sendebuffer 250.

Utførelsesformer innenfor rammen av foreliggende oppfinnelse omfatter også datamaskinlesbare medier for å bære eller inneholde datamaskin-eksekverbare instruksjoner eller datastrukturer lagret deri. Slike datamaskinlesbare medier kan være et hvilket som helst tilgjengelig medium som kan aksesseres av en generell eller spesialinnrettet datamaskin. Som eksempler, uten begrensning, kan slike datamaskinlesbare medier omfatte RAM, ROM, EEPROM, CD-ROM eller andre optiske lagre, magnetdisk-lagre eller andre magnetiske lagringsanordninger, eller et hvilket som helst annet medium som kan anvendes for å bære eller lagre ønskede programkodeinnretninger i form av datamaskin-eksekverbare instruksjoner eller datastrukturer og som kan aksesseres av en generell eller spesialinnrettet datamaskin. Når informasjon blir overført eller levert over et nettverk eller en annen kommunikasjonsforbindelse (enten kablet, trådløs eller en kombinasjon av kablet og trådløs) til en datamaskin, be-trakter datamaskinen på relevant måte forbindelsen som et datamaskinlesbart med ium. En hvilken som helst slik forbindelse kan således betegnes et datamaskinlesbart medium. Kombinasjoner av det ovennevnte er også omfattet innenfor rammen av datamaskinlesbare medier. Datamaskin-eksekverbare instruksjoner kan for eksempel omfatte instruksjoner og data som forårsaker at en generell datamaskin, en spesialinnrettet datamaskin eller en spesialinnrettet prosesseringsanordning utfører en gitt funksjon eller gruppe av funksjoner.

Figur 4 og den følgende beskrivelsen er ment for å gi en kort, generell beskrivelse av et egnet databehandlingsmiljø i hvilket oppfinnelsen kan bli implementert. Selv om det ikke er nødvendig, vil oppfinnelsen bli beskrevet i den generelle sam-menhengen datamaskin-eksekverbare instruksjoner, så som programmoduler, som blir eksekvert av datamaskiner i nettverksmiljøer. Generelt omfatter programmoduler rutiner, programmer, objekter, komponenter, datastrukturer, etc. som utfører spesifikke oppgaver eller implementerer spesifikke abstrakte datatyper. Datamaskin-eksekverbare instruksjoner, assosierte datastrukturer og programmoduler representerer eksempler på programkodeinnretningene for å utføre trinn i fremgangsmåtene beskrevet her. Den konkrete sekvensen av slike eksekverbare instruksjoner eller assosierte datastrukturer representerer eksempler på motsvarende handlinger for å utføre funksjonene beskrevet i disse trinnene.

Fagmannen vil forstå at oppfinnelsen kan praktiseres i nettverkede databehandlingsmiljøer med mange typer datasystemstrukturer, omfattende personlige datamaskiner, håndholdte anordninger, flerprosessorsystemer, mikroprosessorbasert eller programmerbar forbrukerelektronikk, personlige datamaskiner i nettverk, minidata-maskiner, stormaskiner og liknende. Oppfinnelsen kan også praktiseres i distribuerte databehandlingsmiljøer der oppgaver blir utført av lokale og eksterne prosesserings-anordninger som er forbundet (enten via kablede forbindelser, trådløse forbindelser eller en kombinasjon av kablede og trådløse forbindelser) gjennom et kommunika-sjonsnettverk. I et distribuert databehandlingsmiljø kan programmoduler befinne seg i både lokale og eksterne minnelagringsanordninger.

Som kan sees i figur 4, omfatter et eksempel på system for å implementere oppfinnelsen en generell databehandlingsanordning i form av en konvensjonell datamaskin 420 som omfatter en prosesseringsenhet 421, et systemminne 422 og en systembuss 423 som kopler forskjellige systemkomponenter inklusive systemminnet 422 til prosesseringsenheten 421. Systembussen 423 kan være en hvilken som helst av mange typer busstrukturer, omfattende en minnebuss eller minnekontroller, en ekstern buss og en lokal buss, som anvender en hvilken som helst av en rekke tilgjengelige bussarkitekturer. Systemminnet omfatter et leseminne (ROM) 424 og et direkteaksessminne (RAM) 425. Et BIOS (basic input/output system) 426 som inneholder de grunnleggende rutinene som hjelper til å overføre informasjon mellom ele-menter i datamaskinen 420, for eksempel under oppstart, kan være lagret i ROM 424.

Datamaskinen 420 kan også omfatte en harddiskstasjon 427 for å lese fra og skrive til en magnetisk harddisk 439, en magnetdisk-stasjon 428 for å lese fra eller

skrive til en flyttbar magnetdisk 429 og en optisk stasjon 430 for å lese fra eller skrive til en flyttbar optisk disk 431, så som et CD-ROM eller et annet optisk medium. Hard-diskstasjonen 427, magnetdisk-stasjonen 428 og den optiske stasjonen 430 er koplet til systembussen 423 henholdsvis via et harddiskstasjon-grensesnitt 432, et magnet-diskstasjon-grensesnitt 433 og et optisk stasjon-grensesnitt 434. Stasjonene og deres assosierte datamaskinlesbare medier tilveiebringer ikke-volatil lagring av datamaskin-eksekverbare instruksjoner, datastrukturer, programmoduler og andre data for datamaskinen 420. Selv om det eksemplifiserte miljøet som beskrives her omfatter en magnetisk harddisk 439, en flyttbar magnetisk disk 429 og en flyttbar optisk disk 431, kan andre typer datamaskinlesbare medier for å lagre data anvendes, inklusive mag-netkassetter, flashminnekort, DVD-plater, Bernoulli-patroner, RAM-minner, ROM-minner og liknende.

Programkodeinnretninger som omfatter én eller flere programmoduler kan være lagret i harddisken 439, magnetdisken 429, den optiske disken 431, ROM 424 eller RAM 425, inklusive et operativsystem 435, ett eller flere applikasjonsprogrammer 436, andre programmoduler 437 og programdata 438. En bruker kan mate inn kommandoer og informasjon til datamaskinen 420 via et tastatur 440, en pekeranord-ning 442 eller andre innmatingsanordninger (ikke vist), så som en mikrofon, en styre-spak, en spillkontroll, en parabolantenne, en skanner eller liknende. Disse og andre innmatingsanordninger er ofte koplet til prosesseringsenheten 421 via et serieport-grensesnitt 446 som er koplet til systembussen 423. Alternativt kan innmatingsanord- ningene være tilkoplet via andre grensesnitt, så som en parallellport, en spillutgang eller en universell seriell buss (USB-port). En monitor 447 eller en annen type frem-visningsanordning er også koplet til systembussen 423 via et grensesnitt, så som et skjermkort 448.1 tillegg til monitoren omfatter personlige datamaskiner typisk andre periferiske utmatingsanordninger (ikke vist), så som høyttalere og skrivere.

Datamaskinen 420 kan kjøre i et nettverket miljø som anvender logiske forbindelser til én eller flere fjerndatamaskiner, så som fjerndatamaskiner 449a og 449b. Fjerndatamaskinene 449a og 449b kan hver være en annen personlig datamaskin, en tjener, en ruter, en nettverks-PC, en peer-anordning eller en annen vanlig nettverks-node, og omfatter typisk mange av eller alle de elementene som er beskrevet ovenfor i forbindelse med datamaskinen 420, selv om kun minnelagringsanordninger 450a og 450b og deres assosierte applikasjonsprogrammer 436a og 436b er illustrert i figur 4. De logiske forbindelsene som er vist i figur 4 omfatter et lokalt nettverk (LAN) 451 og et regionalt nettverk (WAN) 452, som er vist her kun som eksempler og ikke begrensning. Slike nettverksmiljøer er vanlige i kontornettverk, bedriftsomspennende data-nettverk, intranett og Internett.

Når den blir anvendt i et LAN-nettverksmiljø, er datamaskinen 420 koplet til det lokale nettverket 451 via et nettverksgrensesnitt eller nettverkskort 453. Når den blir anvendt i et WAN-nettverksmiljø, kan datamaskinen 420 omfatte et modem 454, en trådløs forbindelse eller andre midler for å etablere kommunikasjon over det regionale nettverket 452, for eksempel Internett. Modemet 454, som kan være internt eller eksternt, er koplet til systembussen 423 via serieport-grensesnittet 446.1 et nettverksmiljø kan programmoduler som er vist i forbindelse med datamaskinen 420, eller deler av disse, være lagret i den eksterne minnelagringsanordningen. En vil forstå at de viste nettverksforbindelsene kun er eksempler, og at andre midler for å etablere kommunikasjon over det regionale nettverket 452 kan anvendes.

Foreliggende oppfinnelse kan realiseres i andre konkrete former uten at en fjerner seg fra dens idé eller essensielle særtrekk. De beskrevne utførelsesformene skal i alle henseende betraktes som kun illustrerende, og ikke begrensende. Oppfin-nelsens ramme defineres derfor av de etterfølgende kravene heller enn av den fore- gående beskrivelsen. Alle endringer som faller innenfor kravenes betydning og ekvi-valensramme skal være omfattet av disse.

Claims (69)

1. Fremgangsmåte, som utføres i en meldingsformidlings-kjøreinfrastruktur som abstraherer sende- og mottaksoperasjoner for å utveksle meldinger med et partner-endepunkt over én eller flere tilgjengelige meldingstransporter, for å bedre tilgjengeligheten og skalerbarheten til en meldingsapplikasjon ved å velge minst én av den ene eller de flere meldingstransportene å forbinde med meldingsapplikasjonen under kjøring, idet fremgangsmåten omfatter det å: motta én eller flere instruksjoner fra meldingsapplikasjonen som spesifiserer én eller flere ende-til-ende meldingsleveringsgarantier som skal benyttes til valg av minst én passende meldingstransport under kjøring, uten at meldingsapplikasjonen spesifiserer den minst ene passende meldingstransporten under utvikling/kompiler-ing, idet den ene eller de flere ende-til-ende meldingsleveringsgarantiene omfatter minst én av følgende: levering av meldinger minst én gang, levering av meldinger maksimalt én gang, levering av meldinger i den rekkefølgen de ble sendt og sesjonens levetid, velge den minst ene passende meldingstransporten fra den ene eller de flere tilgjengelige meldingstransportene for å oppfylle den ene eller de flere ende-til-ende meldingsleveringsgarantiene spesifisert i den ene eller de flere instruksjonene mottatt fra meldingsapplikasjonen, og opprette en forbindelse i meldingsformidlings-infrastrukturen mellom meldingsapplikasjonen og den valgte minst ene passende meldingstransporten for å utveksle meldinger mellom meldingsapplikasjonen og partner-endepunktet.

2. Fremgangsmåte ifølge krav 1, videre omfattende det å motta én eller flere instruksjoner fra meldingsapplikasjonen som spesifiserer én eller flere lokale meldingspålitelighetstrekk, der den ene eller de flere lokale meldingspålitelighetstrekkene omfatter minst én av følgende: en sesjonsstatuslagring, en meldingslevetid og transak-sjonbasert bufring av meldinger.

3. Fremgangsmåte ifølge krav 2, der sesjonsstatuslageret omfatter et pluggbart lager.

4. Fremgangsmåte ifølge krav 3, der det pluggbare lageret omfatter minst én av lagring i minne, persistent lagring på disk, lagring i en daemon-prosess, lagring i ikke-volatilt minne, lagring i optisk medium, magnetbånd, nettverkstilknyttet lagring eller flyttbar lagring.

5. Fremgangsmåte ifølge krav 4, der det pluggbare lageret omfatter et lager som er eksternt for meldingsformidlings-infrastrukturen.

6. Fremgangsmåte ifølge krav 2, der de lokale meldingspålitelighetstrekkene videre omfatter en maksimal bufferkvote som definerer et maksimalt antall meldinger som vil bli bufret av meldingsformidlings-infrastrukturen og som når den kombineres med en maksimal meldingstørrelse, definerer et maksimalt antall bit-oktetter som vil bli bufret av meldingsformidlings-infrastrukturen, en minste bufferkvote som definerer et minste reservert antall meldinger som vil bli bufret av meldingsformidlings-infrastrukturen og som når den kombineres med en maksimal meldingsstørrelse, definerer et minste antall bit-oktetter som vil bli bufret av meldingsformidlings-infrastrukturen, et send-tidsavbrudd som avblokker sende-operasjonen når det ut-løper, et prioritetsvalg der meldinger med høyere prioritet gis fortrinnsrett for overfør-ing og levering over meldinger med lavere prioritet, samt en konfigurerbar detektering av korrupte meldinger der et antall ganger en meldingsleveranse avbrytes kan konfigureres for å bestemme når meldingen ansees å være korrupt.

7. Fremgangsmåte ifølge krav 2, der det lokale meldingspålitelighetstrekket med transaksjonsbasert bufring av meldinger gjøres tilgjengelig uavhengig av sesjonsstatuslagringens persistens.

8. Fremgangsmåte ifølge krav 1, der forbindelsen som opprettes omfatter en kanal, et sesjonsstatusbuffer, en protokoll og et pluggbart lager.

9. Fremgangsmåte ifølge krav 8, der den ene eller de flere spesifiserte ende-til-ende leveringsgarantiene omfatter levering av en melding minst én gang, idet protokollen periodisk sender en kopi av en tidligere sendt melding til partner-endepunktet etter et gjenforsøksintervall inntil en kvittering mottas.

10. Fremgangsmåte ifølge krav 9, der den ene eller de flere spesifiserte ende-til-ende leveringsgarantiene videre omfatter en sesjonslevetid, og der, dersom det ikke mottas en kvittering i løpet av en spesifisert sesjonslevetid, ingen ytterligere gjenfor-søk gjøres og en feilangivelse leveres til meldingsapplikasjonen.

11. Fremgangsmåte ifølge krav 9, videre omfattende det å motta et lokalt meldingspålitelighetstrekk vedrørende en meldingslevetid, der, dersom det ikke mottas noen kvittering i løpet av en spesifisert meldingslevetid, ingen ytterligere gjenforsøk gjøres og en feilangivelse leveres til meldingsapplikasjonen.

12. Fremgangsmåte ifølge krav 9, der gjenforsøksintervallet justeres av et forleng-ningsintervall etter suksessive gjenforsøksintervaller.

13. Fremgangsmåte ifølge krav 8, der status for kanalen, sesjonsstatusbufrene og protokollen opprettholdes i det pluggbare lageret.

14. Fremgangsmåte ifølge krav 1, der den minst ene passende meldingstransporten omfatter minst én av følgende transporter: TCP/IP, UDP, HTTP, RPC og SMTP.

15. Fremgangsmåte ifølge krav 1, der utvekslingen av meldinger defineres av et antall meldingsutvekslingsmodeller, omfattende minst én av énveis meldingsformidling, forespørsel/respons-meldingsformidling og full toveis meldingsformidling.

16. Dataprogramprodukt, i en meldingsformidlings-kjøreinfrastruktur som abstraherer sende- og mottaksoperasjoner for å utveksle meldinger med et partner- endepunkt over én eller flere tilgjengelige meldingstransporter, som omfatter ett eller flere datamaskinlesbare medier som bærer datamaskin-eksekverbare instruksjoner som implementerer en fremgangsmåte for å bedre tilgjengeligheten og skalerbarheten til en meldingsapplikasjon ved å velge minst én av den ene eller de flere meldingstransportene å forbinde med meldingsapplikasjonen under kjøring, idet fremgangsmåten omfatter det å: motta én eller flere instruksjoner fra meldingsapplikasjonen som spesifiserer én eller flere ende-til-ende meldingsleveringsgarantier som skal benyttes til valg av minst én passende meldingstransport under kjøring, uten at meldingsapplikasjonen spesifiserer den minst ene passende meldingstransporten under utvikling/kompiler-ing, idet den ene eller de flere ende-til-ende meldingsleveringsgarantiene omfatter minst én av følgende: levering av meldinger minst én gang, levering av meldinger maksimalt én gang, levering av meldinger i den rekkefølgen de ble sendt og sesjonens levetid, velge den minst ene passende meldingstransporten fra den ene eller de flere tilgjengelige meldingstransportene for å oppfylle den ene eller de flere ende-til-ende meldingsleveringsgarantiene spesifisert i den ene eller de flere instruksjonene mottatt fra meldingsapplikasjonen, og opprette en forbindelse i meldingsformidlings-infrastrukturen mellom meldingsapplikasjonen og den valgte minst ene passende meldingstransporten for å utveksle meldinger mellom meldingsapplikasjonen og partner-endepunktet.

17. Dataprogramprodukt ifølge krav 16, der fremgangsmåten videre omfatter det å motta én eller flere instruksjoner fra meldingsapplikasjonen som spesifiserer én eller flere lokale meldingspålitelighetstrekk, og der den ene eller de flere lokale meldingspålitelighetstrekkene omfatter minst én av følgende: en sesjonsstatuslagring, en meldingslevetid og transaksjonsbasert bufring av meldinger.

18. Dataprogramprodukt ifølge krav 17, der sesjonsstatuslagringen omfatter et pluggbart lager.

19. Dataprogramprodukt ifølge krav 17, der de lokale meldingspålitelighetstrekkene videre omfatter en maksimal bufferkvote som definerer et maksimalt antall meldinger som vil bli bufret av meldingsformidlings-infrastrukturen og som når den kombineres med en maksimal meldingstørrelse, definerer et maksimalt antall bit-oktetter som vil bli bufret av meldingsformidlings-infrastrukturen, en minste bufferkvote som definerer et minste reservert antall meldinger som vil bli bufret av meldingsformidlings-infrastrukturen og som når den kombineres med en maksimal meldingsstørrelse, definerer et minste antall bit-oktetter som vil bli bufret av meldingsformidlings-infrastrukturen, et send-tidsavbrudd som avblokker sende-operasjonen når det utløper, et prioritetsvalg der meldinger med høyere prioritet gis fortrinnsrett for overføring og levering over meldinger med lavere prioritet, samt en konfigurerbar detektering av korrupte meldinger der et antall ganger en meldingsleveranse avbrytes kan konfigureres for å bestemme når meldingen ansees å være korrupt.

20. Dataprogramprodukt ifølge krav 19, der send-tidsavbruddet tillater sende-operasjonen bare dersom bufferkvoten angir at det er ledig plass før en forbestemt tidsavbrudd-periode har forløpt.

21. Dataprogramprodukt ifølge krav 17, der det lokale meldingspålitelighetstrekket med et transaksjonsbasert meldingsbuffer er tilgjengelig uavhengig av sesjonsstatus-lagerets persistens.

22. Dataprogramprodukt ifølge krav 16, der den opprettede forbindelsen omfatter en kanal, et sesjonsstatusbuffer, en protokoll og et pluggbart lager.

23. Dataprogramprodukt ifølge krav 22, der protokollen kopierer en mottatt melding til et mottaks buffer.

24. Dataprogramprodukt ifølge krav 23, der protokollen holder rede på et neste for-ventet meldingssekvensnummer.

25. Dataprogramprodukt ifølge krav 23, der, dersom en mottatt melding er et dupli-kat av en tidligere mottatt melding basert på en status opprettholdt av et sesjons-endepunkt, duplikatmeldingen blir forkastet.

26. Dataprogramprodukt ifølge krav 22, der den ene eller de flere spesifiserte ende-til-ende leveringsgarantiene omfatter levering av en melding minst én gang, og der protokollen periodisk sender en kopi av en tidligere sendt melding til partner-endepunktet etter et gjenforsøksintervall inntil en kvittering blir mottatt.

27. Dataprogramprodukt ifølge krav 26, der den ene eller de flere spesifiserte ende-til-ende leveringsgarantiene videre omfatter en sesjonslevetid, og der, dersom det ikke er mottatt noen kvittering i løpet av en spesifisert sesjonslevetid, ingen ytterligere gjenforsøk blir gjort og en feilangivelse blir levert til meldingsapplikasjonen.

28. Dataprogramprodukt ifølge krav 26, videre omfattende det å motta et lokalt meldingspålitelighetstrekk vedrørende en meldingslevetid, der, dersom det ikke er mottatt en kvittering i løpet av en spesifisert meldingslevetid, ingen ytterligere gjen-forsøk blir gjort og en feilangivelse blir levert til meldingsapplikasjonen.

29. Dataprogramprodukt ifølge krav 16, der fremgangsmåten videre omfatter det å planlegge overføring eller levering av minst én melding av en sekvens av meldinger til partner-endepunktet.

30. Dataprogramprodukt ifølge krav 29, der planleggingen er basert på minst én av konnektivitet, lastbalansering, meldingsprioritet og anvendelse av en mindre kostbar transport.

31. Dataprogramprodukt ifølge krav 22, der status for kanalen, sesjonsstatusbufrene og protokollen er opprettholdt i det pluggbare lageret.

32. Fremgangsmåte, som utføres i en meldingsformidlings-kjøreinfrastruktur som abstraherer sende- og mottaksoperasjoner for å utveksle meldinger med et partner-endepunkt over én eller flere meldingstransporter, for å bedre tilgjengelighet og skalerbarhet i en meldingsapplikasjon ved å velge minst én av den ene eller de flere meldingstransportene å forbinde med meldingsapplikasjonen under kjøring, idet fremgangsmåten omfatter de trinn å: bestemme under kjøring minst én passende transport, uten at meldingsapplikasjonen spesifiserer den minst ene passende transporten under utvikling/kompiler-ing, blant den ene eller de flere transportene, som oppfyller én eller flere ende-til-ende leveringsgarantier spesifisert av meldingsapplikasjonen, idet den ene eller de flere ende-til-ende transportgarantiene omfatter minst én av: levering minst én gang, levering maksimalt én gang, levering i rekkefølge og sesjonens levetid, og forbinde meldingsapplikasjonen og den bestemte minst ene passende transporten for å utveksle meldinger mellom meldingsapplikasjonen og partner-endepunktet.

33. Fremgangsmåte ifølge krav 32, videre omfattende det trinn å implementere ett eller flere lokale meldingspålitelighetstrekk, der det ene eller de flere lokale meldingspålitelighetstrekkene omfatter minst én av: sesjonsstatuslagring, en meldingslevetid og en transaksjonsbasert bufring av meldinger.

34. Fremgangsmåte ifølge krav 33, der sesjonsstatuslagringen holdes i et pluggbart lager som omfatter minst én av et daemon-prosesslager, et persistent databaselager og et applikasjonslager.

35. Fremgangsmåte ifølge krav 33, der de lokale meldingspålitelighetstrekkene videre omfatter en bufferkvote som definerer et maksimalt antall meldinger som vil bli bufret av meldingsformidlings-infrastrukturen, et send-tidsavbrudd som avblokker sende-operasjonen når send-tidsavbruddet utløper, et prioritetsvalg der meldinger med høyere prioritet sendes før meldinger med lavere prioritet, samt en konfigurerbar detektering av korrupte meldinger der et antall ganger en meldingsleveranse avbrytes kan konfigureres for å bestemme når meldingen ansees å være korrupt.

36. Fremgangsmåte ifølge krav 33, der det lokale meldingspålitelighetstrekket med transaksjonsstøtte gjøres tilgjengelig uavhengig av sesjonsstatuslagringens persistens.

37. Fremgangsmåte ifølge krav 32, der meldingsapplikasjonen og den bestemte minst ene passende transporten forbindes via en kanal, et sesjonsstatusbuffer, en protokoll og et pluggbart lager innenfor meldingsformidlings-infrastrukturen.

38. Fremgangsmåte ifølge krav 37, der kanalen er et applikasjonsprogrammer-ingsgrensesnitt som tilveiebringer en abstraksjon for sending og mottak av meldinger.

39. Fremgangsmåte ifølge krav 38, der sesjonsstatusbufrene omfatter et sendebuffer og entydig merker en melding med et monotont økende meldingssekvensnummer.

40. Fremgangsmåte ifølge krav 38, der sesjonsstatusbufrene omfatter et mottaks-buffer som holder på meldinger inntil de er levert til applikasjonen.

41. Fremgangsmåte ifølge krav 37, der den ene eller de flere spesifiserte ende-til-ende leveringsgarantiene omfatter "minst-én-gang"-levering av en melding og en sesjonslevetid, og der under sesjonslevetiden protokollen periodisk sender en kopi av en tidligere sendt melding til partner-endepunktet etter et gjenforsøksintervall inntil en kvitteringsmelding mottas.

42. Fremgangsmåte ifølge krav 37, der meldingsformidlings-infrastrukturen tilveiebringer minst én av deteksjon og håndtering av sesjons- eller meldingsfeil.

43. Fremgangsmåte ifølge krav 42, der håndteringen av meldingsfeil omfatter minst én av det å varsle feilen til en operasjonskode, varsle feilen til meldingsapplikasjonen, varsle feilen til én eller flere pluggbare feilbehandlere og varsle feilen til en operatørperson.

44. Fremgangsmåte ifølge krav 43, der de overlevbare feilene omfatter korrupte meldinger, tapte meldinger, dupliserte meldinger, forsinkede meldinger, meldinger som ankommer i feil rekkefølge, transportfeil, nettverksfeil, prosessfeil og systemfeil.

45. Fremgangsmåte ifølge krav 42, der meldingsformidlings-infrastrukturen varsles om at feilen er fikset og på nytt forsøker en operasjon som feilet.

46. Fremgangsmåte ifølge krav 37, der status for kanalen, sesjonsstatusbufrene og protokollen opprettholdes i det pluggbare lageret.

47. Dataprogramprodukt, i en meldingsformidlings-kjøreinfrastruktur som abstraherer sende- og mottaksoperasjoner for å utveksle meldinger med et partner-endepunkt over én eller flere transporter, som omfatter én eller flere datamaskinlesbare medier som bærer datamaskin-eksekverbare instruksjoner som implementerer en fremgangsmåte for å bedre tilgjengelighet og skalerbarhet i en meldingsapplikasjon ved å velge minst én av den ene eller de flere meldingstransportene å forbinde med meldingsapplikasjonen under kjøring, idet fremgangsmåten omfatter de trinn å: bestemme under kjøring minst én passende transport, uten at meldingsapplikasjonen spesifiserer den minst ene passende transporten under utvikling/kompiler-ing, blant den ene eller de flere transportene, som oppfyller én eller flere ende-til-ende leveringsgarantier spesifisert av meldingsapplikasjonen, idet den ene eller de flere ende-til-ende leveringsgarantiene omfatter minst én av: levering minst én gang, levering maksimalt én gang, levering i rekkefølge og sesjonens levetid, og forbinde meldingsapplikasjonen og den bestemte minst ene passende transporten for å utveksle meldinger mellom meldingsapplikasjonen og partner-endepunktet.

48. Dataprogramprodukt ifølge krav 47, videre omfattende det trinn å implementere ett eller flere lokale meldingspålitelighetstrekk, der det ene eller de flere lokale meldingspålitelighetstrekkene omfatter minst én av: sesjonsstatuslagring, en meldingslevetid og en transaksjonsbasert bufring av meldinger.

49. Dataprogramprodukt ifølge krav 48, der sesjonsstatuslagringen holdes i et pluggbart lager som omfatter minst én av et daemon-prosesslager, et persistent databaselager, og et applikasjonslager.

50. Dataprogramprodukt ifølge krav 48, der de lokale meldingspålitelighetstrekkene videre omfatter en bufferkvote som definerer et maksimalt antall meldinger som vil bli bufret av meldingsformidlings-infrastrukturen, et send-tidsavbrudd som avblokker sende-operasjonen når det utløper, et prioritetsvalg der meldinger med høyere prioritet blir sendt før meldinger med lavere prioritet, samt en konfigurerbar detektering av korrupte meldinger der et antall ganger en meldingsleveranse avbrytes kan konfigureres for å bestemme når meldingen ansees å være korrupt.

51. Dataprogramprodukt ifølge krav 48, der det lokale meldingspålitelighetstrekket med transaksjonsbasert meldingsbufring er tilgjengelig uavhengig av sesjonsstatus-lagerets persistens.

52. Dataprogramprodukt ifølge krav 47, der meldingsapplikasjonen og den bestemte minst ene passende transporten forbindes via en kanal, et sesjonsstatusbuffer, en protokoll og et pluggbart lager, innenfor meldingsformidlings-infrastrukturen.

53. Dataprogramprodukt ifølge krav 52, der sesjonsstatusbufferet opptar meldinger fra meldingsapplikasjonen, leverer meldinger til meldingsapplikasjonen og opprettholder statusinformasjon vedrørende meldinger som er sendt og mottatt.

54. Dataprogramprodukt ifølge krav 53, der statusinformasjonen omfatter minst én av en sesjonsidentifikator, den ene eller de flere spesifiserte ende-til-ende transportgarantiene og en adresse til et partner-endepunkt.

55. Dataprogramprodukt ifølge krav 53, der statusinformasjonen omfatter minst én av et sendingssekvensnummer og informasjon vedrørende kvitteringsstatus.

56. Dataprogramprodukt ifølge krav 53, der statusinformasjonen omfatter minst én av en konfigurerbar levetid og et send-tidsavbrudd, og der informasjon blir lagret.

57. Dataprogramprodukt ifølge krav 52, der protokollen utfører endepunktsidentifi-sering for å identifisere partner-endepunktet.

58. Dataprogramprodukt ifølge krav 57, der protokollen initierer endepunktsidentifi-sering med et mellomledd for å dirigere meldinger til en node i minst én av en applikasjonsfarm eller en -oppdeling innenfor en applikasjonsfarm.

59. Dataprogramprodukt ifølge krav 52, der den ene eller de flere spesifiserte ende-til-ende leveringsgarantiene omfatter "minst-én-gang"-levering av en melding og en sesjonslevetid, og der under sesjonslevetiden protokollen periodisk sender en kopi av en tidligere sendt melding til partner-endepunktet etter et gjenforsøksintervall inntil en kvitteringsmelding blir mottatt.

60. Dataprogramprodukt ifølge krav 52, der status for kanalen, sesjonsstatusbufrene og protokollen opprettholdes i det pluggbare lageret.

61. Dataprogramprodukt, for en meldingsformidlings-kjøreinfrastruktur som abstraherer sesjonsstatuslagring og sende- og mottaksoperasjoner for å utveksle meldinger med et partner-endepunkt over én eller flere meldingstransporter, som omfatter ett eller flere datamaskinlesbare medier som inneholder datamaskin-eksekverbare instruksjoner som implementerer en fremgangsmåte for å bedre tilgjengelighet og skal erbarhet i en meldingsapplikasjon ved å velge minst én av den ene eller de flere meldingstransportene å forbinde med meldingsapplikasjonen under kjøring, idet fremgangsmåten omfatter det å: motta én eller flere instruksjoner fra meldingsapplikasjonen som spesifiserer sesjonsstatuslagring, idet sesjonsstatusen holdes i et pluggbart lager som omfatter minst ett av et daemon-prosesslager, et persistent databaselager og et applikasjonslager, motta én eller flere instruksjoner fra meldingsapplikasjonen som spesifiserer én eller flere ende-til-ende leveringsgarantier som skal benyttes til valg av minst én passende meldingstransport under kjøring, uten at meldingsapplikasjonen spesifiserer den minst ene passende meldingstransporten under utvikling/kompilering, idet den ene eller de flere ende-til-ende leveringsgarantiene omfatter minst én av følgende: levering av meldinger minst én gang, levering av meldinger maksimalt én gang, levering av meldinger i den rekkefølgen de ble sendt og sesjonens levetid, velge minst én passende meldingstransport fra den ene eller de flere tilgjengelige meldingstransportene for å oppfylle den ene eller de flere ende-til-ende meldingsleveringsgarantiene spesifisert i instruksjonene mottatt fra meldingsapplikasjonen, og opprette en forbindelse i meldingsformidlings-infrastrukturen mellom meldingsapplikasjonen og den valgte minst ene transporten for bruk til å utveksle meldinger mellom meldingsapplikasjonen og partner-endepunktet.

62. Dataprogramprodukt ifølge krav 61, der fremgangsmåten videre omfatter det å motta ett eller flere lokale meldingspålitelighetstrekk som omfatter minst én av følg-ende: en meldingslevetid, en transaksjonsbasert meldingsbufring, en bufferkvote som definerer et maksimalt antall meldinger som vil bli bufret av meldingsformidlings-infrastrukturen, et send-tidsavbrudd som avblokkerer sende-operasjonen når det ut-løper, et prioritetsvalg der meldinger med høyere prioritet blir sendt før meldinger med lavere prioritet, samt en konfigurerbar detektering av korrupte meldinger der et antall ganger en meldingsleveranse avbrytes er konfigurerbart for å bestemme når meldingen ansees å være korrupt.

63. Dataprogramprodukt ifølge krav 61, der forbindelsen som blir opprettet omfatter en kanal, et sesjonsstatusbuffer, en protokoll og det pluggbare lageret.

64. Dataprogramprodukt ifølge krav 63, der den ene eller de flere spesifiserte ende-til-ende leveringsgarantiene omfatter "minst-én-gang"-levering av meldinger og en sesjonslevetid, og der under sesjonslevetiden protokollen periodisk sender en kopi av en tidligere sendt melding til partner-endepunktet etter et gjenforsøksintervall inntil det en kvitteringsmelding blir mottatt.

65. Dataprogramprodukt ifølge krav 64, der gjenforsøksintervall blir justert med en forsinkelsesperiode etter suksessive gjenforsøksintervaller.

66. Dataprogramprodukt ifølge krav 61, der fremgangsmåten videre omfatter det å planlegge overføring av minst én melding av en sekvens av meldinger til partner-endepunktet.

67. Dataprogramprodukt ifølge krav 66, der planleggingen er basert på minst én av tidvis konnektivitet, lastbalansering, meldingsprioritet og anvendelse av en mindre kostbar transport.

68. Dataprogramprodukt ifølge krav 63, der status for kanalen, sesjonsstatusbufrene og protokollen blir holdt i det pluggbare lageret.

69. Dataprogramprodukt ifølge krav 61, der utvekslingen av meldinger er definert av et antall meldingsutvekslingsmodeller, omfattende minst én av énveis meldingsformidling, forespørsel/respons-meldingsformidling og full toveis meldingsformidling.