Webbased organisatiespecifieke applicaties

Webbased organisatiespecifieke applicaties

Is het verstandig om organisatiespecifieke applicaties webbased te maken?

Radboud Universiteit Nijmegen Bachelorscriptie Informatiekunde Begeleider: Dr. P. M. Achten Coördinator: Dr. ir. G. J. Tretmans Auteur: Datum: Studentennummer: Studie:

Peter Vos Januari 2006 S0340790 Informatiekunde

Voorwoord Tijdens mijn vakantiewerk bij een grote Nederlandse verzekeringsorganisatie kwam ik een inventarisatie tegen van applicaties die op dat moment binnen de organisatie gebruikt werden. Per applicatie was aangegeven of het omgezet kon worden tot webbased en zo ja, wat daarvoor nodig was. Door deze inventarisatie in het document kwam ik op het idee van dit onderzoek. Naast dit document wekte het mijn interesse doordat het bedrijf waar ik nu parttime werk, ze alleen over bedrijfsspecifieke applicaties beschikken die webbased zijn. Voor het schrijven van mijn bachelorscriptie heb ik besloten om onderzoek te doen naar de voordelen en nadelen van webbased applicaties. Na een eerste oriëntatie in de literatuur op dit gebied kwam ik al zeer uitlopende meningen tegen. Het volgende citaat wat negatief is betreffende webbased applicaties staat in een artikel [Ha02] van Ahmed E. Hassan: “Web applications are the legacy software of the future. Developed under tight schedules, with high employee turn over, and in a rapidly evolving environment, these systems are often poorly structured and poorly documented. Maintaining such systems is problematic.” In dit citaat is Hassan nogal negatief over de ontwikkeling van webapplicaties. De vraag is of dit wel altijd terecht is als we ze vergelijken met andere soorten applicaties. Het volgende citaat [VP05] van Patrick Valente is echter wel positief over webbased applicaties: “Many experts have identified that a key issue in the acceptance of optimisation is the progressive adoption of web-driven technologies. The World Wide Web already offers information, advice and remote access to software for solving optimisation problems. Well-established companies such as IBM, SAP and ILOG offer products which are specially developed and evolved to enhance existing optimisation software tools with the support of internet technology devices.” Deze citaten geven mij een aanzet tot een onderzoek naar positieve en negatieve kanten van webbased applicaties ten opzichte van ‘traditionele’ applicaties. Ik wil in mijn scriptie, door er vanuit diverse informatiekundige gebieden er na te kijken, beoordelen of het webbased maken van applicatie een goede keuze is. Het antwoord op de onderzoeksvraag kan vanuit meerdere disciplines worden gegeven wat het onderzoek veelzijdig maakt. Tenslotte wil ik graag enkele personen bedanken voor hun medewerking. Allereerst wil ik de heer Achten hartelijk bedanken voor zijn hulp bij het schrijven van deze scriptie. Door de tijd die hij voor mij vrij heeft gemaakt, heb ik veel ondersteuning van hem gehad tijdens het schrijven van mijn eerste wetenschappelijke scriptie. Daarnaast wil ik graag de heer Janssen van Checkit en de heer Pop van Plus Retail BV bedanken voor het invullen van mijn vragenlijst voor dit onderzoek. Als laatste wil ik mijn zus Heidi Vreeburg-Vos bedanken voor de tips die zij mij ter verbetering van mijn scriptie gegeven heeft. Peter Vos, Nijmegen, 22-01-2006.

Inhoudsopgave 1

Onderzoeksopzet ........................................................................................ 4 Probleemstelling ..................................................................................... 4 Theoretisch kader ................................................................................... 4 Gerelateerde literatuur............................................................................. 5 Methode ................................................................................................ 5 Bijdrage onderzoek ................................................................................. 6 2 Webbased applicaties .................................................................................. 7 2.1 Definitie webbased applicatie .................................................................... 7 2.2 Web-based ontwikkelen ........................................................................... 9 2.3 Conclusie ............................................................................................. 10 3 Kwaliteitskarakteristieken ISO 9126 ............................................................ 11 3.1 Wat is kwaliteit bij een softwaresysteem? ................................................. 11 3.2 De inhoud van een ISO 9126 kwaliteitskarakteristiek en de mate waarin het bruikbaar is voor het onderzoek .............................................................. 12 3.3 Conclusie ............................................................................................. 18 4 Kwaliteitskarakteristieken webbased applicaties ............................................ 19 4.1 Functionality......................................................................................... 19 4.1.1 Interoperability ................................................................................ 19 4.1.2 Security .......................................................................................... 20 4.1.3 Functionality compliance ................................................................... 22 4.2 Usability .............................................................................................. 23 4.2.1 Understandability ............................................................................. 23 4.2.2 Learnability ..................................................................................... 24 4.2.3 Operability ...................................................................................... 25 4.2.4 Attractiveness.................................................................................. 28 4.2.5 Usability compliance ......................................................................... 28 4.3 Efficiency ............................................................................................. 29 4.3.1 Time behaviour ................................................................................ 29 4.3.2 Resource behaviour .......................................................................... 30 4.3.3 Efficiency compliance ........................................................................ 33 4.4 Portability ............................................................................................ 34 4.4.1 Adaptability ..................................................................................... 34 4.4.2 Installability .................................................................................... 36 4.4.3 Co-existence.................................................................................... 36 4.4.4 Replaceability .................................................................................. 37 4.4.5 Portability compliance ....................................................................... 38 4.5 Conclusies literatuurstudie...................................................................... 38 5 In de praktijk ........................................................................................... 41 5.1 Vragenlijst ........................................................................................... 41 5.2 Conclusie praktijkonderzoek ................................................................... 44 6 Vergelijking literatuur met praktijk.............................................................. 45 7 Eindconclusie ........................................................................................... 47 8 Literatuurlijst ........................................................................................... 49 Bijlage I [16] ..................................................................................................... 51 Bijlage II: CORBA vs. Webservices........................................................................ 54 1.1 1.2 1.3 1.4 1.5

Bachelorscriptie Onderwerp: webbased organisatiespecifieke applicaties

1

Onderzoeksopzet

1.1 Probleemstelling Het onderzoek richt zich op de vraag of het verstandig is een nieuwe applicatie webbased te maken. Er zal naar voren moeten komen welke voordelen en nadelen dit geeft ten opzichte van niet webbased applicaties. Er wordt daarvoor naar bepaalde “non-functional requirements” en kwaliteit aspecten gekeken. Het volgende thema zal in dit onderzoek centraal staan: “Is het verstandig een nieuwe organisatiespecifieke applicatie webbased te maken, zodat de voordelen het overwinnen van de nadelen als deze wordt vergeleken met een zelfde applicatie die niet webbased is?” Om antwoord te kunnen geven op deze vraag dienen eerst de volgende deelvragen beantwoord te worden: 1. Wat is de definitie van een webbased applicatie? (hoofdstuk 2) 2. Welke kwaliteitskarakteristieken van ISO 9126 geven het duidelijkst de voor- en nadelen weer om een applicatie dan wel webbased of niet webbased te maken? (hoofdstuk 3) a. Wat is kwaliteit bij een softwaresysteem? b. Wat houdt een bepaalde kwaliteitskarakteristiek of aspect in? c. Kan een kwaliteitskarakteristiek of aspect dusdanige voor- en nadelen weergeven zodat deze relevant is voor dit onderzoek? 3. Welke voor- en nadelen zijn er te vinden kijkend naar de verschillende aspecten van een bepaalde kwaliteitskarakteristiek? (hoofdstuk 4, 5 en 6) a. Welke beveiligingsprincipes veranderen of zijn er extra nodig voor webbased applicaties? b. Wat gebeurt er met de andere aspecten van de kwaliteitskarakteristiek functionality bij webbased applicaties? c. Welke onderdelen en vormen van de kwaliteitskarakteristiek usability zullen significant anders zijn bij webbased applicaties? d. Hoe efficiënt werkt een webbased applicatie ten opzichte van een zelfde applicatie die niet webbased is, als er naar het tijdsgedrag en het gebruik van resources gekeken wordt? e. Zijn er voor- en nadelen te onderscheiden als er gekeken wordt naar aspecten als adaptability installability, co-existence en replaceability van de kwaliteitskarakteristiek portability? Het kennisgebied waarop het onderzoek zich richt, is het informatiekundige gebied en dan voornamelijk de aspecten: requirements engineering, kwaliteit van informatiesystemen en system-alignment. Vooral de non-functional requirements van software systemen spelen een belangrijke rol in dit onderzoek.

1.2 Theoretisch kader Er zijn veel verschillende soorten applicaties en bij de meeste van de applicaties zal een webbased variant gemaakt kunnen worden. Denk daarbij aan soorten software voor privé gebruik: zoals een tuinontwerpprogramma, of een standaard boekhoudpakket of software die zowel in een bedrijf als privé wordt gebruikt zoals Word of Excel. Omdat

Pagina 4 van 54

Bachelorscriptie Onderwerp: webbased organisatiespecifieke applicaties deze soorten nogal van elkaar verschillen in gebruik en doel wordt deze scriptie beperkt tot één bepaalde soort, namelijk organisatiespecifieke software. Denk hierbij aan een voorraadadministratie systeem of een klantenbeheer systeem. Het onderzoek richt zich dus op software dat voor een organisatie ontwikkeld of aangepast is. Het onderzoek zal een globaal beeld moeten geven wat uit literatuurstudies tot stand komt. Er zal niet specifiek worden ingegaan op één bepaald gekozen voorbeeldsysteem, waarvan alle voor en nadelen worden besproken, maar over meerdere soorten organisatiespecifieke systemen waar de gezamenlijke voor- en nadelen naar voren voor komen. Omdat dit een niet al te groot onderzoek betreft zal er niet op elke requirement of kwaliteitskarakteristiek worden ingegaan. In het onderzoek zal worden aangegeven met welke afweging er voor bepaalde aspecten is gekozen en waarom we bepaalde kwaliteitsaspecten niet behandelen.

1.3 Gerelateerde literatuur Er is veel literatuur te vinden in de onderzoekswereld die de omzetting van een ‘oude’ (legacy) applicatie naar een webbased applicatie bespreken zoals o.a. [SS03]. In dit artikel wordt een proces beschreven waarin code wordt hergebruikt van een bestaand legacy systeem, om het vervolgens om te zetten naar een XML-interface. Zo zijn er veel meer artikelen te vinden o.a. [TG02, e.a ] die een soortgelijk proces bespreken, waar onder andere vooral middleware wordt besproken, dat wordt ingezet in dit proces. Als we het hebben over kwaliteitskarakteristieken gericht op webbased applicaties zijn er diverse artikelen die met een eigen model of een afgeleid model van het ISO 9126 model komen. In deze artikelen wordt vooral scalability als belangrijk kwaliteitsaspect toegevoegd en besproken, onder andere in [KR01, SS04]. In het artikel [PP01] wordt een vergelijking gemaakt tussen een webbased applicatie en een desktopapplicatie, waarin dit artikel het dicht bij hetzelfde doel komt als van dit onderzoek. Alleen is het onderzoek van [PP01] alweer vier jaar oud. Er wordt hierin alleen één klein programma, een kalender, onderzocht waarin men vooral in gaat op de kwaliteitskarakteristieken efficiency en usability. Tenslotte geeft het artikel [DV05] een duidelijk overzicht van wat de huidige technieken en stand van zaken is betreffende webbased applicaties. Dit artikel is daardoor ook voor dit onderzoek gebruikt.

1.4 Methode Het onderzoek zal voornamelijk een literatuurstudie als basis hebben. Eerst zal precies onderzocht moeten worden en aangegeven worden wat wordt bedoeld met een webbased applicatie. Dan zal in het beginstadium van het onderzoek worden besloten welke kwaliteitsaspecten er onderzocht en behandeld gaan worden. Voor de verificatie van de literatuurstudie zullen er één of twee organisaties geïnterviewd worden die overwegen, bezig zijn met het ontwikkelen of al beschikken over een webbased applicatie. Het antwoord van de hoofdvraag zal vorm krijgen doordat hoofdzakelijk via een literatuurstudie een antwoord op elke deelvraag gezocht wordt. Hierdoor zal er een overzichtelijk model ontstaan, waarin duidelijk wordt wanneer webbased applicaties interessant zijn. Voor elke deelvraag is in paragraaf 1.1 aangegeven in welk hoofdstuk deze wordt besproken.

Pagina 5 van 54


1.5 Bijdrage onderzoek Dit onderzoek moet een bijdrage leveren aan het onderzoeksgebied en aan de praktijk doordat het laat zien in welke gevallen het ontwikkelen van een applicatie met webbased technieken verstandiger is dan wanneer dat met andere, ‘traditionelere’, technieken zou gebeuren. Zoals besproken in paragraaf 1.3 zijn er, tot zover ik weet, nog geen artikelen gepubliceerd die dit op een soortgelijke wijze hebben gedaan als in dit onderzoek. De meeste onderzoeken en artikelen beschrijven vooral een omzetting van een oude applicatie naar een webbased applicatie. Weer een andere lichting onderzoeken bespreekt en vergelijkt maar één of enkele kwaliteitsaspecten. Daarom zal dit onderzoek meerdere kwaliteitsaspecten bespreken die beoordeeld kunnen worden als de applicatie als nieuw zou worden gebouwd. Een kanttekening betreffende de geldigheid van de uitkomsten van dit onderzoek moet wel gemaakt worden. Door de snel ontwikkelende en veranderende omgeving van de webbased technieken die in dit onderzoek besproken worden, kunnen een aantal conclusies na enige tijd niet meer relevant zijn.

Pagina 6 van 54


2

Webbased applicaties

Om onderzoek te kunnen doen naar webbased organisatiespecifieke applicaties moet er eerst duidelijk worden gemaakt wat we onder bepaalde begrippen verstaan. In het bijzonder zal duidelijk moeten worden wat de begrippen organisatiespecifieke applicatie en webbased van het hoofdthema precies inhouden dit wordt behandeld in paragraaf 2.1. In paragraaf 2.2 zal het ontwikkelen van een webbased applicatie in het kort behandeld worden. In paragraaf 2.3 wordt de definitie gegeven van webbased organisatiespecifieke applicaties. Dit beantwoord dus de eerste deelvraag van bladzijde 4.

2.1 Definitie webbased applicatie In het applicatielandschap zijn er diverse soorten van software met elk een eigen doel. Hieronder worden de meest relevante voorbeelden voor dit onderzoek genoemd die Pressman onderscheidt in [PR00]: - systeemsoftware: gemaakt om service te geven aan andere soorten software met als karakter dat het voornamelijk direct communiceert met de hardware. Voorbeelden zijn drivers, compilers en besturingssystemen. - Real-Time Software: voornaamste doel om gebeurtenissen in de fysieke omgeving te monitoren, analyseren of te besturen. Het systeem reageert meestal direct op de gebeurtenissen die het ontvangt vanuit de omgeving. Voorbeelden zijn lopende band software met PLC computers of een digitale thermometer met een sensor. - Personal Computer Software: één van de grootste soorten van de softwaregroepen. Dit zijn de programma’s die de meeste mensen zowel op hun thuiscomputer als op de computer op het werk hebben. Programma’s als een tekstverwerker, spreadsheet, mediaplayer en webbrowser zijn hier voorbeelden van. Maar de grootste groep hierbinnen zijn de computerspellen die een steeds groter marktgebied veroveren. - Artificial intelligence software: software dat gebruikt maakt van non-numerieke algoritmes om complexe problemen op te lossen. - Webbased software: de webpagina’s die ontvangen worden door een webbrowser is de software die uitvoerende instructies (CGI, HTML, PHP, ASP of Java) en data (hypertext en vele visuele en audio vormen) bevatten. In essentie is het netwerk een enorme computer die een haast ongelimiteerde bron van data aanbied die voor het grootste deel toegankelijk is voor diegenen die zich op het netwerk bevinden. - Business software: bedrijfsinformatieverwerking software is een groot software applicatie gebied. Het zijn vaak grote informatiebeheerssystemen die gekoppeld zijn aan een of meerdere databases waarin veel bedrijfsinformatie verzameld is. Dit soort applicaties bewerken bestaande data op een manier dat het bedrijfsoperaties en managementbeslissingen vereenvoudigt. Het is software die speciaal gemaakt of aangepast is, zodat het bedrijf er het best mee kan functioneren. Een combinatie van de laatste twee soorten van software, business en webbased software zijn de soorten waar dit onderzoek zich op richt. Het soort business software is in deze scriptie vertaald naar organisatie specifieke software. Organisatie wordt gehanteerd in plaats van business aangezien non-profit organisaties, zoals een ziekenhuis, evengoed over dit soort specifieke (aangepaste) software beschikken. Aangezien er nog vele aanverwante definities zijn binnen deze soorten zullen we die hieronder verder behandelen. Om te beginnen is in [RH02] een goed onderscheid gemaakt tussen twee soorten applicaties binnen het eerder besproken soort webbased software:

Pagina 7 van 54

Bachelorscriptie Onderwerp: webbased organisatiespecifieke applicaties Web hypermedia application [RH02]:”A Web hypermedia application is a nonconventional application characterised by the authoring of information using nodes (chunks of information), links (relations between nodes), anchors, access structures (for navigation) and its delivery over the Web. Technologies commonly used for developing such applications are HTML, JavaScript and multimedia…” Web software application [RH02]:”A Web software application, on the other hand, represents any conventional software application that depends on the Web or uses the Web's infrastructure for execution. Typical applications include legacy information systems such as databases, booking systems, knowledge bases etc. Many e-commerce applications fall into this category. The technology employed here are COTS components, components such as DCOM, OLE, ActiveX, XML, PHP, dynamic HTML, databases, and development solutions such as J2EE…” Bij de eerste definitie van web hypermedia application worden de pagina’s op het internet bedoeld zoals iedereen die kent, bijvoorbeeld persoonlijke homepages of de site van een universiteit. Dit zijn de applicaties die onder andere informatie aanbieden en voor iedereen toegankelijk zijn via het internet. Op dit soort applicaties richt het onderzoek zich niet. Het onderzoek houdt zich bezig met de tweede definitie, namelijk web software application. Dit zijn in de meeste gevallen traditionele software applicaties die ook nietwebbased gebouwd zouden kunnen zijn. Maar doordat het als communicatiemiddel gebruik maakt van het client-server protocol HTTP en als gebruikersinterface code in de vorm van HTML naar de gebruiker stuurt, is het webbased software. De gebruiker is genoodzaakt om gebruik te maken van een webbrowser om de applicatie te gebruiken. Dit soort webbased software applications worden ook wel in het Nederlands webapplicaties genoemd. Webapplicaties hebben volgens Pressman de volgende kenmerken [PR00]: - network intensive: By its nature a web application is network intensive. It resides on a network and must serve the needs of a diverse community of clients. A web application may reside on the internet (thereby enabling open worldwide communication). Alternatively, an application may be placed on an Intranet (implementing communication across an organization) or an Extranet (internetwork communication). - Content-driven: In many cases, the primary function of a web application is to use hypermedia to present text, graphics, audio and video content to the end-user. - Continuous evolution: Unlike conventional application software that evolves over a series of planned, chronologically-spaced releases, web applications evolve continuously. It is not unusual for some web applications (specifically, their content) to be updated on an hourly schedule. De onderstaande definitie van Ruhe voor web applications samen met de kenmerken gegeven door Pressman komt het best overheen met de applicaties die we in dit onderzoek gaan behandelen, namelijk de webbased organisatie specifieke applicaties. Web applications [RJ03]: ”a software application that uses web sites as a front-end for broad and remote access. The back-end provides full user functionality; the user can affect the status of the business logic on the web server. Web applications consist of different components when compared with traditional software applications, e.g. shopping carts, scripts, and COM components. Typical web applications are financial / trading, business-to-business, and intranet business management applications.” In de behandelde literatuur wordt bovendien nog een onderscheid gemaakt tussen drie vlakken waarop een webbased applicatie zich kan bevinden, namelijk: het internet, het intranet en het extranet. Het grootste verschil tussen deze drie vlakken is het publiek waar de applicatie voor bedoeld is.

