Tjänsteleveransplattform

En tjänsteleveransplattform ( SDP ) är en uppsättning komponenter som tillhandahåller en tjänst(er) leveransarkitektur (såsom skapande av tjänster, sessionskontroll och protokoll) för en typ av tjänst som levereras till konsumenten, oavsett om det är en kund eller ett annat system. Även om det ofta används i telekommunikationssammanhang , kan det gälla alla system som tillhandahåller en tjänst (t.ex. VOIP-telefon, Internet Protocol TV, Internet Service eller SaaS ). Även om TM Forum (TMF) arbetar med att definiera specifikationer inom detta område, finns det ingen standarddefinition av SDP inom industrin och olika aktörer definierar dess komponenter, bredd och djup på lite olika sätt.

SDP:er kräver ofta integrering av IT-kapacitet och skapandet av tjänster som överskrider teknik- och nätverksgränser. SDP:er som är tillgängliga idag tenderar att vara optimerade för leverans av en tjänst inom en given teknologisk eller nätverksdomän (t.ex. inom telekommunikation inkluderar detta: webb, IMS , IPTV, mobil-TV, etc.). De tillhandahåller vanligtvis miljöer för tjänstekontroll, skapande och orkestrering och utförande. Återigen inom telekommunikation kan detta inkludera abstraktioner för mediekontroll, närvaro/plats, integration och andra kommunikationsmöjligheter på låg nivå. SDP:er är tillämpliga för både konsument- och affärsapplikationer.

Enbart inom telekommunikationssammanhang är affärsmålet med att implementera SDP att möjliggöra snabb utveckling och distribution av nya konvergerade multimediatjänster, från grundläggande POTS- telefontjänster till komplexa ljud-/videokonferenser för videospel med flera spelare (MPG). I SaaS-sammanhang uppnås liknande affärsmål men i en kontext som är specifik för den specifika affärsdomänen.

Framväxten av Application Stores , för att skapa, hosta och leverera applikationer för enheter som Apples iPhone och Google Android -smarttelefoner, har fokuserat på SDP:er som ett sätt för kommunikationstjänsteleverantörer (CSP) att generera intäkter från data. Genom att använda SDP för att exponera sina nätverkstillgångar för både interna och externa utvecklingsgemenskaper, inklusive webb 2.0-utvecklare, kan CSP:er hantera livscyklerna för tusentals applikationer och deras utvecklare.

Telekommunikationsföretag inklusive Telcordia Technologies , Nokia Siemens Networks , Nortel , Avaya , Ericsson och Alcatel-Lucent har tillhandahållit kommunikationsintegreringsgränssnitt och infrastruktur sedan början till mitten av 1990-talet. Den kostnadsbesparande framgången för IP-baserade VoIP- system som ersättningar för proprietära PBX-system (PBX) och stationära telefoner har lett till en förändring av industrifokus från proprietära system till öppna standardteknologier.

Denna förändring till öppna miljöer har lockat mjukvarufokuserade telekommunikationsföretag som Teligent Telecom och tillåtit systemintegratörer som Tieto , Accenture , IBM , TCS , HP , Alcatel-Lucent , Tech Mahindra , Infosys , Wipro och CGI att erbjuda integrationstjänster. Dessutom erbjuder nya konsortier av mjukvaruföretag för telekommunikation förintegrerade mjukvaruprodukter för att skapa SDP:er baserade på element, såsom värdeskapande tjänster, konvergent fakturering och hantering av innehåll/partnerrelationer.

Eftersom SDP:er kan passera teknikgränser blir ett brett utbud av blandade applikationer möjliga, till exempel:

  • Användare kan se inkommande telefonsamtal (trådlöst eller trådlöst), IM-kompisar (PC) eller platser för vänner (GPS-aktiverad enhet) på sin tv-skärm
  • Användare kan beställa VoD-tjänster ( Video on demand ) från sina mobiltelefoner eller titta på strömmande video som de har beställt som ett videopaket för både hemmet och mobiltelefonen
  • Flygbolagskunder får ett textmeddelande från ett automatiserat system angående ett flyginställt flyg och kan sedan välja att använda ett röst- eller interaktivt självbetjäningsgränssnitt för att boka om

Historia

