Skip to end of metadata
Go to start of metadata

Content Studio har en övergripande arkitektur som kan indelas i fyra stycken skikt eller applikationsroller. Den första och den som användare kommer i kontakt med är klientrollen. Administratörer på företaget kommer dessutom ofta i kontakt med de roller som utgörs av serverkomponenterna - de som serverar data och tjänster till användaren. Dessa är i allmänhet installerade på en eller flera servrar på nätverket antingen lokalt som i fallet intranät eller som ett fjärrnätverk om det är fråga om en webbplats. Det tre serverrollerna är webbservern som tar emot anrop och returnerar färdigt data, Content Studio server som fungera som länk mellan den intelligenta databasen och webbservern och slutligen databasen själv som har en central roll i Content Studio.

Klienten – konsumenten

Den i särklass vanligaste klienten eller datakonsumenten i Content Studio är webbläsaren. På en webbplats kan den vara de flesta på marknaden förkommande läsare ex. Internet Explorer, Mozilla eller Opera. Är webbplatsen ett intranät där man önskar s.k. single sign-on med individuell användaridentifiering mot nätverket fungerar för närvarande bara Internet Explorer på grund av de stor krav detta ställer på webbläsaren. Det samma gäller för det administrativa gränssnittet Content Studio. Webbläsare sammanställer de åtgärder som användare önskar göra ex. titta på ett dokument eller spara en ändring i en artikel och skickar dessa till nästa roll i kedjan - webbservern.

Webbserver - sammanställaren

Webbservern tar emot förfrågningar från konsumenterna och skickar dessa vidare till Content Studio server för vidare bearbetning. Content Studio server svarar med strukturerat oformaterat data som sedan sammanställs till webbsidor som kan tolkas av klienten. Det administrativa gränssnittet fungerar på ett delvis annorlunda sätt. Detta utgörs av statiska XHTML-sidor med en stor mängd logik i form av javaskript som körs hos konsumenten. Då konsumenten kräver nytt data laddas inte sidorna om utan förfrågningar kan ske direkt utan omladdning mot CSWS (Content Studio Web Services) i form av XML. Då svaret i form av XML kommer tolkas detta direkt av webbläsaren utan att webbservern levererar någon ny sida varpå webbläsaren bygger om den redan laddade sidan dynamiskt. Detta gör att klienten upplever det administrativa gränssnittet mycket likt ett ordinarie Windowsprogram. Detta sätt att arbeta stöds bara av Microsoft Internet Explorer. Webbserver står i intim förbindelse med Content Studio server via den centrala modulen CSAPI (Content Studio Application Programming Interface). 

Microsoft Internet Information Server

Microsoft Internet Information Server (IIS) är en del av operativsystemen Windows 2003 Server och Windows 2008 Server och utgör webbserver för Content Studio. Microsoft IIS är väl integrerad med operativsystemet och är en stabil och flexibel miljö för webbapplikationer som exempelvis Content Studio.

Samverkan med CS API och CS Administrativa gränssnitt

All kommunikation med webbklienter (webbplatsbesökare, administratörer och externa webbtjänster) sker via Microsoft IIS. De sidor som genereras av Content Studio och de som ingår i Content Studio administrativa system exekveras under Microsoft IIS. Resultatet av exekveringen returneras normalt till klienten som HTML eller XML. Inget data kan skickas till klienten eller till Content Studio via HTTP, utan att passera Microsoft IIS.

Många av Content Studios funktioner bygger på olika direktanrop till Content Studio API. Detta gäller både Active Scripting komponenter och Content Studio administrativa gränssnitt. I de flesta fall hanteras detta via direkta anrop till de COM+ objekt som installerats för Content Studio, men i många fall sker det via anrop till HTML- eller ASP-sidor som i sin tur kommunicerar med Content Studio API.

Remoting/COM-objekt och CS API

Content Studio v4.x

En webbplats skapad i Content Studio v4.x utnyttjar i stor utsträckning de COM-objekt som utgör kärnan i Content Studio. Detta sker genom användning av Active Scripting komponenter eller genom direkta anrop via COM+ eller via HTTP. Anrop mot Content Studio API kan ske via i stort sett alla programmeringsspråk; VB-script, JavaScript, C++, Delphi, Visual Basic, C# m fl.

I Content Studio v4 har merparten av de publika API-anropen kapslats in i motsvarande asp-sidor. Detta gör det möjligt att kommunicera med en webbplats och dess bakomliggande API med hjälp av endast HTTP-protokollet och port 80 vilket underlättar integration mellan olika tjänster. ASP-sidor hanterar automatiskt sessionshantering och alla säkerhetskontroller.

Content Studio v5 .NET