Pagina 8 van 54

Bachelorscriptie Onderwerp: webbased organisatiespecifieke applicaties -

Internet (pagina’s) is een extern netwerk waar iedereen toegang tot heeft. Intranet (pagina’s) is een intern netwerk waar alleen (bepaalde) mensen binnen de organisatie zelf toegang tot hebben. Extranet (pagina’s) is een combinatie van deze twee. Het is wel bereikbaar via het internet maar alleen voor bevoegde personen (de pagina’s zijn afgeschermd en beveiligd).

Er zijn webapplicaties die zich op zowel geen van deze vlakken bevinden en standalone draaien tot webapplicaties die zich op alle drie de vlakken tegelijk bevinden. In het laatste geval biedt een organisatie bijvoorbeeld via het internet actuele informatie aan haar klanten. Via het intranet worden de medewerkers op de hoogte gehouden van zaken die zich binnen de organisatie spelen, zoals nieuwe huisregels binnen het gebouw. Via het Extranet kunnen leveranciers of grote afnemers offertes of orders plaatsen op afgeschermde pagina’s.

2.2 Web-based ontwikkelen Nu bekend is geworden wat voor soorten applicaties er zijn en specifieker wat webbased applicaties zijn, zal er in het kort nog besproken worden of het ontwikkelen van webbased applicaties anders is vergeleken met de meeste andere soorten applicaties. De eventuele veranderingen bij het ontwikkelen, kunnen namelijk wel een interessant gegeven zijn voor de beantwoording van de hoofdvraag. Uit de diverse literatuur [DV05, PP05, VP05, PR00, e.a] die onderzocht is voor dit onderzoek wordt vaak beschreven dat een webbased applicatie ontwikkelen over het algemeen een stuk lastiger en moeilijker is dan een ‘traditionele’ vergelijkbare applicatie. Dit komt met name doordat de webbased technieken sneller veranderen en elkaar afwisselen dan met andere technieken het geval is. Verder moet de programmeur in verhouding vaak veel meer verschillende technieken beheersen om een applicatie te ontwikkelen. Enkele citaten uit artikelen die dit aangeven zijn [DV05]:

“…Industrial-strength application development platforms such as J2EE and .NET, built on several years of ad-hoc experimentation, aim at simplifying application development. Unfortunately, the learning curve for mastering one of these platforms is long and steep, and even the most proficient software engineer who can master non-web application development will be overwhelmed by the complexity…”

Over de veel belovende webbased techniek AJAX wordt het volgende gezegd [PL05]: “According to analyst Ray Valdes with market research firm Gartner developers can add Ajax

techniques piecemeal to an existing system, one code snippet at a time. However, the added, trying to implement all the techniques at once in a complex project approaches the rocket-science level of difficulty. Your average developer is not going to be able to figure it out,”

Deze citaten uit de literatuur geven mede aan dat voor het ontwikkelen van webbased applicaties eerder nadelen dan voordelen gevonden worden op de vraag of het verstandig is applicaties webbased te ontwikkelen. Een organisatie zal over competente en snel lerende werknemers moeten beschikken om applicaties webbased te ontwikkelen, aldus onder andere [PL05].

Pagina 9 van 54


2.3 Conclusie Ter afsluiting van dit hoofdstuk wordt een antwoord gegeven op de eerste deelvraag van dit onderzoek, namelijk: “ Wat is de definitie van een webbased applicatie? ” Het antwoord op deze vraag is een eigen definitie van webbased organisatiespecifieke applicaties die hieronder is geformuleerd. In figuur 1 is weergegeven hoe de verschillende behandelde definities in dit hoofdstuk zich tot elkaar verhouden en hoe hieruit de eigen definitie tot stand is gekomen.

Definitie: Een webbased organisatiespecifieke applicatie is een software applicatie dat als hoofddoel heeft een organisatie te faciliteren in de dataprocessen en informatiebehoefte die binnen de organisatie spelen. Dit faciliteren doet de software applicatie doordat het gebruik maakt van de webinfrastructuur (HTTP) en webbased software technieken (php, asp, jsp). De infrastructuur en webbased technieken zijn vooral aan de front-end van de applicatie zichtbaar (HTML-pagina’s of java-applets) voor de gebruikers in de organisatie. Deze front-end is meestal bereikbaar via een inter- intra- of extranet waarmee de backend (organisatielogica, datawarehouses) is te bewerken.

Soorten Applicaties Soorten Software

Organisatiespecifieke Applicaties

Webbased Organisatiespecifieke Applicaties

Business Software Web Hypermedia Applicaties Webbased Software

Webapplicaties Web Software Applicaties

(netwerk intensive, content driven en continuous evolution) (inter-, intra- en extranet)

Figuur 1 – Domeingebied van webbased organisatiespecifieke applicaties

Pagina 10 van 54


3 Kwaliteitskarakteristieken ISO 9126 Dit onderzoek probeert te ontdekken waarin ‘normale’ en webbased applicaties van elkaar verschillen. Om dit te doen moeten we toch bepaalde maatstaven hebben om dit te onderzoeken. Daarom is besloten om dit te doen aan de hand van verschillende kwaliteitsnormen voor software. Voor deze kwaliteitsnormen is er gekozen voor de definities en uiteenzettingen van de ISO 9126 aspecten. In dit hoofdstuk zal eerst aangegeven worden wat onder kwaliteit wordt verstaan bij software. Daarna zullen we een uitleg en een definitie geven van de verschillende kwaliteitskarakteristieken die ISO hanteert voor software. We sluiten dit hoofdstuk af met een bespreking welke karakteristieken relevant zijn om mee verder te gaan in dit onderzoek en welke niet. Dit is gedaan doordat in eerste instantie dit onderzoek te klein is qua tijdsbestek om op elk aspect van kwaliteit in te gaan. Ten tweede is bij de vergelijking die tijdens dit onderzoek centraal staat, niet elk kwaliteitsaspect even relevant. In de laatste paragraaf zal er een antwoord gegeven worden op deelvraag twee van dit onderzoek.

3.1 Wat is kwaliteit bij een softwaresysteem? Deze paragraaf geeft het antwoord op subdeelvraag a van deelvraag twee: “Wat is kwaliteit bij een softwaresysteem?” Volgens de ISO 9126 definitie, waarvan we de kwaliteitskarakteristieken onderzoeken, is de kwaliteit van software als volgt [IS00]: “Quality is the totality of characteristics of an entity that bear on its ability to satisfy stated and implied needs.” Ik ben van mening dat de definitie van kwaliteit van ISO 9126 nogal algemeen van aard is. Daarom zal ik de definitie van de al eerder aangehaalde Pressman[PR00] hieronder als definitie van kwaliteit van webbased organisatiespecifieke applicaties gaan gebruiken. Ik denk dat hieruit meer naar voren komt dat het betrekking heeft op de kwaliteit van software systemen. In zijn boek geeft Pressman aan dat zijn eigen kwaliteitskarakteristieken en die van ISO ook voor webbased applicaties belangrijk zijn om in acht te nemen [PR00]: “Conformance to explicitly stated functional and performance requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software.” Deze definitie is zo opgesteld dat het de volgende drie punten bevat [PR00]: • • •

software requirements are the foundation from which quality is measured. Lack of conformance to requirements is lack of quality. Specified standards define a set of development criteria that guide the manner in which software is engineered. If the criteria are not followed, lack of quality will almost surely result. There is a set of implicit requirements that often goes unmentioned (e.g. the desire for ease of use and good maintainability). If software conforms to its explicit requirements, but fails to meet implicit requirements, software quality is suspect.

Pagina 11 van 54


3.2 De inhoud van een ISO 9126 kwaliteitskarakteristiek en de mate waarin het bruikbaar is voor het onderzoek In deze paragraaf worden de zes definities van de ISO 9126 kwaliteitskarakteristieken uiteengezet aan de hand van de verschillende aspecten die hieronder vallen. Er zal daarbij worden aangegeven in welke mate deze relevant zijn voor dit onderzoek. De zes kwaliteitskarakteristieken zijn weergegeven in figuur 2 hieronder.

Figuur 2 – ISO 9126 karakteristieken

Functionality Definitie: a set of attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied needs. [IS00]

Figuur 3 - ISO 9126 karakteristiek functionality

Bij deze karakteristiek wordt er vooral naar de kwaliteit gekeken van de inhoud van het systeem. In hoeverre is er voldaan aan de functional requirements. Dit wordt onder andere gedaan door op de volgende deelaspecten in te gaan: • • • •

•

suitability: voldoet de functionaliteit van de applicatie aan een geschikte verzameling van functies voor specifieke taken en gebruikersdoelen. Accuracy: zijn de resultaten, de uitvoer en de werking van de applicatie wel correct. Interoperability: om een goede kwaliteit te krijgen voor dit deelaspect zal de applicatie in staat moeten zijn eenvoudig communicatie uit te wisselen met (van te voren vastgelegde) applicaties. Security: de applicatie zal informatie en data moeten beschermen tegen personen die niet geautoriseerd zijn om het te lezen of te veranderen. Tevens moet het ervoor zorgen dat personen die wel hiervoor geautoriseerd zijn hierdoor niet worden belemmerd. Functionality compliance: de applicatie zal zoveel mogelijk gebruik moeten maken van de standaarden, overeenkomsten en wetmatigheden die gerelateerd zijn aan functionality. Pagina 12 van 54

Bachelorscriptie Onderwerp: webbased organisatiespecifieke applicaties Bruikbaarheid onderzoek o Suitability: welke technieken er gebruikt worden en hoe deze zijn geimplementeerd, zullen geen invloed hebben op de verwachting van de gebruiker van de functionele werking van de applicatie. De functionele behoefte kan waarschijnlijk zowel in een unix-commando interface geïmplementeerd worden als in een webbased applicatie interface. Dit aspect zal daarom niet interessant zijn voor dit onderzoek. o Accuracy: voor dit aspect geldt hetzelfde als voor suitability die hierboven is vermeld. o Interoperability: dit aspect is voor dit onderzoek wel interessant doordat communicatie met andere applicaties misschien op een andere manier verloopt. Het is namelijk een geheel andere techniek die meestal server-georiënteerd is. o Security: dit aspect is van belang omdat webbased applicaties in een webbrowser werken. Hierdoor zou iedere internetgebruiker een dergelijk applicatie kunnen draaien, aangezien de meeste mensen een webbrowser hebben. Uit het onderzoek van Kruegel blijkt ook dat webbased applicaties een grotere risico lopen om aangevallen te worden. Het is dan ook verstandig hier extra rekening mee te houden [KC05]: “Web servers and web-based applications are popular attack targets…… Attacks that exploit web servers and web-based applications represent a substantial portion of the total number of vulnerabilities”. o Functionality compliance: webbased technieken zijn uit een ander perspectief dan normale applicaties ontstaan met andere doelen. Er zijn veel verschillende en andere soorten standaarden waarvan een aantal vereist zijn om te gebruiken. Voor het ontwikkelen en het geschikt maken zijn er misschien ook andere ontwikkelmethoden en standaarden die onderzocht moeten worden of die verschillen met die van niet webbased applicaties. Reliability Definitie: capability to maintain a specified level of performance when used under specified conditions. [IS00]

Figuur 4 - ISO 9126 karakteristiek reliability

Er kan natuurlijk altijd een fout optreden in de software van een applicatie waaraan een gebruiker niet kan doen. Maar ook een gebruiker kan ook iets onrechtmatigs veroorzaken binnen de applicatie waardoor er iets verkeerd gaat in de applicatie. Om dit te voorkomen moeten er een aantal functionaliteiten worden toegevoegd aan de applicatie. In welke mate de applicatie dit doet kan bekeken worden door meerdere deelaspecten: • •

maturity: de applicatie moet proberen te voorkomen dat er verkeerde resultaten opgeleverd kunnen worden doordat er fouten zitten in de software. Fault tolerance: de applicatie zal een gespecificeerde mate van performance moeten behouden in bepaalde gevallen dat software fouten of software overtredingen voorkomen.

Pagina 13 van 54

Bachelorscriptie Onderwerp: webbased organisatiespecifieke applicaties •

•

Recoverability: het vermogen van de applicatie om na een software fout of overtreding zichzelf weer te herstellen tot een bepaald niveau. Daarnaast moet de applicatie in staat zijn de direct bij de fout betrokken data te herstellen tot de situatie voor de fout. Reliability compliance: de beschikbare standaarden die worden gebruikt om te zorgen dat de applicatie blijft werken nadat er een fout is opgetreden.

Bruikbaarheid onderzoek: Alle deelaspecten van reliability zullen waarschijnlijk met een zelfde mate van nauwkeurigheid worden bekeken bij zowel webbased- als niet webbased applicaties. De technieksoorten die gebruikt worden voor de ontwikkeling en de opzet van de applicatie, zal geen invloed hebben op de kwaliteit van deze karakteristiek. Al zullen er bij het aspect recoverability misschien wel wat interessante verschillen te zien zijn. Door de minimaal te vinden verschillen op het gebied van reliability en door het korte karakter van dit onderzoek wordt deze karakteristiek niet verder uitgewerkt. Usability Definitie: a set of attributes that bear on the effort needed for use, and on the individual assessment of such use, by a stated or implied set of users. [IS00]

Figuur 5 - ISO 9126 karakteristiek usability

Hier gaat het er vooral om of de applicatie goed bruikbaar is door de gebruiker. Reageren de knoppen en de menu’s zoals de gebruiker dit zou verwachten? Is het systeem lastig te begrijpen? Dit soort kenmerken zijn van belang binnen deze karakteristiek. Het is onder te verdelen in de volgende deelaspecten: •

• • • •

understandability: hier gaat het erom of het systeem begrijpbaar is voor de gebruiker. Kan de applicatie gebruikt worden voor de verschillende taken en welke condities komen hier bij kijken? Hierdoor is het van belang dat er een handleiding bij de applicatie geleverd wordt. Learnability: bij dit aspect is het van belang dat het omgaan met de applicatie eenvoudig is aan te leren. Operability: hier is het van belang in welke mate de gebruiker het systeem beheert en er controle over heeft. Er moeten bijvoorbeeld geen processen starten of uitgevoerd worden die de gebruiker niet bedoeld had. Attractiveness: is de applicatie aantrekkelijk genoeg om te gebruiken of irriteert het de gebruiker juist. De schermopbouw is bijvoorbeeld niet op de verwachte manier opgebouwd. Usability compliance: zijn er standaarden te vinden voor de usability voor het soort van applicatie wat er gebouwd is die de gebruiker kan verwachten?

Pagina 14 van 54

Bachelorscriptie Onderwerp: webbased organisatiespecifieke applicaties Bruikbaarheid onderzoek o Understandability: dit aspect is zeker wel van belang voor het onderzoek. Zo zullen de meeste mensen wel bekend zijn met een webbrowser, maar biedt dit voordelen of juist nadelen? o Learnability: voor mensen die console applicaties soorten gewend zijn en weinig met een muis werken zal dit lastiger zijn dan voor mensen die al veel ervaring hebben met het internet. o Operability: dit aspect zal tevens interessant zijn aangezien de gebruiker in een webbrowser werkt en alle data en schermen van een webserver gehaald worden. Wat gebeurt er bijvoorbeeld als een gebruiker de ingevulde gegevens ongedaan wil maken en dat denkt te doen door op de backtoets te drukken van de webbrowser. o Attractiveness: Bij dit aspect kan onderzocht worden of een interface bijvoorbeeld op een bepaalde manier opgebouwd moet zijn, omdat een gebruiker dit zou verwachten in een webbrowser. Bij webbased applicaties zal er meer met een muis worden gewerkt dan bijvoorbeeld applicaties binnen Unix of DOS, biedt dit voordelen (eenvoudig) voor de gebruiker of juist grotere nadelen (eerder RSI). o Usability compliance: hoe het best een userinterface van een webbased applicatie gemaakt kan worden is al diverse malen onderzocht. Doordat er met een webbrowser wordt gewerkt, zal er moeten worden voldaan aan bepaalde standaarden doordat dit kan worden verwacht door de gebruikers en de webbased-technieken. Efficiency Definitie: capability to provide appropriate performance, relative to the amount of resources used, under stated conditions. [IS00]

Figuur 6 - ISO 9126 karakteristiek efficiency

In de meeste gevallen zal het zo zijn dat een organisatie wil dat een applicatie zo efficiënt mogelijk werkt. Efficiency kan op verschillende manieren bekeken worden. Hieronder wordt de karakteristiek efficiency op drie verschillende aspecten benadert: • • •

time behaviour: er wordt gekeken hoeveel tijd gebruikers en de applicatie zelf nodig hebben om bepaalde taken en handelingen binnen de applicatie te verrichten. Resource behaviour: hoe efficiënt gaat de applicatie om met hardwarebronnen als netwerkverbruik, processor-, interne en externe geheugencapaciteit als het bepaalde functies uitvoert? Efficiency compliance: in welke mate zijn er efficiency standaarden en afspraken voor de soort applicatie die gebruikt kunnen worden?

Pagina 15 van 54

Bachelorscriptie Onderwerp: webbased organisatiespecifieke applicaties Bruikbaarheid onderzoek o Time-behaviour: door de webbased userinterface zal er veel met de muis moeten worden gewerkt. Kost dit meer of minder tijd? De user-interface van webbased applicaties heeft door webbrowser misschien beperkingen vergeleken met bijvoorbeeld een GUI. Zo zou het kunnen zijn dat de rechtermuisknop niet gebruikt kan worden of dat functies als ‘undo’ en ‘re-do’ niet mogelijk zijn. Verder zal het scherm waarmee de gebruiker moet werken waarschijnlijk van de server gehaald worden. Als dit vaak moet gebeuren bijvoorbeeld bij elk nieuw ingevoerd gegeven, kan dit veel tijd kosten. o Resource behaviour: de webbased applicaties zullen zich in een andere applicatie vestigen namelijk de webbrowser. Kost dit juist meer of minder resources aan de server of de client kant? Dit is een belangrijke vraag die bij dit aspect onderzocht kan worden. Hoeveel netwerkverkeer vraagt een webbased applicatie vergeleken met een normale applicatie? Dit kan hoger zijn bij een webbased applicatie aangezien de schermen bij dit soort applicaties van de server worden gehaald in plaats van dat ze bij de client op het werkstation zijn geïnstalleerd. Deze vragen zijn relevant voor het onderzoek. o Efficiency compliance: in de literatuur zal gekeken moeten worden of er al standaarden bestaan die te maken hebben met efficiëntie waaraan een webbased applicatie kan voldoen. Zijn deze standaarden efficiënter of minder efficiënt dan die van traditionele applicaties? Maintainability Definitie: capability to be modified. Modifications may include corrections, improvements or adaptation of the software to changes in environment, and in requirements and functional specifications. [IS00]

Figuur 7 - ISO 9126 karakteristiek maintainability

Aangezien organisaties tegenwoordig vaak opereren als een open systeem, is het logisch te concluderen dat een applicatie regelmatig zal moeten worden aangepast. In deze kwaliteitskarakteristiek wordt dan ook bekeken in welke mate de applicatie dit toestaat. • • • • •