I slutet av 1990-talet såg en period av aldrig tidigare skådad förändring av företagsapplikationer när greppet om klient-server-arkitekturer gradvis slappnade av och tillät ingången av n-nivåarkitekturer. Detta representerade tillkomsten av applikationsservern , en flexibel kompromiss mellan den dumma terminalens absoluta värde och den logiktunga klientdatorn. Även om deltagarna i applikationsserverringen var många och varierade, delade de gemensamma fördelar: abstraktion av databasleverantörer, programmeringsmodeller med öppen standard (oftast objektorienterade ), hög tillgänglighet och skalbarhet, och presentationsramverk, bland annat. Dessa omvandlingar utlöstes av affärskrafter inklusive den rasande flodvågen som var internetboomen, men inget av det hade varit möjligt utan spridningen av standarder som TCP/IP -protokollet, programmeringsspråket Java och webbapplikationen Java EE serverarkitektur. Det är mot denna omvandling som bakgrund som telekoms era av snabba förändringar sattes igång.

Fram till de första åren av 2000 var marknaderna för kommersiell och affärstelekommunikationsteknik fortfarande mättad med proprietär hårdvara och mjukvara. Öppna standarder började bli populära när IP-tekniker introducerades och med den snabba expansionen av Voice-over-IP (VoIP) för överföring av röstdata över paketnätverk och SIP ( Session Initiation Protocol ) för standardiserad mediekontroll, särskilt när det gäller företagsröst kommunikation.

I denna nya standardstödda miljö har konvergensen av röst- och datavärlden blivit mindre en moniker för katastrofala försök till telekom/IT-integrering och mer en verklig väg för produktion av nya och bättre konsument- och företagstjänster. De senaste åren har man sett introduktionen eller spridningen av olika SIP-programmeringsbibliotek (reSIProcate, Aricent , MjSip och dess härledda port av HSC) och produkter baserade på den relativt nya SIP-standarden och IP Multimedia Subsystem- standarden som definieras av 3GPP har vunnit ett stort följare. Service Delivery Platform, vars kraft till stor del kommer från kvaliteten och acceptansen av dessa stödjande standarder, vinner snabbt acceptans som ett allmänt tillämpbart arkitektoniskt mönster.

I dagens industri används flera definitioner av Service Delivery Platform (SDP) utan etablerad konsensus om en gemensam betydelse. På grund av detta, och behovet för tjänsteleverantörer att förstå hur man bättre hanterar SDP:er, TM Forum (TMF) börjat standardisera konceptet Service Delivery Framework (SDF) och SDF-hantering. SDF-definitionen tillhandahåller den terminologi och de begrepp som behövs för att referera till de olika inblandade komponenterna, såsom applikationer och möjliggörare, nätverks- och tjänstexponering och orkestrering.

Det som behövs för att leverera en blandning av personliga tjänster från flera SDP:er till slutanvändare är ett sätt att samarbeta dessa SDP:er genom gemensamma tjänsteaktiverare och nätverksresurser. Till grund för dessa tjänsteaspekter har dock varit ett grundläggande koncept att användarens attribut och de tjänster de får kräver ett gemensamt arkiv och en gemensam datamodell , såsom de som tillhandahålls av en LDAP/X.500-katalog eller HSS-databas. Tidiga SDP-implementeringar av denna karaktär startade i mitten/slutet av 1990-talet för konvergerade ISP-tjänster. Större och mer komplexa SDP:er har implementerats under de senaste 5 åren i miljöer av MSO-typ och för mobiloperatörer.

Sammanhang

SDP:er anses vanligtvis för miljöer av telekomtyp som ett kärnsystem som kopplar samman kundens access- och nätverksinfrastruktur med OSS-systemen och BSS-systemen. SDP:er i detta sammanhang är vanligtvis förknippade med en viss serviceregim såsom mobiltelefoner eller för konvergerade tjänster.

SDP:er beaktas också i samband med mycket stora omvandlings-, konvergens- och integrationsprogram som kräver en avsevärd budget. Svårigheten med sådana projekt är att det kan finnas hundratusentals design- och implementeringsbeslut som ska fattas - när väl arkitekturen väl är överens. Naturligtvis dikterar bara denna fråga behovet av mjukvaruutveckling och operativ ingenjörskompetens. Förmodligen är det bästa sättet att minska dessa design- och integrationsproblem att simulera SDP i ett småskaligt system innan det stora projektet faktiskt startar. Detta gör att arkitekturen kan verifieras att den uppfyller drift-, tjänsteleverans- och affärskraven.