COM-objekten är i Content Studio v5 .NET ersatta av ett ramverk helt skrivet i .NET Framework 2.0 och som anropas via Remoting-teknologin som är inbyggd i .NET Framework. Content Studio ramverk (Content Studio Server), är ett publikt API som är väl dokumenterat och kan anropas från alla .NET-språk ex. C#, VB.NET, Managed C++, J#, Delphi.NET, Eiffel mm. En framtida version av CS API kan komma att använda den nya WCF (Windows Communication Foundation) vilken använder samma underliggande teknologi med abstraherar kommunikationen yttterligare för att underlätta för anroparen.

I Content Studio v5 .NET har merparten av de publika API-anropen kapslats in i motsvarande ASPX-sidor. Detta gör det möjligt att kommunicera med en webbplats och dess bakomliggande API med hjälp av endast HTTP-protokollet och port 80 vilket underlättar integration mellan olika tjänster. ASPX-sidor hanterar automatiskt sessionshantering och alla säkerhetskontroller. Kommunikation med aspx-sidorna (och därigenom de underliggande API:erna) sker normalt genom användning av querysträngen 'Action=' och ofta 'ID=', 'CategoryID=' och genom att posta XML-data till sidorna. Sidorna returnerar i de allra flesta fall utdata som XML.

Kommunikation med ASP-sidorna (och därigenom de underliggande API:erna) sker normalt genom användning av querysträngen 'Action=' och ofta 'ID=', 'CategoryID=' och genom att posta XML-data till sidorna. Sidorna returnerar i de allra flesta fall utdata som XML.

Klienten – konsumenten

Den i särklass vanligaste klienten eller datakonsumenten i Content Studio är webbläsaren. På en webbplats kan den vara de flesta på marknaden förkommande läsare ex. Internet Explorer, Mozilla eller Opera. Är webbplatsen ett intranät där man önskar s.k. single sign-on med individuell användaridentifiering mot nätverket fungerar för närvarande bara Internet Explorer på grund av de stor krav detta ställer på webbläsaren. Det samma gäller för det administrativa gränssnittet Content Studio. Webbläsare sammanställer de åtgärder som användare önskar göra ex. titta på ett dokument eller spara en ändring i en artikel och skickar dessa till nästa roll i kedjan - webbservern.

Content Studio Server - datatransportören och analytikern

Content Studio server har till huvuduppgift att synkronisera anrop från webbservern eller i förekommande fall direkt från klient mot de lager av procedurer som är databasens gränssnitt utåt. Content Studio server sköter också om all synkronisering av dokumenten och deras säkerheter med det underliggande filsystemet.

Vidare finns även här den intelligenta CSScriptParser som format om den källkod av Active Scripting-komponenter, dynamisk metadata och dynamisk formatering som sparas till de slutliga filer som utgör det som exekveras av webbservern vid en förfrågan. Arbetsflödesmotorn lever sitt liv här precis som ett antal hjälpobjekt som krävs för att kunna interagera med det underliggande operativsystemet. En särskild plats tar Content Studio Event Actions (CSEA) som utför händelsekörningar via den underliggande operativsystemstjänsten Microsoft Message Queuing (endast i Content Studio v4.x).

Här tar en särskild motor hand om händelser genererade av systemet och utför dem då tid finns tillgänglig. Det kan vara exempelvis åtgärder som utförs när en användare godkänner ett dokument eller då ett dokument raderas och detta utan att användaren behöver vänta på något eller ens vara medveten om att detta utförs s.k. asynkrona händelser. Content Studio server körs för det mesta på samma server som webbservern men de kan vara olika maskiner.

I Content Studio v5 .NET används inte längre operativsystemstjänsten Microsoft Message Queuing (MSMQ). Istället har en helt ny integrerad flertrådig tjänst har skapats som utför bakgrundstjänster då servertid finns tillgänglig. Förutom asynkrona händelser är det nu även möjligt att skapa synkrona händelsehanterare till flera av server-händelserna ex. On_Document_Save. Dessa är atomiska dvs. om händelsehanteraren misslyckas eller anser att ex. en regel inte är uppfylld rullas hela transaktionen i Content Studio tillbaka. Dessa händelsehanterare får därför funktionen OnBefore… medan de asynkrona händelserna hanterar OnAfter…. Synkrona och asynkrona händelshanterare programmeras i .NET 2.0 och installeras på servern men anropen till dessa konfigureras i Content

Databasen - det intelligenta datalagret

Databasen är mycket mer än ett passivt datalager. Den är också en intelligent analys och dataorganisatör som huserar under databashanteraren Microsoft SQL-server 2000 eller senare. Det är i själva verket så att minst nittio procent av all affärslogik finns här och av denna anledning stöds endast denna databashanterare. Här kontrolleras säkerheter, här skapas urval och listor.