Analyzability: de mogelijkheid om fouten of tekortkomingen eenvoudig via een diagnose vast te stellen en daarbij aan te geven in welk deel van de applicatie deze voorkomen. Changeability: de mogelijkheid om een gespecificeerde verandering in te voeren bij o.a. de specificatie, het ontwerp, de code, de documentatie en zelfs de testsoftware. Stability: het voorkomen van onverwachte complicaties en effecten van een bepaalde ingevoerde verandering. Testability: de mogelijkheid om de aanpassing te valideren na correctheid. Maintainability compliance: het gebruik van standaarden en afspraken die verandering binnen een applicatie op een juiste en goed overwogen manier tot stand brengen.

Pagina 16 van 54

Bachelorscriptie Onderwerp: webbased organisatiespecifieke applicaties Bruikbaarheid onderzoek De hierboven besproken aspecten van de karakteristiek maintainability zullen niet worden behandeld in dit onderzoek. Of een applicatie eenvoudig dan wel zeer lastig is aan te passen, verschilt niet significant bij een webbased applicatie. De manier waarop het gebouwd wordt, is vooral het procesmatige karakter van belang. Al wordt er in sommige literatuur wel aangegeven dat webbased applicaties eerder ad-hoc worden gemaakt [HA02]. Ik ben van mening dat dit meer komt door het onvolwassen karakter waarop dit soort applicaties wordt gebouwd, dan dat het aan het soort van applicaties ligt dat dit veroorzaakt. Verder is er nog weinig onderzoek gedaan naar het goed testen van webbased applicaties in vergelijking met applicatiesoorten als embedded, console en real-time software. Deze onderwerpen zijn dusdanig uitgebreid dat ze een geheel eigen apart onderzoek vergen. Daarom laat ik deze kwaliteitsaspecten in dit onderzoek toch achterwege, vanwege het korte karakter van het onderzoek. Portability Definitie: capability to be transferred from one environment to another (hardware, software, organizational). [IS00]

Figuur 8 - ISO 9126 karakteristiek portability

De portability van een bepaalde applicatie geeft de mate aan waarin een applicatie flexibel is om in verschillende soorten omgevingen te werken. Dit kan essentieel zijn als de applicatie met andere applicaties moet samenwerken of als een applicatie op verschillende platforms of netwerkomgevingen gaat werken. De deelaspecten die we onder deze karakteristiek bekijken zijn: • • • • •

adaptability: het vermogen van de applicatie om in verschillende omgevingen te werken, zonder dat er acties of middelen worden ondernomen die niet van te voren al waren voorzien of opgenomen in de applicatie zelf. Installability: de applicatie kan op verschillende omgevingen worden geïnstalleerd. Co-existence: de applicatie moet in staat zijn om naast andere onafhankelijke applicaties te werken en gebruik te maken van dezelfde soorten bronnen. Replaceability: de applicatie moet in staat kunnen zijn om een ander gespecificeerd software product te vervangen wat dezelfde doelstellingen heeft en in dezelfde omgeving werkzaam is. Portability compliance: om de portability te bewerkstellen zijn afspraken en standaarden haast niet weg te denken. Daarom zal een applicatie hieraan zoveel mogelijk moeten voldoen.

Bruikbaarheid onderzoek: o Adaptability: dit aspect is relevant doordat er moet worden onderzocht of een webbased applicatie beter in staat is in bepaalde netwerkomgevingen te draaien dan traditionele applicaties. Verder wordt onder dit aspect onderzocht of het lastig is de applicatie aan te passen aan de verschillende webbrowsers. o Installability: dit aspect is waarschijnlijk een voordeel voor webbased applicaties of dit voordeel echt zo groot is, wordt hier onderzocht. Misschien is een webbased applicatie niet in staat om in alle soorten omgevingen te worden uitgevoerd.

Pagina 17 van 54

Bachelorscriptie Onderwerp: webbased organisatiespecifieke applicaties o

o

o

Co-existence: zijn webbased applicaties goed in staat om te functioneren naast andere soorten applicaties, bijvoorbeeld met XML? Als een bedrijf bijvoorbeeld fuseert, kan het zo zijn dat de webbased applicatie naast een grote SAP-applicatie moet werken. Kan het dan op dezelfde servers en werkstations geïnstalleerd zijn en kan de webbased applicatie van dezelfde database gebruik maken zonder dat dit problemen oplevert? Replaceability: bij dit aspect gelden dezelfde relevante onderzoeksdomeinen als bij het aspect co-existence. Deze vraag is het meest relevant als een organisatie van plan is zijn software webbased te maken. De applicatie zal dan waarschijnlijk van dezelfde data gebruik moeten maken als de applicatie die het vervangt. Portability compliance: om bijvoorbeeld dezelfde bronnen te gebruiken of in meerdere soorten omgevingen uitgevoerd te kunnen worden zal een applicatie van al bestaande standaarden gebruik moeten maken. Daarom is het interessant om te onderzoeken of een webbased applicatie hiertoe in staat is.

3.3 Conclusie Uit het voorgaande is gebleken dat niet alle zes karakteristieken van de ISO standaard in dit onderzoek aan bod komen. De voornaamste redenen hiervan zijn: Voor bepaalde karakteristieken is al een goed onderzoek gedaan, de deelaspecten van een karakteristiek zijn niet interessant genoeg voor het hoofdthema of door het kleine karakter van dit onderzoek. In de vorige paragraaf 3.2 is er een antwoord tot stand gekomen op subdeelvragen b en c van de tweede deelvraag die als volgt geformuleerd was: “Welke kwaliteitskarakteristieken van ISO 9126 geven het duidelijkst de voor- en nadelen weer om een applicatie dan wel webbased of niet webbased te maken?” Het antwoord op deelvraag twee zijn de volgende karakteristieken zie figuur 9: functionality, usability, efficiency en portability. De volgende karakteristieken en aspecten worden daarom buiten het onderzoek gelaten: reliability en maintainability en de aspecten suitability en accuracy van de karakteristiek functionality.

Figuur 9 – ISO 9126 model met in blauw aangegeven welke aspecten worden behandeld en in rood welke aspecten buiten dit onderzoek vallen.

Pagina 18 van 54


4 Kwaliteitskarakteristieken webbased applicaties Binnen dit hoofdstuk zal elk kwaliteitsaspect apart in een paragraaf worden behandeld. In de paragrafen worden punten behandeld die voor dit aspect opmerkelijk zijn en specifiek gelden voor webbased applicaties. Daarbij zullen er vergelijkingen worden gemaakt, wat er anders is in het aspect bij webbased applicaties en of dit juist voordelen of nadelen zijn ten opzichte van andere soorten. In dit hoofdstuk wordt er een antwoord in de literatuur gezocht op de derde deelvraag van dit onderzoek.

4.1 Functionality In deze paragraaf zullen de aspecten interoperability, security en functionality compliance worden behandeld zoals in paragraaf 3.3 was aangegeven. Bij interoperability worden middleware technieken en client-server architecturen besproken. Bij security worden diverse beveiligingsmodellen besproken. Als laatste geven we bij functionality compliance de standaarden weer die voor webbased technieken aanwezig zijn.

4.1.1 Interoperability Als een applicatie een zo goed mogelijke kwaliteit voor interoperability wil nastreven, kan de applicatie het best zoveel mogelijk met bepaalde standaarden gaan werken, om beter te kunnen communiceren met andere applicaties. Vooral voor data-uitwisseling tussen verschillende applicaties is dit belangrijk. Deze communicatie tussen verschillende applicaties verloopt via een bepaalde infrastructuur. Volgens Serbedzija zijn er een aantal verschillende modellen belangrijk om te onderscheiden als we kijken naar webbased applicaties [SB04]. Deze modellen zijn ontstaan aan de hand van het client-server model. Hierin wordt de user-interface en programma (client) gesplitst van het datamodel (server). Internetapplicaties werken meestal volgens dit model. Een voorbeeld is een internetapplicatie met internetpagina’s met veel javascript. Hierbij bevindt de applicatielogica zich vooral aan de client-side. De volgende modellen zijn van belang om te onderscheiden bij webbased applicaties [SB04]: -

-

-

Het medium-client model was heel populair in de jaren 80 en werd vooral op LAN’s veel gebruikt voor database systemen. Hierin wordt de applicatie evenredig verdeeld over de server en de client. De gebruikersprocessen vinden aan de client kant plaats. Server georiënteerde processen worden daarentegen zoveel mogelijk op de server uitgevoerd. Dit model is in de oude vorm niet geschikt voor webbased applicaties aangezien de koppeling tussen de client en de server te sterk aanwezig is. Het null-client model. Bij dit model vinden alle systeemprocessen op de server plaats. Bij de client vinden we alleen een simpele gebruikersinterface. Het oude mainframe systeem met terminals is hier een goed voorbeeld van. Dit model is een perfect model voor server-side webapplicaties en wordt ook veel op het WWW toegepast met standaard formaten als HTTP voor communicatie en HTML voor de presentatie. Hier vind je vooral de velen soorten interfaces als asp, php en cgi. Het thin-client model wordt veel toegepast bij Java applicaties. Dit model zit tussen de null-client en medium-client model in en heeft een extra laag er tussen, namelijk de middleware. Op deze laag bevindt zich dan vaak de applicatielogica waardoor de input en output van de gebruiker wordt geregeld. Door een middleware laag toe te voegen blijft de applicatie aan de client kant klein.

Pagina 19 van 54

Bachelorscriptie Onderwerp: webbased organisatiespecifieke applicaties Het laatste model is volgens het artikel het meest geschikt voor de webbased organisatie specifieke applicaties die we bespreken. In dit model bevindt zich zoals gezegd een zogenaamde middleware. Hieronder wordt uitgelegd wat dit precies is in het model. Middleware wordt ook wel gedefinieerd als [SB04]: de verbindende software dat elementen van een applicatie in interactie laat zijn door netwerklinks. Het hoofddoel van een middleware is een verbindingsbrug zijn tussen de verschillende systeemarchitecturen, besturingssystemen, databases en programmeertalen. Er kan dus wel worden gesteld dat de middleware het kwaliteitsaspect inter-operability sterk verhoogt voor een bepaalde applicatie. Wil een webbased applicatie hier ook hoog op scoren, dan kan deze het best een thin-client model nemen als infrastructuur model. Enkele webbased-middleware technieken zijn al beschikbaar zoals Java RMI en CORBA. Dit thin-client model samen met een webbased-middleware maakt het een stuk eenvoudiger om een huidige applicatie om te zetten naar een webapplicatie. Tevens geeft dit model voordeel als er een nieuwe applicatie wordt gebouwd die met andere systemen moet communiceren of van dezelfde databronnen en infrastructuur gebruik gaat maken.

4.1.2 Security Voor de organisatiespecifieke applicaties die we in deze scriptie behandelen is security een zeer belangrijk aspect. De reden hiervoor is dat deze applicaties vaak vertrouwelijke en waardevolle informatie en data bewerken. Deze data en informatie wordt tussen de verschillende componenten heen en weer gecommuniceerd. Er zullen daarom diverse beveiliging- en toegangsmodellen worden geïmplementeerd voor de applicatie. In dit soort applicaties moet er vaak per rol of gebruiker worden vastgelegd tot welke objecten en data deze toegang of bewerkingsrechten hebben. Voor bestaande soorten van applicaties zijn er al security modellen beschikbaar die zekerheid bieden en veel worden toegepast. Echter voor webapplicaties zijn er nog geen standaard modellen die zo geïmplementeerd kunnen worden. Er wordt vaak wel een model of een combinatie van de oude modellen op webapplicaties toegepast. Door het andere karakter van een webapplicatie dat een aantal extra issues en verschillen met zich meebrengt, bieden deze security modellen hiervoor nog niet voldoende zekerheid. Twee van deze modellen zijn het DAC en MAC model. Hieronder volgt een korte beschrijving van deze modellen. Het DAC (discretionary access control) model [JA01]: dit model is zo opgesteld dat het alle objecten en informatiesoorten verzamelt en daar worden dan specifieke beveiligingsrichtlijnen voor opgesteld. Dit model is vrij flexibel en wordt daarom wel voor webbased applicaties toegepast. Een grote keerzijde is dat het model kopiëren van gevoelige informatie van het ene object naar het andere object toelaat. Iemand kan vervolgens hier misbruik van kan maken. Het MAC (mandatory access control) model [JA01]: dit model is gericht op het beveiligen van de verschillende informatiestromen binnen een applicatie door hier verschillende vertrouwelijkheidniveaus op aan te brengen. De objecten hebben dan ook vertrouwelijkheidniveaus toegewezen gekregen waardoor ze tot bepaalde informatie toegang hebben. Het is gebaseerd op het militaire Bell-LaPadula model. Voor webbased applicaties is het model interessant doordat de serviceprovider van de applicatie een multi-level rangschikking kan maken van toegang tot bepaalde informatie aan de verschillende soorten gebruikers. Beide traditionele modellen worden nog wel toegepast voor webbased applicatie maar vooral een combinatie van deze twee modellen. Om deze combinatie nog succesvoller te maken, moet er bij webbased applicaties gelet worden op: bescherming van kopiëren en verspreiding van data, actieve objectmanagement en complexe interactiesystemen. Er zijn nieuwere modellen voorgesteld die dit wel proberen te implementeren. Er is het RBAC model, wat een speciaal toegepast model op webbased applicaties bevat en er worden nieuwe zogenaamde TBAC modellen voorgesteld.

Pagina 20 van 54

Bachelorscriptie Onderwerp: webbased organisatiespecifieke applicaties Het RBAC (Role-based Access Control) [JA01] is een rolgericht model waar in rollen toegang hebben tot bepaalde objecten. Dit biedt vooral voordelen bij grotere webbased applicaties met veel gebruikers. Er is ook een webbased gebaseerde implementatie van dit model dat gebruik maakt van SSL en HTTPS authenticiteitmechanismen. Een hoofdkenmerk van RBAC is zijn potentiële steun voor een multi-domein omgeving, die het tot een aantrekkelijke kandidaat voor webbased applicaties maakt. De vorige modellen DAC, MAC en RBAC zijn vooral gebaseerd op de aanpak vanuit een gebruikersperspectief. Ze zijn daarom vaak niet flexibel genoeg voor gebruik van beleid gericht op de content / informatie en de taken en transacties zoals die vaak binnen organisatiespecifieke webbased applicaties bestaan. Diverse onderzoekers hebben daarom een familie van TBAC (task-based access control) modellen samengesteld [JA01]. Deze modellen bestaan uit delen van de hierboven besproken modellen in de vorm van een hiërarchie. Het TBAC model is nog niet af en wordt daardoor niet of nauwelijks toegepast. Hoewel er een fenomenale groei is geweest van webbased applicaties op het internet is de beveiliging van toegangscontrole op deze applicaties grotendeels verwaarloosd. De RBAC en TBAC modellen geven al wel enig potentieel voor het grote assortiment van veiligheidsvereisten die grote ondernemingen stellen voor hun webbased applicaties. De volgende drie redenen vereisen een goed security model voor webbased applicaties [JA01]: - de beschikbaarheid van hoge volumes van gevoelige informatie van de eindsystemen die door ondernemingen en overheid gekoppeld aan het internet zijn; - gemakkelijke distributie van kwaadaardige software door virussen; - het gemak waarin computermisdaden anoniem vanaf geografische grenzen uitgevoerd kunnen worden. Daarbij komt het tekort van gerechtelijk bewijs in computermisdaden, die de ontdekking en het veroordelen van misdadigers extreem lastig maakt. Een aantal technieken die veel in security modellen worden toegepast zijn public-key infrastructuren, digitale handtekeningen voor authenticatie en encryptie mechanismen om gegevens tijdens datatransport te versleutelen. Een speciale werkgroep ‘Het Web application security consortium’ [WA05] is nu bezig richtlijnen op te stellen voor een firewall die als hoofddoel heeft het beveiligen van een webapplicatie. Het is een open forum waarin professionele security experts uit het bedrijfsleven en de academische gemeenschap deelnemen. Een groot voordeel van een firewall is dat het geen aanpassing van de code noodzakelijk maakt binnen de applicatie. Verder zal een webapplicatie firewall(WAF) ervoor zorgen dat bedrijven zelf niet bij nieuwe ontdekte beveiligingsgaten hun software aan hoeven te passen maar alleen de firewall moeten updaten. Een aantal van de richtlijnen die tot nu toe opgesteld zijn [WA05]: -

de WAF moet kunnen omgaan met de veel toegepaste encryptie techniek SSL en moet de data hierbinnen kunnen lezen om na te gaan of het veilige SSL aanvragen zijn; de WAF moet in staat zijn bepaalde gevaarlijke soorten verkeer te blokkeren voordat het de servers van de organisatie kan benaderen.; de WAF kan zowel als software als een hardware component worden opgeleverd; de WAF moet de ‘availability’ van een grote website kunnen garanderen; de WAF moet met de bekende internetstandaarden kunnen werken als verschillende versie van het HTTP-protocol; de WAF moet diverse gebeurtenissen kunnen loggen zoals HTTP-transacties.

Pagina 21 van 54


4.1.3 Functionality compliance Bij een webapplicatie moet er veel meer rekening worden gehouden met openbare multiplatform standaarden dan bij andere soorten applicaties. Dit komt doordat de applicatie zich in een webbrowser bevindt waardoor de webapplicatie aan bepaalde eisen moet voldoen. Dit kan soms enige nadelen opleveren omdat koppelingen anders gaan of bepaalde interacties niet geregeld kunnen worden in de user-interfaces. Toch zijn de voordelen vaak groter dan de nadelen als men met standaarden werkt. Zo heeft men bijvoorbeeld meer aanbod van kant-en-klare componenten, zijn koppelingen naar andere systemen / applicaties eenvoudiger aan te leggen en is er eenvoudiger professionele kennis voor het ontwikkelen of onderhouden te verkrijgen. Er zijn op het moment veel verschillende technieken, webbrowsers en servers die gebruikt kunnen worden. Lang niet alle technieken voldoen aan de standaard die het W3C heeft opgesteld voor het internet en werken daardoor ook niet op alle webbrowsers en besturingssystemen. Bij het maken van een webapplicatie voor een organisatie is het verstandig om hier zo min mogelijk van af te wijken. In het artikel van Doyle [DV05] worden de diverse technieken overzichtelijk uiteengezet die voor interactieve webapplicaties worden gebruikt. Deze zijn te zien in een aantal tabellen in bijlage I. In het artikel worden deze technieken in drie topclassificaties opgedeeld: -

-

-

foundational technologies [DV05]: is de basisfunctionaliteit van het web dat wordt bepaald door het protocol HTTP, de content standaarden als HTML, XHTML en CSS. De basis server functionaliteit wordt tevens bepaald door het HTTP-protocol. In de tabellen 1 en 2 van bijlage I is een overzicht te zien met o.a het marktaandeel van de webbrowsers. Integration technologies [DV05]: deze technieken maken niet direct dynamische content aan maar zorgen ervoor dat webapplicaties toegang hebben tot informatie in andere systemen bijvoorbeeld verschillende databases. Veel gebruikte standaarden van deze technologieën zijn weergegeven in tabel 3 en 4 van bijlage I. Dynamic content generation technologies [DV05]: deze technologieën zorgen voor de dynamische content van een webapplicatie. Deze worden gebruikt voor de soort applicaties die we bespreken in dit onderzoek. Een aantal voorbeelden van deze technieken staan in de tabellen 5, 6 en 7.