SDP:er bör inte bara betraktas som en kärnfunktion inom en operatör utan som ett antal sammankopplade, distribuerade tjänstenoder (t.ex.) av redundansskäl och för olika tjänsteprofiler till olika affärs- och marknadssektorer. Många operatörer tillhandahåller produkter i kommersiell skala som paketerad röst, webbhotell, VPN, post, konferens och meddelandetjänster till myndigheter och företagskunder. Utvecklingen av sådana paketerade tjänster kan vara från fragmenterade hanteringssystem till en "virtuell privat tjänstmiljö" där operatören driver en dedikerad SDP för var och en av sina kunder som behöver deras tjänster på begäran och under deras kontroll.

SDP:er kan också användas för att hantera oberoende, trådlöst aktiverade områden som köpcentra, flygplatser, pensionärsbyar, vårdcentraler.

Element

Tjänsteskapande miljö

används en telekomprogramutvecklares primära åtkomstpunkt, miljön för skapande av tjänster (SCE, även applikationsskapande miljö eller integrerad utvecklingsmiljö ) av utvecklaren för att skapa programvara, skript och resurser som representerar de tjänster som ska exponeras. Dessa kan variera i komplexitet från grundläggande Eclipse-plugin-program till helt abstraherade, metadatadrivna telekomapplikationsmodelleringsapplikationer (som Avayas utgående CRM Central-produkt).

Syftet med SCE-föreningen är att underlätta ett snabbt skapande av nya kommunikationstjänster. Om man ignorerar faktorer som marknadsföring för tillfället, ju lättare det är för utvecklare att skapa tjänster för en given plattform, desto större blir antalet tillgängliga tjänster och därmed acceptansen av plattformen av den bredare telekommarknaden. Därför kan en leverantör av telekominfrastruktur få betydande fördelar med en SDP som tillhandahåller snabbt tjänsteskapande.

Utnyttjandet av konvergerade miljöer för skapande av Java EE och SIP-tjänster påskyndade antagandet av tjänsteleveransplattformar. Java-baserade applikationsutvecklare, traditionellt fokuserade på IT-applikationer, utvecklar kommunikationsapplikationer i realtid med hjälp av Java EE och nätverksanslutningsprotokoll som SIP och Parlay X webbtjänster. Programvaruleverantörer kombinerar dessa tekniker (t.ex. Oracle Jdeveloper och Oracle Communication and Mobility Server med grundläggande Eclipse-plugin) för att nå ut till en bredare utvecklarbas.

Utförandemiljö

Service Execution Environments (SEE) används för att utföra de kommunikationstjänster som utvecklats i SCE. Exekveringsmiljöer är vanligtvis utformade för att efterlikna den hårdvara som den specifika tjänsten förväntas köras på. SEE kan levereras med SCE som en IDE

Mediakontroll

Närvaro och plats

En aspekt av en SDP är att den måste vara centrerad kring den nya " närvaropunkten" . Detta är punkten för användaråtkomst till deras konvergerade tjänster där deras preferenser och rättigheter utvärderas i realtid. Behandling av preferenser och rättigheter säkerställer att användarens tjänster i deras enhets-/platssammanhang levereras korrekt. Eftersom rättigheterna är relaterade till operatörens produkt- och tjänstehanteringssystem, bör kärnarkitekturen för en SDP definiera hanterade produkter, tjänster, användare, preferens- och berättigandeprocesser.

Implementeringen av standarder förblir en kritisk faktor i närvaroapplikationer. Implementeringen av standarder som SIP och SIMPLE (Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions) blir allt vanligare. SIMPLE Presence tillhandahåller ett standardportabelt och säkert gränssnitt för att manipulera närvaroinformation mellan en SIMPLE-klient (watcher) och en närvaroserver (närvaroagent). Se JSR 164 för ENKEL närvaro. Leverantörer av SIMPLE Presence-servrar inkluderar Oracle och Italtel.

Integration

Användningen av standarder för exponering för gränssnitt över SDP:er och inom SDP bör minimera behovet av integration inom tre huvudområden: (1) södergående till underliggande kärnkomponenter i nätverket (2) mellan supportapplikationer som CRM, fakturering och tjänsteaktivering ( 3) tredjepartsapplikationer och tjänster. Implementeringen av tjänsteorienterad arkitektur (SOA) kan använda standardgränssnitt och webbtjänster.

Programvaruleverantörer inkluderar HP, wwite, IBM, Oracle och Sun microsystems. Nätverksutrustningsleverantörer tillhandahåller också SDP:er såsom IMS, IPTV, Mobile TV, etc. och erbjuder utvecklingen av dessa SDP:er.

Förhållande till SOA