En viktig stötesten när vi utvecklar Content Studio är att så litet data som möjligt ska returneras tillbaka till anroparen och rundturer mellan databasen och Content Studio server ska undvikas så långt det är möjligt. Detta ställer naturligtvis stora krav på databasens utformning och är därför indelad i tre logiska skikt. Det första är de publika lagrade procedurerna som kan anropas utifrån och genom att använda dessa robusta procedurer garanteras både säkerhet och datatas integritet. De publika procedurerna använder sig frekvent av underliggande privata procedurer och funktioner samt de underliggande tabellerna och datavyerna.

Dessa procedurer är inte säkrade mot felaktiga anrop och får under inga omständigheter anropas av externa klienter - det går inte att garantera datasäkerheten om dessa anropas. Det samma gäller den lägsta nivån - de fysiska tabellerna, vyerna och funktionerna som utgör själva datalagret. Databasen körs ibland på samma maskin som webbservern men för större webbplatser rekommenderas att databasservern är en dedikerad maskin.

Precis som tidigare kan man dock använda de asynkrona anropen http-GET/POST direkt utan extra programmering.
I Content Studio v4.x exekverades Content Studio Server under COM+ men i .NET versionen körs den som en tjänst (Service) och kommunikationen sker via .NET Remoting antingen via TCP eller IPC-protokollen. Körs databas och Content Studio Server på samma fysiska maskin kan tjänsten dessutom köras under kontot NETWORK SERVICE eller LOCAL SERVICE och dessa tjänstekonton är ämnade just för detta ändamål.

Kontona har mycket begränsade rättigheter på servern vilket är bra ur säkerhetssynpunkt. Om däremot databasen körs på annan server måste Content Studio Server köras under ett fysiskt konto som är känt av SQL-server eftersom all autentisering mot SQL-server sker via Windows autheticering eftersom inga lösenord sparas i klartext in connectionsträngarna. 

Microsoft SQL Server

All information i Content Studio lagras i Microsoft SQL Server 2005 eller 2008. Alla dokument, versionshistorik, arbetsflöden, inställningar, bilder etc. Databasen är anpassad för lagring av stora informationsmängder och hanterar alla typer av innehåll. Databasen är synnerligen normaliserad men i vissa fall förekommer spegling av information för att uppnå högsta möjliga prestanda.
Eftersom all information som finns på webbplatsen/intranätet lagras i databasen räcker det att säkerhetskopiera databaserna för att kopiera webbplatsen. Vid återställning av databasen kan filerna speglas ut i filsystemet (via verktyget 'Site Content Manager') varefter webbplatsen fungerar igen. 

Utvecklingsstrategi

Utvecklingsstrategin har varit att skapa en databas som är uppbyggd kring ett fåtal grundelement som stödjer alla typ av innehåll (jmf dedikerade tabeller för nyheter, pressreleaser etc). Strategin har skapat en databas som är mycket flexibel och som har fördelen att alla tillägg i funktionalitet återspeglar sig på alla typer av innehåll. Exempelvis hanteras ett Xml-dokument på samma sätt som ett XHtml-dokument, en menypunkt, programkod, en nyhet eller en sidfot; alla baseras på samma tabeller, samma prodcedurer och funktioner och stödjer därmed alla kärnfunktioner såsom tidsstyrd publicering, säkerhetsinställningar, Event Actions et c. Sammanfattningsvis kan databasen beskrivas som en generisk SQL databas avsedd för lagring av alla typer av dokument.
Content Studio databasarkitektur, API: er och kringliggande tjänster gör att utvecklaren normalt inte behöver bygga egna databaser i SQL Server eller göra direkta anrop till databasen (ex. SELECT * FROM EMPLOYEES). Databasen underhålls och byggs ut automatiskt av Content Studio Server vilket underlättar och rationaliserar utvecklingsarbetet.
SQL-databasen anropas normalt endast av CS Server (.NET i v5 eller COM+ i v4) och de publika API: er som exponeras via .NET resp. COM+ och http. Direktanrop till SQL Server rekommenderas ej, men stödjs via SqlClient, ADO, via den äldre ODBC-standarden eller motsvarande. Alla transaktioner mot databasen sker via lagrade procedurer. Funktionsblocket i procedurerna är krypterade medan in/ut-parametrar är okrypterade och publika 

Uppdateringar

För att förenkla uppdateringar av Content Studio och dess databaser är alla objekt i databasen märkta med versionsnummer. När installationsprogrammet körs avgörs vilka tabeller, procedurer, vyer och UDF:er som måste uppdateras. Detta gör det enkelt och säkert att köra installationsprogrammet eftersom databasen synkroniserar sig själv - även om uppgradering sker flera gånger.