Pagina 22 van 54


4.2 Usability Er zijn de laatste jaren veel artikelen gepubliceerd die de usability bespreken van websites. In deze artikelen gaat het echter om website en e-commerce specifieke zaken en minder over de usability van webapplicaties die iemand gebruikt voor zijn werk. Deze kijk op usability is namelijk geheel anders. Bij e-commerce applicaties gaat het vooral om availability en de pagina zo aantrekkelijk mogelijk maken voor de eerste indruk van een bezoeker. Een bezoeker moet snel worden aangetrokken door de website en moet de pagina snappen. Dit is voor organisatie specifieke applicaties anders omdat deze applicaties een langere tijd aantrekkelijk moeten blijven om mee te werken. Een aantal belangrijke onderwerpen die besproken worden van usability die terug gevonden zijn in de literatuur, zijn onder andere: ‘adaptability’ van een webbased applicatie wat besproken wordt onder het aspect learnability, en de structuur van de applicatie zodat de gebruiker weet waar hij zich bevindt, binnen een proces van de applicatie, dit is te vinden onder het aspect operability. Voor de rest is een consistent uiterlijk en gedrag van de applicatie van belang zodat werknemers comfortabel kunnen werken, wat terug zal komen onder understandability en attractiveness.

4.2.1 Understandability Als een gebruiker gaat werken met een applicatie is het van groot belang dat hij weet wat een bepaalde actie voor een gevolg heeft. Deze gevolgen zullen daarom zo goed mogelijk aangegeven moeten worden binnen een applicatie. Voor gevaarlijke of grote gevolgen van acties zal om een bevestiging gevraagd moeten worden. Tevens zal er geprobeerd moeten worden aan te geven binnen de applicatie wanneer een actie voltooid is. Bij webbased applicaties moet hier vooral op gelet worden. Dit komt doordat een webbased applicatie in de meeste gevallen meer een schil bovenop een andere applicatie is waardoor de gevolgen minder zichtbaar zijn. Denk bijvoorbeeld aan webbased applicaties die het thin-client of null-client model toepassen. Alle echte applicatielogica bevindt zich dan op een andere server waardoor de werking wat meer verborgen is. De user-interface van een webbased applicatie werkt meestal ook op een heel andere manier dan een consoleapplicatie of een GUI. Eén klik met de linkermuisknop op een link kan al een actie uitvoeren in tegenstelling tot een traditionele applicatie waar vaak meerdere harde enters of dubbelklikken nodig zijn om een actie uit te voeren. Aangezien alle acties met één klik op een link gaan binnen een webbased applicatie, terwijl mensen dubbelklikken gewend kunnen zijn vanuit de Windows-omgeving, dient de gebruiker zich hier van bewust te zijn en gemaakt te worden door de applicatie. De ontwerper van een applicatie zal er dus voor moeten zorgen dat er iets veranderd in het scherm zodra de gebruiker op een actie klikt. Statusveranderingen binnen een applicatie zijn in een webbased user-interface een stuk lastiger weer te geven voor de gebruiker, maar toch zal een webontwikkelaar het moeten proberen in te bouwen. De recentere techniek AJAX [PL05] en Java kunnen hierbij echter helpen. Zo kan er voorkomen worden, door gebruik te maken van AJAX, dat een volledige pagina vernieuwd moet worden. De user-interface kan dan veel sneller laten zien dat een actie uitgevoerd wordt of dat de applicatie zich in een andere status bevindt. Een ander belangrijk punt is dat de gebruiker bij het eerste en eventueel latere gebruik goed duidelijk moeten worden gemaakt, dat hij met een webbrowser heeft te maken waarbinnen de applicatie werkt. Dit kan een aantal complicaties geven waardoor de gebruiker soms niet meer weet wat hij doet. Als de gebruiker bijvoorbeeld verschillende browservensters heeft openstaan waarin hij werkt kan dit problemen opleveren doordat de statussen verschillen van het ene venster met het andere venster. Zo kan een gebruiker in één venster bijvoorbeeld een object hebben verwijderd uit de database terwijl in het andere oude venster de gebruiker dit verwijderde object nog kan bewerken.

Pagina 23 van 54

Bachelorscriptie Onderwerp: webbased organisatiespecifieke applicaties Dit soort situaties kunnen rare foutmeldingen opleveren en de ontwerper / programmeur zal deze situaties moeten voorkomen. In ‘traditionele’ applicaties komt dit veel minder voor. Hiervoor zijn twee redenen. Ten eerste doordat een applicatie zelf zich echt in een bepaalde staat bevindt, en ten tweede doordat de applicatie in de meeste gevallen maar één keer kan worden opgestart. Een zelfde soort probleem is dat het veel gebruikte principe van ‘undo’ (laatste actie ongedaan maken) en ‘redo’ (laatste actie weer herhalen) wordt verwisseld met de knoppen vorige(back) en volgende(forward) van de webbrowser. Dit blijkt wel uit het onderzoek van Pop [PP01], waarin een desktop kalender applicatie wordt vergeleken met een webbased variant. In sommige bestaande webapplicaties is de ‘undo’ taak wel geïmplementeerd door de laatste actie van een gebruiker bij te houden in de sessieinformatie aan de server kant van de webapplicatie. Toch kan vaak niet meer dan één actie terug ongedaan worden gemaakt in tegenstelling tot vele GUI desktopapplicaties. Het gebruik van de vorige en volgende knoppen van een webbrowser bij een webapplicatie kan in sommige gevallen gevaarlijke en / of verwarde situaties opleveren. Doordat de status niet bij de client wordt bijgehouden maar bij de middleware of de applicatieserver en de pagina’s dynamisch zijn gemaakt, kunnen de volgende situaties optreden (verschillend van hoe de webapplicatie gebouwd is): -

-

er komt een scherm met allemaal verschillende foutmeldingen; de gebruiker krijgt een oud scherm te zien wat is opgeslagen op zijn eigen computer, waardoor hij waarschijnlijk een verkeerde status van de applicatie te zien krijgt, waar vervolgens door hierop acties uit te voeren weer foutmeldingen kunnen ontstaan; de applicatie vangt dit op en staat dit niet toe, waarnaar het de gebruiker weer terug laat gaan naar het startpunt; de applicatie reageert hier op zoals de gebruiker waarschijnlijk gewild zou hebben en maakt de laatste actie ongedaan, zodat de applicatie zich weer in de staat bevindt van het vorige scherm.

Het is uiteraard noodzakelijk dat de gebruiker van te voren weet wat er gebeurt. Anders kunnen er rare situaties ontstaan aangezien de gebruiker dan niet meer snapt wat hij precies doet binnen de applicatie.

4.2.2 Learnability Het begrijpen en leren hoe een applicatie werkt kan soms binnen een dag. Dit kan voor de organisatiespecifieke webbased applicaties uit dit onderzoek langer duren. Bij een uitgebreide organisatorische applicatie waarin veel verschillende soorten processen worden verwerkt kan dit weken of maanden duren. Soms kan er voor deze soort applicaties ook geen training worden opgezet, waarin met testdata wordt gewerkt. Men zal dan tijdens het daadwerkelijke gebruik van de applicatie het zich moeten aanleren. Het is daarom handig dat niet meteen alle functies / procedures voor een gebruiker zichtbaar zijn in de user-interface, zodat de gebruiker niet overspoeld wordt met termen en knoppen waar hij de werking niet van kent en begrijpt. Het is beter als een applicatie de user-interface aanpast aan (het niveau van) de gebruiker. Dit wordt ook wel adaptability genoemd. In het artikel [KR01] van Kappel wordt behandeld hoe dit voor een webbased applicatie gerealiseerd kan worden. De aanpasbaarheid van webbased applicaties vindt volgens dit artikel volgens een 3D model plaats die is opgedeeld in levels (content, hypertext, presentation), aspecten (structure, behaviour) en fases (analyse, design en implementatie).

Pagina 24 van 54


Figuur 10 – 3D model aandachtgebieden van adaptability webapplicaties [KR01]

Niet alleen moet bij de presentatie rekening worden gehouden met het aanpassen naar gebruikersvoorkeuren (welke informatie) maar ook moeten de navigatiestructuren aanpasbaar aan de gebruiker worden gemaakt. Zoals in het model te zien is, zijn er zo nog een aantal andere dimensie waarmee rekening gehouden dient te worden bij het ‘adaptabile’ maken van een applicatie. Het is een complex proces om alle dimensies goed te kunnen modelleren en de meeste modelleertechnieken zijn hier nog niet goed toe in staat. Hierdoor blijft het voorlopig nog lastig om een ‘adaptable’ applicatie te creëren. Toch zal een webapplicatie bouwer er zoveel mogelijk naar moeten streven de userinterface zo in te richten dat het voor de gebruiker eenvoudig is te begrijpen. Dit kan al eenvoudig gerealiseerd worden door goed over een navigatiemenu na te denken en bijvoorbeeld alleen short-cuts aan te bieden aan de wat gevorderde gebruiker. Als er gekeken wordt naar de ‘traditionelere’ applicatie kan de gebruiker vaak zijn voorkeuren en instellingen opslaan op zijn eigen computer. Doordat een webbased applicatie al zijn logica, informatie en interfaces vaak van een server (middleware) haalt, is dit lastiger te realiseren. Een webbased applicatie zal daarom de instellingen van de gebruikers ook op deze server moeten opslaan. Uit [KR01] blijkt dat het goed te ontwikkelen is om voor elke gebruiker de instellingen op te slaan op de server bij een webbased applicatie. De ontwikkelaar kan dan zelfs proberen om met de verschillende dimensies uit figuur 10 rekening te houden, waardoor de webbased applicatie ‘adaptable’ wordt. Voor mensen die nog nooit met het internet gewerkt hebben, is het handig een extra cursus te organiseren, om hier mee bekend te raken. Er kan namelijk niet zonder meer worden aangenomen dat iedereen de webinterface kent. Daarnaast is het net als bij ‘traditionele’ desktopapplicaties soms verstandig om begincursussen te organiseren voor de applicatie vooral als het grotere en complexe applicaties betreft. Op dit gebied zullen webbased applicaties niet veel verschillen met de ‘traditionele’ varianten.

4.2.3 Operability Onder dit aspect wordt besproken hoe een gebruiker met de webbased applicatie kan omgaan en of hij weet wat hij doet als hij bijvoorbeeld op een link klikt. De vraag is of een gebruiker bij een webbased applicatie beter in staat is om de applicatie te beheersen en er controle over te hebben dan bij een traditionele applicatie. Het navigeren door de applicatie wordt in de literatuur [EA99] als een belangrijk nadelig punt voor webbased applicaties genoemd. Bij ‘traditionele’ applicaties kan men vaak maar op één manier bij een bepaalde taak komen. Bij webbased applicaties daarentegen komt het vaak voor dat men op verschillende manieren bij de taak kan belanden. Dit maakt de applicatie voor de beginnende gebruiker vaak een stuk complexer. Dit probleem heeft ook wel de volgende titel gekregen: “lost in hyperspace syndrome”. Dit geeft aan dat er een duidelijke structuur moet komen, voornamelijk in de implementatie van het navigeren door de applicatie heen. Dit komt doordat de status van de applicatie veel minder duidelijk aanwezig is bij een webapplicatie in tegenstelling tot GUI-applicaties, waar het meestal

Pagina 25 van 54

Bachelorscriptie Onderwerp: webbased organisatiespecifieke applicaties wel duidelijk zichtbaar en herkenbaar is. Alleen een duidelijke structuur voor de applicatie kan dit status probleem oplossen [EA99]. Een duidelijke structuur wordt bij een website / webapplicaties vaak opgebouwd als een boom zoals geïllustreerd in figuur 11.

Figuur 11 – Boomstructuur webhiërarchie [EA99]

Een voordeel van het gebruik van een boomstructuur is dat de gebruiker eenvoudig kan zien op welke niveau hij zich in de applicatie bevindt (sitemap). Het is anders als een gebruiker een bepaald aantal acties uitvoert binnen een webbased applicatie die in een bepaalde reeks / volgorde tot elkaar staan. Als een gebruiker bij het eindpunt van deze reeks van acties is, dan is het voor de gebruiker niet zo zeer belangrijk op welke locatie die zich bevindt maar is het meer belangrijk op welke locatie hij wordt terug verwezen. Het is dus voor de gebruiker veel interessanter om te weten op welke positie hij zit binnen de reeks van de uit te voeren acties. Daarom zal deze actiereeks zo logisch mogelijk moeten worden ingebouwd in de hiërarchie van de applicatie. Als een gebruiker van een applicatie bepaalde taken of acties wil gaan uitvoeren dan doet hij dat meestal volgens een bepaalde volgorde. In deze volgorde zijn verschillende stadia die een gebruiker doorloopt en waar problemen kunnen optreden. De verschillende stadia zijn [EA99]: 1. forming the goal: tijdens dit stadium heeft de gebruiker de behoefte om een bepaald probleem op te lossen. 2. Forming the intention: de gebruiker besluit om door middel van een algemene aanpak het probleem op te lossen. 3. Specifying an action: de intentie is om gedetailleerd in een bepaalde volgorde de acties te ondernemen. 4. Executing the actions: uitvoeren van deze acties. 5. Perceiving the state of the world: de gebruiker observeert de resultaten van zijn acties. 6. Interpretation of the state of the world: de gebruiker trekt conclusies hoe de omgeving is veranderd door zijn ondernomen acties. 7. Evaluation of the outcome: de gebruiker relateert zijn interpretaties in de vorm van doelen en bekijkt aan de hand hiervan of er meer acties nodig zijn om het probleem op te lossen. In figuur 12 zijn deze stadia nog eens langs een tijd en abstractie-as weergegeven. Per stadium zullen nu aandachtgebieden worden behandeld waarop gelet moet worden bij het ontwikkelen en implementeren van een webapplicatie.

Pagina 26 van 54


Figuur 12 – De 7 stadia van een actie met daarbij aandachtgebieden voor webapplicaties [EA99]

1: De gebruiker moet hier weten dat hij de webapplicatie kan gebruiken om het probleem op te lossen. Hij moet dus weten hoe hij bij deze webapplicatie kan komen. Webapplicaties zijn minder zichtbaar aanwezig. Hiermee dient rekening gehouden te worden. Er kan een icoon op de desktop gemaakt worden naar de root van de webapplicatie, of door op een startpagina (homepage intranet) een link te plaatsen naar de webapplicatie. 2: Hier is vooral de structuur en navigatie van de site van belang. Dit kan goed worden verzorgd door duidelijke webadressen proberen te maken en een sitemap van de webapplicatie te maken. Deze sitemap kan ook in een kleinere vorm aanwezig zijn op elke pagina. Dit kan bijvoorbeeld door deze bovenin de menubalk te plaatsen, waarin alleen de ouders en grootouders tot aan het root element worden weergegeven. Bij een webbased applicatie moeten er duidelijkere namen aan links of knoppen worden gegeven dan bij GUI’s, omdat gebruikers minder bereid zijn om de applicatie te verkennen. De gebruiker kent vaak niet de hele applicatie daarom is het nodig om de structuur consistent te maken. 3: Alle bewerkacties van informatie en gegevens moeten consistent zijn aangebracht. Zo heb je bijvoorbeeld bij een GUI applicatie de actie ‘cancel’. Deze actie is lastiger in te voeren voor een webbased applicatie. De actie kan het beste gevormd worden door simpelweg elke keer bij ‘cancel’ één niveau omhoog te gaan in de structuur, dus vanaf het kind bij de vorige ouder te belanden. 4: Om een goede prestatie te behouden moeten er zo weinig mogelijk page-loads voorkomen tijdens de uitvoering van verschillende acties. 5: Om een beter prestatieniveau van de gebruiker binnen de applicatie te krijgen, moet er geen misinterpretatie kunnen ontstaan van de gegeven data en informatie op een pagina. De relevante informatie moet op de pagina ook snel te vinden zijn. Zet daarom nooit meer informatie op een pagina dan nodig is, maar juist wel die informatie die relevant is, en de gebruiker nodig kan hebben voor het invullen van gegevens. Geef de verschillende soorten pagina’s een consistent ontwerp. Zet de acties dicht bij de data waar ze op gericht zijn en groepeer de informatie correct. 6: Zorg dat de gebruiker kan zien dat hij een actie voltooid heeft. De gebruikte terminologie moet tevens duidelijk zijn. Als er bijvoorbeeld een scherm moet komen om een cookie te accepteren maak dit dan duidelijk aan de gebruiker, met niet te technische termen die de gebruiker waarschijnlijk niet kent. 7: Hiervoor zijn geen opmerkingen. Uit het voorgaande blijkt dat er een aantal verschillende punten zijn die opvallen en waaraan moet worden gedacht bij webbased applicaties. Een aantal van deze punten gingen vaak bij ‘traditionele’ applicaties van zelf goed.

Pagina 27 van 54


4.2.4 Attractiveness Om een webbased applicatie aantrekkelijk te maken voor een gebruiker zal de applicatie zoveel mogelijk moeten voldoen aan de verwachtingen van gebruikers. Als een gebruiker bijvoorbeeld een klik maakt met een muis moet de applicatie zoveel mogelijk voldoen aan wat de gebruiker met de klik bedoeld had. Qua uiterlijk kan er veel bereikt worden met een webapplicatie. De HTML-structuur is een opmaaktaal die de ontwikkelaar ruime mogelijkheden biedt voor het ontwerpen van een consistent duidelijke en mooie applicatie. De nieuwe HTML standaard, XHTML in combinatie met CSS (cascade style sheets) maakt het de ontwerper eenvoudiger om een consistent uitziende applicatie te ontwikkelen. In deze nieuwe standaard is de informatie / data gescheiden van de opmaak. In het XHTML bestand bevindt zich de informatie en de eventuele applicatielogica en daarbinnen bevindt zich een link naar een CSS bestand waarin alle code staat betreft het opmaken van de pagina. Dit opmaakbestand kan dan voor elke pagina opnieuw worden gebruikt, zodat elke internetpagina dezelfde opmaak heeft. Bij webbased applicaties moet er veel met de muis worden genavigeerd en geklikt. Dit kan als vervelend en niet aantrekkelijk worden ervaren, doordat gebruikers altijd gewend waren alles met het toetsenbord te kunnen uitvoeren. Een ontwikkelaar kan hier tevens rekening mee houden door sneltoetsen beschikbaar te stellen binnen de applicatie, die vooral voor een gevorderde gebruiker interessant zijn. Een andere manier om de muisbewegingen binnen de applicatie te beperken, is door alle informatie in één keer op het scherm weer te geven zodat de gebruiker niet hoeft te scrollen. Bij een goed ontwerp staat alle informatie direct zichtbaar op het scherm en hoeft er niet naar beneden gescrolld te worden. Een geheel ander probleem bij webbased applicaties is dat de gebruiker meerdere soorten webbrowsers kan gebruiken en verschillende schermresoluties. Bij de ontwikkeling moet hier rekening mee worden gehouden. De gebruiker kan hierop geattendeerd worden om toch een andere webbrowser of een andere resolutie te gebruiken. De ontwikkelaar kan proberen de webbased applicatie voor zoveel mogelijk webbrowsers en schermresoluties goed bruikbaar te maken. Er zijn technieken zoals Javascript beschikbaar waarmee de applicatie kan opvragen wat de instellingen van een gebruiker zijn zodat de applicatie zich hierop kan aanpassen.

