2. De aard van de gerealiseerde webservice
Een IT-dienstverlener, [ISTIA-IAIE], wil een dienst voor het maken van afspraken aanbieden. De eerste doelgroep bestaat uit zelfstandige artsen. Deze hebben doorgaans geen secretariaat. Klanten die een afspraak willen maken, bellen dan rechtstreeks naar de arts. Hierdoor wordt de arts gedurende de dag vaak gestoord, wat ten koste gaat van de beschikbaarheid voor zijn patiënten. Het bedrijf [ISTIA-IAIE] wil hen een afsprakenplanningsdienst aanbieden die volgens het volgende principe werkt:
- een secretariaat verzorgt de afspraken voor een groot aantal artsen. Dit secretariaat kan worden beperkt tot één persoon. Het salaris van deze persoon wordt gedeeld door alle artsen die gebruikmaken van de dienst.
- het secretariaat en alle artsen zijn aangesloten op het internet
- de RV-afspraken worden opgeslagen in een gecentraliseerde database, die via internet toegankelijk is voor zowel het secretariaat als de artsen
- Het vastleggen van RV gebeurt normaal gesproken door het secretariaat. Het kan ook door de artsen zelf worden gedaan. Dit is met name het geval wanneer de arts aan het einde van een consult zelf een nieuwe RV aan zijn patiënt toekent.
De architectuur van de dienst voor het vastleggen van RV is als volgt:
![]() |
Artsen werken efficiënter als ze zich niet meer met de RV hoeven bezig te houden. Als er voldoende artsen zijn, zal hun bijdrage aan de exploitatiekosten van het secretariaat gering zijn.
Het bedrijf [ISTIA-IAIE] besluit het servergedeelte in de vorm van een webservice te realiseren. De applicatie krijgt de volgende architectuur:
![]() |
- [1]: de lagen [dao, jpa] die toegang tot de gegevens mogelijk maken, worden gerealiseerd met behulp van een webservice J2EE
- [2]: we zullen verschillende soorten clients presenteren: Java, C#, Asp.Net

