Instant News - ett koncept för realtidspush. Peter Antman

Instant News - ett koncept för realtidspush Peter Antman

2

Innehåll 1 Sammanfattning 5 2 Vad är Instant News? 7 2.1 Vad är unikt med Instant News?................................ 7 2.2 Vilka tjänster transformerar Instant News?........................... 7 2.2.1 Bevakningar...................................... 7 2.2.2 Push........................................... 8 2.2.3 Instant Messaging................................... 9 2.3 Hur löser Instant News dessa problem?............................. 9 2.3.1 Jabber.......................................... 10 2.4 XML och Message-oriented Middleware............................ 10 3 Övergripande teknisk beskrivning 11 4 Användningsfall 13 4.1 Bertils bostadsservice...................................... 13 4.2 Dagens Allehanda........................................ 13 5 Affärsmöjligheter för Instant News 15 5.1 Roller.............................................. 16 5.1.1 Koncept- och produktutvecklare............................ 16 5.1.2 Implementatör..................................... 16 5.1.3 Användare....................................... 16 5.2 Vad ligger störst potentiellt mervärde?............................. 16 5.3 Risk............................................... 17 5.3.1 Två hot finns mot det unika i konceptet........................ 17 6 Tekniskt beskrivning 19 6.1 In-kanal............................................. 19 6.2 Filtrering/Bevakning...................................... 19 6.3 Utskick............................................. 21 3

4 INNEHÅLL 6.4 Användarhantering....................................... 21 6.5 Formateringsmodul....................................... 21

Kapitel 1 Sammanfattning Detta PM beskriver en nyupptäkt teknisk möjlighet att pusha personaliserat innehåll till kunder. Det beskriver också den plattform vilket möjliggör detta och affärsmässiga möjligheter med konceptet. 5

6 Kapitel 1. Sammanfattning

Kapitel 2 Vad är Instant News? Instant News är arbetsnamnet på ett koncept och en teknisk plattform/produkt som genom att föra ihop ett antal disparata och hittills inte för detta syfta använda tekniska lösningar i en produkt gör det möjligt att i realtid välja ut/personalisera nyheter eller annan nyhetsinformation så som aktiekurser eller bostadsannonser och skicka dem direkt till intressenten på den plats där han för tillfället befinner; och detta utan att man själv behöver bygga ifrastrukturen för detta. Det kanske mest träffande sättet att beskriva Instant News är att det är en sökmotor som söker av framtiden och skickar träfflistan direkt till den som söker när sökvilkoren (någon gång i framtiden) uppfyllts. 2.1 Vad är unikt med Instant News? Det unika med Instant News är att den innebär en lösning på ett sedan länge olöst problem, nämligen att i realtid kunna skicka information till en mottagare utan att denne själv behövt söka upp infornationen aktivt och att man kommer kunna veta när man skickar informationen att mottagaren är närvarande i andra änden. Det välkända namnet på detta önskemål är Push. Problemen med Push-teknologier har dock varit notoriska och det finns ingen av oss känd väl fungerande lösning för en masspublik i dag. Genom att föra ihop ett antal disparata tekniska lösningar och produkter - som i dag inte (ännu) utnytjas tillsammans - från å enda sidan konsumentmarkanden och å andra sidan den mer tunga företagsmarknaden, kan Instant News presentera en lösning på pushproblemet. 2.2 Vilka tjänster transformerar Instant News? Ett sätt att bättre förstå Instant News är att förstå vilka olika typer av tjänster och behov som Instant News för samman i ett koncept och hur det löser problem som plågar dessa tjänster i dag. Vi kan identifiera tre typer av tjänster: bevakningar, push av innehåll och Instant Messaging. 2.2.1 Bevakningar En populär tjänst på Internet är olika typer av bevakningar. En bevakning innebär typiskt att en intressent kan ställa upp ett visst sökvilkor för någon form av innehåll, så som innehållet i en nyhet, en viss typ av bostad, ett pris på en produkt, en aktiekurs eller liknande. När detta sökvillkor (tröskel) uppfylls någon gång i framtiden skickas ett meddelande till intressenten. Enligt vår erfarenhet plågas emellertid bevakningstjänster av tre notoriska problem: sökning, realtid och push. 7