4.2.5 Usability compliance Bij webbased applicaties zijn diverse usability standaarden voorgesteld. Zo heeft het W3C accessibility checklijsten [W3C] opgesteld, waaraan webbased applicaties kunnen voldoen zodat ze voor een grote groep mensen te gebruiken zijn waaronder mensen met een bepaalde handicap. Hierin staan onderwerpen uitgelegd zoals bijvoorbeeld wat je moet doen voor niet-tekst onderdelen e.d. Er is al heel veel onderzoek gedaan naar de wijze waarop webbased applicaties het best functioneren voor een gebruiker. De meeste organisaties volgen daarin dan ook de standaarden zoals het W3C die voorstelt. Verder kunnen de standaarden van ISO 9241 en ISO 13407 worden nagestreefd, maar deze zullen niet verschillen voor webbased applicaties in vergelijking met traditionele applicaties. Het is zoals al besproken in andere paragrafen (4.1.3) verstandig om niet teveel af te wijken van de webstandaarden zoals gebruikers die gewend zijn op het internet. Er zal hier nu niet dieper op in worden gegaan door de kleinschaligheid van dit onderzoek.

Pagina 28 van 54


4.3 Efficiency De meeste literatuur die beschikbaar is over het onderwerp efficiency gaat over ecommerce applicaties. Een deel van het beschrevene kan gebruikt worden voor de organisatiespecifieke applicatie die in dit document wordt behandeld. In de paragraaf time behaviour worden de tekortkomingen van webapplicaties van GUI-mechanismen besproken. In de paragraaf van resource behaviour behandelen we vervolgens de onderwerpen server-clustering en middleware technieken.

4.3.1 Time behaviour Bij time behaviour gaat het er om hoe snel een gebruiker kan werken met een webbased applicatie. Hier is niet veel van terug te vinden in de literatuur. Dit komt doordat het verschilt op de manier hoe een applicatie opgebouwd is. Wel kwamen een aantal zaken naar voren in het onderzoek van [PP01] die kenmerkend zijn voor webapplicaties en het werken ermee trager laten gaan. Maar tegenwoordig zijn deze met de nieuwste technieken meestal goed op te lossen. Hieronder zullen deze punten behandeld worden met daarbij eventuele opmerkingen erbij: •

• •

•

er kwam naar voren dat gebruikers van webbased applicaties snel geneigd zijn om andere internetsites te gaan bezoeken in plaats van te werken binnen de applicatie [PP01]. Binnen een bedrijf kan het bezoeken van andere webpagina’s worden afgesloten voor bepaalde gebruikers door de firewall. De gebruikers hebben dan alleen nog recht om intranetsites binnen het bedrijf te bezoeken. Voor thuiswerkers en managers e.d. die wel toegang nodig hebben, is dit niet te regelen en moet er vertrouwd worden op hun eigen verantwoordelijkheid. Een bepaalde actie ongedaan maken kwam in het onderzoek naar voren als een tijdrovend probleem [PP01]. Dit hoeft niet meer zo te zijn als de applicatie op een andere manier wordt ontwikkeld, zie hiervoor paragraaf 4.2.1. Slepen en rechtermuisknop acties zijn vaak niet beschikbaar binnen webbased applicaties. Dit kan veel tijd kosten aangezien er nu via speciale dialoog-vensters gegevens moeten worden veranderd of ingevuld [PP01]. Er zijn al een aantal applicaties gesignaleerd waar dit in een beperkte mate wel mogelijk is gemaakt zoals de webbased versie van het emailprogramma Microsoft Outlook. Toch blijft dit lastig aangezien er bij veel webbrowsers de rechtermuisknopacties zijn uitgeschakeld. Hier dient een ontwikkelaar van een webapplicatie dus wel degelijk rekening mee te houden. Verder dient een ontwikkelaar wel consistent te zijn met het invoeren van deze acties. Zo kan er bijvoorbeeld bij de webbased versie van Outlook wel gesleept worden in de agenda, maar kan men geen emailberichten slepen van de ene map naar de andere. Een gebruiker moet soms lang wachten tot een pagina opnieuw is geladen bij een kleine aanpassing of actie volgens [PP01]. Dit is tegenwoordig goed op te lossen door gebruik te maken van AJAX-technieken en clustering van de verschillende middleware en back-end servers. Dit zal in de paragraaf resource behaviour uitgebreider worden besproken.

Door gebruik te maken van de nieuwste technieken ondervinden gebruikers steeds minder last van soms wat beperkte interactiemechanismen die er bij webapplicaties zijn of waren. Als de applicatie ontwikkeld wordt volgens de al besproken zaken bij de karakteristiek usability zoals: adaptability, een goede navigatiestructuur, learnability en understandability. De gebruiker zal dan waarschijnlijk ongeveer even efficiënt kunnen werken als bij een GUI applicatie het geval is. Het ligt er maar net aan hoe een applicatie is opgebouwd en welke technieken er zijn gebruikt of een gebruiker efficiënt kan werken of niet.

Pagina 29 van 54


4.3.2 Resource behaviour Er is de laatste jaren veel onderzoek gedaan naar de performance van webbased applicaties en dan voornamelijk die van e-commerce systemen. Aangezien e-commerce systemen qua handelingen en acties (veel contact met databases en businesslogica) lijken op die van webbased applicaties zoals die in deze scriptie worden behandeld, kunnen een aantal conclusies van deze onderzoeken wel gebruiken worden voor dit onderzoek. Zo blijkt o.a. uit [DG05] dat het gebruik maken van webservices met een hoog aantal gebruikers de responstijd van de server aanzienlijk kan laten toenemen. Deze webservices, die de bottleneck kunnen vormen bij webapplicaties, bevinden zich vooral in de middleware, waar alle applicatielogica wordt uitgevoerd. Deze webservices zoals SOAP, werken met XML-berichten die voor veel overhead zorgen, dat bij een groot aantal gebruikers (meer dan 200) veel processorrekenkracht vraagt voor het coderen en decoderen van de XML-berichten. In dit artikel wordt daarom geadviseerd deze middleware servers goed in de gaten te houden en op zoek te gaan naar meer efficiënt werkende XML-parsers en (de)codeermechanismen van b.v. SOAP berichten. Verder wordt er geadviseerd voor veel aanroepen van veel gebruikers naar de database, gebruik te maken van ‘database connection pooling’. Bij de organisatiespecifieke applicaties die in dit onderzoek besproken worden, is dit zeker van belang aangezien organisatie specifieke applicaties veel gegevensverwerkende activiteiten bevatten. Bij de complexe webinfrastructuur kunnen er performance problemen optreden [AC03, DG05]. Het upgraden van alleen een server zal het probleem niet snel oplossen. Vandaar dat er vaak ander soort technieken, zoals clustering worden gebruikt om de performance redelijk te houden voor gedistribueerde websystemen. Een oplossing die wordt voorgesteld in [AC03] is die van meerdere knooppunten (nodes) die zijn opgesteld in meerdere lagen, zie figuur 13.

Figuur 13 – Voorbeeld van een multi-tier architectuur voor een cluster-based websysteem [AC03]

In figuur 13 is een voorbeeld te zien van een geclusterd websysteem met één virtueel IPadres aan de front-end. Het niveau van meerdere indirecte verbindingen en omwegen in een multi-tier webcluster-architectuur geeft wel weer andere interessante performance problemen, door de verschillende routeringen en doorverzendingen. Doordat de

Pagina 30 van 54

Bachelorscriptie Onderwerp: webbased organisatiespecifieke applicaties webswitch (helemaal bovenaan in de figuur) alle eerste aanvragen binnenkrijgt, is het verstandig hier niet te complexe doorstuuralgoritmen te gebruiken. De verschillende soorten algoritmen die in [AC03] aan bod komen zijn: Centralized vs. Distributed en State-blind vs. State-aware. Een aantal dat in deze vier algoritmesoorten vallen die onderzocht zijn binnen het artikel zijn: Round-Robin, Least-Loaded-cpu/conn/disk, WRR, PART, CAP, LARD. Volgens [AC03] zijn de performance problemen van webbased applicaties mede te danken aan de behoefte aan client-authenticatie en systeembeveiliging, de gegroeide complexiteit van de middleware (applicatielogica) en de hoge availability eisen. Er worden dan ook diverse aanbevelingen gegeven en oplossingen genoemd om deze op te lossen zoals: • om de lading over de knooppunten tussen de verschillende servers in evenwicht te brengen, die in de meerdere lagen zijn opgesteld, kan een webcluster het best twee controle knooppunten hebben: één mechanisme om de statische informatie routering te verzorgen, en één mechanisme die in contact is met de back-end servers en routeringen verzorgt voor de dynamische informatie toevoer. • Tussen de meest gebruikte verzendingsalgoritmen in de commerciële clusters van het web, gaf Round-Robin de beste resultaten en was vrij stabiel. Least-Loaded presteerde juist heel slecht, omdat dit routeringalgoritme ervoor zorgt dat de servers vol gaan lopen, doordat alle verzoeken worden verzonden naar dezelfde server totdat nieuwe informatie bekend is. Daarom is het verrassend te noemen dat de Least-Loaded benadering heel veel in commerciële producten voorkomt. Aan de andere kant geven de ‘server state-blind’ algoritmen niet zulke slechte routeringbesluiten, wat vaak wel wordt verwacht door de verschillende auteurs. • De ‘server-state’ algoritmen doen het minder goed dan verwacht. De meest gedetailleerde statusinformatie leidt het meest tot slechte routeringbesluiten, vooral wanneer deze niet heel recent zijn. Het meest belovende algoritme is het algoritme dat alleen een alarm stuurt, wanneer de server een bepaalde drempelwaarde overstegen is, in combinatie met wat ‘client state’ informatie. Server statusinformatie blijft tot nu toe moeilijk en kostbaar om te verkrijgen en geeft minder gewenste resultaten dan gehoopt. Met behulp van clustering kunnen een hoop performance problemen worden opgelost en dan vooral voor de grotere webbased applicaties. Dit blijkt wel uit de artikelen [AC03, DG05] waarin tevens wordt geadviseerd om een goede server- netwerkarchitectuur op te stellen. Het goed overwegen welke routeringalgoritmen er het best gebruikt kunnen worden is tevens aan te raden. Organisatiespecifieke webapplicaties worden door een vrij constant aantal mensen gebruikt (het personeel), waardoor een organisatie eenvoudiger kan schatten hoeveel capaciteit het nodig heeft, dit in tegenstelling tot e-commerce applicaties. De bottleneck van de performance ligt nu vooral bij de middleware servers in vergelijking met de ‘traditionele’ organisatie applicaties doordat de applicatielogica deels verschoven is van de client naar de server kant. Een organisatie kan hierdoor veel lichtere werkstations kopen voor de werknemers. Het netwerkverkeer zal door deze verandering ook toenemen voor webbased applicaties maar dit is tegenwoordig niet meer de bottleneck, aangezien de meeste organisatie minstens over 100 Mbit netwerken beschikken in samenwerking met nog snellere backbone verbindingen. Dit netwerkverkeer en de belasting van de servers kan verder worden verminderd door bijvoorbeeld de techniek van AJAX (Asynchronous Javascript and XML) te gebruiken. In [PL05] staat dat AJAX applicaties een betere performance hebben dan webbased applicaties die oudere technieken gebruiken. Deze betere performance is vooral te danken aan de techniek, dat voor een kleine actie waarin (nieuwe) data wordt verwerkt niet de hele pagina opnieuw hoeft te worden herladen, zoals bij oude webbased applicaties wel het geval was. Deze techniek bestond voor een deel al wat jaren zonder dat het aan de naam AJAX was gekoppeld. Eerst werd het alleen voor kleine onderdelen gebruikt in webbased applicaties zoals menu’s, maar op het moment van schrijven zijn er

Pagina 31 van 54

Bachelorscriptie Onderwerp: webbased organisatiespecifieke applicaties al verscheidene complete webbased applicaties mee ontwikkeld zoals google’s GMAIL. AJAX bestaat uit de volgende onderdelen die gezamenlijk de techniek realiseren zoals iedereen gewend was bij ‘traditionele’ desktopapplicaties: • dynamic HTML (DHTML); dit zijn dynamische webpagina’s doordat ze zijn opgebouwd uit Javascript en CSS. Als er bijvoorbeeld met de muis wordt bewogen over een link, is de pagina in staat om deze link een andere kleur te geven of de tekst groter weer te geven. • XML; wordt door AJAX gebruikt om data te coderen en te transporteren tussen de server en de webbrowser van de client. Het is een W3C standaard voor een markup meta-taal dat gebruikt kan worden om data gestructureerd om te zetten in online documenten. • Cascading Stylesheets (CSS); dit is ook een W3C standaard die website ontwikkelaars en gebruikers meer controle geven over hoe de webbrowsers de pagina’s weergeven. In de stylesheet wordt gedefinieerd hoe bepaalde elementen er uit moeten zien op de pagina. • Document object Model (DOM); dit is een W3C standaard voor een programmainterface dat ontwikkelaars in staat stelt om HTML en XML documenten te maken en te veranderen als een set van programmaobjecten wat het ontwerpen vereenvoudigt. • Javascript; dit script, ontwikkeld door Netscape en Sun, heeft ervoor gezorgd dat HTML-pagina’s dynamischer werden. AJAX gebruikt asynchrone Javascript wat een HTML-pagina in staat stelt om een asynchrone aanvraag naar de server te sturen voor een XML-document. • XMLHttpRequest; dit zijn Javascript gebaseerde objecten die HTTP aanvragen doen en snel een antwoord op de achtergrond terug ontvangen zonder dat de gebruiker het merkt.

Figuur 14 – Verschil in aanvragen naar webserver tussen traditioneel en AJAX applicatie [PL05]

Hierboven in figuur 14 is het verschil te zien van aanvragen van één oude webbased applicatie met de server en één die gebruik maakt van de XMLHttpRequest objecten. In het artikel is te lezen dat deze techniek voor een vermindering zal zorgen van netwerk en server belasting voor webbased applicaties doordat de dataverzendingen een stuk kleiner zijn.

Pagina 32 van 54


4.3.3 Efficiency compliance Om een goede kwaliteit te verkrijgen voor efficiency compliance zal de ontwikkelaar de al bekende standaarden moeten gebruiken om de performance te meten van de applicatie. Voor websites zijn hiervoor veel verschillende modellen te vinden in de literatuur om de scalability en performance te meten. Maar om het goed te vergelijken met normale organisatiespecifieke applicaties zullen er algemenere modellen gebruikt moeten worden om bijvoorbeeld de CPU en netwerkbandbreedte te meten.

Pagina 33 van 54


4.4 Portability Portability is heel belangrijk voor organisaties en lang niet altijd een technisch probleem maar vooral een economisch probleem zo stelt David Rowley [RD96], aangezien er een hoop geld verdiend kan worden als je het maar één keer hoeft te ontwikkelen en dan in elke omgeving kan gebruiken. Bij aanpassingen aan de applicatie hoeft dan nog maar één versie worden aangepast in plaats van de verschillende versies voor elke omgeving. De applicatie moet wel voor elke omgeving getest worden en hier moeten misschien wel aparte testtechnieken voor worden ontwikkeld. Men weet dan tenminste zeker of de applicatie zich ook daadwerkelijk in elke omgeving hetzelfde gedraagt.

4.4.1 Adaptability Adaptability wordt altijd als één van de kerncompetenties genoemd van webbased applicaties. Dit komt doordat binnen het web er veel standaarden zijn die bij de meeste omgevingen zijn geïmplementeerd. Van Java en andere webbased technieken zegt men dan ook gauw, “write once, run everywhere”. Dit geldt vaak nog wel, alleen gaat dit soms minder eenvoudig dan door sommige auteurs in de literatuur wordt aangenomen. Niet alle en dan vooral de nieuwste webbased technieken worden in alle omgevingen ondersteund. Hieronder zullen we een aantal technieken of programma’s die nodig zijn of gebruikt worden behandelen. TCP-IP Het protocol dat wordt gebruikt bij webbased applicaties is TCP-IP. Dit protocol heeft zijn veel gebruikte positie aan het web te danken. In de meest gebruikte en bekendste besturingssystemen van tegenwoordig is dit protocol geïmplementeerd. TCP/IP is een pakketgeschakeld protocol en bevindt zich op de netwerken transportlaag. Internet toepassingslaagprotocollen [W3C] Bovenop het TCP-IP protocol zijn er voor webbased applicaties nog diverse presentatielaag protocollen namelijk: HTTP, HTTPS, SMTP, POP3, IMAP, FTP, SSL en SSH. Al deze protocollen zijn net als TCP-IP geïmplementeerd in de meeste besturingssystemen, doordat ze bij de internetstandaarden horen. HTTP is hiervan de bekendste en wordt vooral gebruikt voor het versturen van HTML en XML documenten tussen webbrowser en webserver. HTML / XML / CSS [W3C] HTML is de opmaaktaal van webpagina’s, waarvoor een webbrowser nodig is om deze te laten zien. Dit is het interfacescherm van de webapplicaties, waaruit alle data en opmaakelementen worden weergegeven via de webbrowser. Er zijn al veel uitbreidingen geweest voor deze taal en elke webbrowser ondersteunt in elk geval de eerste versie. De laatste versie hiervan is HTML 4.01 die door de huidige webbrowsers wordt ondersteund. Er worden nu geen uitbreidingen meer gedaan voor HTML, omdat het W3C nu XHTML als opvolger heeft aangewezen. Deze taal bevindt zich in versie 2.0 en is een combinatie van de talen XML voor data en CSS voor de opmaakcodes. De taal is strikter dan zijn voorganger en wordt ook door de nieuwere versies van de huidige webbrowsers ondersteund. XML is de internetstandaard om data in op te slaan en te versturen. De meeste besturingssystemen hebben hun eigen webbrowsers en parsers om met XML om te kunnen gaan, omdat het een algemeen geaccepteerde internetstandaard is.

Pagina 34 van 54

