De keuze voor portaltechnologie is vaak snel gemaakt. De keuze of men gebruik gaat maken van Microsoft SharePoint of DotNetNuke (DNN) ligt vaak minder voor de hand. Is de keuze eenmaal gemaakt, dan twijfelt men later vaak of wellicht toch het andere product het voordeel van de twijfel had moeten krijgen. Of men kies deels uit onwetendheid: men kent of SharePoint of DNN.
Als SharePoint specialist heb ik recent kennis gemaakt met de mogelijkheden van DotNetNuke. De kennis die ik hierbij heb opgedaan is voor mij van cruciale waarde om keuzes in de toekomst beter te verantwoorden. In dit artikel zal een aantal overeenkomsten c.q. verschillen van beide producten in kaart worden gebracht. Doel hiervan is het verbreden van uw inzichten in deze producten die u kunnen helpen bij het beantwoorden van de veelgestelde vraag: SharePoint of DotNetNuke?
Een Portal is een Gateway waarmee leden toegang hebben tot bedrijfsinformatie
SQL Server Database
Beide producten maken gebruik van intuïtieve Microsoft technologie en gebruiken beide SQL Server als database. DotNetNuke kan overigens ook op een andere database werken, maar alleen SQL Server wordt standaard ondersteund. Tevens kunnen zowel SharePoint als DNN uitgebreid worden door gebruik te maken van .NET-development.
Zowel SharePoint als DotNetNuke gebruiken dus SQL Server voor de opslag van data. Een belangrijk verschil is echter dat we de SharePoint contentdatabase enkel en alleen mogen benaderen via de SharePoint interface (een site) of via het objectmodel (door te programmeren). DotNetNuke heeft een datamodel dat eventueel direct benaderbaar is. Zo kan men vrij snel in DotNetNuke direct in de database een portal-url aanpassen. In SharePoint is dit “helaas” niet mogelijk.
Tevens is het met beide producten mogelijk om door middel van maatwerk gebruik te maken van een andere database. Dit hoeft dan ook niet per definitie SQL Server te zijn. Deze “extra” database kan echter niet gebruikt worden als vervanging voor de installatie database!
Central Admin en Host Account
SharePoint gebruikt de Central Administration voor Farm-level beheertaken. De “Central Admin” is een aparte webapplicatie die apart te benaderen is. DotnetNuke kent de “Host” -account waarmee extra privileges worden verkregen na het authenticatieproces. Inloggen kan echter direct op de portal.
Fig. 1: SharePoint Central Administration
Toevoegen van Custom WebParts en Modules
SharePoint kent een tool die Stsadm.exe heet. Met deze commandline tool is het o.a. mogelijk om custom WebParts te deployen en beschikbaar te maken op een website. Dergelijke deployment gebeurt doorgaans middels een Windows Solution Package (.WSP). Een solution package is een gecomprimeerd bestand met daarin de functionaliteiten. Een of meer XML bestanden beschrijven waar de bestanden uit de .WSP file geplaatst dienen te worden. Het maken en deployen van een solution file vereist redelijke SharePoint kennis. Deployment is voor veel developers en bedrijven dan ook een bottleneck.
De solution package dient gedeployed te worden naar de webserver(s). Bij gebruik van stsadm.exe kan dit niet gedaan worden via de webbrowser. In een organisatie betekent dit vaak het inschakelen van een beheerder met voldoende rechten.
Modules voor DotNetNuke kunnen via de webbrowser worden toegevoegd. Voor het bouwen hiervan is uiteraard DNN-kennis vereist. Het packagen van een module (.zip-file) vraagt over het algemeen echter minder expertise dan het maken van een Solution Package voor SharePoint.
Het nadeel van DotNetNuke ten opzichte van SharePoint op dit vlak is, dat DNN-modules alleen binnen DNN gebruikt kunnen worden. SharePoint WebParts kunnen gebruik maken van twee base classes: SharePoint WebPart of ASP.NET WebPart. WebParts gebaseerd op de ASP.NET base class kunnen ook in ASP.NET-sites worden gebruikt. SharePoint specifieke WebParts kunnen gebruikt worden in systemen die gebruik maken van Windows SharePoint Services. Hierbij kan men bijvoorbeeld denken aan Project Server.
Een ASP.NET WebPart is weliswaar niet direct in DotNetNuke te gebruiken, het is wel mogelijk een module te maken waarin een WebPart wordt “gehost”.
Fig. 2: DNN - Toevoegen van een module
Visibility
In SharePoint kan men gebruik maken van Audience Targeting en Security Features om bepaalde data zichtbaar te maken of juist te verbergen. Vaak komt het voor (vooral in WSS) dat de gebruiker meer te zien krijgt dan hij of zij eigenlijk mag zien.
Bij DNN is het mogelijk om instanties van modules (dus een module die op een pagina is geplaatst) te koppelen aan één of meer rollen. Per rol kan worden aangegeven welke rechten (View, Edit, …) van toepassing zijn op de betreffende module. Standaard worden de rechten op een module geërfd van de pagina, zodat gebruikers die de pagina mogen zien, ook de module mogen zien. Daarnaast kunnen aan gebruikers individuele rechten worden toegekend. Deze rechten komen dan wel altijd bovenop de rechten die de gebruiker vanuit de aan hem toegekende rollen heeft.
Scalability
DNN kan geïnstalleerd worden op één webserver en één SQL Server. Wanneer men DotNetNuke in een webfarm of –garden zouden willen laten draaien, dient men daarvoor een en ander handmatig te configureren. Concreet heeft iedere DNN-installatie dus één enkele “DNN-database”. Wel is het mogelijk DNN meerdere malen te installeren op een server. Dit in tegenstelling tot SharePoint. SharePoint is echt een serverproduct waarvan maar één instantie op een server geïnstalleerd kan worden. Het beste kan men SharePoint dan ook zien als een serverproduct en DNN als een ASP.NET applicatie.
In SharePoint is het mogelijk de scalability te beheren vanuit de Central Administration. Het is zelfs mogelijk om bijvoorbeeld per Site Collection een aparte contentdatabase te hebben. Tevens kent SharePoint Features als Enterprise Search en Single Sign-on. We kunnen zelfs gebruik maken van een aparte Search en Indexing server. Hierbij kan men gebruik maken van uitgebreide indexeeropties.
DotNetNuke stelt hier tegenover dat veel performance gerelateerde instellingen via het Host-menu kunnen worden geconfigureerd en dat standaard onderdelen zoals de zoek- en indexeermogelijkheden met maatwerk of software van derden kunnen worden aangepast.
Office-Integratie en Multi-Language
SharePoint is heel sterk in Office integratie (MOSS 2007: Microsoft Office SharePoint Server 2007). Bij DotNetNuke ontbreekt dit eigenlijk.
Zo is het met Infopath Forms Services mogelijk om in een handomdraai een professioneel formulier te maken wat ingevuld kan worden door de gebruiker. De data kan opgeslagen worden in o.a. een SharePoint lijst.
Een ander voorbeeld is integratie met Outlook. Bij gebruik maken van een workflow kan een taak gecreëerd worden in een takenlijst. Deze taak kan zichtbaar worden in de Outlook-takenlijkst van de gebruiker.
SharePoint is heel sterk in Office integratie; hier staat tegenover dat Multi-Language standaard is bij DotNetNuke
Hier staat tegenover dat Multi-Language standaard is bij DotNetNuke. Dit is al sinds begin 2005 geïmplementeerd op de standaard ASP.NET manier. Bij SharePoint is dit niet standaard. Het is uiteraard wel mogelijk om meerdere talen te installeren.
Doorlooptijd en kosten
Over het algemeen is de tijdsduur voor het up-and-running krijgen van een out-of-the-box DotNetNuke portal (installatie en configuratie) korter dan die van SharePoint. Dit geldt niet alleen voor interne hosting maar ook voor externe hosting. Wil men bij SharePoint eveneens toegang hebben tot de stsadm.exe tool dan zal men eveneens remote desktop toegang moeten hebben tot de webserver.
Aangezien DotNetNuke Open Source is, en een zeer liberaal licentiemodel kent, vallen de kosten van DotNetNuke al snel lager uit. Sharepoint heeft ook de WSS variant die gratis verkrijgbaar is bij Windows 2003, maar deze is enigszins beperkt in functionaliteit ten opzichte van de grote broer MOSS 2007. Het is echter te kort door de bocht om te stellen dat DotNetNuke altijd goedkoper is. Deze afweging kan alleen per situatie apart worden gemaakt.
Intranet v.s. extranet
Met beide pakketten is het mogelijk om zowel een intranet- als internetportal op te zetten. Men kan hierbij gebruik maken van verschillende authenticatiemechanismen. Of de oplossing een internet- of intranetapplicatie moet worden kan een belangrijke factor zijn bij de bepaling van de keuze voor DotNetNuke of SharePoint.
Praktijk: WebPart development vs. Module development
In de volgende paragrafen zal dieper ingegaan worden op het development aspect van een WebPart c.q. Module. Hierbij is het nadrukkelijk niet de bedoeling om een complete tutorial te beschrijven voor de development hiervan, maar wil ik alleen enkele verschillen of overeenkomsten schetsen. Tevens dient opgemerkt te worden dat zowel bij WebPart- als Module development meerdere wegen bestaan die naar Rome leiden.
WebParts en Modules voegen functionaliteit toe om te voorzien in de bedrijfsbehoefte
SharePoint: WebPart Development
De eenvoudigste manier om een WebPart te ontwikkelen is door gebruik te maken van “WSS extensions for Visual Studio”. Deze extensies voor Visual Studio zijn zowel voor Visual Studio 2005 als 2008 beschikbaar als download op de site van Microsoft.
Na het installeren van deze extensies hebben we binnen Visual Studio de beschikbaarheid over een aantal extra project templates. Een hiervan is het SharePoint WebPart.
Fig. 3: De beschikbare templates in VS2008 na installatie van WSS Extensions for Visual Studio
Na de keuze voor “WebPart” ziet ons Visual Studio project er als volgt uit:
Bij de referenties in het project kan men zien dat een referentie is toegevoegd naar de Microsoft.SharePoint.dll. Dit is slechts een van de vele dll’s die gebruikt kunnen worden voor SharePoint development. SharePoint objecten beginnen met “SP” (SharePoint). Een lijst heet dus binnen SharePoint een SPList, dit in vergelijking met een generic list. Door de toevoeging van SP voor een objectnaam zijn objecten voor .NET developers eenvoudiger te herkennen.
Door een naamconventiefout zorgen de SPSite- en SPWeb objecten echter vaak voor verwarring:
- SPSite geeft toegang tot de top-level site (dit is een collection)
- SPWeb geeft toegang tot de pagina (hier zou men wellicht SPSite verwachten)
Binnen een webpart kan men op de volgende manier toegang krijgen tot de pagina (SPWeb):
SPSite siteCollection = SPContext.Current.Site;
SPWeb site = SPContext.Current.Web;
Listing 1: Het benaderen van een webpagina (SPWeb) vanuit een WebPart
Door in de Project Properties de juiste url op te geven bij “Start Browser With Url” kan met één druk op F5 gedeployed worden naar een development server. Als het goed is, is het WebPart nu beschikbaar in de WebPart Gallery en klaar voor gebruik. Het maken van een uitgebreider Solution Package en deployment binnen bijvoorbeeld een OTAP omgeving vergt uiteraard meer kennis en kunde dan enkel en alleen een druk op F5. Debuggen is mogelijk door de debugger te attachen aan het juiste W3WP proces.
Naast de WSS Extensions gebruiken developers vaak tools van CodePlex om WebParts en Windows Solution Files te maken. Veel gebruikte tools zijn: STSDEV, WSPBuilder en SharePoint Solution Installer.
DotNetNuke: Module Development
Om een DotNetNuke Module te ontwikkelen kan men als vergelijkbare stap met de WSS Extensions for Visual Studio gebruik maken van de starterkit van DotNetNuke. Deze bevat eveneens een aantal project templates. Hiermee is een ontwikkelaar snel op het juiste spoor gezet. Aangezien DotNetNuke “gewoon” een ASP.NET applicatie is, kan het maatwerk worden gedebugged vanuit Visual Studio en zijn er op de ontwikkelmachine geen extra installaties nodig. Met DotNetNuke kan een ontwikkelaar al aan de slag met louter de (gratis) Express-edition producten van Microsoft.
Fig. 5: Bij DotNetNuke worden diverse projecttemplates meegeleverd in de starterkit
Een belangrijke keuze bij het maken is of men een module wenst te maken die gecompileerde bestanden bevat of een dynamic module. Bij een dynamic module worden de bronbestanden als het ware gecompileerd op de server: dat laten we dan over aan ASP.NET.
In tegenstelling tot een WebPart die meestal als Windows Solution File gedeployed zal worden, is de module file een .zip-bestand. Vanuit onze DNN development omgeving kunnen we deze .zip-file laten genereren inclusief een configuratiefile. Hierbij is er de keuze voor het maken van een module met of zonder bronbestanden. Het gecrëeerde zip-bestand kan vervolgens direct toegevoegd worden aan een DotNetNuke site.
Conclusie
Aangezien iedere oplossing andere requirements heeft, zal steeds overwogen moeten worden voor welk product we kiezen. Veel mensen neigen bij bijvoorbeeld een webshop meer naar DotNetNuke, terwijl bij een enterprise intranet, waarbij Office-integratie een grote rol speelt, SharePoint de voorkeur verdient.
Scalability kan een belangrijk kwaliteitsaspect zijn. Door de huidige situatie te bekijken waar de applicatie aan dient te voldoen en wat de verwachting is over 5 jaar (bijv. omvang gebruikers- en site-toename) kan men een goed beeld krijgen van de vereiste scalability. Hierbij dient men te voorkomen dat de huidige keuze DNN is en over 5 jaar SharePoint (of visa versa).
Een valkuil die men vaak ziet is dat een definitieve keuze gemaakt is voor DotNetNuke of SharePoint binnen een organisatie en dat men met dit product “alle” problemen probeert op te lossen. Heel geforceerd tracht men oude applicaties in dit product te verweven. Uiteraard kan het allemaal wel, maar men moet zich wellicht de vraag stellen: “is dit de beste oplossing voor deze situatie?”.
Links: