SE521504C2 - Arrangemang och metod i ett nätverk där transaktioner skapar händelser som lagras i interservermeddelanden - Google Patents

Description

20 25 30 521 504 2 styr specifika rutiner, omkopplingsfunktioner etc. som tillhör den första kategorin, och utskriftstjänster, nätverksfaxar, CD-ROM-ställ / jukeboxar, kommunikationsportar / kort/ Sökvägar etc. som tillhör den andra kategorin.

Sammanfattning av uppfinningen Det finns behov av ett arrangemang inom kommunikationsnätverk, som kan överbrygga det ovan nämnda problemet och introducerar ett enkelt sätt att hantera meddelandetrafik, speciellt meddelanden mellan servrar i nätverket.

Vad som behövs är ett arrangemang som tillåter servrarna i nätverket att undvika att lagra infonnation i tabeller eller databaser som innehåller pågående begäran från klienterna. Därför är det också ett ändamål för uppfinningen att presentera ett arrangemang som tillåter enkel tilldelning av resurser för hantering av meddelanden genom att antingen placera begäranmeddelanden i köer för läsning av meddelanden eller att behandla dem.

Det finns också ett behov av ett arrangemang som tillhandahåller säker hantering av meddelanden utan risk för förlust av information.

Av detta skäl genererar transaktionen i enlighet med inledningen ytterligare minst en händelse i åtminstone en server, och information om denna händelse lagras åtminstone i nämnda meddelanden från server till server. Företrädesvis är nämnda händelse en tilldelning av en resurs och meddelanden innefattar en begäran om resurs. Dessutom innefattar informationen information om kontext som innefattar information om i vilken server de olika resurserna finns.