8 Kapitel 2. Vad är Instant News? Problemen med sökningarna är måhända av teknisk natur, men vår erfarenhet säger oss att de flesta bevakningstjänster är uppbyggda på så sätt att de med jämna mellanrum söker av en befintlig informationsmängd, ett exempel är att bevakningstjänsten med jämna mellanrum ställer en fråga (en fråga eller fler per bevakande intressent) mot en relationsdatabas och rensar ut alla träffar som är äldre än ett visst datum eller klockslag. Ett exempel på en tjänst som fungerar så är DN bostad. I praktiken innebär detta att sökningen görs mot ett historiskt material. Förvisso kan man teoretiskt tänka sig att sökningarna görs så frekvent (under en minut) att materialet aldrig kommer upplevas som gammalt. Det finns emellertid en inbyggd begränsning som gör att denna typ av sökningar skalar dåligt. Ju större informationsmaterialet blir och ju fler som söker desto längre tid tar hanterandet av bevakningarna, oberoende av om hårdvara uppgraderas eller nya sökalgoritmer introduceras. Innebörden av detta är att denna typ av bevakningar de facto inte kan ske i realtid, utan med vissa förbestämda intervall (med ofta ganska långa avstånd emellan). Med riktigt stora informationsmängder kan det innebära att en bevakning måste göras på ett dygns gammal information och att olika intressenter kommer få infromationen i en bevakning med upp till flera timmars förskjutning. För att göra en bevakning intressant måste resultatet också skickas till intressenten. En bevakning där intressenten med jämna mellanrum själv måste kontrollera om något resultat har inkommit är inte särskilt intressant. Det innebär att bevakningssystem måste ha någon form av pushfunktionalitet. Det vanligaste sättet i dag att skicka en bevakning är via mail (alternativt SMS). Mail en är väl fungerande Pushkanal som massmedium, dvs den fungerar stabilt, man behöver inte bygga någon egen infrastruktur och alla har redan mailfuktionalitet. Som realtids-pushkanal innehåller den emellertid flera begränsningar. För det första tar mail tid, ibland går det fort, men i bland kan utdelandet av ett mail ta flera timmar. För det andra finns det ingen metod att veta att intressenten verkligen läser sin mail eller har tillgång till den i realtid: mail måste nämligen alltid hämtas. Det innebär att ett mail ur mailfunktionalitetens perspektiv kan ha kommit fram till brevlådan, men att ingen har hämtat det. SMS har bättre realtid, men dess användbarhet begränsas av att det kostar pengar att skicka ett SMS, vilket gör det till en dyr tjänst - om man ens kan hitta ett sätt att ta betalt för SMS. Det är också ett begränsast format, vilket gör fortsatt användande av informationen till en knölig process för den som får bevakningen skickad till sig, så som att följa en länk, titta på en annons eller spara innehållet. 2.2.2 Push Därmed kommer vi till problemen med push. En rad olika försök har gjorts att komma runt begränsningarna med World Wide Web (att det alltid är klienten/intressenten som måste inleda förbindelsen) och med mail som innehållskanaler. Problemet med samtliga lösningar är att de hittills alltid har krävts att kunden/intresenten skaffar ett för tjänsten specifikt program för att kunna få innehåll från en viss leverantör av innehåll. Tyiska exempel var Microsoft kanaler som krävde Internet explorer, 25 timmar som krävde en egen klient, eller en lång rad av andra specialiserade tjänster som kräver att man använder deras java-applet eller någon annan specialskriven programvara. Ur ett leverantörspespektiv innebär det att för att kunna tillhandahålla innehåll som pushas till intressenterna så måste man samtidigt utveckla sin egen programmvara och få intressenterna att installera denna, vilket för med sig höga utvecklings- och underhållskostnader. Ur intressenterna perspektiv innebär det att man måste installera och lära sig använda en mängd olika program, varav flera kommer ha dålig funktionalitet eftersom de skapats av företag som egentligen inte är mjukvaruföretag. En god tumregel är att konsumenter inte kommer vilja ha och inte kommer att använda mer en högst en handfull program för sin informationsinhämtning och bearbetning. Man har ett mailprogram, en web-browser, en ordbehandlare och kanske en mobiltelefon eller handdator. Olika Pushteknologier har kommit och sedan snabbt försvunnit de senaste åren. Den senaste produkten med

