Biblic Hu^i. S-v.p.! Aeer kopieeren. I papier. daarna NIETE>^IND^ DATACOMMUNICATIE T.B.V. DONAR, WVO-INFOPLAN EN AQUABEL BINNEN RIZA

rijkswaterstaat

ministerie van verkeer en waterstaat

riza rijksinstituut voor integraal zoetwaterbeheer en afvalwaterbehandeling tel. 03200-70411, fax. 03200-49218 doorkiesnummer 03200-70773

DATACOMMUNICATIE T.B.V. DONAR, WVO-INFOPLAN EN AQUABEL BINNEN RIZA

Aan: Repro Van: Bibliotheek

S-v.p.! A e e r kopieeren ENKELZIJr^G/DrjBBELZIJD Voorkant/achterkant op DIK, WJ l

I

papier

daarna N I E T E > ^ I N D ^

Biblic H u ^ i B

'j voorbaat dank

Werkdocument 93.135X auteurs) datum

J. Engels (MD-TI), Jan Duker (RIZA) 29 September 1993

Datacommunicatie t.b.v. DONAR/WVO/Agi)ABEL

INHOUDSOPGAVE 1. Inleiding 2. Samenvatting 3. Ontwikkelingen op het gebied van datacommunicatie 3.1. Algemeen 3.2. Basisbegrippen 3.3. Computercommunicatie architectuur 3.4. Communicatie netwerktechnieken 3.4.1. Publieke datanetwerken (PDN's) 3.4.2. ISDN 11 3.4.3. Breedband ISDN 3.4.4. ATM (Asynchronous Transfer Mode) 3.4.5. Internetworking of networkcomputing 3.5. Marktontwikkelingen 3.5.1. Netwerkcomputing Trends, Technologie en Taktiek 3.5.2. Netwerk Architecturen 3.5.3. IT-Management 3.5.4. Management van Networking Systems 3.5.5. Publieke Telecommunicatie 3.5.6. Samenvatting 4. Ontwikkelingen binnen de diverse projecten 4.1. Project DONAR 4.1.1. Inleiding 4.1.2. Stand van zaken m.b.t. de bouw 4.1.3. Gekozen datacommunicatieoplossing 4.2. Project WVO/Infoplan 4.2.1. Inleiding 4.2.2. Stand van zaken m.b.t. de bouw 4.2.3. Gekozen datacommunicatieoplossing 4.3. Project AQUABEL 4.3.1. Inleiding 4.3.2. Stand van zaken m.b.t. de bouw 4.3.3. Gekozen datacommunicatieoplossing 4.4. Verschillen en overeenkomsten tussen DONAR, WVO en AQUABEL 5. Afstemming datacommunicatie-faciliteiten t.b.v. de drie projekten 6. Huidige en toekomstige datacommunicatie-infrastructuur binnen RIZA 7. Conclusies en aanbevelingen 7.1. Conclusies 7.2. Aanbevelingen 8. Geraadpleegde literatuur

© MD-TI/RIZA-IO

4 5 6 6 6 9 10 11 12 12 13 14 14 17 19 19 20 21 22 22 22 23 23 26 26 26 27 29 29 30 30 31 33 34 37 37 38 39

Pagina 3

Datacommunicatie t.b.v. DONAR/WVO/AgUABEL

1.

INLEIDING.

In samenwerking met RIZA worden een drietal grote landelijke informatiesystemen gebouwd, te weten DONAR, AQUABEL en WVO-Infoplan. Deze systemen worden door verschillende projektgroepen ontwikkeld en er ontstond behoefte om de datacommunicatie-infrastructuur van deze projekten eens met elkaar te vergelijken. Daarbij is het van belang om aan te geven wat de verschillen zijn, qua opzet, tussen deze systemen. RIZA heeft opdracht gegeven om te onderzoeken wat de gevolgen van bovengenoemde systemen zijn voor de eigen datacommunicatie-infrastructuur om straks een goed gebruik van deze informatiesystemen te kunnen waarborgen. De nu voorliggende nota is het resultaat van dat onderzoek. Tevens is onderzocht in welke mate de drie informatiesystemen met elkaar overeenstemmen op het gebied van programmeer hulpmiddelen en gebruikers interface. Bij grote afwijkingen bestaat immers het risico dat geen uniforme structuur opgezet kan worden binnen RIZA of ,dat er bij gebruik van de drie systemen naast elkaar conflicten kunnen ontstaan. Om een goed beeld te krijgen van de consequenties voor de datacommunicatiestructuur bij RIZA en de eisen die hieraan door de verschillende in ontwikkeling zijnde informatiesystemen worden gesteld, is de hulp ingeroepen van de Meetkundige Dienst, afdeling TI. T.a.v. de datacommunicatieaspecten bij RIZA en de verschillende informatiesystemen heeft de projektgroep zich de volgende vragen gesteld : - Welke keuzes zijn er al gemaakt in de verschillende ontwerpen, welke besluiten dienen er nog genomen te worden? - Zijn er bij de verschillende projecten overeenkomsten m.b.t. deze keuzes? - Kunnen keuzes zodanig op elkaar worden afgestemd dat er een uniforme datacommunicatiestructuur bestaat t.b.v. de drie informatiesystemen? - Past e.e.a. in de huidige datacommunicatie-infrastructuur binnen IO? Dit rapport tracht een antwoord te geven op de verschillende vragen.

© MD-TI/RIZA-IO

Pagina 4

Datacommunicatie t.b.v. DONAR/WVO/AQUABEL

2.

SAMENVATTING

De huidige structuur van het RIZA-net is zodanig dat de toepassingen DONAR/ADONA/DAVOS, WVO en AQUABEL geen onoverkomelijke problemen zullen opleveren voor wat betreft de datacommunicatie. Een duidelijk beeld omtrent de belasting van het netwerk vergt echter nader onderzoek omdat de intensiteit van gebruik op dit moment moeilijk in te schatten is. Er is geen sprake van een uniforme datacommunicatiestructuur voor de drie toepassingen. Ten aanzien van de gebruikersinterface hebben DONAR/ADONA/DAVOS en WVO dezelfde opzet gekozen, namelijk een grafische vorm, terwijl in AQUABEL gekozen is voor een karakter georienteerde gebruikersinterface. Dit onderzoek toont aan dat het wenselijk is om te komen tot een infrastructuurbeleid w a a r a a n bestaande en toekomstige toepassingen en produkten getoetst kunnen worden.

© MD-TI/RIZA-IO

Pagina 5


3.

ONTWIKKELINGEN OP HET GEBIED VAN DATACOMMUNICATDZ.

3.1. Algemeen Datacommunicatie netwerken zijn ontwikkeld als gemeenschappelijk communicatiesysteem en om gebruikers in staat te stellen computer-resources en informatiebronnen te delen. Dit gezamelijk gebruik en de uitwisseling van informatie houdt niet op bij de grenzen van de organisatie. Gebruikers hebben vaak de behoefte databases op computers in een "ander" netwerk te raadplegen. Hierdoor is 6en enkel netwerk onvoldoende om tegemoet te komen aan de toegenomen behoefte om informatiesystemen te koppelen. Belangrijk bij het koppelen van informatiesystemen waarbij twee of meer computers betrokken zijn is de voorziening van een passende datacommunicatiefaciliteit. Staan computers in dezelfde ruimte of gebouw dan kan een eenvoudige punt-naar-punt verbinding al voldoende zijn. Als de systemen echter in verschillende delen van de stad of het land staan dan zijn over het algemeen faciliteiten van een WAN nodig. Technologische ontwikkelingen hebben ingespeeld op de toenemende vraag naar datacommunicatiefaciliteiten. Digitalisering van schakel en transmissieapparatuur zorgen voor een implementatie van nieuwe netwerkdiensten. Integratie van van tekst, grafische beelden, facsimile, audio en video is vandaag de dag al mogelijk. De groeiende vraag naar funktionaliteit heeft tot gevolg dat een datacommunicatienetwerk voortdurend in ontwikkeling verkeert. Toenemende complexiteit leidt tot een behoefte aan flexibiliteit, integratie en standaardisatie van communicatie-diensten, apparatuur, toegangsprocedures en tarieven. Om daaraan tegemoet te komen was het noodzakelijk dat leveranciers van datacommunicatieapparatuur en diensten het eens werden over een verzameling van gemeenschappelijke technologieen en standaards om netwerken in staat te stellen met elkaar te communiceren. Netwerkdiensten hebben onder meer betrekking op de coordinatie van de gegevensuitwisseling, de synchronisatie van de dialoog, data-conversie en aansluiting op de systeemomgeving van de gebruiker. Op het gebied van de netwerkdiensten bestaat momenteel nog weinig standaardisatie. als gevolg daarvan wijken de netwerkarchitecturen van de verschillende leveranciers op dit punt sterk van elkaar af. 3.2. Basisbegrippen In de meest eenvoudige vorm vindt datacommunicatie plaats tussen twee apparaten die direct met elkaar verbonden zijn door een punt-naar-punt transmissiemedium. Het is echter dikwijls niet praktisch om twee apparaten direct, punt-naar-punt, te verbinden. Redenen hiervoor kunnen zijn: • de apparaten staan erg ver uit elkaar en het zou zeer kostbaar worden om een © MD-TI/RIZA-IO

Pagina 6

D a t a c o m m u n i c a t i e t.b.v. DONAR/WVO/AgUABEL

speciale verbinding te maken tussen twee apparaten die honderden kilometers uit elkaar staan; • dat er meerdere apparaten zijn die elk op verschillende momenten een verbinding verlangen met vele anderen, bijvoorbeeld alle telefoontoestellen in de wereld. Het is niet praktisch om een verbinding te maken tussen ieder paar van apparaten. De oplossing voor dit probleem is ieder apparaat te verbinden met een communicatienetwerk waarbij elk apparaat wordt aangesloten aan een netwerknode. Schematisch ziet dit er als volgt uit:

\ml - Communicalie netwerk node I

I = Netwerk station

Figuur 3.1

Communicatienetwerken kunnen verdeeld worden op basis van de architectuur en technieken die gebruikt worden bij het oversturen van data. We onderscheiden de volgende typen van communicatie netwerken: • Geschakelde netwerken - Circuit-geschakelde netwerken - Berichtgeschakelde netwerken - Pakket-geschakelde netwerken • Broadcast netwerken - Packet radio netwerken - Satelliet netwerken - Lokale netwerken (LAN's) 1. GESCHAKELDE NETWERKEN

Circuitschakeling Communicatie via circuitschakeling impliceert dat er een toegewezen communicatiepad is tussen twee stations. Dat pad is een geschakelde serie van verbindingen tussen nodes. Het meest sprekende voorbeeld van circuitschakeling is ons telefoonnet. Circuitschakeling heeft twee belangrijke nadelen: a.Zowel bron- als bestemmingsstation moeten op hetzelfde moment beschikbaar © MD-Tl/RIZA-IO

Pagina 7


zijn voor dataoverdracht; b.Capaciteit moet beschikbaar zijn en door het netwerk tussen twee stations toegewezen worden. Het voordeel van circuitschakeling is dat de volledige kanaalcapaciteit tijdens de verbindingstijd ter beschikking staat aan de twee stations. Berichtschakeling Een alternatieve benadering is het uitwisselen van logische eenheden van data, de zogenoemde berichten (messages). Voorbeelden hiervan zijn telegrammen, elektronische post, computerbestanden en transactievragen en antwoorden. Bij berichtenschakeling (message switching) is het niet noodzakelijk om een pad te alloceren tussen twee stations. Voordeel hiervan is dat de twee stations niet op hetzelfde moment beschikbaar hoeven zijn. Het adres van de bestem-ming wordt eenvoudig toegevoegd aan het bericht en het geheel wordt daarna op het netwerk van node naar node doorgegeven. Een dergelijk systeem noemen we store-andforward systeem. Belangrijkste nadeel van bericht schakeling is dat het niet geschikt is voor real-time en interactief verkeer omdat van tevoren niet te voorspellen is wanneer het bericht aankomt. Pakketschakeling (packet switching) Pakketschakeling probeert de voordelen van beide andere systemen te combineren en de nadelen te minimaliseren. Pakketschakeling lijkt erg veel op berichtschakeling. Het grote verschil is echter dat de lengte van de dataeenheden, die over de lijn gaan, bij pakketschakeling beperkt is, er is een maximale pakketgrootte. Lange berichten die de maximale pakketgrootte overstijgen worden in stukken verdeeld en afzonderlijk verzonden. Opmerkelijk is dat de beperking van de pakketgrootte een enorm effect heeft op de performance van het netwerk. Hoe kleiner de pakketgrootte hoe korter de wachttijd in de node en des te sneller kan het van node naar node worden verstuurd. 2. Broadcast netwerken In een broadcast netwerk zijn geen geschakelde nodes. Ieder station is door middel van een zender/ontvanger verbonden met een medium dat met alle andere stations gedeeld wordt. Kenmerken zijn: • Op ieder station is slechts 66n in- en uitvoer poort nodig. • Omdat de transmissie faciliteit gedeeld wordt met anderen kan slechts een station succesvol uitzenden op 'n bepaalde tijd. Dit heeft tot gevolg dat er een soort mechanisme nodig is om de toegang op het gemeenschappelijke medium te controleren. • Mogelijkheden van een tijdelijke verbinding tussen twee stations zijn beperkt door de aard van het broadcast medium. Immers niemand anders kan op zo'n moment van het netwerk gebruik maken. • Noodzaak tot beveiliging omdat op elk punt in het netwerk de totale berichtenstroom af te tappen is. © MD-TI/RIZA-IO

Pagina 8


3.3.

Computercommunicatie architectuur

Als computers, terminals en/of andere gegevensverwerkende apparatuur data gaan uitwisselen zijn de volgende twee begrippen belangrijk: • protocol len • computer communicatie architectuur De structuur van datacommunicatie is gelaagd, met andere woorden in plaats van 66n enkele module die de communicatie functie verzorgt, is er een verzameling van modules. Die struktuur van modules wordt ook wel communicatie architectuur genoemd. Een voorbeeld hiervan is de telefoon, op het hoogste niveau gebruikt men het protocol "intoetsen van een nummer", het toestel zet deze aanslag vervolgens om in een aantal elektrische signalen (een ander protocol), deze signalen worden in de centrale verwerkt waarbij weer andere protocollen gebruikt worden, enz. Een dergelijke structuur van het telefoongebeuren noemen we dus communicatie architectuur. Protocollen maken dus onderdeel uit van die structuur. Een protocol is een verzameling van regels of conventies die betrekking hebben op de wijze waarop twee deelnemers samenwerken om informatie uit te wisselen. Oorspronkelijk waren protocollen eenvoudig van opzet. Met het groeien van de organisaties werden de netwerken echter complexer en uitgebreider. Veel computerapparatuur, vooral die van verschillende leveranciers, sloot niet op elkaar aan. De ondersteunende communicatiesoftware ontwikkelde zich tot een niveau waarop deze niet meer te onderhouden was. Tegen deze achtergrond werd het concept van de gelaagde protocollen ontwikkeld. Het principe van gelaagde protocollen is, dat zolang als de lagen op een peer-topeer manier samenwerken (zie Figuur 2.1), en zolang als de koppeling tussen de functie op een laag en de daaraan grenzende hogere en lagere laag niet be'invloed wordt, het niet belangrijk is hoe de functie van die ene laag uitgevoerd wordt. Dit is het principe van het Open Systems Interconnection (OSI) model. In onderstaande Figuur wordt weergegeven op welke wijze modules, in dezelfde laag (peer-to-peer), op verschillende computers met elkaar communiceren: d.m.v. een protocol. computer 1

computer 2 applicatie protocol

applicatie

transport protocol

transport netwerk netwerkaccess

applicatie

access protocol

l~s

/

transport ^ N ^

[ communicatie ( ( X \v netwerk / " \ yS s/

netwerkaccess

Figuur 3.2

© MD-TI/RIZA-IO

Pagina 9


3.4. Communicatie netwerktechnieken In de inleiding is al verteld dat het niet praktisch is om twee apparaten via een punt-naar-punt verbinding direct aan elkaar te koppelen. Zijn er meerdere apparaten dan speelt het fenomeen topologie een rol. Topologie betekent de wijze waarop de apparaten via communicatieverbindingen met elkaar verbonden zijn, de structuur van het communicatienetwerk. In de onderstaande Figuur is een voorbeeld getekend van 'n topologie van een geschakeld netwerk.

B

\

u o

Ti)

C* j

0)-" = NETWERKSTATION = COMMUNICATIE NETWERK

NO )!•

Figuur 3.3

Data die vanaf een station het netwerk in komt wordt naar de bestemming gerouteerd door van node naar node te schakelen. Er zijn dus verschillende routes mogelijk. De classificatie van geschakelde netwerken zoals ci,^uit, bericht of pakket, heeft te maken met de wijze waarop de nodes de data naai de volgende node doorschakelen op weg van bron naar bestemming. De betrouwb;>arheid van het geschakelde netwerk wordt verhoogd als er meer dan €€n pad is tussen ieder paar van stations. Bij LAN's onderscheiden we de volgende basis topologieen: ring, bus ,boom en ster. Bij de bus/boom structuur kunnen twee transmissietechnieken worden toegepast: baseband en broadband. Baseband gebruikt digitale signaal technieken en kan gebruikt worden op twisted pair of coax kabel terwijl boadband gebaseerd is op analoge signaal techniek en coax kabel gebruikt. LAN STANDAARDS

In de afgelopen jaren is een grote inspanning gestoken in het definieren van standaards. Deze LAN standaards hebben een brede acceptatie bij zowel leveranciers als gebruikers bereikt. De meeste standaards zijn ontwikkeld door IEEE en overgenomen door de ISO. Door ANSI is de FDDI standaard voor ring netwerken ontwikkeld en ook die is overgenomen door de ISO.

© MD-TI/RIZA-IO

Pagina 1 0


3.4.1. Publieke datanetwerken (PDN's) Een publiek datanetwerk is een geschakeld netwerk, bedoeld voor de overdracht van data en moet faciliteiten bieden voor de interworking (samenwerking) van apparatuur van verschillende leveranciers. Na veel discussie en experimenten is een verzameling van internationaal overeengekomen standaards geaccepteerd door de CCITT. Dit zijn de -X- en I-series waartoe bijvoorbeeld hoort X.25, X.400,1.430, etc. 3.4.2. ISDN De grote vraag naar nieuwe diensten en de wens deze diensten te integreren met spraak is een grote stimulans geweest om ISDN te ontwikkelen. Het voorziet in een digitale verbinding met als doel het ondersteunen van een groot aantal diensten, inclusief spraak en niet-spraak diensten. Belangrijk is ook dat de gebruiker niet voor iedere dienst van ISDN een aparte koppeling (interface) nodig heeft maar alle diensten via edn toegangspunt (access point) kan gebruiken. In de onderstaande Figuur is dit principe weergegeven.

y

'telefoon

digital exchange

X digital exchange — _Jdn-integrated digital etwork

teMban ISDN-integrated services digital network Figuur 3.4

De hoofddoelstelling van ISDN is het, op hetzelfde netwerk, ondersteunen van een grote varieteit aan spraak en niet-spraak applicaties. Het ondersteunt verder geschakelde en niet geschakelde verbindingen zoals circuit en pakketschakeling. De protocollen voor ISDN kennen een gelaagde structuur en zijn conform het OSI-model. Het voordeel hiervan is, dat standaards die ontwikkeld zijn voor OSI direct van ISDN gebruik kunnen maken. Een voorbeeld hiervan is het X.25 protocol. © MD-TI/RIZA-IO

Pagina 1 1


ISDN zal, zoals het er nu naar uitziet, vanwege z'n tariefstructuur, die gebaseerd is op verbindingstijd, in combinatie met de hoge transportsnelheid en snelle toegangstijd de huidige netwerken, die gebaseerd zijn op X.25 en FR, uit de markt prijzen en zal mogelijk zelfs in veel gevallen huurlijnen verouderd maken. 3.43. Breedband ISDN De inkt is nauwelijks droog van de eerste definitieve verzameling van ISDN standaards of de planning en ontwerpinspanning wordt gericht op een netwerkconcept dat nog vooruitstrevender is dan ISDN zelf. Dit nieuwe concept wordt door CCITT 'de breedband aspecten van ISDN' genoemd. Breedband ISDN diensten, speciaal video diensten, vereisen datasnelheden die orden van grootte hoger zijn dan die nu door ISDN geleverd kunnen worden. Een grotere dataoverdracht snelheid impliceert veelal ook een groter aantal diensten die een netwerk kan leveren. B-ISDN kent de volgende diensten: • Interactieve diensten, dit betreft een uitwisseling van data die 2 kanten uitgaat; • Distribute diensten, een primair 1-richting systeem, bijvoorbeeld bestandsoverdracht; • Conversatie diensten, een bidirectionele dialoog communicatie faciliteit, realtime en eind-naar-eind informatieoverdracht tussen 2 deelnemers. Een voorbeeld hiervan is de beeldtelefoon. Een ander voorbeeld is het vergezeld laten gaan van beelden met teksten in verschillende talen of compound documenten die opgebouwd zijn uit tekst, images, spraak en/of videocomponenten; • Berichten diensten, de bekende store-and-forward dienst uitgebreid met bijvoorbeeld: video-mail, voice-mail of combinaties daarvan. • Retrieval diensten, deze voorzien de gebruiker in de mogelijkheid om gegevens te halen uit informatiecentra die geschikt zijn voor publiek gebruik. In de huidige beperkte vorm kennen we dit als videotex systemen. De B-ISDN dienst op dit gebied omvat daarnaast ook videobeelden, geluid, etc. 3.4.4. ATM (Asynchronous Transfer Mode) Het voordeel van pakketschakeling is dat je een verbinding kunt volstouwen met pakketten van verschillende afzenders die naar verschillende bestemmingen moeten. Op die manier biedt het een oplossing voor de behoefte aan flexibiliteit in bandbreedte en beschikbaarheid. Als het goed gebeurt dan worden verbindingen efficient. Het grootste probleem is dat de vertraging bij het verplaatsen van informatie vaak groot is, en variabel. Dit geeft problemen met stem-, beelden video-overdracht en wellicht nog bij andere vormen van informatie-overdracht waarbij synchronisatie vereist is. ATM is een hoge snelheid, pakketschakel techniek die gebruik maakt van pakketten met een vaste lengte die cellen worden genoemd. De keuze van kleine cellen met een vaste lengte reduceert de vertraging en de variatie in vertraging voor diensten zoals spraak en video die daar gevoelig voor zijn. ATM is dus een mechanisme dat een groot aantal diensten kan ondersteunen, zoals video, beeld en diverse klassen van dataverkeer. Het is geschikt voor zowel WAN's als voor LAN's en voor applicaties in een networking-omgeving. © MD-TI/RIZA-IO

Pagina 12


3.4.5. Internetworking of networkcomputing De gebruiker heeft steeds meer behoefte om toegang te krijgen tot bronnen buiten het eigen netwerk. Omdat netwerken die daarvoor in aanmerking komen sterk kunnen verschillen, is het niet praktisch te veronderstellen om ze maar in 66n netwerk samen te voegen. Om diverse verschillende netwerken zodanig met elkaar te verbinden, dat twee stations in willekeurige netwerken met elkaar kunnen commu-niceren, zijn faciliteiten nodig. De totale configuratie van dergelijke netwerken heet ook wel internet en elk van de onderliggende netwerken wordt subnetwerk genoemd. De volgende scenario's zijn denkbaar bij internetworking: LAN-LAN, LAN-WAN, WAN-WAN en LAN-WAN-LAN.

© MD-TI/RIZA-IO

Pagina 13


3.5.

MARKTONTWIKKELINGEN

3.5.1. Netwerkcomputing Trends, Technologie en Taktiek Netwerkcomputing (NC) is voor veel applicaties het uitgangspunt geworden, een voorbeeld hiervan is client/server computing. Voor ontwerp en gebruik van deze applicaties is ook een netwerkcomputing infrastructuur vereist. NC is meer dan alleen een uniform netwerk met gestandaardiseerde protocollen. Het probleem is het oplossen van de moeilijkheden die voortkomen uit gescheiden lokale netwerken, om op die manier universele dienstverlening en toegang tot applicaties te creeren. In onderstaande Figuur zijn de verschillende toepassingsmogelijkheden van het netwerk geschetst.

gedistribueerde ue

data management

applicatie

presentatie

prcseniane

prcseniane

applicatie

prcseniane

applicatie

presenlalie

Gedistribueerdc database Dit is nu nog niet mogelijk

gewone terminal loepassing

clienl/server toepassing client/server toep. waarbij twee toepass.

waarbij de applicatie en dataopslag op aparte computers stun

met elkaar communiceren X-terminal

Figuur 3.5

In deze Figuur zijn een drietal vormen van client/server toepassingen te zien. De tweede van rechts geeft een variant waarbij de applicatie gescheiden is van de dataopslag. Communicatie tussen deze twee loopt via het netwerk. Bij de middelste wordt het netwerk gebruikt voor de communicatie tussen twee applicaties. Een standaard die voor deze communicatie sterk in opkomst is is de RPC (Remote Procedure Call). De RPC maakt onderdeel uit van de OSF/DCE (Open Software Foundation/Distributed Computer Environment) industriestandaard. OSF is een organisatie van een groot aantal leveranciers met als doel © MD-TI/RIZA-IO

Pagina 14


het creeren van een software infrastructuur die niet leveranciersgebonden is. Een software infrastructuur omvat zowel hardware als programmeerhulpmiddelen die nodig zijn om programma's te kunnen ontwikkelen en draaien. Dus programma's die voldoen aan de OSF standaards zijn overdraagbaar tussen platforms van leveranciers die ook voldoen aan de OSF standaards. DCE biedt een neutraal platform voor het ondersteunen van gedistribueerde applicaties. Gedistribueerd wil hier zeggen een toepassingen die opgedeeld wordt over meerdere computersys-temen die ook geografisch verspreid kunnen staan en onderling informatie uitwisselen, client/server toepassingen zijn daar een voorbeeld van. Een van de belangrijkste onderdelen van DCE is de RPC. De mogelijkheid die helemaal rechts staat is op dit moment nog geen realiteit. Gedistribueerde databases zijn theoretisch wel mogelijk maar de praktische implementatie levert nog veel problemen op. Applicaties, gebaseerd op RPC's (Remote Procedure Call) vragen gedurende korte tijden, voor de dataoverdracht, een grote bandbreedte (maatgevend voor de capaciteit van een verbinding) van het netwerk. Het verkeer op het netwerk is minder frequent maar intensiever. Om deze reden kunnen huurlijnen (PTT-lijnen die een vaste verbinding vormen tussen twee lokaties) met de daaraan gekoppelde starre tariefstructuur te duur worden voor verbindingen t.b.v. applicaties gebaseerd op RPC's. De enige methode voor het optimaliseren van het gebruik van digitale huurlijnen is het multiplexen van andere protocollen tussen RPC-transporten. Het enige bestaande protocol met het nodige volume om deze gaten op te vullen is spraak. Nog beter is het echter om bij WAN-verkeer bandbreedte op aanvraag te beschikking te stellen. Gebruikers kunnen zelf aangeven hoeveel bandbreedte op welk moment ze nodig hebben. NC is niet alleen een technologie, maar ook een business trend. De drijvende kracht achter NC is een verbeterde communicatie in de organisatie tussen personeel, klanten, leveranciers en andere partners, gebaseerd op een vemieuwde netwerk-infrastructuur. De verwachting is dat toepassing van multimedia en client/server niet direct tot performanceproblemen op de LAN's zal leiden. De bottlenecks treden eerder op bij harddisk-access en WAN elementen (lijncapaciteit, gebruikte protocollen, gebruikte apparatuur, etc.), dan op het LAN. Daarnaast zal ook, indien de juiste compressietechnieken worden toegepast (JPEG, MPEG, H.261), het imagetransport weinig invloed hebben op de vereiste bandbreedte. Video, audio en image zullen standaard datatypen worden in de Netwerk Computing omgeving. De toenemende belangstelling van de Industrie voor client/server applicatie architectuur leidt lot een toenemende vraag naar veel geavanceerdere netwerken. De introductie van open client/server applicaties confronteert de netwerken met de volgende veranderingen: • Een continue reductie van het terminal protocol op backbone netwerken; © MD-TI/RIZA-IO

Pagina 15

Datacommunicatie t.b.v. DONAR/WVO/AQUABEL

• een continue toename van RPC en later, image protocollen (protocollen die gebruikt worden voor het overdragen van beelden) op backbone netwerken; • Een toename van zgn. secondary protocollen (die geen verband houden met gebruikers applicaties, bijvoorbeeld management protocollen); • servers kunnen overal in het netwerk geplaatst worden; • geavanceerde servers verlenen diensten aan iedere geauthoriseerde gebruiker in het netwerk; • netwerken moeten verbindingen ondersteunen van iedere client naar iedere server daarbij niet gehindert door topologie beperkingen; De komende vijf jaar zal de rol van netwerken veranderen van interconnectivity naar interoperability. De volgende generatie computerverwerking vraagt om een nieuwe, zeer betrouwbare, zeer flexibele, hoge snelheid spraak- video- en data backbone netwerkinfrastructuur Backbone netwerken van de 90'er jaren worden geconfronteerd met een groter aantal protocoltypen. Client/server architecturen, beeldtransport en computercomputer communicatie vereisen naast significant meer bandbreedte ook lagere reponsetijden dan de huidige netwerken. Aan de andere kant zal het lijngebruik van de meeste moderne communicatieprotocollen afnemen. In onderstaande Figuur zijn van verschillende toepassingen de bandbreedte eisen vermeld. Applicatie

Tradiuonele Bandbreedte eisen

Video

Extreem hoog

Multimedia

Extreem hoog

Image

Zeer hoog

Interactief

Hoog

Client/server

Hoog

Bestandsoverdracht

Laag tot middel

Figuur 3.6

Een aantal componenten zal invloed hebben op de eisen van capaciteit/bandbreedte voor de komende drie tot vijf jaar. Sommige zullen een positief effect hebben (zoals vorderingen in compressie), terwijl anderen een negatief effect hebben (zoals aanvullende opslag eisen op de servers over het netwerk). Het wereldomvattende, media onafhankelijke, hoge snelheid ATM/B-ISDN is mogelijk op lange termijn een strategische oplossing voor het bandbreedte probleem. Multimedia WAN infrastructuren die gebaseerd zijn op nieuwe compressiestandaarden en geavanceerde netwerktechnologie vragen om een andere aanpak ' MD-TI/RIZA-IO

Pagina 16


bij het ontwerpen. Traditionele capaciteitsplanning is vaak gebaseerd op de aanname dat men diensten op voorhand kan voorspellen, als van bepaalde verkeerstypen en bestandsomvang uitgegaan wordt. Andere netwerkeisen, gebaseerd op nieuwe applicaties, betekenen dat deze methode niet meer toereikend is. Met de te verwachten komst van networkcomputing zullen responsetijden steeds moeilijker te garanderen zijn als gevolg van het feit, dat data bestemd is voor, of gevraagd wordt uit, verschillende gedistribueerde databases en servers. 3.5.2. Netwerk Architecturen Desktop multimedia wordt voor de huidige applicaties al realiteit en dit zal nog verder toenemen. Een aantal organisaties willen toegang tot multimedia applicaties vanaf gedistribueerde servers. Om dit mogelijk te maken moet de planning van bandbreedte en capaciteit nu al plaats vinden . Gebruikers moeten bedenken, dat hoewel multimedia in zijn meest uitgebreide vorm een combinatie is van spraak, data, beeld, tekst, graphics en video (VIVID Video Voice Image Data), slechts 2 van deze vormen samen al multimedia is. De meeste, zoniet alle, huidige applicaties die draaien gebruiken multimedia in een minimale vorm en slechts een paar daarvan vragen toegang via een WAN. Dit zal echter de komende 2 a" 3 jaar sterk veranderen waardoor beslissingen over de netwerkinfrastructuur zeer kritisch zullen worden. Gekoppelde LAN's (virtueleLAN's) Veel gebruikers staan voor een dilemma bij het opzetten van organisatiebrede netwerken gebaseerd op bestaande LAN-technologie, maar zich daarbij ook willen richten op toekomstige netwerkontwikkelingen. Pakketgeschakelde virtuele LAN's voorzien in een geleidelijke evolutie en vormen voor velen een levensvatbaar migratiepad richting toekomstige, hoge snelheid, ATM geschakelde netwerken. Het concept van een virtueel LAN is dat netwerkbeheerders hun gekoppelde LAN's dynamisch vanuit een centraal punt kunnen configureren, onafhankelijk van fysieke hubs (zie Figuur 2.2), geografische lokatie, bedrading of netwerkkaarten. Op deze wijze zijn ook pakket-geschakelde LAN's geschikt voor video en andere multimedia toepassingen. Virtuele LAN's op basis van schakelende hubs vormen de logische stap naar "ATM-achtige" voordelen.

© MD-TI/RIZA-IO

Pagina 17


Two twisted pair

HHUB

Station

Two twisted Transmit

IHUB

IHUB

ztn

Station

Station

Station

Station

Receive HHUB=Header hub IHUB= Intermediate hub

Figuur 3.7 Toelichting Figuur 2.7 Met behulp van hubs kan een LAN opgedeeld worden in segmenten. Stations, bijvoorbeeld pc's, van een afdeling kunnen logisch in een segment ingedeeld worden, bijvoorbeeld de DONAR clients en server. Alle dataverkeer van DONAR komt niet verder dan dat betreffende segment. De stations kunnen tegelijkertijd berichten zenden en ontvangen, wat in een LAN zonder hubs niet mogelijk is. Tussen de hubs, in de rechtse Figuur, ligt bijvoorbeeld een glasvezel backbone netwerk. Op deze wijze kan het netwerk van een organisatie effectief opgezet worden, wat met name in client/server omgevingen voordelen biedt.

De verschillen tussen LAN en WAN communicatie is aan het verdwijnen en er treedt een verschuiving op richting intelligente netwerken. Deze verschuiving wordt primair gestuurd door de vraag naar functionaliteiten die zowel in het LAN als in het WAN zitten. LAN-omgevingen bieden snelle responsetijden en directe toegang tot data, en WAN's hebben talrijke mogelijkheden zoals: ondersteuning van multivendor verkeer, uitgebreid netwerk management, mixed media ondersteuning, vaste bandbreedte en bandbreedte op aanvraag, alternatieve routering, load balancing (evenwichtige verdeling van de belasting over de totale capaciteit) en flexibele controle op de data flow (bijvoorbeeld varierend van geen tot totale foutcontrole en herstel). Er is vandaag de dag een kloof tussen hoe het netwerk werkt en waar de organisatie en gebruikers behoefte aan hebben. De communicatie infrastructuur moet onafhankelijk werken van systeemtypen of lokatie. Als het LAN en WAN naar elkaar groeien wordt de invloed van applicaties op netwerken groter en kunnen traditionele LAN applicaties, zoals lokale databases, X-Window systemen, netwerk file systemen en multimedia applicaties, op een economische manier gebruik maken van hoge snelheid WAN-verbindingen. LAN-MANAGEMENT: CENTRAAL VERSUS DECENTRAAL

Netwerken worden steeds complexer en bedrijfs-kritischer. Er is een tendens om het beheer (PC- en/of LAN-beheer) niet meer "verborgen" bij gebruikers te leggen. Hun eigenlijke werk wordt gereduceerd door het steeds oplossen van desktop- en LAN-problemen. Er is ook een economische reden om het PC-beheer en LAN-management door een centrale afdeling te laten verzorgen, dus geen decentraal beheer meer op de afdelingen. De verhouding van het aantal werk© MD-TI/RIZA-IO

Pagina 18


stations tot full-time PC- en LAN-ondersteuning kan met een factor drie verbeteren van ongeveer 50 PC's tot 1 "afdelingsbeheerder" naar 150 tot 1, door de ondersteuning centraal te regelen. Efficientere inzet van personeel kan verkregen worden door een klein aantal deskundige support medewerkers op centraal niveau in plaats van een groter aantal LAN- en PC-beheerders op afdelings of werkgroep niveau. Centralisatie is echter niet altijd mogelijk en wordt bepaald door drie factoren: applicatie diversiteit, graad van technische standaardisatie en de beschikbaarheid van management hulpmiddelen. 3.5.3. IT-Management De traditionele manier van denken over hoe ieder informatiesysteem geimplementeerd moet worden is aan het verouderen. Nieuwe applicaties moeten passen in een groter IT-raamwerk dat gebaseerd is op netwerkcomputing. De organisaties moeten daarvoor een infrastructuur creeren die client/server gebaseerde applicaties ondersteunt. Bij veel organisaties wordt nog teveel gedacht in termen van applicaties of CASE-tools en methodes of men begrijpt de nieuwe technologic niet en staat onder druk om de kosten te bewaken of de uitgaven aan IT te beperken. De gevolgen hiervan zijn, dat organisaties niet meer het vermogen hebben om nieuwe ontwikkelingen te exploiteren en/of afhankelijk worden van 66n leverancier, problemen hebben met beheer, onvoldoende gebruik maken van de verwerkingscapaciteit en niet in staat zijn een goede eindgebruiker verwerking te ondersteunen. Het denken in infrastructuur en ontwikkeling vormen natuurlijk niet de volledige oplossing van de problemen. De meeste organisaties hebben, voor de ondersteuning van persoonlijke applicaties, traditionele file server LAN's gecreeerd, gebaseerd op populaire netwerk operating systemen, zoals Lanmanager en Netware. In toenemende mate worden dit soort netwerken ook gebruikt voor client/server toepassingen. Netwerk Operating Systemen (NOS) voorzien echter niet in alle ondersteuningsmogelijkheden voor complexe applicaties die vragen om beveiliging, tijd synchronisatie of transparante object-lokatie (ongeacht de plaats van het object in het netwerk) diensten. Dit mag wel verwacht worden van toekomstige NOSreleases of algemeen toepasbare operating systemen. 3.5.4. Management van Networking Systems De meeste gebruikers zijn gei'nteresseerd in de voordelen van netwerkcomputing, bijvoorbeeld de aanzienlijke kostenbesparingen voor de organisatie, de mogelijkheid tot bei'nvloeding van de huidige investeringen in pc's, levering van waardevolle diensten (applicaties) aan gebruikers en verbeterde produktiviteit. Echter, er zijn ook obstakels bij de uitvoering van netwerkcomputing. Een van de meest geciteerde barrieres betreft de grote personeelsinzet bij implementatie en de omvangrijke onderhoudskosten rond managementcontrole en inzichtelijkheid. Het wordt duidelijk, dat de huidige hulpmiddelen voor netwerkmanagement en systeemmanagement niet ingericht zijn voor het managen van gedistribueerde processen of client/server omgevingen; en een nieuwe geintegreerde benadering is noodzakelijk om migratie naar nieuwe modellen op grote schaal mogelijk te maken. © MD-TI/RIZA-IO

Pagina 19

D a t a c o m m u n i c a t i e t.b.v. DONAR/WVO/AgUABEL v

De IT industrie wordt gestuurd vanuit diverse richtingen. Netwerk systeemmanagement standaards verschijnen te langzaam en technologieen groeien snel. Twee van de standaards die nu gepromoted worden zijn het Simple Network Management Protocol (SNMP), een makkelijk protocol aan de basis, dat van origine alleen netwerkmanagement beschouwd en nu verbeterd is om mee te spelen in de systeemmanagement arena. Aan de andere kant van het spectrum is er de Distributed Management Environment (DME) van OSF. DME wordt door de industrie gezien als het beste referentiemodel voor netwerk systems management. DME richt zich op de grootste tekortkoming van open systemen, namelijk het gebrek aan uitgebreide netwerk systeemmanagement tools. Ook de OSI standaards (CMIS/CMIP) zullen een belangrijke rol spelen bij het managen van een gedistribueerde omgeving. Het SNMP wordt feitelijk ondersteund door alle netwerken systeem leveranciers. HP's Open View en Sun's SunNet Manager zijn twee voorbeelden van goed geimplementeerde SNMP managers. SNMP en SNMP-2 bieden beveiliging, bulk data transport, manager-to-manager verbinding, additionele protocol functionaliteit en verbeterde transport ondersteuning. De verwachting is dat gebruikers pas begin 1994 produkten gebaseerd op SNMP-2 kunnen implementeren. Om te voorkomen dat iedere ontwikkelaar opnieuw het wiel uitvindt, hebben management integratie platformen een verzameling van basis diensten die door alle management applicaties gebruikt kunnen worden. Vaak betekent technische ondersteuning verplaatsen van personeel naar een lokatie om de problemen in de lokale omgeving op te lossen. Als LAN's overwegend in het hoofdkwartier van de organisatie of centrale organisatie lokaties aanwezig zijn werkt deze aanpak wel. Maar steeds meer worden systemen gedistribueerd/geinstalleerd in gei'soleerde lokaties en creeren op deze wijze nieuwe uitdagingen voor technische supportteams. De sleutel-componenten voor een oplossing zijn dan remote monitoring mogelijkheden. Bij de keuze van netwerkmanagement systemen moeten gebruikers de voorkeur geven aan geintereerde produkten en speciaal die met elektronische software distributie mogelijkheden. 3.5.5. Publieke Telecommunicatie De scheidingslijn tussen publiek en privaat, tussen spraak en data, tussen telecommunicatie en verwerking, tussen draad en draadloos, en tussen geschakeling en transmissie is nu niet meer relevant. Het aandachtspunt is nu bandbreedte op aanvraag tussen 'n gebruiker en elke andere gebruiker. Frame relay , fast packet en X.25 Ofschoon de termen Frame Relay (FR) en fast packet door elkaar worden gebruikt zijn ze toch verschillend. FR is een pakket schakel technologic Het is de naam van een toegangsmethode die gebruikt wordt op de ISDN D-kanalen. Vergeleken met z'n functionele voorganger X.25, reduceert FR de netwerk proces tijd door de flow controle en hertransmissie functies aan de eindsystemen over te © MD-TI/RIZA-IO

Pagina 2 0

Datacommunicatie t.b.v. DO NAR/WVO/AQUABEL

laten. Hierdoor voorziet FR in een grotere bandbreedte dan X.25. 3.5.6. Samenvatting • Tegen het einde van 1993 zullen VIVID applicaties verschijnen die niet door de bestaande netwerk infrastructuren ondersteund kunnen worden. Gebruikers worden gedwongen om tactische, tussenoplossingen te gebruiken. • Invloeden van applicaties op bandbreedte moeten opnieuw bekeken worden. • Client/server architectuur leidt tot een toenemende vraag naar meer geavanceerde netwerken. • De nieuwe generatie van computerverwerking vraagt om een nieuwe, zeer betrouwbare, flexibele, snelle spraak, video en data backbone infrastructuur. • Toenemende diversiteit dwingt gebruikers en leveranciers tot integratie van verschillende netwerkarchitecturen.

© MD-TI/RIZA-IO

Pagina 21

Datacommunicatie t.b.v. POWAR/WVO/AQUABEL

4.

ONTWIKKELINGEN BINNEN DE DIVERSE PROJECTEN.

Dit hoofdstuk schetst de ontwikkelingen binnen de drie projecten. Na een korte inleiding over ieder projekt wordt de stand van zaken m.b.t. de bouw van het informatiesysteem weergegeven. Hierna komt de datacommunicatie aan bod en de relatie hiervan met het netwerk binnen RIZA. Om de diverse oplossingen beter inzichtelijk te maken, is e.e.a. in een Figuur weergegeven. In deze Figuur is het LAN van RIZA, het LAN van ICIM alsmede de verbinding daartussen via RWSNET weergegeven. Verder zijn aan de RIZAkant een HP9000 en een PC opgenomen, aan de ICIM-kant alleen een HP9000. Per project wordt dan het informatiesysteem ingetekend en de mogelijke opties weergegeven. 4.1.

Project DONAR.

4.1.1. Inleiding. De ontwikkeling van DONAR is ooit gestart ter vervanging van een aantal bestaande informatiesystemen die sterk waren verouderd en niet meer aan de huidige gebruikerswensen voldeden. Het gaat hier om de systemen DTBEST en JARKUS. Tevens zou DONAR een deel van de functionaliteit gaan bevatten die op dat moment door toenmalige applicaties werden geboden. Door RIZA en DGW is in een later stadium besloten om DONAR te laten dienen als opslagsysteem voor alle natte Rijkswaterstaat gegevens. Dit werd mede veroorzaakt door de behoefte aan integraal waterbeheer binnen de RWS. Daarnaast zou DONAR geen functionaliteit meer gaan bieden voor het uitvoeren van nabewerkingen op de gegevens. Dit houdt in dat DONAR dus gezien moet worden als een archief-systeem, waarbij bewerkingen op gegevens door andere applicaties worden uitgevoerd. De versie van DONAR zoals hier beschreven is de centrale DONAR, die de gegevens gaat bevatten die landelijk van belang zijn. Daarnaast bestaat de mogelijkheid om bij een dienst of directie een decentrale DONAR te installeren. Hierin kunnen dan de regionale gegevens worden opgeslagen. Een decentrale DONAR is qua database, programmatuur en procedures gelijk aan de centrale DONAR. In de verwerkingssfeer worden de applicaties DAVOS en ADONA/DAVOS ontwikkeld. DAVOS heeft tot doel algemeen toepasbare applicaties te leveren en ADONA/DAVOS de vak-specifieke applicaties. Op deze wijze is een totaalconcept ontstaan, waarin zowel de opslag van gegevens als de bewerkingsapplicaties een plaats kregen, het Overall systeemconcept (Zie [1] en [2]).

© MD-TI/RIZA-IO

Pagina 22


4.1.2. Stand van zaken m.b.t. de bouw. De centrale DONAR is opgeleverd. Op dit moment wordt er getest waarna er conversies plaats gaan vinden. Binnen RIZA wordt een decentrale DONAR geinstalleerd. Van DAVOS is het ontwerp inmiddels gereed en is met de technische uitwerking begonnen. DAVOS wordt gefaseerd opgeleverd waarbij het eerste onderdeel begin 1994 klaar is. Voor ADONA/DAVOS vindt op dit moment onderzoek plaats naar de functionaliteit van de vak-specifieke applicaties. Deze worden in verschillende deelprojekten verder uitgewerkt en in de loop van 1994 zullen de eerste vakspecifieke applicaties operationeel worden. Volgens de planning zal ADONA/DAVOS pas aan het eind van 1995 geheel gereed zijn. 4.13. Gekozen datacommunicatieoplossing. De gebruiker heeft de mogelijkheid om op verschillende manieren met DONAR te werken : 1. De gebruiker zoekt rechtstreeks via zijn PC contact met DONAR. Dit geldt zowel voor de centrale als de decentrale DONAR. 2. De gebruiker maakt gebruik van ADONA/DAVOS welke als schil om DONAR heen ligt. De datacommunicatie van alternatief 1 is vrij eenvoudig, terwijl die van de tweede mogelijkheid wat complexer van aard is. Beide mogelijkheden worden hierna beschreven.

© MD-TI/RIZA-IO

Pagina 23


- Gebruik van de centrale DONAR. REA

ICIM HP9000

DONAR

RWSNET

PC

VT220 Bmulatie

LAN RIZA

LAN ICIM

Figuur 4.1

De PC van de gebruiker is uitgerust met een terminal-emulatiepakket en is aangesloten op het LAN van RIZA. In het LAN is ook een terminalserver opgenomen, welke een koppeling heeft met het RWSNET/DCX (voorheen DINFRA). Via deze verbindingen kan de gebruiker met de centrale DONAR werken die bij ICIM is gei'nstalleerd. - Gebruik van de decentrale DONAR. RIZA

ICIM

UNIXcomputer

HP9000

DONAR

DONAR

RWSNET

PC

VT220 Emulatie

LAN

LAN

RIZA

ICIM

Figuur 4.2

De decentrale DONAR is in dit geval op een UNLX-computer bij RIZA geinstalleerd en is opgenomen in het LAN. De communicatie verloopt op nagenoeg dezelfde wijze als bij een centrale DONAR. Het enige verschil is dat nu rechtstreeks met de machine contact wordt gezocht, i.p.v. met de MD-TI/RIZA-IO

Pagina 2 4


terminalserver die een koppeling tot stand brengt met RWSNET/DCX. Bij gebruik van de decentrale DONAR vindt dus alleen communicatie via het LAN van RIZA plaats. De centrale DONAR blijft natuurlijk in alle gevallen toegankelijk, zoals beschreven in de vorige optie. - Gebruik van ADONA/DAVOS en de centrale DONAR. RIZA

ICIM

UNIXcomputer

HP9000

ADONA

DONAR

RWSNET

PC

X-Term. Emulatie

LAN RIZA

LAN ICIM

Figuur 4.3

ADONA/DAVOS zal binnenkort beschikbaar komen. ADONA/DAVOS ligt als schil om DONAR heen, en biedt de gebruiker de mogelijkheid gegevens op te halen uit DONAR, deze op te slaan in de database van ADONA/DAVOS en deze vervolgens te bewerken. ADONA/DAVOS heeft in tegenstelling tot DONAR, een Grafische User Interface, oftewel een GUI. Omdat ADONA/DAVOS een grafisch georienteerde applicatie is, dient de gebruiker te beschikken over een terminal met grafische mogelijkheden. Deze grafische terminal kan men ook op een PC emuleren, we spreken dan van Xterminal emulatie. Voor het gebruik van applicaties met een GUI is een zware PC vereist. Hierbij moet men denken aan minimaal een 386DX. Verdere specificaties staan in [1] op pagina 36. - Gebruik van ADONA/DAVOS en de decentrale DONAR. Deze mogelijkheid komt grotendeels overeen met die hiervoor werd besproken. DONAR is nu beschikbaar binnen het LAN van RIZA. De gegevens die van DONAR getransporteerd worden naar ADONA/DAVOS, hoeven nu niet meer via de RWSNET verbinding.

© MD-TI/RIZA-IO

Pagina 2 5


REA

ICIM

UNIXcomputer

HP9O00

DONAR ADONA

DONAR

RWSNET

PC

X-Term. Emulatie

LAN REA

LAN ICIM

Figuur 4.4

Deze werkwijze heeft als gevolg dat er alleen bij het benaderen van de decentrale DONAR gebruik wordt gemaakt van de X.25 verbinding via het RWSNET. 4.2.

Project WVO/Infoplan.

4.2.1. Inleiding. Rijkswaterstaat is belast met het uitvoeren van de Wet Verontreiniging Oppervlaktewateren (WVO). Deze wet dient ter bescherming van het oppervlaktewater. RIZA heeft als specialistische dienst een adviserende taak op het gebied van beleidsvoorbereiding en de uitvoering. WVO-Info is een geautomatiseerd informatiesysteem in ontwikkeling dat RWS ondersteuning en informatie gaat geven bij de uitvoering van de WVO. Deze ondersteuning vindt plaats op de volgende taakgebieden : -

Vergunningverlening. Handhaving. Specialistische ondersteuning. Managementinformatie.

WVO-Info geeft aan in welk stadium de vergunningverlening is, of er beroepsprocedures lopen en wat de vergunnings- of saneringseisen zijn. Bij inventarisaties kunnen opgeslagen jaarvrachten worden opgevraagd en kunnen op verschillende manieren dwarsdoorsneden worden gemaakt. 4.2.2. Stand van zaken m.b.t. de bouw. Op 31 december 1992 is het basisontwerp opgeleverd. Op dit moment wordt er gewerkt aan het detailontwerp. Dit zal gereed zijn eind September 1993. © MD-TI/RIZA-IO

Pagina 26


Op 1 februari 1994 wordt het systeem opgeleverd voor een acceptatietest welke duurt tot 1 april 1994 en 1 juli 1994 vindt de officiele oplevering plaats. In de tussenliggende periode wordt geconverteerd. 4.23. Gekozen datacommunicatieoplossing. Het rapport Locatiekeuze WVO-Info [5] beschrijft in hoofdstuk 3.2 een aantal varianten m.b.t. de keuze voor plaatsing van de mini-computer die voor WVOInfo gebruikt gaat worden. Op dit moment wordt de client-server benadering als beste keus gezien. Het server-deel van WVO-Info zal centraal worden gei'nstalleerd op een nog nader te bepalen lokatie (Wordt ongeveer gelijk aan de situatie met DONAR). Het client-deel wordt decentraal binnen RIZA geplaatst, op PC's van gebruikers.

REA

Facilitator HP9000 WVO SERVER

RWSNET

PC

WVO client

LAN REA

LAN ICIM

Figuur 4.5

Gezien de technologische ontwikkelingen, zoals geschetst in paragraaf 2.5, en de structuur van WVO lag het voor de hand om bij de opzet van WVO-info te kiezen voor een client/server opgeving. Daarnaast is ervoor gekozen om de gebruikersinterface grafisch te maken. Als derde uitgangspunt is gekozen voor Ingres als databasepakket en Ingres Windows/4GL als ontwikkelomgeving omdat dit de voorkeursprodukten zijn voor RWS. Binnen deze drie uitgangspunten zijn toen drie scenario's ontwikkeld, te weten: 1. Een centrale versie, hierbij staan data en programmatuur op een centrale computer. Gebruikers werken via terminals of terminal-emulatie en het RWSnet op die centrale machine. 2. Een decentrale versie waarbij iedere directie beschikt over een eigen lokale database en programmatuur. Ook hiervoor geldt weer dat gebruikers via terminals gebruik maken van de toepassing. 3. De derde variant betreft de client/server oplossing. Centraal de dataopslag (server) en decentraal de applicatie (client). Client en server zijn via het RWSnet gekoppeld. Bij deze mogelijkheid zijn nog een aantal sub-varianten © MD-TI/RIZA-IO

Pagina 27


te bedenken waarbij de applicatie, binnen een directie, op de pc van iedere gebruiker staat of op een centrale machine in het LAN. ad 1. Centrale versie. Bij dit alternatief is een grafische gebruikersinterface moeilijk te realiseren. Het is mogelijk om een VT420 terminal te emuleren op de pc maar dit is niet vergelijkbaar met een window-systeem. Tevens wordt daarbij de capaciteit van de pc onvoldoende benut. ad 2. Decentrale versie WVO is een applicatie die niet in iedere directie evenveel gebruikt wordt. Voor directies met slechts enkele gebruikers is het financieel niet aantrekkelijk om een speciale machine te kopen voor WVO. Alleen voor de grote directies deze opzet toepassen betekent een apart ontwikkeltraject volgen waarvan niet duidelijk is of dit voordelen met zich meebrengt. Dit zou alleen zin hebben als het netwerk de datastroom van de grote gebruikers niet kan verwerken. Op dit moment is daarvoor geen enkele indicatie. Meer Unixcomputers en meer programmeerwerk betekenen ook meer beheer en dus hogere kosten. ad 3. Client/server Dit alternatief wordt bij de bouw van informatiesystemen steeds meer gebruikt. Er kan een betere benutting bereikt worden van de aanwezige computercapaciteit. Eventuele uitbreidingen vergen over het algemeen lagere investeringen dan bij de andere twee alternatieven. Onderzoek op het gebied van lijnbelasting, beheer en investeringen hebben duidelijk gemaakt dat een client/server oplossing waarbij de applicatie op de pc van de gebruiker staat in dit geval de beste keuze is. Voordelen van de nu voorgestelde opzet zijn: a. goede benutting van de verwerkingscapaciteit van de pc; b. minder netwerkbelasting dan bij een terminal-computer (terminal-emulatie op de pc) verbinding; c. directe overdraagbaarheid van gegevens uit WVO in een spreadsheet op de pc; d. flexibele uitbreidingsmogelijkheden; e. softwarekosten van Windows/4GL zijn lager dan die van X-emulatie. Er is ook gekeken naar de mogelijkheid om in alternatief 3 voor de client een Unix platform te nemen. De applicatie draait decentraal op een minicomputer die opgenomen is in het lokale netwerk van een directie. De pc van de gebruiker wordt in dit geval gebruikt als terminal en het gebruik van een grafische userinterface impliceert dan X-emulatie. Er wordt dan gebruik gemaakt van het X-protocol in de LAN-omgeving en de client (Unix-platform) staat via het WAN (RWSnet) in verbinding met de database-server. Er kleven aan deze opzet een paar nadelen, te weten: a. het gebruik van het X-protocol brengt een grotere netwerkbelasting met zich mee waardoor er langere responsetijden bij de gebruiker ontstaan dan in de situatie waarbij de applicatie op de pc draait. De gehele window afhandeling gebeurt in dat geval geheel op de pc; © MD-TI/RIZA-IO

Pagina 28


b. er kunnen niet zonder meer gegevens uit de database overgehaald worden in bijvoorbeeld een spreadsheet die op de pc draait. Als de applicatie op de pc draait is dit veel eenvoudiger te realiseren, wat een van de wensen van de gebruikers is; C. een X-terminal emulatie op de pc kost ongeveer fl. 1000,-. De kosten van een runtime versie van Ingres Windows/4GL op de pc zijn +/- fl. 700,-; d. er wordt in deze oplossing nauwelijks gebruik gemaakt van de verwerkingscapaciteit van de pc, terwijl de opzet van het client/server concept juist is, het verdelen van de capaciteitsvraag over de aanwezige platforms; Het X-protocol maakt onderdeel uit van het X -Window systeem dat ontwikkeld is door Massachusetts Institute of Technology (MIT). Het X-Window systeem is ontworpen om gebruikers in staat te stellen gelijktijdig toegang te krijgen tot meerdere applicaties op meerdere computers in een netwerk waarbij iedere applicatie in een apart window op het scherm staat. De drie belangrijkste onderdelen van het X-Window systeem zijn de toolkit, de X-library en het Xprotocol. Met de toolkit kunnen o.a. windows gebouwd worden. De X-library is een verzameling van laag niveau hulpmiddelen voor het definieren en tekenen van windows en voor het informeren van applicatieprogramma's over toetsaanslagen of muisbewegingen. Het X-protocol verzorgtde communicatie tussen client en server. Schematisch ziet een en ander er als volgt uit:

Applicatie

Toolkit]

Library :XW>

Low-level: X netwerk protocol

Figuur 4.6

Men kan de zwaardere pc als nadeel zien bij de voorgestelde oplossing, maar zoals in hoofdstuk 2 al geschetst is zal het aantal toepassingen, gebaseerd op client/server en multimedia technieken alleen nog maar toenemen waardoor die extra capaciteit in de naaste toekomst hard nodig is. Daarbij komt dat de prijzen naar verwachting dit jaar nog verder zullen dalen. Bij aanschaf van pc's geldt op dit moment toch het advies om apparatuur te nemen op basis van Intel 486. De ontwikkelingen op dit gebied gaan zo hard dat het prijstechnisch niet interessant meer is om lichtere pc's te nemen. 4 3 . Project AQUABEL. 43.1. Inleiding. © MD-TI/RIZA-IO

Pagina 29


Het informatiesysteem AQUABEL wordt ontwikkeld om calamiteiten op de Nederlandse binnenwateren af te handelen. Het geeft een calamiteitenorganisatie ondersteuning bij het beslissen over maatregelen die moeten worden genomen bij calamiteiten. AQUABEL bevat verschillende bestanden zoals gegevens over chemicalien, adressen van betrokken instanties, gegevens over materiaal waarmee calamiteiten bestreden dan wel ingeperkt kunnen worden. AQUABEL genereert vragenlijsten die bij calamiteiten ingevuld dienen te worden. Meldformulieren kunnen electronisch of per fax aan belanghebbenden worden verzonden. Ook kunnen persberichten middels AQUABEL snel opgesteld worden. Het stappenplan dat in AQUABEL is opgenomen, ondersteunt de calamiteiten-functionaris bij de besluitvorming, zowel over de maatregelen die hij moet nemen om de calamiteit te bestrijden als over de instanties die hij moet waarschuwen. Een grafische presentatie biedt een actueel overzicht van de exacte locatie van de verontreiniging. Ook wordt informatie verschaft over de ligging van sluizen en stuwen, punten voor de inname van drinkwater en informatie over bevoegde personen en instanties in betrokken gemeenten. Alle informatie over een calamiteit wordt opgeslagen in een logboek, en kan AQUABEL een kostenberekening maken van de afhandeling van een calamiteit. 43.2. Stand van zaken m.b.t. de bouw. De functionaliteit van AQUABEL is in modules opgedeeld. Op dit moment is de meldingenmodule gereed en in gebruik bij Rijkswaterstaat Directie Noord Holland. In het vervolgtraject wordt AQUABEL in een aantal varianten opgeleverd. Het gaat hier om een minivariant, die naast de meldingenmodule een hoeveelheid toegevoegde functionaliteit heeft, een tussenvariant, en de realisatie van volledig AQUABEL. Bij iedere variant vindt ontwikkeling, testen, invoering en opstellen van documentatie plaats. De minivariant wordt in juli 1993 opgeleverd, de tussenvariant begin 1994 en halverwege 1994 dient AQABEL in z'n geheel gereed te zijn. 4 3 3 . Gekozen datacommunicatieoplossing. Bij AQUABEL heeft men gekozen voor een oplossing waarbij de data en applicatie op een centrale computer staan. Op dit moment is alleen de meldingenmodule gereed en operationeel. Deze applicatie is ondergebracht bij de Directie Noord-Holland, en draait daar op een HP9000 computer. Regionale directies kunnen via RWSNET verbinding zoeken met deze computer en vervolgens met deze module van AQUABEL werken. Binnen AQUABEL wordt geen gebruik gemaakt van client-server techniek of een grafische user-interface. De gekozen datacommunicatieoplossing lijkt derhalve sterk op die van de centrale DONAR die bij ICIM is geplaatst, en waarbij het merendeel van de gebruikers zich elders in het land bevinden : © MD-TI/RIZA-IO

Pagina 3 0


REA

ICIM HP9000

Aquabel

RWSNET

PC

VT220Emulatie

LAN REA

LAN ICIM

Figuur 4.7

De gebruiker heeft op zijn PC een terminal-emulatie-pakket, bijv. Smartterm en kan hiermee een VT220 terminal emuleren. De PC is aangesloten op het Ian binnen RIZA. In het LAN is ook een terminalserver opgenomen, welke een koppeling heeft met het RWSNET/DCX Via deze verbindingen kan de gebruiker, middels een seriele verbinding, met AQUABEL werken. 4.4.

Verschillen en overeenkomsten tussen DONAR, WVO en AQUABEL

Bij het gebruik van applicaties in een organisatie is het aan te bevelen om de gebruikersinterface zoveel mogelijk te standaardiseren zeker waar het gaat om nieuw te ontwikkelen applicaties. Bij WVO en ADONA/DAVOS is dat gebeurd, daar heeft men bewust voor een grafische gebruikersinterface gekozen. Bij AQUABEL en DONAR is dat niet het geval, daar is gekozen voor karakter georienteerde userinterface. Voor de dataopslag is bij WVO, DONAR en AQUABEL gekozen voor Ingres. Bij DONAR is er ook de mogelijkheid van decentrale opslag terwijl bij WVO geadviseerd wordt om alles centraal op te slaan. DONAR kent ook een veel groter datatransport dan WVO en het aantal verschillende gegevens is ook vele malen groter dan bij de andere twee systemen. Ook bij AQUABEL is gekozen voor fysiek een centrale databasemachine De opzet van DONAR en WVO vertoont enige overeenkomst. De database en verwerkingsprogrammatuur draaien op verschillende computers. Bij WVO is voor het client/server concept gekozen wat betekent dat er een directe communicatie is tussen programmatuur en database. Bij DONAR is gekozen om deze communicatie grotendeels via de DIF (Donar Interface File) te laten plaatsvinden. Gezien de grote hoeveelheid gegevens zou een directe communicatie de performance van de DONAR-database aanzienlijk vertragen. Bij AQUABEL zijn de gebruikers via terminal verbindingen met de database © MD-TI/RIZA-IO

Pagina 31

Datacommunicatie t.b.v. DONAR/WVQ/AQUABEL

verbonden. Applicatie en database draaien feitelijk op dezelfde machine. De keuze voor deze opzet is gemaakt in een tijd dat de ontwikkelhulpmiddelen en datacommunicatiefaciliteiten nog sterk in ontwikkeling waren.

© MD-TI/RIZA-IO

Pagina 32


5.

AFSTEMMING DATACOMMUNICATDE-FACILITEITEN T.B.V. DE DRIE PROJEKTEN.

Uit het vorige hoofdstuk, waarin van alle drie de informatiesystemensystemen de datacommunicatieoplossing werd geschetst, is gebleken dat er in technische zin geen problemen zijn om de verschillende informatiesystemen binnen RIZA te gaan gebruiken. - Gekozen datacommunicatieoplossing. Als we kijken naar de oplossingen die binnen de diverse informatiesystemen worden toegepast is het gebruik van Client/Server technieken het minst belastend voor het netwerk. Bij deze oplossing vindt alleen datatransport tussen client en server plaats. Dit transport is intensiever maar minder frequent dan de traditionele terminal-computer oplossing. Deze oplossing wordt toegepast bij WVO/Infoplan. Ook het gebruik van VT220 emulatie op de PC, zoals gebruikt bij AQUABEL en DONAR leveren geen onoverkomelijke problemen op. Bij ADONA/DAVOS vindt communicatie plaats op basis van X-emulatie. Dit betekent dat er hoge eisen gesteld worden aan de communicatieverbinding gezien de hoeveelheid informatie die over de lijn gaat. Dit betreft dan zowel data als protocol-informatie. - Aard van het informatiesysteem. De aard van het informatiesysteem is mede bepalend voor de netwerkbelasting. DONAR is veruit het systeem die de grootste hoeveelheden data opslaat en weer opvraagt, daarna komt WVO en dan AQUABEL. Het aantal gegevens bij DONAR is niet alleen groter ook de diversiteit aan gegevens is groter dan bij de andere twee systemen. AQUABEL is een informatiesysteem dat in mindere mate grote hoeveelheden gegevens zal opslaan. - Intensiteit waarmee de informatiesystemen worden gebruikt. Het aantal gebruikers van DONAR zal binnen RIZA ronde de vijftig ligggen, voor WVO/Info ligt het gebruikersaantal rond de dertig, AQUABEL beperkt zich tot ongeveer drie gebruikers. Van deze systemen zal AQUABEL het minst gebruikt worden, n.l. alleen in geval van calamiteiten. WVO/Info en DONAR worden frequenter gebruikt. De gebruikers die nu toegang hebben tot WIER, WORSRO en ISPO krijgen straks met deze systemen te maken.

© MD-TI/RIZA-IO

Pagina 33

Datacommunicatie t.b.v. DOWAR/WVO/AQUABEL

6.

HUIDIGE EN TOEKOMSTIGE DATACOMMUNICATBE-INFRASTRUCTUUR BINNEN

RIZA. Figuur 6.1 geeft de datacommunicatie-infrastructuur weer die op dit moment binnen RIZA aanwezig is. In 1989 en 1990 is een Ethernet-bekabeling aangelegd t.b.v. een dientsbreed LAN. In 1991 is gekozen voor LAN Manager onder OS/2 als het netwerkbesturingssysteem. Begin 1993 wordt dit LAN met een basis-functionaliteit operationeel voor ongeveer 50 gebruikers. Hiema vindt uitbreiding van het aantal gebruikers plaatst en zal ook de functionaliteit uitgebreid worden. In 1994 dient het geheel gereed te zijn. In het netwerk zijn 6 VAX-computers opgenomen, en een HP9000. Ook verschillende printers worden via het netwerk aangestuurd. De gebruikers hebben via verschillende systemen een koppeling met het LAN. Er zijn een aantal SUN-workstations aangesloten, ongeveer 50 PC's, dit aantal wordt zoals reeds hierboven omschreven, nog uitgebreid. Gebruikers kunnen via een emulatiepakket, waarvoor nog een keus gemaakt dient te worden, verbinding maken met de locale systemen zoals VAX en HP9000, of elders geplaatste systemen zoals bij ICIM. Dit laatste geschiedt dan via RWSNET (voorheen DINFRA). Ook kan de gebruiker hiervoor een terminal gebruiken, zoals aangegeven in het schema. Het netwerk wordt dus nog uitgebreid met een aantal voorzieningen, zoals een koppeling met het RWS-net, en een Modemverbinding. De modem-verbinding biedt de gelegenheid externe bronnen te bellen via een kieslijn, dan wel externe bronnen de gelegenheid te geven met het RIZA-net verbinding te zoeken. Bij de drie besproken systemen spelen externe verbindingen een grote rol. Nu kunnen de externe verbindingen op een aantal manieren gerealiseerd worden, m.b.v. huurlijnen of via een publiek of privaat WAN. Gebruikt men een huurlijn als verbinding dan gaat het om een punt-naar-punt verbinding waarop eigen protocollen gebruikt kunnen worden. Publieke netwerken zijn over het algemeen pakket geschakelde netwerken waarbij er tussen de knooppunten meerdere verbindingen mogelijk zijn. Voor het bepalen van de optimale verbinding worden apparaten gebruikt die men routers noemt. Routers zijn complexe apparaten die zorgen voor die routering van de data en dit heeft alleen zin als er meerdere routes mogelijk zijn. Er is een onderlinge informatie uitwisseling tussen routers volgens een van te voren afgesproken protocol. Er zijn diverse van dit soort protocollen en het is daarom belangrijk om daar hetzelfde protocol voor te gebruiken anders functioneert het netwerk niet. De routerfunctie kan in een apart apparaat ondergebracht worden maar zit standaard bijvoorbeeld ook in Unix omdat daar de TCP/IP-familie al standaard inzit. Beheer van routers kan beter door 6en organisatie plaatsvinden om te voorkomen dat er afstemmingsproblemen ontstaan met andere organisaties die misschien weer andere routers gebruiken met andere protocollen (zie ook het rapport ROUTER01). WAN-verbindingen zijn merendeels pakketgeschakelde netwerken. Terminalverkeer over dit soort netwerken is niet efficient omdat er per pakket maar een of in het beste geval een paar characters verstuurd worden. De overhead op een dergelijke verbinding is dan ook erg hoog, ongeveer 90 to 98 %. Toch heeft het © MD-TI/RIZA IO

Pagina 34

Datacommunicatie t.b.v. DO NAR / WVO/AgU ABEL

gebruik van een uniform protocol, zoals TCP/IP, op netwerken grote voordelen. Voordeel is dat voor gebruikers alle services die op het netwerk beschikbaar zijn toegankelijk zijn. Samengevat is de conclusie dat terminalverkeer (pc-emulatie of domme terminal) via terminalservers kan plaatsvinden die via een lokaal netwerk of via een WAN gekoppeld zijn. De koppeling van een WAN kan d.m.v. aparte routers in het WAN of via een Unix computer die zelfde routerfunctie uitvoert. Aparte routers hebben het voordeel dat het beheer, dat vrij complex is, door de leverancier van de WAN-functie kan gebeuren terwijl dit bij de Unix variant door de organisatie zelf moet plaatsvinden met het risico van afstemmingsproblemen. Alle communicatie op basis van TCP/IP heeft als nadeel dat het terminalverkeer veel overhead genereert maar wel eenvoudig in beheer is omdat het aantal protocollen zeer beperkt is. Dit laatste is overigens alleen mogelijk indien er geen domme terminals meer gebruikt worden maar uitsluitend pc's, werkstations of X-terminals.

© MD-TI/RIZA-IO

Pagina 35


OVERZICHT DATACOMMUNICATIE-INFRASTRUCTUUR RIZA-LELYSTAD FEBRUARI 1993

•urn •

PCliMl

• n u M i mdeM RgAtcBon V snamnn (KauB wortt nog gamajfeQ

• POOHTSClECTOfl

VAX (6) en HP9000

D«FB«DCX lAwnc )

D«FB».LAN

MMMagat))