I ett föredraget utförande innefattar nätverket ytterligare en del, företrädesvis en klient-API, ordnad för att styra kommunikationen mellan klienten och servern. Denna del innefattar en databas som kan uppdateras (XSCU Context) för att lagra infonnation åtminstone om nämnda resurs / tjänst och motsvarande server. Dessutom innefattar det, för att tillhandahålla ett robust nätverk, felhantering som bygger på paradigmet "graceful degradation", i vilket ett fel endast påverkar den funktionalitet som ligger nära felet. 10 15 20 25 D) (D 521 504 3 Resursen / tjänsten specificeras och identifieras företrädesvis med en Globalt Unik Identifikator (GUID). F öreträdesvis innehåller nämnda databas information om alla resurser som används av samtliga klienter och även deras läge.

Uppfinningen hänför sig också till ett kommunikationsnätverk, företrädesvis ett datorbaserat nätverk, t. ex. för att tillhandahålla distribuerad och redundant funktionalitet för omkoppling, styming och samordning av olika kommunikationsprotokoll som sammankopplar externa och / eller interna nätverk. Kommunikationsnätverket innefattar åtminstone en uppsättning serverenheter och medel för klientstationer som sammankopplar serverenheterna.

Kommunikationsnätverket innefattar dessutom ett arrangemang för sändning och mottagning av meddelanden. En klient ordnas för att sända ett meddelande för åtkomst av åtminstone en server för att utföra olika typer av händelser. Varje server är ordnad för att kommunicera med en annan server med hjälp av meddelanden från server till server. Klientmeddelandet sätter igång en transaktion mellan servrama och nämnda transaktion åstadkommer dessutom åtminstone en händelse i åtminstone en server, där information om denna händelse lagras åtminstone i nämnda meddelanden från server till server. Företrädesvis innefattar nämnda händelse en tilldelning av en tjänst och / eller en resurs. Meddelandena innefattar begäran om tjänst och / eller resurs och meddelandena innehåller information om kontexten i vilken begäran har gjorts.

Med fördel är varje server ordnad för att skicka klientbegäran vidare mellan sig utan att spara någon information som hänför sig till den aktuella begäran. Varje serverenhet tar emot ett meddelande från en annan serverenhet och vidtar lämpliga åtgärder beroende på meddelandets kontext som innefattas i sj älva meddelandet. En identifiering av händelser och kopplingar, lokalt och/ eller fördelat i nätverket, representeras av motsvarande Globalt Unika Identifikatorer.

Resursmodulema innefattar åtminstone en ISDN resursmodul, för att hantera ISDN (Integrated Services Digital Network) -protokoll, S-Connect resursmodul, för att hantera analogt operatörsgränssnitt, (S-Connect) DSP resursmodul, för att hantera DSP (Digital Signal Processing) för signalering och sändning och mottagning av meddelanden, och en konferensresursmodul för att hantera konferensanordningar för konferensomkopplin g. I det mest föredragna utiörandet är nätverket ett oinkopplingssystem.

I enlighet med en metod för att utföra en händelse som begärs av en klient i ett kommunikationsnätverk, vilket innefattar servrar som hanterar nämnda händelser, innefattar 10 15 20 25 30 504 4 521 metoden stegen att: överföra ett meddelande till servrama genom att nämnda klient begär nämnda händelse, vilken genererar transaktioner som innefattar meddelanden från server till server mellan nämnda servrar med avseende på händelser som utförs av nämnda servrar, ordna åtminstone nämnda meddelanden från server till server med en tabell, som innefattar information om nämnda transaktioner och att uppdatera tabellen åtminstone med hjälp av varje server som tar emot meddelandena, och att leda meddelandet från server till server till dess att den begärda händelsen har utförts. Dessutom resulterar ett meddelande från server till server i ett antal olika händelser: meddelandet kommer att tas emot och behandlas av en server, varigenom en meddelandealstrande server kommer att ta emot en bekräftelse; om en server misslyckas med att läsa ett meddelande kommer meddelandekön att generera ett avbrott, vilken kommer att hanteras av den server som sände meddelandet; om ett kösystem som tar emot ett meddelande är felaktigt kan meddelandet inte sändas och den sändande servem kommer att underrättas av meddelandekötjänsten, och kommer att fortsätta med en lämplig händelse.

Kort beskrivning av ritningarna Den föreliggande uppfinningen kommer som helhet att framstå klarare utifrån kraven och beskrivningen allteftersom denna framskrider i samband med ritningarna, i vilka: Fig. 1 är ett mycket schematiskt blockdiagram som visar huvudelementen i ett nätverk som innefattar ett arrangemang i enlighet med uppfinningen; Fi g. 2 illustrerar schematiskt ett nätverksutförande som innefattar uppfinningen; F ig. 3 är en mer detaljerad men fortfarande schematisk illustration av elementen i nätverksarrangemanget i enlighet med F ig. 2; F ig. 4 illustrerar systemarkitekturen för det utförande som visas i Fig. 2; och Fig. 5 är en schematisk bild av ett exempel på upprättande av en anslutning.

Detaljerad beskrivning av ett utförande I enlighet med ett föredraget utförande, som visas i F ig. 1, sänder, i ett komrnunikationsnätwferk 10, företrädesvis en multiklient 11 / multiserver 12 -miljö, en klient (station) 11 som begär en specifik resurs 13 ett meddelande som hänvisar till nämnda specifika resurs, vilken företrädesvis är identifierad med hjälp av en Global Unik Identifikator (GUID). F öreträdesvis hänvisar inte 10 15 20 25 30 521 504 5 begäran till någon specifik server 12 i nätverket. Företrädesvis köas meddelandena kösystemen för meddelanden 14. Kösystemen 14 kommer att beskrivas senare.

I enlighet med uppfinningen innefattar, i ett nätverk, företrädesvis ett nätverk som bygger på meddelandeköer, ett meddelande som sänds från en klient till en eller flera servrar en begäran om någon händelse eller tjänst. Företrädesvis innefattar meddelandet information om typen av begäran och några parameter eller en uppsättning av data. Klientens begäran resulterar antagligen i ett antal meddelanden från server till server (interservermeddelanden). För att undvika implementering av komplex meddelandehantering i servrarna är åtminstone interservenneddelandena ordnade för att innefatta information om begäran, tilldelade resurser/ tjänster och servertransaktioner som orsakats av den mottagna begäran. Följaktligen behöver servrarna inte innehålla några tabeller över pågående begäran. Alla föreliggande begäran finns antingen i en meddelandekö där de väntar på att bli behandlade eller i en server där de behandlas.

Ett interservermeddelande urrnynnar i ett antal olika händelser: - meddelandet kommer att tas emot och behandlas av en server, varigenom den alstrande servern kommer att ta emot en bekräftelse; - om en server misslyckas med att läsa ett meddelande kommer meddelandekön att generera en timeout vilken kommer att hanteras av den server som sände meddelandet; - om en mottagande meddelandekö är felaktig kan meddelandet inte sändas och den sändande servern kommer att underrättas av meddelandekötjänsten och fortsätta på annat sätt Följaktligen lagras, när ett meddelande tas emot, all information som behövs för att behandla begäran i meddelandet tillsammans med begäran. Därför behöver ingen information lagras i en extem tabell eller databas.

I det följ ande kommer uppfinningen att beskrivas mera i detalj i samband med ett icke begränsande utförande vilket används uteslutande för att underlätta en bättre förståelse av uppfinningen. iörandet, som visas schematiskt i Fig. 2, hänför sig till ett Växelsystem (XS) 20, vilket är en datorbaserad kommunikationsplattforrn som tillhandahåller distribuerade och redundanta funktionaliteter för ornkoppling, styrning och samordning av olika kommunikationsprotokoll som sammankopplar de externa (eller interna) nätverken 21. De externa nätverken kan till exempel 10 15 20 25 521 504 a , » f - » 6 vara vilket som helst av PLMN (Private Land Mobile Network), PSDN (Public Switched Data Network) eller PSTN (Public Switched Telephone Network) etc.

Arkitekturen i ett XS är i huvudsak ett decentraliserat distribuerat system och kan vara baserad på ett varierande antal XS-servrar 12 som står i förbindelse med varandra, till exempel via ett IP- nätverk såsom ett ethernet LAN (Local Area Network) 22.

XS-servrarna 12 kan också vara kopplade till varandra via ett nätverk 23 till exempel via MCl- buss för att åstadkomma omkoppling mellan servrarna.

XS 20 kan vara konfigurerat för att använda en XS-server med ett varierande antal klienter 11, eller som ett distribuerat multiserversystem som försörjer ett varierande antal klienter, som ska kopplas till ett varierande antal server-servrar.

I systemet hanteras hårdvaru (HW) -gränssnitten som resurser, och kan kapslas in under en generiskt XS resurshanterare för resursgränssnitt inom en XS-server 12. F öreträdesvis kapslas olika, d. v. s. protokollspecifika, resursmoduler in och hanteras som undersystem under resursgränssnittet. XS kan därför utsträckas till att hantera nya typer av resurser, t. ex. kommunikationsprotokoll och nätverk i framtida versioner, till exempel IP-telefoni och protokoll för olika radiosystem.

I huvudsak har XS följande fimktioner - Omkoppling, vilken täcker den generiska protokollsoberoende omkopplingen.

- Anropsstyrning, vilken täcker protokollsoberoende funktionalitet för anropsstyrning - Signalering, vilken täcker signaloberoende sändning/ mottagning av ton.

- Hantering av meddelanden, vilken täcker oberoende hantering av meddelanden, såsom avspelning / inspelning.

För att uppnå dessa funktioner finns det några ytterligare funktionsområden: - Uppkoppling av server, vilken hanterar uppkopplingen mellan CL (klienter) och XS.

- Resurshantering, vilken hanterar tilldelning av resurser, t. ex. konferenstilldelning.

- Statusunderrättning, vilken hanterar icke synkron statusinformation från XS och externt nätverk till klienterna. 10 15 20 25 30 521 504 7 - Systemhantering som hanterar konfigurering av XS, övervakning, styrning etc.

XS är baserat på implementering av ett antal resursmoduler, såsom: - ISDN resursmodulen, som hanterar ISDN (Integrated Services Digital Network) -protokollet.

- S-Connect resursmodulen, vilken hanterar det analoga gränssnittet mot operatören (S- connect).

- DSP resursmodulen, vilken hanterar DSP (Digital Signal Processing) -hanteringen av signalering och meddelanden.

- Modul för konferensresurser, vilken hanterar konferensanordningarna för konferensomkoppling.

En DSP är en resurs som kan tilldelas / tas bort och användas för att sända och ta emot toner och meddelanden. En konferensresurs tillhandahåller funktionalitet för att sätta upp en uppsättning deltagare, representerade i form av stolar, till ett forum i vilket deltagama är sammankopplade.

Uppkopplingen till en konferensresurs kan vara i form av en simplex- eller duplexuppkoppling.

XS-kommunikationsenhets (XSCU) -API:n 24 är namnet på åtkomstpunkten för XS-tjänsten.

Den implementeras företrädesvis som en distribuerad asynkron telegrambaserad klient-API.

XSCU API innefattar bland andra konfigurationen för XS-servem och tillåter omkoppling av multinodtyp, belastningsdelning och felhantering, till exempel baserad på paradigmet graceful degradation", i vilket ett fel endast påverkar den funktionalitet som befinner sig nära felet.

Klientens logiska (CL) gränssnitt till XS är XSCU API, vilken innefattas i kommunikationsapplikationen. XSCU hanterar kommunikationen mellan klienten och XS och innefattar funktionalitet för att fördela klientens begäran till XS-servrama, genom att hantera information om klientkontext.

Fig. 3 visar komponentema som ingåri systemet. hanteringsenhet för begäran (XSRMU) 30, XS omkopplingshanterare (XSSM) 31, XS resurshanterare (XSRM) 32, XS huvudhanterare (XSMM) 33 och resurskoppling 34. I XS-servern 12 tas klientens ll begäran emot av XSRMU 30 som hanterar serverns kommunikationsdel. 10 15 20 25 30 521 504 8 Beroende på typen av begäran kommer XSRMU 30 att fördela begäran till XSSM 31 eller XSRM 32 via en huvudkö som synkroniseras av XSMM 33. Resurskopplingen 34 kopplar samman resurser såsom en ISDN-resurs, DSP-resurs, S-connect-resurs, konferensresurs etc.

Det funktionella blocket XSRM 32 tillhandahåller funktionalitet för att hantera, synkronisera och samordna hårdvaruresurser. Det tillhandahåller ett generiskt gränssnitt på hög nivå till hårdvaruresurserna. Företrädesvis sammanfattar det hanteringen och konfigureringen av hårdvarukort, som sammankopplar kommunikationsnätverken. Icke synkrona händelser från hårdvarugränssnitten vidarebefordras till XSRMU 30 via huvudkön som synkroniseras av XSMM 33. Denna har till exempel mekanismer för tilldelning, borttagning och översättning av omkopplingsinforrnation som hänför sig till hårdvaruresurser. XSRM 32 tillhandahåller även ett gränssnitt på hög nivå till hårdvaran och är en ensam tj änsteåtkomstpunkt till det externa kommunikationsnätverkets gränssnitt. XSRM 32 hanterar den fysiska omkopplingen och sainordningen av hårdvaran.

XSSM 31 hanterar resurserna inom en logisk nivå. Den hanterar relationerna mellan resurserna och använder XSRM 32 för att komma åt dem. Den använder även XSRMU 30 för att Vidarebefordra begäran till andra XS-servrar i systemet beträffande hantering av resurser utanför en lokal maskin. Omkopplingen av enkelnodtyp löses enbart genom att använda den lokala XSRM.

XSMM 33 är det huvudsakliga funktionella blocket i XS. Den innehåller huvudapplikationen och den startar och synkroniserar andra enheter i systemet, till exempel genom att hantera en multitrådbaserad arkitektur. Den tillhandahåller funktionalitet för att för att sända och ta emot meddelanden mellan de olika funktionella blocken, t. ex. genom att styra en trådsäkert synkroniserad kö, och anropar varje funktionellt blocks begäran i den ordning som köposterna tas emot.

De huvudsakliga funktionema hos XS SM 31 är att: 0 utföra uppkoppling^r och "tirkopplirig-ar, 0 tilldela, frigöra och återställa specifika resurser, 0 eliminera uppkopplingar som ett resultat av vissa händelser, såsom en yttre blockering. 10 15 20 25 30 », < . i _ .

F öreträdesvis använder XSSM resurstabeller för att ytföra sina uppgifter. Begäran från XSRMU 30 sänds till XSSM genom en kö som sköts av XSMM. För att utföra en uppgift, till exempel att göra en uppkoppling, arbetar XS SM 31 och XSRM mycket nära tillsammans. Uppgifterna delas på så sätt att XSSM 31 hanterar den logiska delen av omkopplingen, vilket innebär den delen där information om resurser t. ex. en Busstabell, Kopplingstabell och Konferenstabell måste uppdateras för att tillhandahålla korrekt information om de verkliga fysiska kopplingama. Med andra ord kopplar XSSM 31 logiskt samman två kopplingspunkter, vilka representerar en tillträdespunkt till ett anrop, en konferens, en DSP eller en logisk adress, med varandra (genom en kopplingstabell, företrädesvis ordnad i XSSM 31) och skickar kommandon till XSRM 32 för att åstadkomma den fysiska sammankopplingen.

Den distribuerade omkopplingen använder MCl-bussen för att föra över mediaflöden mellan XS- SCTVIEIITIÉI.

F unktionsblocket XSRMU 32 tillhandahåller funktionalitet för att hantera kommunikationen i den distribuerade miljön. Kommunikationsvägama är: 0 kommunikation från XSCU (klient) till XS-server; v kommunikation från XS-server till XSCU (klient); och 0 kommunikation från XS-server till XS-server.

Omkopplingen av multinodtyp tillhandahålles i en trestegsprocess: - det första steget innefattar tilldelning av en MCl-bussresurs och sändning av ett XS- servernieddelande (XSMSG) till den andra servern med begäran om exekvering av en tjänst tillsammans med all information som den andra servern behöver för att fullgöra sin del av omkopplingen. XSMSG är gränssnittsmeddelandet från en XS-server till en annan, vilket innehåller data om begäran och underrättelser från en XS-server till en annan.

- Det andra steget är när en annan server tar emot ett XSMSG. Vid mottagandet kommer den att koppla inmatningen från MCl-bussen till utmatningen på den relevanta kopplingspunkten via den interna telefonibussen. När detta är gjort kommer den att sända ett XSMSG som irinehåller ett meddclmde om tj änstexekvering tillsammans med all information som behövs av den alstrande servern för att fullgöra den andra delen av omkopplingen. 10 15 20 25 30 521 504 10 - Det tredje steget är när den alstrande servern tar emot meddelandet om tj änstexekvering.

Den kommer då att koppla samman kopplingspunkten för inmatning till utmatningen på MCl-bussen via den interna telefonibussen. Om detta skulle misslyckas kommer den att sända en avrullningsbegäran till den andra servern och be den att ta bort den tidigare kopplingen.

XS består dessutom av en uppsättning meddelandeköer och köhanterare. XSCU är den del som exponerar XS API för klient och kommunicerar med XS-servrama. Varje CL 35 kommunicerar med XS genom XSCU-gränssnittet med användande av XS API 24.

I huvudsak har varje exempel på XSCU information om i stort sett alla resurser som används av alla CL och dessutom deras lokalisering (koppling till en viss XS-server eller servrar). XSCU tar emot information från varje XS-server när en resurs påbörjas eller tas bort. Med ledning av nämnda information kan begäran ledas via den XS-server som lämpar sig bäst för att hantera en begäran Denna information är också användbar när en XS-server inte fungerar eller inte kan nås. I det följande kallas denna infonnation XSCU systemkontext (XSSC).

Begäran som skapar nya resurser (till exempel Gör Anrop, Tilldela Konferens eller Tilldela DSP) arrangeras i en slumpmässigt utvald serverkö för att fördela arbetsbelastningen över XS-servrama.

Om denna begäran innehåller en "pekare" kommer begäran att föras över till en server som pekats ut av pekaren. Begäran som hänför sig till hela XS (t. ex. kommandon som Utloggning, Äterställning, Avstängning) sänds till alla servrar.

XS-servem sänder underrättelser till den XSCU-enhet som har sänt begäran. Om en resurs skapas eller tas bort sänds en underrättelse med resursinformation till alla andra XSCU for att uppdatera deras XSSC. Vissa underrättelser kan även sändas till CL.

Om begäran är en operation på två resurser som finns på olika ställen (apparater), kommer XSCU att sända begäran till en av dessa och fylla i den logiska adressen för den andra resursen från dess XSSC ( om den representeras av an GULD och inte red^n ^v en logisk adress). De logiska adresserna identifierar en kopplingspunkt på låg nivå inom XS-servem, vilken tillåter en inrnatningskoppling och åtskilliga utmatningskopplingar. 10 15 20 25 30 521 504 ll Företrädesvis innefattar varje XSCU-enhet information om i huvudsak alla resurserna och till vilken XS-server de är knutna. Informationen innefattar alla anrop, kopplingar, konferenser, DSP som skapats av vilken som helst CL och deras identitet (GUID), vilket uttryckligen pekar ut på vilket ställe de finns. Varje XS CU har gränssnitt mot sin klient och mot XS-servrama. Vissa meddelanden rör sig transparent genom XSCU och vissa är intema XS-server / XSCU -meddelanden som inte når CL.

Klientbegäran på en resurs i form av ett XS-meddelande sänds från CL till XSCU. F öreträdesvis innehåller XS-meddelandena inte någon information om den server som meddelandet skall sändas till. Detta sköts i praktiken av API. När klienten sänder ett meddelande kommer XSCU att söka upp vilken som helst resursreferens i XSSC för att ta reda på i vilken server resurserna finns. Om begäran innefattar resurser i olika servrar kommer information att läggas till i XS-meddelandet, vilken hjälper den mottagande servern att hantera begäran. Meddelandena till XSCU som tas emot från XS-servem analyseras och XSSC uppdateras i enlighet med analysresultatet.

XSSC innehåller med fördel tabeller för samtliga resurser och metoder för att lägga till, ta bort och hitta resurser.

XSCU tillhandahåller funktioner för att hantera gränssnittet mot systemet av XS-servrar genom en distribuerad API. Denna funktionalitet bygger på hantering av olika meddelandeinstanser, XS- meddelande vilket är, som beskrivs ovan, det XSCU API meddelande som innehåller data om begäran från CL till XS eller underrättelsedata från XS till CL. XS-meddelandet innehåller i huvudsak alla API. Denna hantering innefattar instansiering, sändning och mottagning av XS- meddelandeinstanser. XSCU kan vara den fullständiga API och den enda åtkomstpunkten för tjänster till XS. Det allmänna API-begreppet är en asynkron telegrambaserad lösning. Den fysiska ltårdvarukonfigurationen för servem är inte synlig för klienten. Systemet Microsoft® Message Queue (MSMQ) är till exempel inte synligt för nätverkskommunikation. Uppenbarligen kan andra system för nätverkskommunikation användas.

Strukturen -ör XSCU API delas in i nera logiska delar, till exempel: - Serverkoppling: hanterar systemrelaterad funktionalitet, t. ex. kopplingen mellan CL och XS-serversystemet; - Omkoppling: hanterar kopplingar mellan XS-kopplingspunkter inom XS-servrarna; 10 15 20 25 30 12 - Resurs: hanterar tilldelning och borttagning av specificerade resurser inom XS-servrarna; - Anropskontroll: hanterar funktioner för styrning av anrop inom XS-servrarna; - Status: asynkront sända meddelanden från XS till CL som informerar den berörda CL om förändringar i status; - Signalering: sändning av meddelanden och mottagning av signaler med användande av en DSP; och - Meddelande: till exempel att spela upp och spela in meddelanden med hjälp av en DSP.

Meddelanden kan läsas, tas bort och även delas mellan konkurrerande CL.

XS innefattar även ett gränssnitt 36 mot yttre nätverk, t. ex PSTN, vilka till exempel använder ISDN-protokollet. Gränssnittet för ISDN implementeras i resursmodulen för ISDN i XS-servern.

Systemet kan också innefatta gränssnitt mot telefonioperatörer som bygger på ett analogt telefongränssnitt. Detta gränssnitt kallas även S-Connect, och det implementeras i resursmodulen för S-Connect i XS-servem.

XS tillhandahåller grundläggande kontakt mellan klient och server via inloggning / utloggning, där varje klient har sin egen specificerade ID (CLID).

Kommunikationema mellan server och klient, vilken bygger på utväxling av XS-meddelanden delas in i begäran och underrättelser, där begäran representerar meddelandena från CL till XS och underrättelserna representerar meddelandena från XS till CL.

För att erhålla förbindelse till en server måste CL göra en instans av XSCU API som hanterar den asynkrona kommunikationen mellan klienten och XS-servem lokalt eller över ett nätverk, t. ex.

LAN.

En begäran om inloggning kommer att leda till att underrättelse tas emot om samtliga inkommande anrop som tas emot av XS, och kommer att göra det möjligt för klienten att sända begäran till XS. Om inloggningen misslyckas kommer ett negativt statusmeddelande att tas emot.

På grund av att XS kan hantera en situation i vilken en XS-server är ur funktion, vilken kommer att orsaka förlust av resurser och möjligen förlust av icke behandlade begäran, kan XSCU underrätta klienterna om vilka resurser som gått förlorade. 10 15 20 25 30 521 504 13 XS tillhandahåller funktionalitet för att tilldela och ta bort definierade XS-resurser: till exempel Konferens och DSP.

För att minimera belastningen på nätverket implementeras mekanismen med "pekare", vilket betyder att resursen kan tilldelas i samma XS-server och samma XS-gränssnittskort som XS- kopplingspunkten till vilken den kommer att kopplas till, under förutsättning att den frivilliga kopplingspunkten för XS är satt i ett meddelande om tilldelning av resurs.

E konferensresurs kan tilldelas med ett garanterat (fast eller varierande) antal deltagare. En konferensdeltagare representeras av en XS-kopplingspunkt, vilken kan vara en resurs kopplad via en simplex- eller duplexuppkoppling.

En DSP kan samtidigt endast vara antingen en mottagare eller en sändare. En koppling till en DSP kan vara duplex, men man kan endast använda DSP i en riktning i taget.

Dessutom tillhandahåller XS funktionalitet för att hantera situationer i vilka en eller många av systemets komponenter ligger nere. Grunden för denna funktionalitet är en fullständigt fördelad och decentraliserad arkitektur. Systemet har förmågan att hantera en situation i vilken en XS- server ligger nere eller inte kan nås. Denna situation kommer att resultera i förlust av resurser och möjligen förlust av icke behandlade begäran. Denna förlust kommer att begränsas till de resurser som är direkt kopplade till den nod som inte fungerar. XS infomierar klienterna om vilka resurser som har förlorats.

Arkitekturen för det distribuerad systemet visas närmare i Fig. 4i vilken alla nodelement har kopplats till varandra i en decentraliserad struktur. I ritningen betecknas samma delar med samma referenstecken som i föregående ritningar. AUX hänvisar tilldelar som kan utföras beroende på de olika applikationerna.

För att åstadkomma denna helt decentraliserade struktur och arkitektur tillämpas paradigmet "fire and forget" i kombination med ett "context" -paradigm i systemets konstruktion. Det '^'r emellertid uppenbart att båda paradigmen kan implementeras separat. 10 15 20 25 30 521 504 14 Paradigmen och systemarkitekturen är meddelandehändelsema mellan XSCU 24 och XS- servrama 12, och internt mellan XS-servrarna 12.

Meddelandetrafiken mellan XSCU 24 och XS-servrarna 12 löses genom att XSCU har kontextsinformation som innefattar information om i vilken XS-server de olika resursema finns.

Denna mekanism underlättar fördelningen av klienternas begäran.

Meddelandetrafiken mellan XS-servrarna bygger på paradigmet "Fire & Forget", vilket betyder att meddelandet innehåller kontextsinforrnation om begäran. Denna mekanism tillåter XS-servrama att skicka klientbegäran mellan sig utan att spara någon information som hänför sig till den faktiska begäran. XS-servern hämtar ett meddelande från en annan XS-server och vidtar lämpliga åtgärder beroende på detta meddelandekontext som är innefattat i själva meddelandet.

En identifiering av resurser och kopplingar, lokala och distribuerade, i XS-miljön krävs. Därför representeras varje resurs t. ex. ett anrop, konferensanordning eller en DSP, och varje koppling, som representerar förhållandet mellan resurserna av en GUID.

I ett utförande hanterar XSSM 30 även konferenstilldelning. Om XS-servem inte har några lediga resurser för konferens tillgängliga, kommer den att vidarebefordra begäran till nästa XS-server i systemet. "Nästa" server väljs ut av den som inte läst meddelandet från sin kö. Denna process kommer att upphöra när vilken som helst XS-server tar hand om begäran eller om det inte finns någon XS-server kvar att sända till (som inte hat läst meddelandet från sin egen kö). Om det inte finns några resurser för konferens lediga i hela systemet kommer den sista servern att sända ett meddelande "misslyckades" till den begärande CL.

I allmänhet upprättas kopplingen genom följande process: - CL gör en begäran om XS-koppling via XSCU, vilken vidarebefordrar den till den lämpliga XS-servem.

- XS-servem gör en lokal tilldelning av en resurs, och överför begäran inklusive en ímnatningsadress och resursadress till nästa berörda .tS=server.

- Denna XS-server utför den lokala omkopplingen och överför begäran i form av en underrättelse, inklusive en utmatningsadress, tillbaka till den första XS-servern. 10 15 20 25 30 521 504 15 - - ; , , .

- Den första XS-servern utför nu den lokala omkopplingen och sänder en underrättelse till CL via XSCU.

Med hänvisning tillbaka till Fig. 1 tillhandahåller en köhanterare for meddelanden funktionalitet för att sända och ta emot meddelanden till / från meddelandeköer och för att hitta, skapa och förstöra meddelandeköer. En köhanterare för meddelanden har sin egen kö i vilken alla inkommande meddelanden läses. Alla utgående meddelanden sänds till andra köer, som är associerade med köhanterare för meddelanden. En köhanterare för meddelanden kan användas av en klient eller av en server i XS. Klientanvändama är då XSCU och serveranvändama är XS- begäranshanterama.

Köema 14 delas in i två kategorier, serverköer och klientköer, och härigenom tillhandahålls ett enkelt sätt att avgöra om köema är associerade med en server eller med en klient.

Följande icke begränsande exempel, lästa tillsammans med ovan beskrivna ritningar och Fig. 5, beskriver tilldelning av resurser och kopplingssteg, och ges för att underlätta en bättre förståelse av uppfinningen: I det första exemplet begär CL1 att få göra en koppling mellan två punkter A och B i XS- systemet. Kopplingen kan vara mellan två abonnenter (A, B) eller mellan en abonnent och en konferensresurs eller vilken som helst annan resurs. Nämnda två punkter kan vara i samma server eller i två olika servrar (som i det föreliggande fallet).

Om de är i samma server kopplas de av XSSM med hjälp av kommandon i XSRM, och om de befinner sig i olika servrar används interserverkopplingen. XSSM skapar en ny koppling, fyller den med detaljerad information om de två punkterna och lagrar den i en kopplingstabell i XSSM och skickar en underrättelse till CLl.

Om punktema befinner sig i olika servrar kommer XSSM i den mottagande servem att tilldela en MCl-bussresurs, skapa ett XSMSG för Server som Utför Tj änsteBegäran, förse det med relevant information och sända det till den andra servem (server 2) som är inblandad i kopplingen och be den att göra sin del av uppkopplingen. 10 15 20 25 30 521 504 16 = - v » . , När meddelandet tas emot kommer XSSM i den andra servern till exempel att tilldela en intern bussresurs från kort till kort, göra en koppling från intembussen till dess punkt med hjälp av XSRM, göra en koppling från den tidigare tilldelade MCl-bussen till den interna bussen med hjälp av XSRM, tilldela MCl-buss, t. ex. för en duplexkoppling, om så krävs, göra kopplingen, skapa en (eller två när det gäller duplex) ny koppling, förse denna med detaljerad information om de två ändpunkterna, lagra den i kopplingstabellen, fylla XSMSG med ny information och slutligen sända tillbaks det till den alstrande servern, d. v. s. server l.

När underrättelsemeddelandet tas emot med status Utfört, kommer XSSM att utföra den andra halvan av kopplingen och sända en underrättelse till CLl. Om underrättelsemeddelandet har status Misslyckades kommer en underrättelse att sändas till CL med misslyckandestatus.

Om denna server misslyckas med sin hälft av kopplingen kommer en avrullningsbegäran att sändas till den andra servern om att ta bort sin halva av kopplingen.

Vid urkoppling kopplar XSSM, om punkterna är i samma server, ur kopplingen med hjälp av XSRM, frigör intema resurser som eventuellt används, tar bort kopplingen från kopplingstabellen, och skickar en underrättelse till klienten. Om de befinner sig på olika servrar kommer XSSM att skapa ett XSMSG, fylla det med relevant information och sända det till den andra servern som är inblandad i kopplingen och begära at den kopplar ur sin halva av kopplingen.

När begäran tas emot kommer XSSM i den andra servern att ta bort sin halva av kopplingen, frigöra inre och MCI-resurser, ta bort kopplingen från kopplingstabellen och fylla XSMSG med nu infonnation och sätta typen till underrättelsemeddelande och slutligen sända servenneddelandet tillbaka till den alstrande servern.

Vid mottagande av underrättelsemeddelandet med status Utfört kommer XS SM att koppla ur den andra halvan av kopplingen och skicka en underrättelse till CL. Om underrättelsemeddelandet har status Misslyckades kommer en underrättelse att sändas till CL med misslyckandestatus.

Om denna server skulle misslyckas med sin halva av kopplingen kommer ingen avrullningsförfrågan att sändas till den andra servern om att återställa sin halva av kopplingen. 10 15 20 25 30 521 504 17 - u » . . , K , I det följande exemplet beskrivs en konferenskoppling.

För att skapa en konferens måste CL först tilldela en konferensresurs. Med konferenstilldelning menas att XS-servern försäkrar klienten att en konferensresurs är reserverad vilken kan hantera ett antal deltagare. Formen för deltagande kan vara simplex eller duplex.

CL ger en unik identifierare tillsammans med information om det maximala antalet deltagare i sin begäran.

När XSSM ta emot en begäran om tilldelning av konferens kommer den att leta efter en ledig konferens i sin konferenstabell. Om en ledig konferens hittas, kommer den att tilldelas och en underrättelse om tilldelad konferens sänds till CL.

Om XSSM inte kan hitta några lediga konferenser i servern kommer den att skapa ett XSMSG av typen tj änstebegäran, fylla det med relevant information och sända det till nästa server och be denna att försöka tilldela en konferens.

När XSSM misslyckas med att sända XSMSG till andra servrar betyder det antingen att servern är ensam i systemet eller att alla andra servrar redan har tagit emot detta meddelande och inte lyckats utföra begäran. I detta fall kommer en underrättelse om konferenstilldelning att sändas till CL tillsammans med en misslyckandestatus, för att informera klienten om att inga lediga konferenser fanns tillgängliga.

Vid mottagandet av tj änstebegäran försöker XSSM att tilldela en konferens. Om operationen lyckas kommer en underrättelse att sändas till CL.

Om CL begär att få lägga till en kopplings punkt till en konferens kan kopplingspunkten representeras av en logisk adress, eller i de fall då en resurs är inblandad som en GUID. CL kan även ge en ny kopplingsidentitet för kopplingen mellan abonnenten och konferensen.

Klientbegäran kommer alltid att sändas till den server på. vilken konierensen är tilldelad. XSSM undersöker det mottagna XSMSG för att ta reda på om kopplingspunkten som vill bli kopplad till konferensen finns i en annan server. Om så inte är fallet försöker XSSM att hitta en tom stol i konferensen. Om en tom stol hittas kommer abonnenten att kopplas till denna stol. Om 10 15 521 504 18 .. i = ef ; s a kopplingen lyckades sänds en underrättelse till CL. Om kopplingspunkten är i en annan server kommer XSSM att skapa ett XSMSG av typen Tjänsteförfrågan, fylla detta med relevant information och sända det till den andra servem och be denna att koppla abonnenten till MCl- bussen.

För att frigöra en konferens gör CL en begäran om att frigöra en tilldelad konferens. XS- meddelandet som sänds från CL-klienten till XS innehåller information om klientens identitet och konferensens identitet. XSSM kontrollerar att konferensen inte har några deltagare kopplade till sig. Om så är fallet frigörs konferensen (en statusflagga för konferensen ändras till ledig).

Uppenbarligen är uppfinningen inte begränsad till det ovan beskrivna nätverksarrangemanget, utan vilket som helst nätverk, såsom datomätverk, (mobila) telekommunikationsnätverk etc. kan utnyttja fördelarna i uppfinningen.

Uppfinningen är inte begränsad till det visade utförandet, utan kan varieras på ett antal olika sätt utan att avvika från omfattningen av de bifogade kraven, och arrangemanget och metoden kan utföras på olika sätt beroende på tillämpning, funktionella enheter, behov och krav etc.

Claims (1)

1. 0 15 20 25 521 504 19 Patentkrav Arrangemang för meddelandetrafik i ett koinmunikationsnätverk innefattande en eller flera klienter (1 1) och en uppsättning servrar (12), varigenom en klient (11) ordnas för att sända ett meddelande för åtkomst av åtminstone en server för att utföra olika typer av åtgärder varigenom nämnda klientmeddelande påbörjar en transaktion mellan servrarna, kännetecknar av, att nämnda transaktion dessutom skapar åtminstone en händelse i åtminstone en server, där information om denna händelse lagras åtminstone i nämnda interservermeddelanden. Arrangemang enligt krav 1, kännetecknar av, att nämnda händelse är tilldelning av en resurs (13) eller tjänst. Arrangemang enligt krav 2, kännetecknar av, att nämnda meddelanden innefattar en resursbegäran. Arrangemang enligt krav 2, kännetecknat av, att i nämnda information ingår kontextsinformation innefattande information om i vilken server de olika resurserna är belägna. Arrangemang enligt vilket som helst av de föregående kraven, kännetecknar av, att nämnda nätverk dessutom innefattar en enhet (XSCU) (24), företrädesvis en klient-API, ordnad för att styra kommunikationen mellan klienten och servern (12), där nämnda enhet (24) innefattar en uppdateringsbar databas (XS CU Context) för att lagra information åtminstone om nämnda resurs / tjänst och motsvarande server. Arrangemang enligt krav 5, kännetecknat av, 10 15 20 25 30 10. ll. 521 504 20 att nämnda nätverk innefattar felhantering baserad på paradigmet "graceful degradation", i vilket ett fel endast påverkar den funktionalitet som befinner sig nära felet. Arrangemang enligt krav 2, kännetecknat av, att nämnda resurs/ tjänst specificeras och identifieras med hjälp av en Globalt Unik Identifikator (GUID). Arrangemang enligt vilket som helst av kraven 2 - 7, kännetecknat av, att nämnda databas innehåller infonnation om alla resurser som används av alla klienter och även deras läge. Kommunikationsnätverk, företrädesvis ett datorbaserat nätverk, t, ex. för att tillhandahålla distribuerad och redundant funktionalitet för omkoppling, styrning och samordning av olika kommunikationsprotokoll som sammankopplar yttre och/ eller inre nätverk (21), där nämnda kommunikationsnätverk innefattar åtminstone en uppsättning serverenheter (12) och medel för klientstationer (11) som sammankopplar serverenhetema, kännetecknar av, att kommunikationsnätverket dessutom innefattar ett arrangemang för meddelandetrafik (22) varigenom en klient (1 1) ordnas för att sända ett meddelande för åtkomst av åtminstone en server för att utföra olika typer av åtgärder, att varje server är ordnad för att kommunicera med an annan server med hjälp av interserverrneddela att nämnda klientmeddelande påbörjar en transaktion mellan servrama, och att nämnda transaktion dessutom genererar åtminstone en händelse i åtminstone en server, där information om denna händelse lagras åtminstone i nämnda interservenneddelanden. Nätverk enligt krav 9, kännetecknar av, att nämnda händelse innefattar tilldelning en tjänst och/ eller en resurs. Nätverk enligt krav 10, kännetecknar av, 10 15 20 25 30 12. 13. 14. 15. 16. 17. 521 504 21 ! » 1 ; ; . att nämnda meddelanden innefattar begäran om tjänst / resurs och att meddelandena innehåller kontextsinfonnation om denna begäran. Nätverk enli gt vilket som helst av krav 9 - 11, kännetecknar av, att varje serverenhet är ordnad för att vidarebefordra klientbegäran mellan varandra utan att spara någon information som hänför sig till faktisk begäran. Nätverk enligt krav 12, kännetecknar av, att varje serverenhet (12) hämtar ett meddelande från an annan serverenhet och vidtar lämpliga åtgärder beroende på meddelandets kontext som innefattas i själva meddelandet. Nätverk enligt krav 9, kännetecknar av, att en identifiering av åtgärder och kopplingar, lokalt och/ eller distribuerat i nätverket, representeras av motsvarande Globalt Unika Identifikatorer. Nätverk enligt vilket som helst av krav 9 - 14, kännetecknar av, att nätverkets arkitektur i huvudsak är ett decentraliserat distribuerat system. Nätverk enligt krav 15, kännetecknar av, att arkitekturen bygger på ett varierande antal serverenheter (12) kopplade till varandra genom ett Lokalorrirådesnätverk (LAN) (22), till exempel genom ett IP-nätverk såsom ett ethernet LAN. Nätverk enligt krav 9, kännetecknar av, att serverenheterna (12) även är kopplade tillvarandra genom ett nätverk (23) rör att åstadkomma omkoppling mellan serverenheterna. 10 15 20 25 30 18. 19. 20. 21. 22. 23. 24. 521 504 22 Nätverk enligt vilket som helst av krav 9 - 17, kännetecknat av, att det är konfigurerat med användande av en serverenhet med ett varierande antal klienter (11). Nätverk enligt vilket som helst av krav 9 - 17, kännetecknar av, att det är konfigurerat som ett distribuerat system för flera användare som försörjer ett varierande antal klienter, som ska kopplas till ett varierande antal serverenheter. Nätverk enligt krav 12, kännetecknat av, att hårdvarugränssnitt hanteras som resurser, vilka är inkapslade under en generisk hanterare för resursgränssrlitt inom en serverenhet (12). Nätverk enligt krav 20, kännetecknat av, att olika resursmoduler kapslas in och hanteras som undersystem under resursgränssnittet. Nätverk enligt krav 21 , kännetecknat av, att nämnda resursmoduler innefattar åtminstone en av ISDN-resursmodul, for att hantera ISDN (Integrated Services Digital Network) -protokolL S-Connect-resursmodul, för att hantera analogt operatörsgränssnitt (S-connect), DSP-resursmodul, för att hantera DSP (Digital Signal Processing) -hantering för signalering och meddelandetrafik, och Konferensresursmodul, för att hantera konferensanordningar för konferensomkoppling. Nätverk enligt vilket som helst av krav 9 - 22, kännetecknat av, att nätverket är ett ornkopplingssystem (20). Nätverk enligt vilket som helst av krav 9 - 23, kännetecknat av, att det dessutom innefattar en enhet (XSCU) (24), företrädesvis en klient-API, ordnad för att 25. 26. 521 504 servrar som hanterar nämnda åtgärder, kännelecknaa' av, att metoden innefattar stegen att: - överföra ett meddelande till servrarna från nämnda klient med begäran om nämnda åtgärd, - skapa transaktioner innefattande ínterservermeddelanden mellan nämnda servrar med avseende på åtgärder som utförts av nämnda servrar, meddelandena, och att - leda interserverrneddelandet till dess att den begärda åtgärden utförs. Metod enligt krav 25, kärznelecknad av, att ett interservenneddelande orsakar ett antal olika åtgärder: - meddelandet kommer att tas emot och behandlas av en server, varigenom en server som alstrar ett meddelande kommer att erhålla en bekräftelse; - om en servennisslyckas med att läsa ett meddelande, kommer meddelandekön att generera en timeout vilken kommer att hanteras av den server som sände meddelandet; - om ett mottagande rneddelandekösystem är felaktigt, kan meddelandet inte sändas och den sändande servem kommer att underrättas av meddelandekötjänsten och kommer att fortsätta med en lämplig åtgärd.