2.3. Hur löser Instant News dessa problem? 9 hög hypefaktor är WAP. I det senaste WAP protokollet ingår möjligheten att också skicka innehåll direkt till en Wapkompatibel mobil enhet. Denna funktionalitet inom WAP är lovande, men den lider också av begränsningar. I dag finns varken den nätmässiga infrastrukturen hos telefonoperatörerna eller ens några mobila enheter som hanterar denna nya standard. Även på flera års sikt kommer WAP-baserade push-lösningar lida av dålig spridning till konsumenter. På tre till fyra års sikt räknar mobiloperatörerna att hälften av alla som är uppkopplade mot Internet kommer att vara det från en mobil enhet. Detta är nu enbart en beräkning, men även om den skulle slå in innebär det fortfarande att hälften är uppkopplade via en klassisk dator - en stor publik med andra ord. Troligt är också att framtidens mobila enheter allt mindre kommer likna dagens mobiltelefoner och alltmer likna dagens datorer i termer av funktionalitet; troligtvis innebär det att de kommer innehålla samma applikationer som dagens och framtidens datorer har eller kommer att ha. Samma villkor som gäller för datorer i dag kommer således gälla också för de mobila enheterna i framtiden: ett antal standardapplikationer vilka inte nödvändigtvis är levererade av den som levererat den mobila enheten. Pushteknologier har därmed inte kunna bli ett äkta massmedium, utan bara en specialtjänst för extra intresserade och motiverade. Konsten att få push att fungera vore således att kunna använda sig av någon konsumentteknologi/produkt som redan har massspridning. 2.2.3 Instant Messaging Denna vitt spridda konsumentprodukt skulle kunna vara det som går under samlingsnamnet Instant Messaging. Ett Instant Messaging system består grovt sätt av två komponenter. Dels kan man lägga upp en lista över vilka kamrater som man är intresserad av att känna till när de är uppkopplade till Internet/befinner sig vid sin dator. Man kan så att säga prenumerera på deras närvaro. Dels är det en infrastruktur att skicka meddelanden till sina kamrater i realtid med garanterad framkomst till mottagaren. I vissa Instant Messaging system finns chat-liknande funktionalietet så att mottagaren till och med ser meddelandet växa fram i samma stund som det skrives ner. Det mest kända exemplet på ett Instant Messaging system är ICQ (I seek you), men det finns flera andra så som AOL Instant Messaging, Microsoft Messanger, Yahoo!. Dessa används i dag av miljontals människor världen över. För unga människor har ett Instant Messaging program blivit en standard konsumentprodukt som finns och flitigt används på datorn. I dessa Instant Messaging system finns infrastrukturen för väl fungerande Pushtjänster. Varför är detta ändå nytt, varför används inte dessa massmedium till detta redan i dag? Det finns troligen två svar på detta: För det första är Instant Messaging till stor del en ungdomskultur - en avancerad chat där man snackar med sina kompisar över Internet. Från det mer affärsinriktade internetutvecklingsperspektivet har detta varit ett negligerat och ointressant område; en subkultur utan varken tekniska eller affärsmässiga utmaningar. Bakom ryggen på dessa har emellertid dess popularitet bland unga konsumenter inneburit att en infrastruktur för push byggts upp. Detta är emellertid troligtvis inte det ända skälet. Även om ICQ och AIM var och en används av en mycket stor skara, så kan de inte prata med varandra. Så som fenomen har med andra ord Instant Messaging fått stort genomslag, men det har inte skapat en standardprodukt. Att använda Instant Messaging som kanal för push innebär således att man måste stödja flera disparata produkter, med olika - och proprietära - protokoll. Ett annat, ännu icke kontrollerat skäl, kan vara att det för dessa system råder begränsande licensvillkor, vilket skulle göra det svårt att använda dem i kommersiell verksamhet. 2.3 Hur löser Instant News dessa problem? Instant News konceptet innebär att lösningar som traditionellt används i tunga affärssystem för klinent/serverprogrammering gift ihop med ett redan befintligt meddelande system som kan kommunicera med alla de olika