Bachelorscriptie Onderwerp: webbased organisatiespecifieke applicaties CSS is de opmaaktaal voor internetpagina’s. Vroeger in de oude versies van HTML vond de opmaak vooral bij de elementen zelf plaats. Met een CSS stylesheet kun je in een apart bestand, of in het bestand zelf van te voren aangeven welke opmaak een bepaald element moet hebben. Deze stylesheets kunnen dan voor meerdere pagina’s worden hergebruikt. Doordat het bij de XHTML standaard hoort is ook deze taal bij elke nieuwe webbrowser geïmplementeerd. Invoegtoepassingen Er zijn een aantal invoegtoepassingen op het web beschikbaar die vooral zijn ontwikkeld om het statische HTML document interactiever te maken. Deze invoegtoepassingen zitten vaak binnen een HTML-document en worden niet altijd door elke webbrowser ondersteund. ActiveX is een invoegtoepassing van Microsoft en wordt bijna alleen ondersteund in de nieuwere Microsoft omgevingen. Het stelt een ontwikkelaar in staat om een component te ontwikkelen in bijvoorbeeld C++ en deze binnen een webpagina te zetten, doordat het behoort tot de Microsoft COM familie. Het is zelfs in staat om op de harde schijf van een client bestanden te lezen en aan te passen, wat vaak als onveilig wordt gezien. Hierdoor wordt het meestal niet door andere besturingssystemen en webbrowsers ondersteund. Flash is een invoegtoepassing van Macromedia (Adobe) en nestelt zich tevens binnen een HTML-document. Het maakt gebruik van de zogenaamde vector- en rastertechniek waardoor er hoge grafisch oplossingen mee ontwikkeld kunnen worden. Het is niet een algemeen geaccepteerde internetstandaard en zit meestal niet standaard in een webbrowser en besturingssysteem geïmplementeerd. Javascript is een scriptingtaal ontwikkeld door Netscape en Sun en wordt door bijna alle webbrowsers en besturingssystemen ondersteund. Een ontwikkelaar kan met deze taal meer interactie invoeren voor de HTML-elementen. Tevens kan hij hiermee diverse gegevens verzamelen van de clientsituatie (besturingssysteem, resolutie) of berekeningen uitvoeren. AJAX is geen acroniem van één invoegtechniek, maar meerdere technieken bij elkaar. Deze techniek is al besproken in paragraaf 4.3.2. De meeste technieken en talen van AJAX zoals DOM, XML en CSS werden al door de oudere webbrowsers ondersteund. Maar de XMLHttpRequest objecten die de kern van het succes van AJAX zijn, worden alleen door de nieuwste grote webbrowsers standaard geïmplementeerd zoals: IE, Firefox, Netscape en Apple’s Safari. Als een webbased applicatie wordt ontwikkeld met deze techniek zal de ontwikkelaar hier wel rekening mee moeten houden. Java Applets is ontwikkeld door Sun en stelt de ontwikkelaar in staat om een Java programma te integreren binnen een HTML-document. Java moet voor deze applets gebruik maken van de Java Virtual machine (JVM), ook van Sun. Deze JVM is voor elk platform bijna wel te verkrijgen en soms standaard geïmplementeerd. Bij enkele besturingssystemen van Microsoft is de JVM er uit gehaald en moet de gebruiker deze zelf installeren, wat de portability voor deze taal er niet beter opmaakt. Nog een ander probleem is dat er verschillende versies in gebruik zijn van JVM. Het kan daardoor ook nog voorkomen dat de nieuwste ontwikkelde applets niet werken bij een client omdat deze over een verouderde JVM beschikt. Webbrowsers Er zijn diverse webbrowsers beschikbaar waarmee een webbased applicatie uitgevoerd kan worden. De meest gebruikte en populairste webbrowsers van dit moment van schrijven zijn: Microsoft Internet Explorer, Mozilla Firefox, Mozilla, Safari, Camino, Opera en Konqueror. Voor elk besturingssysteem wat op dit moment door client computers wordt gebruikt is er minstens één beschikbaar. Elke webbrowser ondersteunt in ieder geval de drie belangrijkste technieken namelijk: TCP-IP, HTML en HTTP. Voor een webbased applicatie zijn de instellingen van de webbrowser en client meestal ook van belang of die wel goed werken. Zo kan de schermresolutie verschillen, kan de lettergrote

Pagina 35 van 54

Bachelorscriptie Onderwerp: webbased organisatiespecifieke applicaties binnen de webbrowser aangepast zijn en is er bijvoorbeeld bij de webbrowser Safari standaard de rechtermuisknopfunctionaliteit beveiligd. De boven besproken onderwerpen gelden vooral voor de client kant van de applicatie. Aangezien een goede kwaliteit op adaptability vooral voor de client kant van belang is, omdat de ontwikkelaars aan de server kant de servers zelf vaak kunnen inrichten zoals ze dit nodig achten en dit bij de client meestal lastiger zal gaan. De portability problemen die voor de server kant van belang zijn, worden hieronder besproken bij co-existence en replaceability.

4.4.2 Installability In de meeste situaties van webbased applicaties hoeft de eindgebruiker bijna niks te installeren van de applicatie, zoals vaak wel het geval was met de ‘traditionele’ desktopapplicaties. Dit wordt als een groot voordeel beschouwd volgens verschillende literatuur [PR00, PP01, VP05, SB04 e.a.]. Dit komt vooral doordat er met de thin- of small client architectuur wordt gewerkt en de applicatielogica zich op de servers bevindt. De gebruiker krijgt vaak alleen de user-interfaces toegestuurd die hij kan bekijken via de al aanwezige webbrowser. Als er iets moet veranderen binnen de applicatie, of als er een uitbreiding moet komen, dan kan die plaats vinden zonder dat de gebruikers hier last van hebben, of zelf iets nieuws moeten installeren. De ontwikkelaars hoeven al deze wijzigingen alleen op de server uit te voeren, zodat de eindgebruikers hier weinig last van ondervinden, behalve dat de server enige tijd misschien niet te bereiken is. Toch kan het zo zijn dat er bij bepaalde webbased applicaties er toch nog wel software geïnstalleerd moet worden. Bij de bespreking hierboven van bepaalde technieken bleek namelijk al dat niet alle technieken altijd standaard werken bij de eindgebruiker. Zo moeten de eindgebruikers, als er gebruikt gemaakt wordt van AJAX, over één van de nieuwste webbrowsers beschikken. Als de webbased applicatie gebruik maakt van Java, is het meestal nodig dat de Java Virtuel Machine moet worden vernieuwd. Het kan zo zijn dat er kleine instellingen gedaan moeten worden bij de webbrowsers of het besturingssysteem van de eindgebruiker.

4.4.3 Co-existence Aan de client kant zullen we weinig problemen tegenkomen en zal de applicatie zonder veel problemen naast al bestaande applicaties uitgevoerd kunnen worden. Dit komt doordat aan deze kant haast geen software wordt geïnstalleerd. Aan de server kant echter, waar de applicatielogica en de aan te passen data zich bevinden, is het wel van belang om dit te onderzoeken. Voor de applicatieservers en datawarehouse-servers waar de webbased applicaties op geïnstalleerd worden en mee zullen moeten samenwerken, zijn er al verschillende technieken beschikbaar om dit te vereenvoudigen zoals de diverse webservices en CORBA. CORBA is een veel gebruikte techniek voor de middlewareservers [SB04, GK02] om verschillende applicaties met elkaar te laten samenwerken. Deze techniek kan met de meeste programmeertalen, besturingssystemen en netwerkprotocollen samenwerken. Webservice technieken als SOAP laten applicaties met elkaar communiceren met XMLberichten. Webservices worden dan ook als volgt gedefinieerd [TG02]: “any service that is available over the internet, uses a standardized XML messaging system, and is not tied to any one operating system”. Een middleware techniek als SOAP is opgenomen tot de internet-

standaarden die worden beheerd en gecontroleerd door het W3C, waardoor de coexistence van webbased applicaties die hier gebruik van maken verbetert. Webservices zoals SOAP, UDDI en WSDL verschillen met een techniek als CORBA doordat ze zich vooral richten op het communiceren tussen applicaties, terwijl CORBA een volledig object georiënteerde architectuur biedt met services als: events, naming en trading. In Bijlage II staan de verschillen weergegeven die in [GK02] worden uitgezet tussen webservices en CORBA. Hierin wordt tevens de volgende observatie gedaan:

Pagina 36 van 54

Bachelorscriptie Onderwerp: webbased organisatiespecifieke applicaties “Wat kan worden ontwikkeld met CORBA kan ook worden ontwikkeld met webservices en visa versa. Alleen de hoeveelheid tijd om het te ontwikkelen kan erg verschillen en in de praktijk kan men CORBA bovenop bijvoorbeeld SOAP gebruiken en andersom.” De grote database leveranciers als Oracle en IBM [SS03] bieden al veel services voor co-

existence voor de webbased applicaties zoals het ondersteunen van de taal XML. Dit biedt voordelen voor de webbased applicaties om met deze al vaak bestaande databases samen te kunnen werken en de gegevens hoeven dan niet in een weer aparte andere database geplaatst te worden. Uit de verschillende onderzochte literatuur blijkt dat webbased applicaties heel goed in staat zijn om naast en met andere applicaties te werken en bestaan. Middleware technieken en webservices samen met de database pakketten zijn hier namelijk al een tijd prima toe in staat en op aangepast.

4.4.4 Replaceability Uit meerdere praktijksituaties blijkt dat een webbased applicatie in staat is om een bestaande applicatie te vervangen in dezelfde bestaande omgeving. Dit blijkt uit o.a [SS03]. Volgens het artikel is de businesslogica het meest lastige gedeelte om te vervangen. In veel praktijkgevallen zijn er bij de vervanging van een terminalsysteem alleen de userinterfaces omgezet naar een webbased uiterlijk. Belangrijk voor de businesslogica is dan dat er zo weinig mogelijk verandert aan de interface. Maar deze techniek, ook wel ‘screen scratching’ genoemd, frustreerde de eindgebruikers alleen maar en haalt niet de daadwerkelijke voordelen uit de webbased technieken. Het artikel [SS03] zegt over dit probleem bij het omzetten van legacy software naar webbased technieken dan ook het volgende: “…it can be said, that while industry has picked up the easy topics of presentation and database access, the research community is striving to resolve the really difficult problem of reengineering existing legacy software for reuse as web servers, i.e. web services. The need for this research work cannot be denied since it involves the salvaging of industrial assets worth more than 3 billion dollars worldwide.” Voor andere (nieuwere) soorten

softwaresystemen geldt dit probleem in mindere mate, aangezien deze eenvoudiger zijn om te vervangen, door bijvoorbeeld gebruik te maken van de hier boven besproken middleware technieken die ze vaak al wel ondersteunen. Er zijn diverse onderzoeken beschikbaar, zoals [SS03], die laten zien dat een webbased applicatie in staat kan zijn om een oud COBOL systeem te vervangen. XML wordt in heel veel gevallen als communicatie en opslagtaal voor data gebruikt. In figuur 15 hieronder is het werkproces te zien van de vervanging van een oud systeem en in figuur 16 is een architectuur van het eindresultaat weergegeven.

Figuur 15 – Werkproces vervanging legacy systems naar een webbased variant [SS03]

Figuur 16 – Webapplicatie als eindresultaat ontstaan uit legacy systeem [SS03]

Pagina 37 van 54


4.4.5 Portability compliance Doordat de meeste internetstandaarden centraal worden beheerd en bewaakt door het W3C, zijn ze heel goed bruikbaar en algemeen geaccepteerd voor organisatiespecifieke applicaties. Niet alle internettechnieken behoren hierbij die gebruikt kunnen worden voor de webbased applicaties, voor deze technieken is dan vaak extra oplettendheid nodig om ze goed te implementeren. Volgens [RD96] zijn portability standaarden in twee soorten op te delen namelijk: • de facto, bepaald door het marktgebied, voorbeelden hiervan: TCP-IP, Java en ASP. • De jure, bepaald door bemiddelingsinstellingen, voorbeeld: TCP-IP, HTTP, HTML, SOAP en XML. TCP-IP valt hier in beide soorten. Dit komt doordat eerst een bepaald marktgebied (o.a. ARPANET) dit alleen als standaard gebruikte maar het is door de populariteit snel als standaard opgenomen door diverse bemiddelingsinstellingen. Beide soorten van standaarden worden meestal wel door de webbrowser leveranciers geïmplementeerd om zo aan de marktvraag te voldoen voor het nog steeds snel veranderende en vernieuwende terrein van webbased applicaties. Een webbased applicatie zal hierdoor hoog scoren op de kwaliteit van portability compliance.

4.5 Conclusies literatuurstudie In deze conclusie zullen we per besproken karakteristiek van dit hoofdstuk een conclusie proberen te vormen, van wat in de literatuur is gevonden over de aspecten in de kwaliteitskarakteristiek. In deze paragraaf wordt er een conclusie gevormd vanuit de literatuur op elk onderdeel van de derde deelvraag van dit onderzoek. Functionality Voor interoperability zijn er weinig nadelen maar vooral voordelen te vinden voor webbased applicaties. Vooral als er gebruik wordt gemaakt van een thin-client architectuur model waarbij een middleware server wordt ingezet, wordt de kwaliteit voor interoperability hoger. Er zijn namelijk diverse goede technieken beschikbaar voor webbased applicaties om dit te realiseren waardoor het goed met andere soorten applicaties kan samenwerken en communiceren. Webbased applicaties zullen voor dit aspect door de technieken sneller hoger scoren voor kwaliteit dan andere soorten. De kwaliteit van het aspect security is voor webbased applicaties lastiger te realiseren dan een aantal andere soorten applicaties. Dit komt door het meer open karakter van de technieken die bij webbased applicaties worden gebruikt. Een factor die dit nog eens extra beïnvloedt is dat als bedrijven een webbased applicatie maken, deze applicatie ook voor buiten het bedrijf benaderbaar willen maken. Ze koppelen de applicatie aan extranetten voor hun klanten en soms ook aan het openbare internet wat de applicatie weer extra kwetsbaar maakt. Daarnaast ontbreken er nog goede modellen voor beveiligings- en toegangscontrole voor webbased applicaties. Er wordt op het moment veel onderzoek gedaan naar de beveiliging van webapplicaties zoals de speciale firewall en de aangepaste beveiligingsmodellen. Deze onderzoeken geven hoop voor de toekomst. Voor functionality compliance zal een webbased applicatie meestal een betere kwaliteit scoren dan applicaties met andere technieken doordat het door de webbrowser en de webbased technieken wordt gedwongen aan een aantal standaarden te voldoen.

Pagina 38 van 54

Bachelorscriptie Onderwerp: webbased organisatiespecifieke applicaties Usability Bij understandability kwam naar voren dat er veel aandacht moet worden besteed aan een aantal zaken zoals de status van de applicatie en dat de applicatie zich bevindt in een webbrowser. Vooral het laatste kan een hoop verwarring geven bij de gebruiker. De ontwikkelaar kan met veel van de genoemde punten in de paragraaf wel rekening houden zodat een gebruiker hier geen last meer van hoeft te ondervinden. Om alle besproken zaken in hoofdstuk 4.2 goed te ontwikkelen, zal meer tijd kosten dan bijvoorbeeld bij een GUI applicatie het geval was geweest. Het te leren begrijpen van een webbased applicatie kan worden vereenvoudigd door gebruik te maken van adaptability. Doordat de applicatielogica zich voornamelijk bij een webbased applicatie op de server bevindt, is het lastiger om de instellingen op te slaan voor elke gebruiker. Het echt dynamisch adaptable maken van een applicatie is voor een webbased applicatie even lastig als bij een andere soort applicatie. Wel zal er aan de gebruikers duidelijk moet worden gemaakt dat de applicatie zich in een webbrowser bevindt. Deze omgeving kan namelijk anders reageren dan hij normaal van een applicatie gewend is. De kwaliteit van de operability kan omlaag gaan door het “lost in hyperspace syndrome”. Het is bij een webbased applicatie minder vanzelfsprekend hoe er door de applicatie wordt genavigeerd. Dit kan komen doordat de structuur minder goed inzichtelijk is voor de gebruiker. Er zijn in paragraaf 4.2 diverse voorstellen gedaan, waarmee de ontwikkelaar dit voor een groot deel kan oplossen. Voor webbased applicaties zijn er genoeg technieken beschikbaar om de applicatie aantrekkelijk te maken voor een gebruiker. Sommige punten vereenvoudigen dit voor de ontwikkelaar van webbased applicaties zoals stylesheets. Andere punten maken dit juist weer lastiger zoals de verschillende schermresoluties. Bij usability compliance kan een webbased applicatie hoger scoren voor kwaliteit dan soortgelijke applicaties. Dit komt doordat hier veel informatie over beschikbaar is bijvoorbeeld accessibility. Dit is met HTML relatief eenvoudig te implementeren. Voor de vijf aspecten van usability geldt dat de ontwikkelaar meer aandacht en ontwikkeltijd nodig is om bepaalde functionaliteiten in de applicatie te verwerken. Daarnaast zal aan de gebruiker enkele zaken moeten worden duidelijk gemaakt bijvoorbeeld de verschillen met een GUI applicatie. Als dit beide goed gebeurt dan hoeft de kwaliteit van usability bij een webbased applicatie niet minder te zijn dan van een soortgelijke applicatie. Efficiency De tijd dat een gebruiker nodig heeft om acties te verrichten binnen een webbased applicatie hoeft niet veel hoger te zijn dan dat van een andere soort applicatie. Zoals al besproken bij usability geldt het ook hier weer dat dit ligt aan hoe de applicatie ontwikkeld is. Vooral als er gebruik wordt gemaakt van de nieuwste webbased technieken zal de kwaliteit van time behaviour gelijkwaardig zijn aan die van een andere soort applicatie. Een ander aspect dat hier invloed op heeft is hoe snel de applicatie reageert op handelingen van de gebruiker. De belasting van de resources van de servers en client zelf spelen hierbij de grootste rol. Deze belasting is bij webbased applicaties vooral bij de servers sterk toegenomen. Doordat de applicatielogica van de client naar de server is gebracht, ligt er een grote druk op deze servers. Voor een groot aantal gebruikers bij een webbased applicatie moet daarom voor deze servers een goed doordachte architectuur opgesteld worden. Als dit niet gebeurt, zal de applicatie aan de client kant dermate traag zijn dat er op het kwaliteitsaspect van time behaviour een stuk slechter gescoord wordt. Bij de client kant is de belasting een stuk lager geworden dan bij andere soortgelijke applicaties. Hier kan een organisatie dan op bezuinigen. Het vergt een hoge investering in tijd en geld om een goede server-architectuur op te bouwen voor een grote webbased applicatie. Doordat er veel grote e-commerce applicaties bestaan op het internet zijn hier al veel goed werkende technieken voor bekend die gebruikt kunnen worden. Als laatste moet er gezegd worden dat een nieuwe techniek als AJAX de netwerk en server belasting weer wat kan verlagen voor een webbased applicatie.

Pagina 39 van 54

Bachelorscriptie Onderwerp: webbased organisatiespecifieke applicaties Portability Door de breed geaccepteerde standaarden van de technieken die een webbased applicatie gebruikt, scoren deze applicaties hoog op het aspect adaptability. Wel zal de ontwikkelaar dan vooral de technieken moeten gebruiken die dan ook echt in de meeste besturingssystemen en webbrowsers geïmplementeerd zijn. De grote voordelen die de nieuwe webbased technieken opleveren voor andere kwaliteitsaspecten is bij dit aspect juist weer het nadeel te vinden dat de techniek nog vaak niet een geaccepteerde standaard kan zijn. Toch hoeft dit nadeel niet een probleem te zijn doordat de nieuwe webbased techniek vaak wel eenvoudig geïmplementeerd kan worden bij de computer van de client. Een groot voordeel van webbased applicaties is dat er aan de client kant niks van de applicatie hoeft te worden geïnstalleerd. De gebruiker kan vaak al werken door alleen de webbrowser te starten. Veranderingen aan de applicatie kunnen aan de server kant worden doorgevoerd zonder dat de gebruiker dit hoeft merken. Voor het aspect installability zal een webbased applicatie dan ook hoog scoren. Er zijn al een langere tijd diverse technieken beschikbaar voor webbased applicaties om naast andere soorten applicaties te werken als we naar de server kant kijken. Middleware technieken als CORBA en webservices als SOAP zijn heel breed geaccepteerd en kunnen goed gebruikt worden. Ook databaseleveranciers hebben hun pakketten bijna allemaal aangepast zodat webbased applicaties hier goed mee kunnen samenwerken. Ze ondersteunen bijvoorbeeld allemaal XML in hun pakket. Aan de client kant zullen webbased applicaties al helemaal geen problemen opleveren doordat de webbrowser op elk modern besturingssysteem geïnstalleerd is. Uit diverse onderzoeken is gebleken dat webbased applicaties wel in staat zijn om een andere applicatie te vervangen. Dit is echter voor oudere legacy systemen een stuk lastiger uit te voeren dan voor modernere applicaties. Vooral het omzetten van de businesslogica van een legacy systeem naar een webbased systeem zal lastig zijn. Dit kan alleen even goed gelden voor andere niet webbased technieken die voor het ontwikkelen van een vervangende applicatie worden gebruikt dus dit hoeft geen nadeel te zijn. Als laatste aspect is besproken hoe goed een webbased applicatie kan voldoen aan standaarden. Bij het ontwikkelen van een webbased applicatie zal vooral gebruik worden gemaakt van technieken die door het W3C zijn vastgelegd of andere breed geaccepteerde de facto technieken. Een webbased applicatie heeft hierdoor een hoge kwaliteit op portability compliance.