Replikering till filsystemet

Information som publiceras lagras förutom i SQL Server även i filsystemet (NTFS/SAN). Genom att spegla ut informationen i filsystemet uppnås högsta möjliga prestanda och belastningen på SQL Server minimeras. I en miljö där Content Studio körs på två (eller flera) servrar och där SQL Server ligger på en annan server än Webbservern, gör lagringen i filsystemet att belastningen delas mellan alla ingående servrar.
 En annan orsak till varför filerna bör speglas ut i filsystemet är att Content Studio i många fall exekverar programkod, exempelvis infogade Active Scripting-komponenter. Eftersom 'Server Execute' ej fungerar mot en databas måste filerna speglas ut.
Utspeglade filer får automatiskt rätt behörigheter satta - Content Studio speglar ut även dessa. Detta betyder att filen är säker även om den anropas via en nätverksresurs eller direkt via konsolen.

Content Studio SQL databas

Content Studio v4.x: Databasen 'Content Studio' innehåller grundläggande information om samtliga webbplatser och intranät som hanteras av installationen. Oavsett vilket antal webbplatser som skapas innehåller SQL Server endast en databas med namnet Content Studio. Vid installation av Content Studio eller en ny webbplats underhålls denna databas automatiskt.
Databasen innehåller information om webbplatsens namn, connectionid, connectionstring till sitedatabasen samt webbserverns namn. Databasen innehåller även
tabeller för hantering av cachning av information via Cache Server, en tabell med möjliga felmeddelanden (flerspråkig) samt fellogg.
Vid säkerhetskopiering måste denna databas inkluderas.
I Content Studio v5 .NET finns inte längre databasen Content Studio. Istället lagras alla inställningar i registret på webbservern.

Sitedatabaser

För varje webbplats som hanteras av Content Studio finns en korresponderande databas. Databasen har i normala fall ett namn som påminner om webbplatsen (www.contentstudio.se har en databas med namnet CS40SITE). Databasen skapas av installationsprogrammet när en webbplats läggs till.
Sammanfattningsvis innehåller databasen information om användare, grupper, dokument och revisioner, workflow definitioner, workflowinstanser, enheter och kategorier, inställningar, xml-index, xdr-scheman,  MLC, loginhistorik, PDF-kö och Event Actions.
All information som lagras för själva webbplatsen lagras alltså i ovanstående tabeller, oavsett vilken slags information det gäller; nyheter i xml-format, MS Word-filer, jpg-bilder etc. Databasen är alltså generisk och fungerar för alla typer av innehåll.
Databasaccess mot den gemensamma Content Studio databasen och de tillhörande sitedatabaserna sker via runtimekontot kallas CS Runtime. Detta konto måste vara DB Owner och ha administrativa behörigheter till databaserna. Detta konfigureras automatiskt av installationsprogrammet, men vid flytt av databasen kan det vara nödvändigt att manuellt konfigurera detta konto i SQL Server och på den lokala maskinen.

Tabeller, procedure, vyer och UDF:er

Både den gemesamma Content Studiodatabasen och alla sitedatabaser innehåller en stor mängd tabeller, procedurer, vyer och UDF:er. Dessa utnyttjas och kapslas in av Content Studio API eller något av de API:er som tillhör de kringliggande tjänsterna eller tillvalsprodukterna. Direkt anrop till tabellerna eller procedurerna rekommenderas ej och supporteras ej.
En viktig del av en sitedatabas är det så kallade XML-indexet. Detta index effektiviserar sökning, filtrering och urval av XML-baserade dokument. Utan XML-index skulle sökning i XML-data bli alltför långsamt - med Content Studio XML Index maximeras prestandan utan att det kräver större insatser av utvecklaren.

XML-index

XML-indexet innehåller en indexerad tabell som dessutom stöds av ett fulltextindex. XML-indexet konfigureras och underhålls av Content Studio - när ett redigeringsformulär skapas eller redigeras skapas automatiskt ett tillhörande XDR-schema varefter XML-indexet förbereds för indexering av utvalda fält. Genom att konfigurera XML-indexet per dokumentkategori, dvs. ange vilka fält som skall ingå i indexeringsprocessen, kommer sparade eller modifierade dokument automatiskt att indexeras.
Anrop till XML-indexet sker via API:et CSQuery, men i normala fall kan de ingående Active Scripting komponenterna användas.
I Content Studio v5 .NET är programmeringsgränsnittet uppbyggt som ett strukturerat ramverk med namnrymder som underlättar för programmeraren. Exempelvis ställer man filterfrågor via metoden Query i klassen XmlIndexQuery i namnrymden ContentStudio.Document.EPT. 

Labels
  • None