10 Kapitel 2. Vad är Instant News? proprietära meddelandesystemen. 2.3.1 Jabber Kärnan i denna lösning är baserad på open source Instant Messaging systemet Jabber. Jabber har utvecklat av entusiaster i två år. Jabber är vid första påseende ett Instant Messaging system som alla andra, bara open source. Men Jabber är mer än så. Det så kallade protokollet för att prata med systemet är öppet och baserat på XML. Vem som helst kan relativt enkelt kommunicera med systemet. Det finns i dag Jabber klienter för i princip varje upptänklig plattform. För det andra kan Jabber kommunicera med andra Instant Messaging system. Jabber kan på så sätt fungera som en knutpunkt. Via Jabber går det att nå användare i ICQ, AIM och flera andra system; nya system tillkommer hela tiden. Jabber löser alltså ett av de svåraste prolemen inom Push: att basera den på något som användarna redan har. Till exempel kommer det att gå att skriva en transport för WAP när den slår igenom. På detta sätt får man en universiell plattform för att nå användare med information i realtid; WAP blir ur detta perspektiv enbart ett specialfall - ett av många sätt som en person kan göra sig tillgänglig för realtidsinformation. 2.4 XML och Message-oriented Middleware Jabber är emellertid i sin nuvarande utformning inte möjligt att använda för att realisera hela den funktionalitet som finns i Instant News konceptet. Genom att föra samman Jabber med en modell hämtad från det som kallas Message-oriented middlerware system får man ett system som kan bevaka information i realtid och skicka den (vid träff) direkt till den plats där användaren för tillfället benner sig.

Kapitel 3 Övergripande teknisk beskrivning Här ges en övergripande beskrivning av de delar som ingår i Instant News plattformen. Grovs sätt består systemet av följande komponenter: En in-kanal dit olika content providers skickar sitt innehåll, de publicerar sin information till en plats, i ett format, utan att behöva bry sig om hur det skall föras ut vidare till slutanvändaren. Funktionalitet - t. ex en websida - där en användare kan registrerar sig. Här kan användaren dels fylla i vilken typ av innehåll den vill ha och ställa upp tröskelvillkor - söka in i framtiden - för när ett visst innehåll skall sickas till denne. Här kan användaren också ange alla de kanaler den finns tillgänglig via och sätta olika former av prioriteringar mellan dessa. Dessa användare blir då internt i systemet prenumeranter till de olika in-kanalerna. I modern Messageoriented Middelware finns denna funktionalitet innbyggd. Denna är också baserad på möjligheten att filtrerar (söka av) informationen i realtid och enbart skicka vidare den information prenumeranten vill ha. Som redan visats saknar dessa system möjligheten att på ett standardmässigt sätt kommunicera innehållet/prenumerationen till klienten. Här kommer Jabber in. En prenumerationsservice ser till att när ett meddelande slunkit igenom den från in-kanalen till en specifik användare, så kontrollerar den via Jabber hur (om alls) användaren för tillfället är uppkopplad, anpassar medelandets utforming till kanaltypen och skickar det direkt till användaren. I ett effektivs system innebär det att användaren kommer få nyheter, information om nya bostäder, att en aktie under- eller överstiger ett visst pris inom loppet av någon sekund från det att innehållet publicerats på inkanalen! 11

12 Kapitel 3. Övergripande teknisk beskrivning