Pagina 40 van 54


5

In de praktijk

Om de onderzochte literatuur en conclusies te kunnen toetsen met de praktijk zijn er voor dit onderzoek twee vragenlijsten naar bedrijven gestuurd met een aantal vragen over de onderwerpen die hierboven besproken zijn. De organisatie Checkit werkt al ongeveer vanaf het ontstaan van het bedrijf met zelf ontwikkelde webbased applicaties zoals een workflow management systeem en een tool management systeem. Checkit is een onafhankelijk search engine media bureau met meer dan dertig werknemers in dienst. Het andere bedrijf dat een vragenlijst heeft ingevuld is Plus Retail. Dit bedrijf is op dit moment een project gestart om bestaande applicaties te vervangen met een webbased varriant. Deze applicaties gaan onder andere door de verschillende supermarkten in het land gebruikt worden. Plus Retail BV is een serviceorganisatie dat service (waaronder ICT) verleent aan de meer dan 215 Plus supermarkten en de kantoren en distributiecentra van Sperwer Holding.

5.1 Vragenlijst De hierboven besproken bedrijven hebben voor dit onderzoek digitaal een vragenlijst opgestuurd gekregen en weer teruggestuurd. Deze vragenlijst is zo opgesteld dat bij de meeste vragen er zowel een invulruimte is om een cijfer te geven en een invulruimte om een opmerking te plaatsen. De geënquêteerde kon bij de meeste vragen met een cijfer aangeven hoe slecht of goed hij een bepaald kwaliteitsaspect vond voor een webbased applicatie in vergelijking met een soortgelijke traditionele applicatie. Hieronder zullen de vragen volgen met daaronder in de meeste gevallen het ingevulde cijfer en de opmerking die de geënquêteerde had gegeven. •

Kunt u vertellen wat de hoofdredenen binnen uw organisatie geweest zijn om een webbased applicatie te (ontwikkelen / aan te passen) in plaats van wat traditionelere soorten applicaties? Plus: Omdat de gebruikers (ongeveer 215 winkels) geografisch verspreid over het land zitten. Een centrale web applicatie hoeft dan maar op een plek onderhouden te worden, in plaats van op meerdere plekken. Checkit: Eenvoud van deployment en beveiligingsmodel - Hergebruik van componenten in klant portaal - Performance

•

In een artikel van de universiteit van California wordt geconcludeerd dat web programmeren in het algemeen lastiger is dan traditioneel programmeren. Dit komt volgens de auteurs doordat de programmeur veel meer verschillende technieken moet kennen en deze technieken sneller afwisselen. Hoe ervaart u dit in de praktijk? Cijfer (lastig :1 …..10: eenvoudig): Plus: 4, Checkit:6 Plus: Dat klopt, daarnaast speelt mee dat problemen die optreden in de software veel moeilijker te traceren zijn. Checkit: Ben het eens met de stelling, maar ik denk dat de moeilijkheidsgraad van programmeren in een legacy applicatie zit hem vooral in de kwaliteit van een onderliggend framework en ontwerp. Indien de basis goed is uitgedacht en de programmeur bijv. niet voor elk onderhoudsscherm het wiel opnieuw hoeft uit te vinden is er geen verschil tussen web of traditioneel programmeren. De extra technieken die gehanteerd moeten worden maken het wel lastiger, maar dit speelt slechts een kleine rol in vergelijking met een goede of slechte basis.

Pagina 41 van 54


Denkt u dat de interoperability wordt bij webbased applicaties

(eenvoudig kunnen communiceren met andere applicaties)

beter

Cijfer (niet beter :1 …..10: veel beter): Checkit: 6 Checkit: Dit is ook weer afhankelijk van de structuur van de applicaties: een webbased applicatie kan heel goed zo ingericht worden dat het onmogelijk is om te communiceren met andere applicaties. Wel is het zo dat de moderne ontwikkel-omgevingen en methodieken het in zich hebben om een goede structuur neer te leggen

•

In de literatuur wordt over het algemeen geconcludeerd dat er dat er nog geen goede security modellen zijn voor webbased applicaties, in vergelijking met 'traditionele' applicaties. Wat vindt u van de veiligheid binnen webbased applicaties? Deelt u deze mening vanuit uw praktijkervaring? Cijfer (veel slechter :1 …..10: veel beter): Plus:4, Checkit:6 Plus: De beveiliging is deels hetzelfde als de traditionele applicaties maar gaat daarin verder omdat webbased applicaties veel toegankelijker zijn en dus ook beter afgeschermd dienen te worden. Checkit: Ik zie geen verschil, ook hier gaat het weer om de inrichting van de applicatie. Wel is het zo dat informatie die over het internet gaat extra aandacht nodig heeft m.b.t. beveiliging.

•

Denkt u dat de vele openbare multiplatform standaarden (van het W3C: HTML HTTP enz..) die bij webbased applicaties komen kijken voordelen opleveren? (b.v. meer kant en klare componenten, eenvoudiger communiceren met andere applicaties en meer professionele kennis). Cijfer (veel slechter :1 …..10: veel beter): Plus:7, Checkit:8 Plus: Het ontwikkelen van standaarden helpt altijd. Ik denk dat dit met deze technologie nog veel belangrijker is dan met de traditionele programmeertalen.

•

Uit onderzoek kwam naar voren dat de statusveranderingen van een webbased applicatie lastiger zichtbaar zijn voor een gebruiker als die een actie uitvoert, ervaart u dit ook zo? (denk b.v. aan de verwarring van een gebruiker met de back en forward knoppen voor respectievelijk undo en redo) Of denkt u dat dit net zo goed realiseerbaar en zichtbaar is te maken dan bij een andere applicatie (met b.v. Java of AJAX)? Cijfer (status onoverzichtelijk :1 …..10: status overzichtelijk): Plus:3, Checkit:4 Plus: Ik denk dat de zichtbaarheid van statusveranderingen inderdaad afneemt afhankelijk van de opzet en kwaliteit van de programmatuur. Dit risico is in ieder geval een stuk groter geworden. Checkit: De status verandering bijhouden maakt een webapplicatie lastiger dan een traditionele is ook onze ervaring. Dit kan inderdaad wel gerealiseerd worden, maar kost extra ontwikkeltijd.

•

In Artikelen wordt veel gesproken over adaptability (aanpasbaarheid) voor de gebruiker. Beginnende werknemers krijgen een wat simpeler scherm en een gevorderde werknemer krijgt meer functies en shortcuts te zien in het interface van de webapplicatie. Denkt u dat dit wat toevoegt aan het snel leren van een applicatie (learnability)? Denkt u verder of dit eenvoudiger is te implementeren in de praktijk voor webbased applicaties? Cijfer (draagt niet bij :1 …..10: draagt veel bij): Plus:3, Checkit:8

Plus: Ik geloof daar zelf niet in. Een gebruiker die regelmatig met een systeem werkt zal zich dit over het algemene redelijk snel eigen kunnen maken en wil dan ook al snel de volledige functionaliteit tot zijn beschikking hebben. Het nut van “eenvoudige” applicaties is volgens mij niet erg groot. Checkit: Draagt zeker bij aan learnability; is net zo eenvoudig te implementeren voor webbased als traditionele applicaties.

Pagina 42 van 54


Het blijkt dat een gebruiker bij webbased applicaties eerder het gevoel krijgt dat hij niet precies weet waar hij zich in de applicatie bevindt (het “lost in hyperspace syndrome” genoemd). Een goede navigatie en infrastructuur zijn dan voor webbased applicaties ook belangrijker dan bij de ‘traditionele’ applicaties. Deelt u deze mening? Houdt u hier ook rekening mee? (met b.v. : mini sitemap altijd in beeld, duidelijke url’s en status binnen een actiereeks zichtbaar)

Cijfer (draagt niet bij :1 …..10: draagt veel bij): Plus:7, Checkit: 8 Plus: Ja ik deel deze mening. Wij maken hiervoor gebruik van een kruimelpad en zorgen ervoor dat de schermen in omgekeerde volgorde van het openen ook weer gesloten moeten worden. Checkit: Ja, dit is zeker een probleem. Wij houden hier rekening mee, maar dit zou nog duidelijker kunnen

•

Denkt u dat webbased applicaties beter in staat zijn om beter aantrekkelijk te worden gevonden door de gebruikers (door b.v. gebruik te maken van consistente opmaakstylesheets)? Cijfer (niet aantrekkelijker :1 …..10: veel aantrekkelijker): Plus:4, Checkit:7 Plus: Dit is vaak alleen visueel aantrekkelijker, niet functioneel. Checkit: Goede consistente vormgeving is voor zowel traditionele als webbased applicaties noodzakelijk om aantrekkelijkheid en gebruikersvriendelijkheid te waarborgen.

•

Zullen medewerkers effectiever kunnen werken binnen webbased applicaties of juist minder? (doordat b.v. er minder soorten handige GUI functies beschikbaar zijn zoals slepen en undo-redo, of dat ze geneigd zijn andere internetpagina’s te bekijken) Cijfer (minder effectief :1 …..10: effectiever): Plus:5 Checkit: 6 Plus: Ik denk dat de effectiviteit niet afhangt van de gekozen ontwikkelmethode maar meer van de kwaliteit van het opzetten en programmeren van de applicatie. Checkit: De meeste GUI functionaliteit is ook te realiseren in een webbased applicatie, echter is nog niet alles standaard voor handen.

•

Hoe denkt u dat de resources (netwerkbelasting, processorkracht, geheugen) zwaarder worden belast bij een webbased applicatie dan bij een zelfde soort applicatie die niet webbased is, kijkend naar zowel server als client? Cijfer (zwaarder voor client :1 …..10: minder resources client): Plus: 8, Checkit: 9 Cijfer (zwaarder voor server:1 …..10: minder resources server): Plus:2, Checkit: 2 Plus:De client zal een stuk minder belast worden (ook afhankelijk van in hoeverre er bijvoorbeeld van Java applets gebruikt wordt gemaakt binnen de applicatie). De diverse servers die nodig zijn worden wel zwaarder belast.

•

Het grote voordeel van webapplicaties wordt vaak de portability genoemd. Maar denkt u dat dit voordeel wel zo groot is? (nadelen: verschillende browsers, java virtual machine niet altijd geïnstalleerd)

Cijfer (meer nadelen:1 …..10: meer voordelen): Plus:8, Checkit:8 Plus: Ik denk dat dit inderdaad het voornaamste voordeel is dat daadwerkelijk gerealiseerd kan worden bij toepassing van webapplicaties. Checkit: Afhankelijk van de doelgroep: bij een legacy applicatie voor intern gebruik lijkt het me geen probleem om bijv. Java virtual machine nodig te hebben of slechtst één webbrowser te ondersteunen; bij applicaties bedoeld voor de massa zal hier rekening mee gehouden moeten worden.

Pagina 43 van 54


5.2 Conclusie praktijkonderzoek In deze paragraaf worden conclusies getrokken uit het praktijkonderzoek. Daardoor wordt deelvraag drie van dit onderzoek vanuit de praktijk beantwoord. Door de kleinschaligheid van het onderzoek en doordat het vooral een literatuuronderzoek betrof is de steekproef beperkt tot twee bedrijven. Waar in het vervolg van de scriptie wordt gesproken over de praktijk heeft het dus betrekking op deze twee bedrijven. De praktijk heeft geen betrekking op het gehele domein van organisaties die organisatiespecifieke software gebruiken. Beide bedrijven gaven een aantal redenen waarom ze webbased applicaties voor hun organisatie prefereren zoals eenvoud in onderhoud en deployment. Voor het programmeren van een webbased applicatie waren beide personen het eens dat de vele en snel afwisselende technieken die gebruikt moeten worden de moeilijkheidsgraad kunnen verhogen. Het lastig traceren van problemen en fouten werd als nog een ander nadeel benoemd voor webbased applicaties. Het ontwikkelen van een goede basis en een goed framework is dan ook belangrijk voor een webbased applicatie. Als vanaf het begin consistent met dit framework wordt gewerkt dan zal het programmeren eenvoudiger verlopen en is het hergebruik van componenten eenvoudiger te realiseren. Voor de karakteristiek functionality kwamen de volgende punten naar voren: • de interoperability van een webbased applicatie hoeft niet per definitie beter te zijn, dit ligt meer aan de structuur van hoe een applicatie is opgezet. • Voor de security van een webbased applicatie kwam naar voren dat de kwaliteit hiervan af kan nemen zodra de applicatie gekoppeld is aan het internet. De applicatie is dan namelijk toegankelijker en zal meer aandacht vergen. • Het voldoen aan functionality compliance door gebruik te maken van standaarden draagt bij aan een goede kwaliteit van een webbased applicatie. Voor de karakteristiek usability kwamen de volgende punten naar voren: • statusveranderingen bijhouden van gebruikersacties is lastiger te realiseren voor webbased applicaties. Het risico is groter geworden dat de statusveranderingen niet inzichtelijk zijn voor een gebruiker. • De meningen liggen verdeeld als het om adaptability gaat. De één vind het meer bijdragen dan een ander. Er werd echter wel opgemerkt dat dit net zo eenvoudig is te realiseren voor een webbased applicatie als een andere soort applicatie. • Het probleem van het navigeren binnen een webbased applicatie wordt erkend vanuit de praktijk en hiermee wordt bij het ontwikkelen rekening gehouden. • Er zijn voor webbased applicaties geen voordelen te vinden die attractiveness vergroten. Voor de karakteristiek efficiency kwamen de volgende punten naar voren: • de kwaliteit van het aspect time behaviour zal volgens de respondenten nauwelijks veranderen. Ook niet doordat het kan zijn dat bepaalde GUIfunctionaliteit niet voorhanden is. • Beide respondenten geven aan dat de performance bij de client aanzienlijk minder wordt en aan de server kant een stuk hoger. In totaliteit wordt de kwaliteit van resource behaviour wel beter gevonden voor webbased applicaties. Uit het praktijkonderzoek bleek dat de verhoging van de kwaliteit van de karakteristiek portability wel als één van de grootste voordelen mag worden gezien voor webbased applicaties. Het probleem dat webbased applicaties kunnen ondervinden doordat ze niet werken in een bepaalde versie van een webbrowser hoeft ook niet als nadelig te worden ondervonden. Het is namelijk binnen een organisatie heel eenvoudig om één soort webbrowser met dezelfde implementatietechnieken te ondersteunen en gebruiken waardoor de webbased applicatie wel bij elke client werkt.

Pagina 44 van 54


6

Vergelijking literatuur met praktijk

In dit hoofdstuk zal een definitief antwoord worden geformuleerd voor de subdeelvragen van de derde deelvraag die als volgt luidt: “Welke voor- en nadelen zijn er te vinden kijkend naar de verschillende aspecten van een bepaalde kwaliteitskarakteristiek?” De antwoorden op deze subdeelvragen worden verkregen door de uitkomsten van de literatuurstudie uit hoofdstuk vier te vergelijken met de uitkomsten van het praktijkonderzoek uit hoofdstuk vijf. Hieronder worden de subdeelvragen behandeld. •

Welke beveiligingsprincipes veranderen of zijn er extra nodig voor webbased applicaties? Uit de literatuur [JA01] blijkt dat er nog geen goede beveiligingsmodellen op het moment beschikbaar zijn voor webbased applicaties. Er worden nog diverse onderzoeken gedaan naar de wijze waarop webbased applicatie goed beveiligd kunnen worden. Het onderzoek [WA05] naar een firewall richt zich specifiek op de veiligheid voor een webbased applicatie. Uit de praktijk blijkt dat er weinig verschillen worden ondervonden voor webbased applicaties. Het beveiligingsgevaar dat de applicatie kan lopen als het is gekoppeld aan het internet is hierop een uitzondering. Er kan geconcludeerd worden dat er in de praktijk wel oplossingen te vinden zijn om een webbased applicatie te beveiligen. Deze oplossingen maken echter gebruik van modellen die minder goed of minder geschikt zijn dan modellen van ‘traditionele’ applicaties. De toegankelijkheid van het internet moet nog als extra beveiligingsrisico mee moet worden genomen.

•

Wat gebeurt er met de andere aspecten van de kwaliteitskarakteristiek functionality bij webbased applicaties? Uit de literatuur, behandeld in paragraaf 4.1.1, kwam naar voren dat het aspect interoperability een goede kwaliteit had door de middleware technieken die vaak worden gebruikt bij webbased applicaties. Er is ook een hoge kwaliteit voor functionality compliance doordat de webbrowser de ontwikkelaar voor een groot deel dwingt standaard technieken te gebruiken. Uit de praktijk blijkt dat als er een goede structuur ontwikkeld wordt met standaard webbased technieken er veel voordelen zijn te onderkennen voor webbased applicaties. De conclusie is dan ook dat een ontwikkelaar een goede kwaliteit kan ontwikkelen voor deze aspecten door gebruik te maken van de geaccepteerde standaarden en het invoeren van een middleware in de client-server architectuur.

•

Welke onderdelen en vormen van de kwaliteitskarakteristiek usability zullen significant anders zijn bij webbased applicaties? Uit de literatuur [PP01, EA99, e.a] blijkt dat bij webbased applicaties een aantal aandachtgebieden zijn te onderkennen. Deze aandachtsgebieden zorgen voor mindere kwaliteit voor de karakteristiek usability als er geen aandacht aan wordt besteedt bij de totstandkoming van de applicatie. De twee belangrijkste aandachtgebieden die nauw met elkaar verbonden zijn, waren: het navigeren binnen de applicatie en het inzichtelijk houden van statusveranderingen binnen de applicatie. Uit de praktijk worden deze problemen erkend. Er wordt daarom extra aandacht aan geschonken bij het ontwikkelen van een webbased applicatie. Als een webbased applicatie wordt vergeleken met een andere soort GUI applicatie blijkt dat webbased applicaties over minder GUI functionaliteiten beschikken [PP01]. In de praktijk blijkt

Pagina 45 van 54

Bachelorscriptie Onderwerp: webbased organisatiespecifieke applicaties dit tegenwoordig wel mee te vallen. Het kost alleen meer ontwikkeltijd doordat er nog geen standaard componenten beschikbaar zijn die kant-en-klaar geïmplementeerd kunnen worden. De conclusie bij deze vraag is dan ook dat een goede kwaliteit voor een webbased applicatie voor usability wel te realiseren is. Het ontwikkelen van een goede kwaliteit kost alleen meer tijd blijkt zowel uit de literatuur als uit de praktijk. •

Hoe efficiënt werkt een webbased applicatie ten opzichte van een zelfde applicatie die niet webbased is als er naar het tijdsgedrag en het gebruik van resources wordt gekeken? Het tijdsgedrag binnen een webbased applicatie hangt af van wat de kwaliteit is voor usability en wat de kwaliteit is van het aspect resource behaviour. In de praktijk blijkt dat dit te maken heeft met de manier hoe een applicatie opgezet is en ontwikkeld is. Uit de literatuur, zie paragraaf 4.3.2, blijkt dat de belasting van de resources van de client kant naar de server kant is verschoven. In de literatuur worden goede oplossingen gegeven om met deze belasting aan de server kant om te gaan [DG05, AC03]. De mensen uit de praktijk erkennen deze verschuiving van de belasting en zagen dit als een voordeel voor de kwaliteit van efficiency. De conclusie op deze vraag is dan ook tweeledig. Voor het aspect recource behaviour neemt de efficiëntie toe. Bij het aspect time behaviour zal de kwaliteit afhangen van andere aspecten.