Mycket har gjorts de senaste åren [ när? ] av konceptet Service-oriented architecture (SOA). Diskussioner som en gång kretsade kring Enterprise Application Integration) har flyttats till SOA-domänen, och gynnar idéer som tjänstesammansättning framför enkel meddelandeanpassning och extrahera, transformera och ladda tekniker.

SOA kan användas som en applikationsintegrationsteknik inom en SDP men tjänas bäst när de används i funktioner med lägre prestanda, såsom anslutningar mellan transaktions OSS- och BSS -applikationer och SDP. SOA behöver noggrant övervägas om de ska möta realtidskraven som ställs på SDP av de konvergerade händelsetjänsterna.

Ett analogt koncept till SDP som finns i SOA-området är Web Service Ecosystem (även känt som Web Service Marketplace) och SaaS-plattformen. Ett webbtjänstekosystem är en värdmiljö där deltagarna exponerar sina tjänster med hjälp av vanliga webbteknologier som HTTP , XML , SOAP och REST . Denna värdmiljö tillhandahåller ett antal tjänsteleveranskomponenter som täcker aspekter som autentisering, identitetshantering, användningsmätning och analys, innehållsanpassning, konvertering av dataformat, debitering och betalning. Detta gör det möjligt för tjänsteleverantörer att fokusera på sin kärnfunktionalitet och att lägga ut tjänsteleveransen till tredje part. Tjänster som distribueras över webbtjänstekosystem kan vara affärskritiska, men de har vanligtvis inte realtids- och högprestandakraven förknippade med telekommunikationstjänster för vilka SDP:er traditionellt utformas. De stöder vanligtvis vanliga affärsfunktioner som offerter, orderhantering, marknadsföringskampanjhantering eller kundvård. SOA kan också användas för att standardisera operativa processer och återanvända dem över SDP:er.

Genomförande av SDP:er

Betydande förändringar i IT- och nätverksarkitekturen krävs vid implementering av verkliga, realtidskonvergerade tjänster, operativa SDP:er. Många SDP:er är utformade som abstrakta ramverk med diagram som använder etiketter som "Service Abstraction Layer", etc. Inom riktiga system existerar inte sådana "lager" faktiskt. Dessutom är det svårt att utifrån abstrakta diagram inse vad den verkliga operativa datamodellen är och hur många servrar, databaser eller kataloger som kan användas eller integreras för att bilda konvergerade tjänster SDP och egenvårdsfunktioner. Operatörer kan ställas inför årliga elräkningar på flera miljoner dollar för sina system. Det följer att multi-server/multi-databas SDP:er inte är jordvänliga eller kostnadseffektiva, om samma funktioner kan integreras och drar mycket mindre ström.

Identitets- och informationshantering: För att specificera eller designa en SDP måste vi bestämma vad kund- och enhetsservicedimensionerna är. Om SDP-designen behöver rymma till exempel 1 miljon användare samt hantera deras enheter och varje identifierat objekt kräver 5 till 10 informationsobjekt, hanterar kärn-SDP förmodligen 20 miljoner objekt i realtid. Eftersom hanteringen av dessa objekt dikterar plattformens kärnidentitetshanteringsprocesser, bör kritisk uppmärksamhet ägnas åt sättet på vilket de implementeras. Erfarenhet har visat att en enskild användare på en konvergerad tjänst SDP kan kräva 100 objekt med information med vissa objekt som t.ex. inställningar som innehåller 100 attribut. Kapacitetskrav för 10 miljoner användare skulle indikera att plattformen behöver stödja 1 miljard objekt och upp till 50 miljarder attribut.

Gruppidentitet och berättigande: Traditionellt har vi hanterat identitetshantering som en enda användare eller enhet som loggar in med ett namn och lösenord och har antagit att en identitetsserver med namn och lösenord löser problemet. Praktiskt taget i MSO-världen har vi kontoinnehavare, sekundära kontoinnehavare (familjens barn), gäster, gåvor, innehåll, enheter, preferenser som alla måste länka ihop för att få en hanterad tjänst. Tjänsterna som den grupperade identiteten tar emot kan vara auktoriserade via namn och lösenord, men bör endast aktiveras genom rättigheter som hänför sig till produktförsörjning. SDP-arkitekturer måste rymma gruppidentitetshantering och produkt-/tjänsträttighetsfunktioner.