Kapitel 4 Användningsfall För att göra Instant News mer förståligt ges här två exempel på hur ett sådant här system praktisk skulle kunna fungera. 4.1 Bertils bostadsservice Bertils bostadsservice har som affärsidé att förmedla bostadsmäklares bostadsannonser på nätet. Detta betalar mäklarna för att Bertil gör. För att öka värdet på sin tjänst till mäklarna vill Bertils bostadsservice ha Instant News. Hos Bertils bostadsservice kan mäklarna bara lägga in annonser genom en applikation som Berils bostadsservice skapat. För att möjliggöra Instant News läggs funktionalitet till denna klient. Varje gång någon lägger in ett bostadsobjekt publicerar detta också i ett XML format till en intern Instant News kanal hos Bertils bostadsservice. Berils bostadsservice skapar också en website där personer som söker bostad kan registera en bevakning. De gör det via att skapa ett användarkonto och fylla i information om hur det kan bli nådda. Bostadssökare Unge Nisse kan där ange att han har en ICQ identitet som han vill få sina bevakningar skickade till. Affärsmannen Roger anger att han vill ha bevakningen till sin WAP telefon när den är tillgänglig, till sitt AIM konto om WAP telefonen inte går att nå, och till sists till sin mailadress om inte de andra finns tillgängliga. På sidan kan användarna också ange en eller flera villkor för när de vill bli notifierade om en bostad, tex läge, pris, storlek eller dyligt. När en bevakning skickas ut ges en förkortad beskrivning av funna objekt, samt en länk som fungerar med den klient till vilken bevakningen skickats som tar kunden vidare till den website Bertils bostadsservice har för sina bostadsannonser. 4.2 Dagens Allehanda Dagens Allehanda är en tidning som vill utnytja värdet i sitt innehåll och dess goda relationer med sina annonsörer. För att öka möjligheten att sälja annonser vill de utöka sin förmåga att leverera sitt innehåll till fler; de väljer Instant News för detta. Hos Dagens Allehanda finns tyvärr flera system som hanterar innehåll internt, ett för papperstidningen, ett för deras website och ett för att hantera telegram. Dagens Allehanda skapar en nyhetskanal där alla deras nyheter 13

14 Kapitel 4. Användningsfall internt publiceras och som Instant News system använder som indata. Funktiknalitet läggs till i de befintliga systemen så att de kan skicka det innehåll som produceras till en intern Instant News kanal. En användare hos Dagens Allehanda måste inte bara fylla på vilket sätt nyheter skall nå honom, han eller hon måste också fylla i uppgifter som sig själv. Här fyller man också i vilken typ av filtrering av nyheter man är intresserad av, så som Sport-Fotboll-Djurgården. Dagens Allehanda lever på sina annonsintäkter, så varje nyhet som når en anvädare kommer också innehålla en annons. Genom att användaren fyllt i information om sig själv och även implicit angivit sina intressen via urvalkrieriet skickar Dagens Allehanda med personaliserade annonser, som de kan ta bra betalt av sina annonsörer för. Dagens Allehanda skickar bara en länk till en personaliserad del av sin site där användaren kan läsa den eller de nyheter den fått ut meddelande om i sin bevakning.

Kapitel 5 Affärsmöjligheter för Instant News I ovanstående användningsfall framskymtar en del av de affärsmöjligheter som finns med Instant News. Vi tror att Instant News potentiellt är värt en substantiellt summa pengar om man använder idén rätt. För att förstå vilka intäktsmöjligheter som finns bör vi emellertid lite striktare dela upp de olika typer av intäkter som finns och vilka olika typer av roller som man kan ha gentemot Instant News. Vi bör också betrakta en riskt som finns knuten till Instant News. För det första bör man åtskilja hur man tjänar pengar på Instant News från hur man tjänar pengar genom Instant News. Det första handlar om hur den som skapar Instant News kan tjäna pengar, det andra om hur de som på olika sätt använder Instant News kan tjäna pengar. För det andra bör man klargöra de olika roller man kan ha gentemot Instant News. Här kan vi skönja följande roller: koncept- och produktutvecklare Denna roll tillkommer de som kommit på iden bakom Instant News och utveckling av själva produkten Instant News. Implementatörer Instant News kommer alltid behöva specialanpassas för olika typer av kunder. En implementatör är den som på konsultbasis bygger en Instant News lösning för en specifik kund. Användare En användare är en innehållsleverantör - med eget eller syndikerat innehåll - som vill ha en unik tjänst för sina användare. Slutanvändare Denna får resultatet av Instant News skickat till sig. Vi räknar inte vidare in denne i affärsbeskrivningen. Dessa roller och de olika sätten att tjäna pengar är analytiska distinktioner och behöver således inte innebära att inte samma företag kan uppehålla flera roller. 15