•

Zijn er voor- en nadelen te onderscheiden als er gekeken wordt naar aspecten als adaptability installability, co-existence en replaceability van de kwaliteitskarakteristiek portability? Voor alle aspecten van portability is er een hoge kwaliteit te behalen bij het ontwikkelen van een webbased applicatie. Dit blijkt uit de diverse literatuur die in paragraaf 4.4 is besproken. Er is echter één probleem. Als er gebruik wordt gemaakt van nieuwere implementatietechnieken dan worden deze nog niet altijd standaard ondersteund door de oudere webbrowsers of besturingssystemen van de client. In de praktijk hoeft dit geen probleem te zijn aangezien er eenvoudig één soort webbrowser kan worden ondersteund en geïnstalleerd voor de gehele organisatie. De eindconclusie is dan ook dat de kwaliteit van portability heel goed is bij een webbased applicatie door de breed ondersteunende webbased technieken.

Pagina 46 van 54


7

Eindconclusie

In dit hoofdstuk wordt tot een antwoord gekomen op de hoofdvraag van dit onderzoek. Het antwoord op de probleemstelling wordt afgeleid van de al gevonden antwoorden op de deelvragen en luidt: “Is het verstandig om een nieuwe organisatiespecifieke applicatie webbased te maken, zodat de voordelen het overwinnen van de nadelen als deze worden vergeleken met een zelfde applicatie die niet webbased is?” Het antwoord op deze probleemstelling wordt afgeleid op de al gevonden antwoorden in de andere hoofdstukken. De in paragraaf 3.3 gedefinieerde webbased organisatiespecifieke applicatie heeft wat betreft bepaalde aspecten een betere kwaliteit dan een andere vergelijkbare applicatie maar wat betreft andere aspecten ook een mindere kwaliteit. Bij het verifiëren van de literatuur met de praktijk bleek dat er over de meeste punten wel hetzelfde werd gedacht. Uit hoofdstuk zes bleek dat bij de volgende kwaliteitskarakteristieken en aspecten de voordelen het winnen van de nadelen voor webbased applicaties: interoperability, functionality compliance, resource behaviour en alle vijf aspecten van portability. Bij de karakteristiek usability zijn er geen voordelen te vinden maar wel nadelen in de vorm van extra ontwikkeltijd van de applicatie. De extra ontwikkeltijd wordt vooral veroorzaakt om een goede kwaliteit te verkrijgen voor de kwaliteitsaspecten understandability en operability, zo blijkt uit de conclusie in hoofdstuk 6. De problemen die deze extra ontwikkeltijd veroorzaken zijn: lastiger om statussen van de applicatie bij te houden, lastiger om een bepaalde actie ongedaan te maken, het “lost is hyperspace syndrome” bij het navigeren door de applicatie en het vaak ontbreken van GUI-functies als slepen en een rechtermuisknop. Wanneer er eenmaal een goede structuur is ontwikkeld en voor bepaalde GUI-functionaliteiten componenten geprogrammeerd zijn, dan heeft een webbased applicatie voor de usability aspecten ook een goede kwaliteit. De componenten en structuur zijn alleen nog niet standaard beschikbaar. Voor een organisatie kost het daardoor in het beginstadium veel extra tijd om een dergelijke structuur en componenten te ontwikkelen. Is dit echter eenmaal ontwikkeld dan kan een organisatie er van profiteren door het te hergebruiken. Het antwoord op de deelvraag betreffende het aspect security is niet positief uitgevallen voor webbased applicaties. De grootste reden hiervoor is dat er nog geen goede beveiligingsmodellen bestaan die standaard beschikbaar zijn om geïmplementeerd te kunnen worden. Om toch een zo goed mogelijke kwaliteit te verkrijgen voor dit aspect, zal er weer extra tijd geïnvesteerd moeten worden om een goede beveiliging te realiseren. Het ontwikkelen van een webbased applicatie is in de meeste gevallen lastiger dan een applicatie die is gemaakt met een andere soort techniek zoals in paragraaf 2.2 en hoofdstuk zes is besproken. Het is daarom verstandig voor een organisatie om een applicatie webbased te ontwikkelen als een organisatie al beschikt over competente werknemers die deze snelwisselende webbased technieken beheersen of als het management van een organisatie bereid is te investeren in zijn huidige werknemers of in nieuwe programmeurs die deze snel wisselende webbased technieken gaan beheersen. De problemen die spelen bij usability kunnen dan worden opgelost door deze (nieuwe) webbased programmeurs. Hierdoor zijn er meer voordelen te vinden die pleiten voor een webbased applicatie dan nadelen die een slechte kwaliteit veroorzaken. Over het algemeen kan geconcludeerd worden dat als een organisatie over de juiste programmeurs kan beschikken het verstandig is om de organisatiespecifieke applicatie webbased te ontwikkelen.

Pagina 47 van 54

Bachelorscriptie Onderwerp: webbased organisatiespecifieke applicaties Er zijn tenslotte nog wel een aantal situaties te onderscheiden, waar deze conclusie niet voor geldt en een aantal situaties die de conclusie versterken. Enkele situaties waarvoor geldt dat het minder of niet verstandig is om een organisatiespecifieke applicatie webbased te ontwikkelen zijn: •

•

•

als een organisatie relatief snel of goedkoop een applicatie ontwikkeld wil hebben, kan hij beter een ander soort techniek kiezen waar al wel veel goed ontwikkelde componenten en modellen voor beschikbaar zijn. Zoals al ter sprake is geweest kost het ontwikkelen van een webbased applicatie vooral in het beginstadium veel extra ontwikkeltijd. Als een organisatie zijn gegevens en de toegang tot de gegevens op een heel hoog niveau beveiligd wil hebben. Het is dan verstandiger om te wachten totdat er betere security modellen beschikbaar zijn die meer zekerheid bieden voor de beveiliging van de webbased applicatie. Deze modellen zijn nu namelijk voor webbased applicaties nog niet voorhanden. Als een organisatie niet over de geschikte medewerkers kan of wil beschikken die met deze technieken kunnen omgaan. Voor een programmeur die werkt met andere technieken is het namelijk onmogelijk om in een korte tijd de technieken aan te leren die nodig zijn om een organisatie specifieke webbased applicatie te ontwikkelen.

Een aantal situaties waarbij het voor een organisatie nog verstandiger is om een organisatiespecifieke applicatie webbased te maken zijn: •

•

•

•

als een organisatie de applicatie wil koppelen aan een extranet of het internet. De organisatie kan besluiten om naast de functionaliteiten van een applicatie waar de medewerkers van een organisatie mee werken, delen hiervan zoals de data en informatie te (her)gebruiken voor bijvoorbeeld een klanten- of leveranciersportaal. Deze delen van de portalen zullen zich dan bevinden op een extranet of het internet. Als dit het geval is dan is het verstandig om de hoofdfunctionaliteiten van de applicatie ook webbased te ontwikkelen. De extra ontwikkeltijden spelen dan geen grote rol meer aangezien een groot deel dan toch ontwikkeld moet worden voor de functionaliteit van de portalen. Als een organisatie te maken heeft met veel veranderingen vanuit de omgeving die moeten worden doorgevoerd in de applicatie, dan is een webbased applicatie zeker aan te raden. De reden hiervoor is dat wanneer een webbased applicatie eenmaal ontwikkeld is, veranderingen realtime kunnen worden uitgevoerd zonder dat de gebruikers dit hoeven te merken. De organisatie hoeft dan niet meer elke keer op alle computers van de clients een nieuwe versie te installeren wat veel tijd en geld kan besparen. Als er in de toekomst meer standaard webbased technieken voorhanden zijn die kanten-klaar ingezet kunnen worden. Dit is nu wel het geval bij de meeste andere GUI technieken. Er kan dan bijvoorbeeld worden gedacht aan javascript objecten die standaard door de webbrowsers ondersteund worden. Het XMLhttpRequest object van AJAX, zoals beschreven in paragraaf 4.3.2, is hier een goed voorbeeld van. Als een organisatie delen of de gehele applicatie ook via mobile apparaten als PDA’s en smartphones beschikbaar wil stellen. De goede kwaliteit van portability en interoperability van webbased applicaties vereenvoudigen dit aanzienlijk zo blijkt uit paragraaf 4.4 en 4.1.1.

Pagina 48 van 54


8

Literatuurlijst

[AC03] Andreolini M. & Colajanni M. & Morselli G. (2002), Performance Study of Dispatching Algorithms in Multi-tier Web Architectures, University of Mondena Italy [DG05] Datla V. & Goseva-Popstajanova K. (2005), Measurement-based performance analysis of e-commerce applications with web services components, West Virginia University V.S. [DV05] Doyle B. J. & Videira-Lopes C. (2005), Survey of Technologies for Web Application Development, ACM Journal University of California V.S. [EA99] Ehrencrona A. (1999), Coping with the Web Interface – Guidelines for Web Applications, Technische Universiteit Delft [GK02] Gokhale A. & Kumar B. & Sahuguet A. (2002), Reinventing the Wheel? CORBA vs. Web Services, VanderBilt University Nashville V.S. & Bell Labs, Lucent Technologies [HA02] Hassan A. E. (2002), Architecture Recovery of Web Applications Services, Software Architecture Group (SWAG) University of Waterloo Canada [IS00] ISO/IEC 9126-1:2000. (2000), Information technology - Software product quality, - Part 1: Quality model, ISO-IEC Geneva Zwitserland [JA01] Joshi J. B. D. & Aref W. G. & Spafford E. H. (2001), Security models for webbased applications, Communications of the ACM & Purdue University [KC05] Kruegel C. (2005), A multi-model approach to the detection of web-based attacks, Elsevier ScienceDirect [KD04] Kulak D. (2004), USE cases requirements in context, Addison-Wesley Boston V.S. [KR01] Kappel G. & Retschitzegger W. & Schwinger W. (2001), Modelling Customizable Web Applications A Requirement's Perspective, University of Linz Austria [MM02] Mendes E. & Mosley N. & Counsell S. (2002), A Comparative Study of Cost Estimation Models for Web Hypermedia Applications, The university of Auckland New Zealand [PF02] Piccinelli G. & Finkelstein A. (2002) Web Services Need Consistency, Dept. of Computer Science University College London [PL05] Dailey Paulson L. (2005), Building rich web applications with Ajax, IEEE computer socicity Ventura California [PP01] Pop P. (2001), Comparing Web Applications with Desktop Applications:An Empirical Study, Linköping University Sweden [PR00] Pressman R. S. (2000), Software Engineering A practitioner’s Approach, MCGraw-Hill, Berkshire England [RD96] Rowley D. (1996), The business of application portability, MKS Waterloo Ontario

Pagina 49 van 54

Bachelorscriptie Onderwerp: webbased organisatiespecifieke applicaties [RJ03] Ruhe M. & Jeffery R. & Wieczorek I. (2003) Using Web Objects for Estimating Software Development Effort for Web Applications, Siemans Germany & the University of new South Wales [RH02] Rodriguez D. & Harrison R. (2002), A Generic Model and Tool Support for Assessing and Improving Web Processes, The University of Reading – UK [SB04] Serbedzija B. N. (2004), Developing Middleware for web-aware systems: lesson learned, University of technology Sydney [SS03] Sneed H. M. & Sneed S. H. (2003), Creating web services from legacy host programs, University of Regensburg Bavaria Germany [SS04] Spriestersbach A. Springer T. (2004), Quality Attributes in Mobile Web Application Development, Dresden University of Technology Germany [TG02] Tilley S. & Gerdes J. e.a. (2002), Adaption challenges in migrating to web services, University of California, Riverside V.S. [VP05] Valente P. (2005), The evolution of web-based optimisation: From ASP to eServices, Elsevier ScienceDirect Amsterdam [W3C] Caldwell B. & ChisHolm W. e.a (2005), Web Content Accessibility Guidelines 2.0, W3CHECKIT: http://www.w3.org/TR/2005/WD-WCAG20-20051123/ [WA05] Web Application security Consortium (2005), Web Application Firewall Evaluation Criteria, http://www.webappsec.org/projects/waf_evaluation/ [WI00] Weippl E. & Ibrahim I. Schwinger W. & Winiwarter W. (2000), Web engineering for intranets: rethinking software engineering

Pagina 50 van 54


Bijlage I [16] Technology Markup Standards Protocol specifications Web browser Web server

Tier

Implementations HTML, XHTML, CSS HTTP, SSL, MIME, WebDAV Internet Explorer, Opera, Mozilla, Netscape Apache, Internet Information Server, Sun JavaWeb Server, ZeusWeb Server, Jigsaw

Client Server Client Server

Tabel 1: foundational technologieën van het web Tier Webbrowsers

Web servers

Product (Provider) Web browsers Internet Explorer (Microsoft) Opera (Opera Software) Mozilla (The Mozilla Organization) Netscape (AOL / Netscape) Apache (Apache Software Foundation) Internet Information Server (Microsoft) Sun Java System Web Server (Sun) Zeus Web Server (Zeus Technology)

Platform (Tier share %) Windows (69.7) Several (1.9) Several (23.3) Several (1.4) Several (68.4) Windows (20.9) Several (23.3) Several (1.2)

Tabel 2: Webbrowsers en webservers met hun marktaandeel in 2005

Technology Browser interfaces State management webservice clientinterfaces Scripting interfaces

Exemplars Netscape Cookie API SOAP, XML-RPC XMLHttpClient

Key Properties and Common Usage Used for client state persistence. Highly portable. Increased interactivity. Highly portable. Increased interactivity.

Tabel 3: client-based integratietechnologien

Technology Programming languages Natively compiled

Exemplars

Key Properties and Common Usage

C, C++

Interpreted

Perl, Python, Ruby

Byte-code compiled

Java, .NET languages

Highly portable, high performance, low usability. CGI scripting and web server extension. Highly portable. Performance varies. CGI scripting. Highly portable. Good performance. Extensive language run-time libraries.

Components Complex components Simple components Middleware Messaging Security Data Access Object-relational mapping Web services

CORBA, COM, EJB, .NET managed components JavaBeans, Spring, picoContainer, Java classes

Enterprise systems development.

MSMQ, MQseries, J2EE, JMS J2EE, JAAS ODBC, JDBC, ADO, .NET Hibernate, JDO, TopView, iBatis SOAP, XML-RPC

Enterprise systems development.

Enterprise systems development. Improved usability.

Enterprise systems development. Highly portable, highly scalable Highly portable, highly scalable, improved usability Highly portable

Tabel 4: server-side integratietechnologieën

Pagina 51 van 54

Bachelorscriptie Onderwerp: webbased organisatiespecifieke applicaties Technology Browser extension Browser specific APIs

Exemplars


CCI, ActiveX, Netscape, Plug-API

High performance, low usability. Extend browser capabilities.

JavaScript, VBScript, DOM, SVG Macromedia flash, Java Applets

Highly portable due to Web standards acceptance. Increased interactivity Highly portable depending on plug-in spread. Marketing presentation development.

CURL, Sash Weblications, Konfabulator, XAML

Used for applications with high interactivity requirements that need to access the Internet Used for browser alternative development Used by forms-based business systems. Improved cached content delivery.

Client dynamism Directly interpreted Byte-code Rich interfaces Browser alternatives

Client frameworks Forms interfaces Dynamic assembly

Jakarta Client, Commons http-client InfoPath, XForms Edge Side Includes(ESI), Client Side Includes(CSI)

Tabel 5: Client-based dynamische content generatietechnologieën

Technology Server extension Server- specific

Exemplars


ISAPI, NSAPI, Apache API

Proprietary. Scalable. Complex. Implement extended server capabilities.

CGI

Portable. Not scalable. Low usability. Small-scale application with simple navigational requirements Portable. Scalable. Low usability. Medium to large-scale applications with simple navigational requirements

Gateways Simple Fast CGI Scalable Interpreters General purpose Template-based

Server-side Javascript, modperl SSI, XSSI, ColFusion, ASP, PHP, JWIG

Medium to large-scale applications with simple navigational requirements Portable, Medium to large-scale applications with simple navigational requirements

Tomcat, Resin

Highly Portable, Scalable, Medium to enterprise Applications, Frameworks Portable. Scalable. Generally used as the view component of MVC implementations. Scalable Web publishing Highly portable. Highly scalable. Complex.Enterprise systems.

Extended servers Servlet engines

JSP, Velocity, Webmacro, XMLC, FreeMArker

Template engines Conternt Management J2EE application servers

Zope, Cocoon WebSphere, jRun, JBOSS, WebLogic

Tabel 6: server-side dynamische content generatietechnologieën

Pagina 52 van 54

Bachelorscriptie Onderwerp: webbased organisatiespecifieke applicaties Technology Frameworks Scripting languagebased Application-driven Page-driven, component-based, Desktop model Page-driven componentbased, Web model Application/Page Hybriddriven component-based Portal composition

Exemplars


Twisted (Python), WebWare(Python), Snakelets (Python), Rails (Ruby) Struts, Spring MVC, WebWork, Maverick, Barracuda Echo, wingS, WebCream, Wi.Ser WebObjects, Tapestry,ASP.NET WebForms JavaServer Faces

Java Portlet specification, WebParts, Tiles, SiteMesh Model Driven Development AutoWeb, RMM, OOHDM, Oracle Web Development Data-centered Suite, WebML, WebRatio Codecharge, CodeSmith, GUI-centered DeKlarit, Fabrique Oracle, ADF, IBM/Rational MDA-compliant Rapid Developer Development environments Adobe PageMill, Amaya, Authoring tools Microsift Office (Word, Excel, Powerpoint) Microsoft VisualStudio .NET, Sun Java Studio Creator, Website management WebSphere Application Developer Others MAWL ,bigwig., JWIG, Programming languages functional continuation, Cocoon Flow

Portable. Small to large-scale applications with complex navigation requirements. Portable. Scalable. Enterprise web sites with complex navigation requirements. Portable. Complex. Ease transition to Web programming. Portable. Scalable. High usability.Rapid development. Simple to medium complexity navigation requirements. Portable. Scalable. High usability. Enterprise web sites with complex navigation requirements. Rapid development. Portable. Scalable. Enterprise portal development. Data-intensive applications.

Interaction-intensive applications. OMG-standard

Static content creation and editing

Programming-intensive.

Research projects.

Tabel 7: server-side ontwikkelingsbenaderingen

Pagina 53 van 54


Bijlage II: CORBA vs. Webservices Aspect Data model Client-Server coupling Location transparency Type system Error handling Serialization Parameter passing Transfer syntax State Request semantics Runtime composition Registry Service discovery Language support Security Firewall Traversal Events

CORBA Object model Tight Object references IDL static + runtime checks IDL exception built into the ORB by reference by value (valuetype) CDR used on the wire binary format stateful at-most-once DII Interface Repository Implementation repository CORBA naming/trading service RMI registry any language with an IDL binding CORBA security service work in progress CORBA event service

Web services SOAP message exchange model Loose URL XML schemas runtime checks only SOAP fault messages can be chosen by the user by value (no notion of objects) XML used on the wire Unicode stateless defined by SOAP UDDI/WSDL UDDI/WSDL UDDI any language HTTP/SSL, XML signature uses HTTP port 80 N/A

Tabel 8: Comparison between CORBA and Web services [GK02]

Pagina 54 van 54

Webbased organisatiespecifieke applicaties

Recommend Documents