"^ -t^

WftwtOS.

(TCP/1PI

DIAHNOUT

nm«„r.l

(ScrwrangirwdloTO)

-.laNHdraqmi-i

Tl^noonjuoleool : DECNET. NETBEUI. I C P * . LAT; Oa-PtaocO

ETWHHEI COAX-BUS

Figuur 6.1 © MB-TI/RIZA-IO

Pagina 3 6


7. CONCLUSffiS EN AANBEVELINGEN. 7.1.

Conclusies WVO-info Geadviseerd wordt om de variant te nemen waarbij er een centrale databaseserver is en de clients bestaan uit pc's waarop de applicatie draait. Als ontwikkelomgeving wordt Ingres Windows/4GL geadviseerd. Deze oplossing biedt de meeste perspectieven op het gebied van flexibiliteit, uitbreidbaarheid en functionaliteit. De client op een Unix-platform heeft als nadeel dat er, indien die overcapaciteit niet aanwezig, een aparte machine per directie aangeschaft moet worden. Bij de meeste directies is dit niet haalbaar omdat er te weinig gebruikers zijn. Een gescheiden oplossing waarbij directies met veel gebruikers een aparte decentrale database hebben en de andere directies van een centrale database gebruik maken betekent onnodige investeringen. De integriteit van de gegevens is zeer moeilijk te waarborgen en de beheersinspanning is veel groter. De conclusie hier is dat er t.a.v. de datacommunicatie-infrastructuur voor WVO er vooralsnog geen problemen te verwachten zijn. AQUABEL

Binnen dit projekt zijn een aantal zaken die zich uitzonderlijk goed lenen voor realisatie m.b.v. E-mail. Bij de oorspronkelijke opzet van dit systeem was dat nog niet mogelijk omdat de ontwikkelingen rond E-mail binnen de RWS nog niet zover waren. Geadviseerd wordt om binnen de huidige opzet van AQUABEL te bezien of alsnog een E-mail inpassingen mogelijk en haalbaar is. Voordeel is dan dat dit niet apart geprogrammeerd hoeft te worden en past binnen het CCI (Corporate Communications Infrastructure). Conclusie t.a.v. AQUABEL is dat de datacommunicatie geen problemen opleverd gezien de geringe belasting die deze toepassing met zich meebrengt. Gezien de ontwikkelingen is het jammer dat bij AQUABEL niet gekozen is voor een grafisch gebruikersinterface. DONAR/ADONA/DAVOS Probleem hier is dat deze projekten al in een vergevorderd stadium verkeerden toen het onderzoek naar de datacommunicatie-infrastructuur gestart werd. Bij DONAR is gekeken naar wat er mogelijk was binnen de huidige infrastructuur en op basis daarvan is gekozen voor communicatie op basis van terminal-emulatie. Bij de bouw van ADONA/DAVOS is aanvankelijk gedacht aan een client/server oplossing. Uiteindelijk heeft men gekozen voor communicatie op basis van Xemulatie. In technische zin past dit goed binnen de infrastructuur van RIZA. Men moet echter alert zijn op de netwerkbelasting die X-emulatie met zich meebrengt. RIZA-net Een client-server toepassing betekent nog niet veel voor de netwerk infrastructuur. Dit verandert zodra er meerdere van dit soort toepassingen © MD-TI/RIZA-IO

Pagina 37


operationeel worden. Gezien de sterke groei van client/server- en multimedia toepassingen moet nu al rekening gehouden worden met de opzet of aanpassing van de netwerkinfrastructuur. Geadviseerd wordt om het LAN volgens een sterstructuur op te zetten daarbij gebruik makend van hubs waardoor men dynamisch kan segmenteren en een veel betere controle heeft over de belasting van het gehele net. Deze opzet biedt in de toekomst de beste garanties om door te groeien naar hoge snelheid netwerken, zoals bijvoorbeeld ATM. Ook is een gesegmenteerd LAN beter te beheren omdat gebruikers logisch gegroepeerd kunnen worden in eenzelfde segment. Dit kan ongeacht de fysieke lokatie van deze gebruikers. Verhuizen van werkplek heeft geen consequenties voor bekabeling, vooropgesteld dat er op de nieuwe werkplek een aansluiting is. Ten aanzien van het beheer van het netwerk wordt geadviseerd om dit centraal te regelen. Netwerken worden dermate complex dat men op afdelingen al over zeer specialistische kennis moet beschikken om een goed beheer te kunnen uitvoeren. RWS-net Het RWS-net is een maasvormig netwerk en bestaat uit snelle verbindingen met hoge doorvoercapaciteit; op het aansluitpunt tot 256 kbps. Binnen het RWS-net wordt voor het versturen van data gebruik gemaakt van routering. Dit maakt het mogelijk om afzonderlijke data-eenheden (pakketten) via de meest gunstige route te sturen. De belasting wordt daardoor over de beschikbare lijnen verdeeld. Mocht de capaciteit dan nog niet voldoende zijn dan worden automatisch extra lijnen via het openbare PTT-netwerk IDN-1 (dit zijn digitale lijnen) bijgeschakeld zonder dat de gebruikers daar iets van merken. MD-TI is belast met het strategische beheer van dit RWS-net. Door intensief overleg met ICIM die het operationele en tactische beheer voert, wordt getracht om voortdurend nieuwe technologieen in te passen in dit RWS-net om zodoende gelijke tred te houden met de ontwikkelingen op het gebied van netwerktechnologie zonder het risico te lopen dat nu gebruikte technieken niet meer zouden functioneren. 7.2.

Aanbevelingen

- Geconstateerd wordt dat dit projekt in een relatief laat stadium gestart is waardoor er geen aanbevelingen meer gemaakt konden worden voor een aantal projekten die al liepen. Om soortgelijke problemen in de toekomst te voorkomen wordt aanbevolen om op korte termijn te werken aan een infrastructuurbeleid. Alle nieuwe projekten en produkten kunnen dan aan dit beleid getoetst worden ten einde afstemmings-problemen te voorkomen. Het hanteren van standaards kan daarbij een eerste aanzet vormen. - Er is nu onderzoek gedaan naar de technische infrastructuur van de drie projekten. Niet bekend is welke belasting de toepassingen daadwerkelijk met zich meebrengen. Aanbevolen wordt om een projekt te starten die deze belasting onderzoekt. Doel van het projekt is om te komen tot aanbevelingen voor de technische © MD-TI/RIZA-IO

Pagina 38


infrastructuur. Gezien de opzet van de beschreven toepassingen kan in een dergelijk projekt onderzocht worden welke belasting de gekozen oplossingen, te weten client/server, X-emulatie en terminalemulatie vormen voor de datacommunicatie-infrastructuur van RIZA.

© MD-TI/RIZA-IO

Pagina 39

8. Geraadpleegde literatuur. [1]

DONAR/ADONA/DAVOS/DAVOS Overall systeemconcept - Concept versie 0.7 - 30 november 1992

[2]

DONAR/ADONA/DA VOS/DA VOS en de informatievoorziening binnen het Waterbeheer -Concept versie 0.7 - 30 november 1992

[3]

WINMANOl/Userinterface services - TI 1990-578 - 20 September 1990

[4]

CLIENTOl/Bedrijfssysteem en communicatie services - TI 1992-1467 - 23 november 1992

[5]

Locatiekeuze WVO-Info - IP/User Guide - 29 december 1993

[6]

LAC (Local Area Communications) reports - Gartner Group

[7]

Vision deel 1 - Volmac

[8]

Clusterdocument Netwerkservices - MD-TI

[9]

LAN strategic maart 1993

[10] Telecommmagazine, PTT - februari 1993 [11] IEEE Communications Magazine - April 1992 [ 12] Data and Computer Communications - Stallings

Biblic Hu^i. S-v.p.! Aeer kopieeren. I papier. daarna NIETE>^IND^ DATACOMMUNICATIE T.B.V. DONAR, WVO-INFOPLAN EN AQUABEL BINNEN RIZA

Recommend Documents