16 Kapitel 5. Affärsmöjligheter för Instant News 5.1 Roller 5.1.1 Koncept- och produktutvecklare Det kanske mest närliggande exemplet på hur produktutvecklarna kan tjäna pengar är genom att de skapar en mer eller mindra prepaketerad produkt som de sedan säljer till användare. Det finns emellertid flera alternativa och/eller parallella sätt att få värdetillväxt på uppfinningen Instant News. Ett sätt är att bygga ett företag runt konceptet och sattsa på att detta företag blir uppköpt av ett större företag som ser värdet i Instant News. En annan variant är att utveckla konceptet precis så lång att det går att sälja det till något företag som skulle kunna ha stor nytta av det, till exempel en nyhetsportal som Avantgo. 5.1.2 Implementatör Genom att vara kunnig i Instant News finns också en marknad för konsulttjänster genntemot kunder som vill ha Instant News som en funktion i sina tjänster. Här kan man både tänka sig konsultverksamhet som är baserad på en redan befintlig produktifiering av Instant News. Det går förstås också att tänka sig att Instant News aldrig produktifieras och att uppfinnarna i ställer använder idén bakom för att under en tid erbjuda en unik lösning till en mindra krets av kunder, för att sedan - i konkurrent med andra som också kommer börja bygga liknande system baserad på samma ide - göra det till alla som vill ha hjälp med Instant News funktionalitet. 5.1.3 Användare En användare är någon som använder Instant News - via produkten, specialbyggd medhjälp av konulter eller internt - i sin verksamhet som ensam eller som en av flera tjänster. En användare är typiskt någon som vill leverera innehåll i realtid enligt urval till en masspublik, så som en tidning, en bostadstjänst, en börsstite. En användare behöver nödvändigtvis inte vara den som själva äger eller producerar innehållet utan kan också vara en portal som samlar innehåll från många leverantörer, i en eller flera kategorier. Instant News passar väl för denna typ av användare eftersom dess infrastruktur är byggd för att det skall vara lätt att låta många olika leverantörer av innehåll för en viss kategori publicera sitt innehåll gentemot en Instant News motor. 5.2 Vad ligger störst potentiellt mervärde? Det är naturligtvis svår att avgöra vilken typ av användande av Instant News som skulle genererar störst mervärde. Givet att man under en viss tid kan äga marknaden för Instant News är vår gissning att följande två kategorier har möjligheten till störst värdetillväxt: - Antingen en produktifiering av Instant News i ett externt bolag som efter uppbyggnad säljs till ett större företag som kan använda den i sitt eget utbud alternativt sälja produkten. - Eller att man (oberoende av produktifiering) själv eller med en eller flera sammarbetspartners bygger en informationsportal som samlar information från många olika håll och som använder Instant News för att tillhandahålla en unik tjänst. För att lyckas med detta måste ett antal samarbetskontrakt slutas innan portalen och den underliggande teknologin blir känd ( det är förstås högst troligt att också en sådan tjänst skulle kunna vara ett önskvärt uppköpsobjekt för ett antal internationella aktörer). Minst värdetillväxt får man om konceptet enbart utnytjas för att under en kortare tid bygga tjänster på konsultbasis åt en mindre grupp kunder. Detta av tre skäl: man får bara betalt för implementation och inte för det unika i idén, andra kommer snart kunna bygga liknande system, det finns inget bestående värde som kvarstår efter att konsulttänsten är utförd.

5.3. Risk 17 5.3 Risk Detta för oss över till en riskt som måste tas i beaktande, och som kan påverka strategiska val för en affärsmodell runt Instant News. Konceptet bakom Instant News är för tillfället unikt. Enligt vår bedömning kan det förbli unik under en kortare tid beroende på att det bara är möjligt att formulera idén om man har insikt i en rad disparata värdar: ungdomsvärdens Instant Messaging, open source implementationen Jabber, J2EE och andra typer av affärssystem, önskemålen hos innehållsleverantörer, problemen med de befintliga bevakningssystemen och annonsmarknaden. 5.3.1 Två hot finns mot det unika i konceptet För det första finns det säkert ett fåtal till i världen som sitter inne med samma typer av information och utifrån det kan formulera en liknande eller alternativ lösning. Vår bedömning är att vi har cirka 6 månader på oss ur det perspektivet. För det andra kommer eventuellt offentliggörande av koncepter att sätta igång en jakt på hur lösningen är skapad hos andra på marknaden. Instant News är ett koncept av den typen som när det väl blir bekant upplevs som fullt naturlig. Om ett år kommer alla tro att denna form av tjänst alltid funnits. Detta gör att det är viktigt att formulera sin affärsmässiga strategi runt Instant News innan man ger spridning åt idén till en större krets.