Närvaro och händelser: Närvaro är statushanteringen för alla onlinetillgångar. Men vad betyder detta för systemarkitekturer? Traditionellt har vi tillämpat ett "transaktionellt" paradigm där till exempel en användare loggar in och skapar en transaktion på en nätverksswitch, en webbserver eller databasapplikation. Närvarotjänster innebär att vi hanterar statushändelser till priser som är mycket, mycket högre än våra traditionella transaktionssystem. Frågan är: hur hanteras miljoner om inte miljarder händelser i fragmenterade system, flera databasarkitekturer eller i själva verket ramverk? SDP-arkitekturer bör också ha ett sammanhängande, högintegrerat evenemangshanteringssystem som en kärnfunktion.

Konvergerade identiteter: Ett operativt problem uppstår med 3G IMS och SIP och konvergerade tjänster. SIP kan tillämpa IP-adresser (IPv4 eller v6), SIP URI (e-postadresser) och SIP TEL URI:er (telefonnummer) i meddelandefälten Till, Från, Via och Kontakt. Sådana identifierare kan peka på en telefonenhet, en kylskåpsdörr, en innehållsgård, ett enda innehåll, en användare eller till och med en grupp användare. Denna flexibilitet innebär att ett SIP-samtal kan ringas från nästan vad som helst till vilken annan sak som helst förutsatt att den har rätt att göra det. Eftersom SIP kan tillämpa en blandning av dessa Internet- och telefonsystemidentifierare i samtalsprocessen, följer det att SDP måste koppla sin SIP-bearbetning tätt med DHCP-systemet och DNS, HSS-mobildatabasen, användarauktoriseringssystemet , närvarohändelsesystemet , användarens adressbok, bearbetning av telefonsamtalsfunktioner och operatörens service/produkthantering med dess berättigandesystem - allt i realtid. Det följer att sådan funktionalitet skulle vara mycket svår att tillämpa på många sammankopplade funktioner och fragmenterade databaser med hjälp av "SOA".

SDP-tekniker och verktygssatser bör ta itu med tre grundläggande frågor: [ citat behövs ]

  1. Vilka är de varor och tjänster som erbjuds och hanteras i realtid av operatören och av kundens egenvårdssystem - och detta inkluderar hanteringen av närvarobaserade tjänster (det händelsedrivna internets värld) och hur användarrättigheter i realtid behandlas.
  2. Vilken är den konvergerade tjänstinformationsmodellen som används i SDP-designen som representerar onlineverksamheten för operatören som har abonnenter, enheter, telefonsamtal, preferenser, rättigheter, adressböcker etc. att hantera. I många fall kräver MSO:er med bara 10 miljoner kunder en SDP med 500 miljoner informationsobjekt - och för att dessa objekt ska nås tusentals gånger i sekunden av många olika SDP-funktioner.
  3. Vilken är evenemangs-/närvarohanteringsarkitekturen som används i SDP-designen som hanterar hastigheten för affärshändelserna online. Situationen kan vara att befolkningen i en stad som kommer hem på natten kan generera miljarder onlinestatushändelser. Hur kommer dessa att behandlas av SDP?

Dessa tre stora systemkrav dikterar faktiskt arkitekturen för en verklig operativ SDP oavsett de "abstrakta etiketter" man tillämpar på dess logiska modeller, SOA, meddelandebussprotokoll och serversammankopplingar. Om dessa grundläggande krav utelämnas från SDP-designen lämnar det operatören med många affärs-, service- och operativa problem att ta itu med, såsom:

  • identitetshantering (av all information i SDP som representerar operatörens onlinetillgångar),
  • SDP:s tjänsteflexibilitet (det vill säga att produkten och tjänsterna som erbjuds är hårdkodade i SDP så att nya tjänster orsakar koduppgraderingar) och;
  • fasta egenvårdsinrättningar (ingen flexibilitet eller hänsyn till SDP:s användare såsom språk, ålder, seende, preferenser, etc.).

I vissa situationer har MSO:er miljontals rader av hårdkodade produkt- och tjänstehanteringsflöden i sina system och kan inte enkelt flytta till de nyare konvergerade tjänstedimensionerna.

Ett snabbt test av en SDP-design är att utvärdera dess informationsmodell och se om den är baserad på användarmiljöerna för konvergerade tjänster, och se hur den modellen används och hanteras av alla system som behöver inkludera dess närvaro- och händelsehanteringsfunktioner. .

Till stöd för SDP-utvecklingen och utvecklingen till realtids, smidig tjänsteleverans, bör nästa generationssystem övervägas .

Se även

Hämtad från " https://en.wikipedia.org/w/index.php?title=Service_delivery_platform&oldid=1099188541 "