18 Kapitel 5. Affärsmöjligheter för Instant News

Kapitel 6 Tekniskt beskrivning Flera delar av Instant News kan lösas/implementeras på olika sätt, alla subsystem är heller inte helt färdiggenomtänkta. Den beskrivning som här följer skall således betraktas som en möjlig variant av flera. Instant News innehåller följande komponenter/subsystem: in-kanal för innehållsleverantörer, intern filtrering av publicerat innehåll, användarhantering där användare anger vart de vill ha sin information och hur den skall filtreras, formatering av innehåll beroende av vart information skall skickas, utskickning av innehåll till mottagare. 6.1 In-kanal In-kanal systemet baseras på modern Message-oriented middleware koncept. Två standard API-er bör väljas, dels Java Messanges Service (JMS), dels en SOAP baserad väg in för de som inte hanterar Java. En inkanal är konceptuellt en Topic som en Publisher publiserar sitt innehåll till. Detta innehåll skall vara format i XML enligt en för innehållskategorien specifik document type definition, till exemple nitf för nyheter. Leverantören av innehåll känner således enbart till en enda kanal till vilken den levererar/publicerar sitt innehåll. Om man följer JMS konceptet så finns ytterligare en typ av användare av en kanal/ett topic, nämligen en eller flera subscribers (prenumereanter). I JMS finns också möjligheten att för en subscriber specificera ett urvalskriterium. Det vill säga, ett publicerat meddelande skickas bara ut till de subscribers som har ett filtreringsvillkor som uppfylls av det publicerade meddelandet. Utifrån detta perspektiv skulle således själva filtreringen kunna utföras av ett JMS kompatibelt system. Emellertid har JMS en svaghet. Det finns ingen inbyggd hantering av XML. Filtreringen kan heller inte göras av själva meddelanden utan bara på speciell iformation i huvudet på meddelandet. Detta innebär till exempel att det i JMS inte är möjligt att filtrerar på innehållet i en nyhetstext. 6.2 Filtrering/Bevakning Filtrering läggs därför i en egen del. Dess API är gömt för leverantören av data, intern används dock en open source implementation av ett Message-oriented middleware system, xmlblaster. Detta är helt baserat på XML och kan via frågespråket XPath filtrerar direkt i det publicerade XML innehållet. Praktiskt skulle en sådan implementation skapas genom att en xmlbaserad publisher-komponent prenumerarer på inkommande data på in-kanalen för en viss kategori och återpublicerar denna internt. Användare som 19

20 Kapitel 6. Tekniskt beskrivning

6.3. Utskick 21 lagt in en bevakning grupperas efter deras fråga (alla med samma fråga hanteras i denna del som samma användare) och en prenumeration sätts upp mot den interna kanalen. 6.3 Utskick Den som representerar frågegrupperna är utskicks systemet. Det innebär att när xmlblaster släpper igenom en nyhet hamnar den i utskicksystemet. Denne vet vilka användare som är knutna till en viss prenumeration. Via användarhanteringen kontrollerar den hur de olika användarna vill ha sina bevakningar utskickagade. Utskicksmodulen använder sedan Jabber för att för varje användare kontrollera om den är närvarande på någon av de platser den angivit. När den fått ett svar på vilken typ av klient användaren är närvarande vid använder den formateringsmodulen för att device-anpassa meddelandet och lämnar sedan över till Jabber för att skicka det vidare till slutanvändaren. 6.4 Användarhantering Denna är en normal användarahantering med web-gränssnitt, eller annat gränssnitt som passar tjänsten, tex wap. 6.5 Formateringsmodul Även formateringsmodulen är något som kan byggas med kända tekniker. Eftersom de möjliga valen av device att skicka innehållet till måste vara känt innifrån system finns det inga tekniska problem att implementera denna.