FTP-siirtojen yleissuunnittelu ja organisointi osa 1 Jorma Kiiski, Manycom Software Oy

Transkriptio

1 FTP-siirtojen yleissuunnittelu ja organisointi osa 1 Jorma Kiiski, Manycom Software Oy Artikkelin kirjoittaja on ollut viimeiset kymmenen vuotta aktiivisesti mukana suunnittelemassa ja toteuttamassa FTP-väliohjelmistoja, jotka yhdessä IBM:n tarjoamien FTP-ohjelmistojen kanssa mahdollistavat FTP-siirtojen joustavan automatisoinnin ja hallinnan IBM OS/400- ja i5/oskäyttöjärjestelmäympäristöissä. Näitä ohjelmistoja käyttäen Manycom on toteuttanut FTPsiirtoympäristöjä (sekä FTP-asiakas- että palvelinratkaisuja) noin 60:lle yritykselle Suomessa ja ulkomailla. Artikkeliin on koottu tässä käytännön suunnittelu- ja toteutustyössä kertynyttä osaamista ja näkemystä siitä, miten FTP-siirtoympäristö tulisi suunnitella, organisoida ja toteutttaa. Johdanto FTP-tiedostosiirtoja käytetään usein PC-työasemien ja palvelinten välisessä liikenteessä, mutta FTP:n pääasiallinen käyttöalue on kuitenkin sovellus- ja muiden palvelinten välisessä tiedostojen siirrossa niin yritysten sisällä kuin yritysten välilläkin. FTP:stä onkin muodostunut sovellusintegroinnin yksi tärkeimmistä työkaluista, eikä sen asemaa näytä mikään horjuttavan tulevinakaan vuosina varsinkaan yritysten välisessä kommunikoinnissa, missä tosiaikaisen tiedonsiirron toteuttaminen ei aina ole tarpeen eikä järkevääkään. Järjestelmä- ja sovellusintegroinnissa on perimmältään kyse siitä, että integroitavista sovelluksista ainakin yksi käyttää toisen sovelluksen tuottamaa tulostustietoa ( yhteistä tietoa ) syöttötietona omien tulostustietojensa tuottamiseen. Tätä tarkoitusta varten sovelluksen on siis tavalla tai toisella päästävä käsiksi toisen sovelluksen tuottamaan tietoon. Jos yhteinen tieto on talletettuna tiedostojärjestelmässä, johon kummallakin sovelluksella on suoraan pääsy, ei kummankaan sovelluksen tarvitse integroinnin vuoksi käyttää mitään ns. tiedonsiirtopalvelua. Sovellukset voivat välittää toisilleen tietoa suoraan myös esim. ohjelmakutsun syöttö- ja paluuparametreissa. Tämä tilanne edellyttää käytännössä sitä, että sovellukset sijaitsevat samassa loogisessa (ja fyysisessä ) järjestelmässä. Jos näin ei ole, yhteisen tiedon tuottaneen sovelluksen (tai jonkin muun apusovelluksen) on käytettävä erityistä tiedonsiirto-ohjelmistoa ja palvelua siirtääkseen tiedon muistialueelle, johon toisella sovelluksella on pääsy, tai toisen sovelluksen on käytettävä erityistä tiedonsiirto-ohjelmistoa ja palvelua päästäkseen käsiksi sen oman muistialueen ulkopuolella sijaitsevaan, toisen sovelluksen tuottamaan yhteiseen tietoon. Tätä tilannetta havainnollistaa oheinen, lähinnä tiedostosiirtoihin pohjautuvaa integrointia esittävä kuva. Integrointialueella tarkoitetaan kuvassa niitä integroitavien sovellusten osia, jotka ovat mukana integroinnissa. Integrointialueseen kuuluvat osat on tässä merkitty sovelluksiin kuuluviksi. Käytännössä niitä voidaan myös tarkastella erillisinä, integrointiin osallistuvina apusovelluksina. 1

2 Kuva. Tiedostosiirtopohjaisen sovellusintegroinnin ympäristö. Yleisesti ottaen voidaan todeta, että sovellukset ja niiden tarjoamat tietopalvelut ja siten myös tiedonsiirto, tulisi toteuttaa tosiaikaisina aina, kun tarjottavan tietopalvelun tosiaikaisuudesta on selkeää etua. Aina, varsinkaan yritysten välisessä kommunikoinnissa, tätä etua ei ole, tai tosiaikaista tiedonsiirtoa ei ole muista syistä järkevää toteuttaa. Tällöin sovellusten välisessä tiedonsiirrossa käytetään ei-tosiaikaista siirtotapaa, useimmiten FTPtiedostosiirtoa, jolla tietoa voidaan siirtää sovelluksesta-sovellukseen eli tietokannasta tietokantaan, tai siirrossa voidaan käyttää jotain ei-yhteydellistä välivarastoivaa tiedonsiirtoa, kuten sähköpostia, jolloin tieto siirretään vastaanottajan postilaatikkoon (ei suoraan tietokantaan). Artikkelin rajaus Tässä artikkelissa keskitytään käsittelemään ei-tosiaikaisista kommunikointitavoista FTP-tiedostosiirtoa ja sen toteuttamista erityisesti IBM AS/400-, iseries- ja i5-ympäristöissä. Siirtoympäristön suunnittelua tarkastellaan erityisesti sovellusintegroinnin ja automatisoinnin näkökulmasta. Koska FTP-siirtojen teknisestä suunnittelusta on nykyisin jo varsin hyvin tietoa saatavilla IBM:n manuaaleista, Redbook:eista ja Info Center palvelusta (kts. lähdeviitteet-kappale jäljempänä), keskitytään tässä artikkelissa FTP-tekniikan sijasta käsittelemään FTP-siirtojen yleissuunnitteluun ja organisointiin liittyviä seikkoja ja problematiikkaa. Tästä aiheesta ei löydy tietoa em. IBM:n tietolähteistä, eikä aiheesta ole muutenkaan liiemmin kirjoitettu julkisuudessa. Koska moni suunnittelija on pohtinut, ja mahdollisesti edelleenkin pohtii sitä, pitäisikö tiedostoja siirtää FTP:llä vai sähköpostilla, vai molemmilla, on artikkelin myöhemmin julkaistavassa jatko-osassa lyhyt positionti myös tästä aiheesta. FTP-siirtojen yleinen toimintaympäristö Seuraavassa tarkastellaan FTP-siirtojen yleisimmän käyttöalueen, sovellusten välisen tiedostosiirron, ja sen toimintaympäristön yleistä rakennetta ja toiminnallisuutta. Sovellusten integroinnilla tarkoitetaan sovellusten suunnittelua ja toteuttamista niin, että ne yhteistoiminnassa tuottavat yhteisestä tiedosta halutut tietopalvelut. Sovellusintegrointi ja siten myös sen suunnittelu ja toteutus käsittävät kolme pääaluetta: tietomuunnokset, tiedonsiirto ja yhteinen hajautettu prosessointi. 2

3 Sovellusten yhteistoiminnallisuusvaatimus tuo suunnitteluun ja toteutukseen yksittäiseen sovellukseen verrattuna oleellisesti kovempia haasteita, koska integroitavat sovellukset ja niiden käyttöympäristöt jo yksinkin muodostavat yleensä mutkikkaan systeemin. Sovellusintegroinnissa onkin perimmältään kyse kahden tai useamman systeemin yhdistämisestä haluttujen toimintojen ja tarjottavien tietopalvelujen suhteen yhdeksi systeemiksi. Jokainen, joka on lukenut systeemiteoriaa tai ylipäätään tarkkaillut elävässä elämässä esiintyviä systeemejä, tietää, että mutkikas systeemi on paljon helpompi suunnitella, toteuttaa ja hallita, kun sen jakaa toiminnallisesti selkeisiin osasysteemeihin, määrittelee näiden välille selkeät toiminnalliset rajapinnat, ja lopuksi määrittelee kunkin osasysteemin ja myös koko systeemin tarjoamille palveluille halutut laatuvaatimukset. Kun tarkastellaan sovellusintegraatiota, ei sen merkitystä, että kokonaissysteemi suunnitellaan ja toteutetaan osasysteemeistä, joiden välille määritellään selkeät rajapinnat, voi aliarvioida. Itse asiassa, tämä on käytännössä ainoa tapa täyttää ne kovat laatuvaatimukset, joita sovellusintegroinnille nykyisin asetetaan. Näistä laatuvaatimuksista keskeisimpiä ovat: luotettavuus, turvallisuus, tehokkuus, helppokäyttöisyys, joustavuus muutoksille sekä poikkeustilanteiden helppo ja nopea hallinta. Edellä mainituista laatuvaatimuksista vaikeimmin toteutettavia ovat yleensä kaksi viimeksi mainittua. Sovellusintegroinnin tuloksena syntyvä systeemi on yleensä varsin pitkäikäinen, joten sen perusrakenteen on oltava kestävä. Kuitenkin sen oltava myös joustava ja kehtiyskelpoinen, jotta systeemiin tarvittavat muutokset ja lisäykset voidaan tulevina vuosina toteuttaa nopeasti ja edullisesti. Vaikka osasysteemien ja kokonaissysteemin sinänsä pitää olla joustavia ja uusiin tarpeisiin helposti mukautuvia, yhden asian tulee kuitenkin olla mahdollisimman pysyvä: olemassa olevien rajapintojen, erityisesti sovellus- ja poistumakohtarajapintojen, mutta myös loppukäyttäjille tarjottavien rajapintojen eli käyttöliittymän tulisi olla mahdollisimman pysyviä. Olemassa olevien sovellus- ja poistumakohtarajapintojen muutokset ovat aina riskialttiita, joskus työläitäkin, ja monesti lähes mahdottomia käytännössä toteuttaa varsinkin, jos muutos vaikuttaa myös yhteyskumppanin sovelluksiin ja käyttäjiin. Rajapintoihin tarvittavat muutokset joudutaankin usein toteuttamaan niin, että vanhat rajapinnat jäävät osittain käyttöön samalla kun kun niiden rinnalla otetaan käyttöön vaiheittain uusia rajapintoja. Kun liiketoiminnan rytmi kiihtyy, ja liikekumppanit, asiakkaat ja omankin organisaation muut yksiköt asettavat yhä tiukempia laatuvaatimuksia toiminnan luotettavuudelle ja nopeudelle, on poikkeustilanteiden hallinnan helppous ja nopeus tulleet entistä tärkeämmiksi. Kokonaissysteemin jakaminen erikseen hallittaviksi osasysteemeiksi antaa tässäkin asiassa parhaat edellytykset asetettujen laatuvaatimusten täyttämiseen. Tämä koskee erityisesti FTP-tiedonsiirtoa käyttäviä systeemejä, jotka ovat erityisesti heterogeenisissa ympäristöissä usein varsin kompleksisia, virhealttiita ja vaikeasti hallittavia. Kestäviä mutta joustavia ja kehityskelpoisia sekä helposti hallittavia ratkaisuja saadaan aikaan vain suunnitelmallisuudella ja kurinalaisella toteuttamisella. Vähänkään laajempia sovellusintegrointiratkaisuja varten pitäisikin määritellä integrointiarkkitehtuuri eli yleiset rakenne- ja suunnittelusäännöt, joihin toteutukset perustuvat. Tällaisen integrointiarkkitehtuurin yhtenä osana tulee olla kuvaus siitä, miten sovellusten välinen tiedonsiirto toteutetaan. Tiedonsiirtoa voidaan ja sitä tulisi tarkastella omana osasysteeminään ja määritellä sille tarvittaessa oma tiedonsiirtoarkkitehtuurinsa. Erityisen perusteltua tämä on silloin, kun tiedonsiirrossa käytetään laajasti FTP:tä. Monipuolisuutensa ja mutkikkuutensa ansiosta FTP ansaitsee ja vaatii hyvinkin oman tarkastelunsa. Onnistuneen kokonaisarkkitehtuurin kulmakiviä on se, että FTP-siirtosysteemin ja sitä hyödyntävien sovellusten välille muodostuvia ns. sovellus- ja poistumakohtarajapintoja tarkastelllaan palvelurajapintoina, ja että ne tällaisina myös suunnitellaan ja toteutetaan. Sovellusten ja FTP-siirtotysteemin välinen rajapinta muodostuu käytännössä useista teknisesti erillisistä rajapinnoista (API- ja poistumakohta-rajapinnoista), joiden kautta voidaan tehdä palvelupyyntöjä molempiin suuntiin. Toiminnan läpinäkyvyyden ja jäljitettävyyden kannalta on välttämätöntä, että palvelupyyntöön saadaan aina välitön vaste, joka kertoo itse pyynnön hyväksymisestä tai hylkäämisestä. Läpinäkyvyyden ja jäljitettävyyden kannalta on varsinkin automatisoitujen siirtojen osalta aivan välttämätöntä, että kaikki tapahtumat kirjoitetetaan lokiin. Jos oikein tarkkoja ollaan, niin palvelupyynnöt ja niiden vasteet pitäisi kirjata molempien osasysteemien lokiin. Luonnollisesti jokaisen palvelupyynnön prosessoinnin onnistuminen (prosessoinnin tilatiedot) tulee myös kirjata asianmukaiseen valvontahakemistoon tai lokiin. 3

4 Oheisessa kuvassa on esitetty malli siitä, miten kokonaissysteemi voidaan ja tulisi jakaa osasysteemeihin FTP-siirtoihin pohjautuvassa sovellusintegroinnissa. Tässä FTP-pohjaisessa mallissa on pyritty, kuten sovellusintegroinnissa yleensäkin tulisi pyrkiä, siihen, että kukin osasysteemi muodostaa selkeästi oman itsenäisen prosessointivaiheensa niin, että ongelmatilanteissa prosessia voidaan jatkaa keskeytyneen vaiheen alusta. Tällainen vaiherakenne joudutaan huomioimaan sekä osasysteemejä ja niiden rajapintoja että itse sovelluksia suunniteltaessa. Vaikka sovellusintegroinnin toteutus tällaisen vaihemallin mukaisesti vaatii vaivaa ja investointeja, se on aivan välttämätöntä, jos halutaan rakentaa toimiva eli luotettava, joustava ja mahdollisimman helposti hallittavissa oleva järjestelmä! Kuva. Sovellusintegroinnin yleinen vaihemalli, kun siirtokäytäntönä on FTP. Jos sovellukset muutetaan tuottamaan suoraan tietomuunnosten lähtötietona olevat integrointitiedostot, erillisiä integrointiohjelmia (osasysteemit 2 ja 9) ei tarvita. Aina ei myöskään tarvita erillisiä integrointitiedostoja eikä tietomuunnosohjelmia, jos sovellukset tuottavat suoraan valmiit siirtotiedostot. Yleisenä periaatteena kuitenkin tulee pitää sitä, että sovellustiedostoista tuotetaan aina erilliset siirtotiedostot, joita sovellukset eivät siirtohetkellä käytä. Siirto-ohjelmien ei pitäisi koskaan lähettää suoraan operatiivisia sovellustiedostoja, eivätkä siirto-ohjelmat saisi koskaan noutaa tai vastaanottaa suoraan dataa operatiivisiin sovellustiedostoihin. Edellä kuvattu malli toteuttaa ns. löyhästi kytkettyjen systeemien mallia. Se on viime vuosina saanut, eikä syyttä, entistä enemmän arvostusta osakseen varsinkin yritysten välisissä, heterogeenisissa sovellusintegrointiympäristöissä. Tiukasti kytketyt systeemit, esim. tietokanta-tietokanta-toteutukset ovat yksinkertaisesti liian jäykkiä nopeasti muuttuvissa, heterogeenisissa järjestelmäympäristöissä. Sitä, miten automatisoidussa prosessissa eri vaiheiden käynnistykset ja suoritusten kontrollointi voidaan ja tulisi hoitaa lähetys ja vastaanottopäässä, käsitellään tarkemmin artikkelin jatko-osassa. FTP-siirtojen yleissuunnittelua ja toteuttamista tarkastellaan jatkossa lähemmin edellä esitetyn vaihemallin pohjalta. Ennen sitä lienee kuitenkin paikallaan tuoda esille ne FTP-tekniikkaan liittyvät perusasiat, joilla on keskeitä merkitystä FTP-ympäristön yleissuunnittelussa. FTP-tekniikasta yleissuunnittelun kannalta - lyhyesti FTP on asiakas-palvelin (client-server) -tekniikkaan pohjautuva, TCP/IP-kuljetuspalvelua käyttävä, yhteydellinen, päästä-päähän kuittaava, luotettava siirtokäytäntö, joka on suunniteltu ja tarkoitettu myös heterogeenisessa ympäristössä tapahtuvaan tiedostojen siirtämiseen TCP/IP-verkkojen kautta. 4

5 FTP:n perus toiminnallisuuteen kuuluu FTP-asiakastilassa mahdollisuus lähettää tiedostoja FTP-palvelimelle ja noutaa tiedostoja FTP-palvelimelta. Vastaavasti, FTP-palvelintilassa voidaan vastaanottaa FTP-asiakkaan pyynnöstä tiedostoja FTP-asiakkaalta ja lähettää FTP-asiakkaan pyynnöstä tiedostoja FTP-asiakkaalle. FTP-asiakas ja FTP-palvelin ovat toisistaan täysin erillisiä toimintoja ja prosesseja. Sama järjestelmä pystyykin toimimaan samaan aikaan sekä FTP-asiakkaana että palvelimena. Kuten oheinen kuva havainnollistaa, kahden järjestelmän välillä voi samanaikaisesti olla menossa neljän tyyppisiä tiedostosiirtooperaatioita. Kuva. FTP-asiakas- ja FTP-palvelinprosessit ja siirtosuunnat. On syytä huomata, että FTP on alun pitäen suunniteltu ja tarkoitettu vain manuaalisesti operoitavaksi, eli inhimillisen FTP-käyttäjän operoimaksi olettaen, että tämä käyttäjä tarkistaa kunkin palvelimelle tehdyn pyynnön paluukoodin ja sanoman visuaalisesti näytöltä, ja että käyttäjä on älykäs ja hyvin koulutettu ja ohjeistettu, ja siten pystyy suoriutumaan lukuisista erilaisista potentiaalisista poikkeustilanteista. FTP:n suurin puute sovellusintegraation kannalta onkin se, että sitä ei ole varsinaisesti lainkaan suunniteltu automatisoidun tiedostosiirtoliikenteen tarpeita ajatellen. Se, että FTP-asiakas saa jokaiseen FTPpalvelimelle lähettämäänsä pyyntöön varsin hyvin standardoidun numeerisen vasteen, ei vielä läheskään riitä siihen, että FTP:n voitaisiin sanoa olevan suunniteltu siirtojen automatisointitarpeita ajatellen. Kun kuitenkaan parempaakaan standardoitua tiedostojen siirtotapaa, joka täyttäisi sovellusintegroinnin vaatimukset, ei ole käytettävissä, on tyytyminen FTP:hen. Onneksi FTP:ssä on kuitenkin ylipäätään riittävästi manuaalisia ominaisuuksia, joita taitavasti hyödyntäen ohjelmallinen automatisointi voidaan toteuttaa siten, että lopputulos on yleensä jopa yllättävän hyvä. Tästä on kiittäminen tietokonetta, joka jaksaa suorittaa tehtävänsä aina samalla tavalla ja väsymättä. Erityisesti on syytä huomata, että uudempi HTTP-pohjainen tiedostosiirtotekniikka tarjoaa, ainakin nykymuodossaan, FTP:täkin vähemmän ominaisuuksia automatisoidun, luotettavan siirtosysteemin toteuttamiseen sovellusten välillä. Näin ollen HTTP-tiedostosiirroista ei ole FTP:n kilpailijaksi tässä ympäristössä. Toisen merkittävän käytännön ongelman, joka tosin ei ole FTP:n aiheuttama, muodostaa heterogeeniset järjestelmäympäristöt ja niissä käytettävät erilaiset tiedostojärjestelmät erilaisine hakemistorakenteineen, tiedostomuotoineen, tiedon esitys- ja tallennusmuotoineen ja nimeämiskäytäntöineen. Yksin OS/400- ja i5/os-ftp-asiakas- ja palvelin ohjelmistot tukevat kumpikin kuutta eri tiedostojärjestelmää. Asiakas-palvelin konseptin mukaisesti, FTP-asiakas on se, joka aloittaa FTP-istunnon muodostamalla ns. FTP-ohjausyhteyden FTP-palvelimeen. Pakollisen tunnus/salasana-tunnistuksen jälkeen, FTP-asiakas voi lähettää minkä tahansa RFC-standardin mukaisen palvelupyynnön (palvelinalikomennon), esim. tiedoston noutopyynnön palvelimelle kyseistä ohjausyhteyttä käyttäen. Palvelin kuittaa jokaisen palvelupyynnön suorituksen ja onnistumisen 3-numeroisella vasteella ja tekstimuotoisella vastesanomalla. Palvelin ei koskaan muodosta ohjausyhteyttä asiakkaaseen tai tee sille palvelupyyntöjä. FTP:tä koskevissa RFC-standardeissa on tiedostojen siirtotoimintojen lisäksi FTP-konseptiin kuuluvina lisätoimintoina määritelty mm. etätiedostojen uudelleennimeäminen ja tuhoaminen, tiedostonimien listaus, 5

6 etäoletushakemiston vaihtaminen, sekä etäkomentojen eli palvelinjärjestelmän komentojen käynnistys. Lisäksi on määritelty joukko vähäisempiä aputoimintoja, kuten FTP-palvelimen tilan kysely, jne. Em. lisätoiminnoista ovat luonnollisesti mahdollisia vain ne, joita kyseiset FTP-asiakas- ja palvelinohjelmistot tukevat. Käytännössä lähes kaikki kaupalliset FTP-ohjelmistot, OS/400:n ja i5/os:n FTP-asiakas- ja palvelinohjelmistot mukaan lukien, tukevat em. lisätoimintojen käytön. FTP:n perustoiminnallisuuteen kuuluu lisäksi joukko eri siirtomoodeja ja tyyppejä. Tiedostokohtaisesti voidaan määrittää, että siirto tapahtuu merkkipohjaisesti siten, että tietuemuoto ja tietueen pituus säilyvät, tai siirto tapahtuu binäärisiirtona. Merkkipohjaisen siirron yhteydessä voidaan FTP-ohjelmiston toimesta suorittaa haluttu merkkikoodimuunnos, yleensä ASCII-EBCDIC- tai EBCDIC-EBCDIC-muunnos. Binäärisiirto on tarkoitettu lähinnä ei-tekstimuotoisen datan (ohjelmien tai muiden ns. nauhatiedostojen ) siirtämiseen, joskin sitä voi käyttää myös tekstimuotoisen datan siirtämiseen silloin, kun siirron aikana ei ole tarvetta suorittaa merkkikoodi- tai muitakaan konversioita. FTP-asiakkaan paikallisjärjestelmässä suorittamiin lisätoimintoihin ei RFC-standardeissa juurikaan oteta kantaa, mutta käytännön FTP-asiakastoteutuksissa myös OS/400- ja i5/os-ympäristössä on mm. mahdollisuus koska tahansa FTP-istunnon aikana vaihtaa paikallista työskentely- eli oletushakemistoa, listata paikallisia tiedostonimiä, kopioida ja tuhota tiedostoja, ja ajaa ylipäätään mitä tahansa CL-komentoja. Lähdeviitteitä FTP-siirtojen teknisestä toteutuksesta Seuraavat IBM:n tietolähteet tarjoavat varsin kattavan ohjeistuksen FTP-siirtoihin liittyvästä tekniikasta (pari tuhatta sivua yleistä TCP/IP-asiaa ja pari sataa sivua FTP-asiaa) kattaen sekä FTP-asiakas- että FTPpalvelintilassa tapahtuvan toiminnan: - IBM Info Center, TCP/IP Topics, - V5R3 - iseries Memorandum to Users, June 2004 Update - V5R3 - iseries FTP-rzaig, April V5R2 - TCP/IP Applications on the iseries Server-sg246321, May V5R1 - iseries e-business Handbook-sg , October V5 - iseries-tcp/ip Configuration and Reference-sc , May V4 - TCP/IP for AS400 - More Cool Things Than Ever-sg245190, March V4 - AS400e-TCP/IP Configuration and Reference-sc , May V3R2 - Cool Title About the AS/400 and Internet, Version 3R2, sg V3 OS/400 TCP/IP Configuration and Reference - TCP/IP Tutorial and Technical Overview-gg243376, August 2001 FTP-siirtojen yleissuunnittelu ja organisointi FTP-siirtojen yleissuunnittelulla ja organisoinnilla tarkoitetaan tässä siis FTP-siirtojen sovellus- ja poistumakohtaliitäntöjen ja itse siirtojen muuta kuin FTP-teknistä suunnittelua ja organisointia. Itse FTPtekniikkaa käsitellään tässä artikkelissa jatkossakin tilan puutteen vuoksi vain siltä osin, kuin se suoranaisesti liittyy siirtojen yleissuunnitteluun. Kuten minkä tahansa systeemin, FTP-siirtosysteeminkin arkkitehtuurisuunnittelu voidaan suorittaa seuraavasti: yleisen rakenteen, osasysteemien, rajapintojen ja toimintojen suunnittelu systeemin laatuvaatimusten suunnittelu FTP-siirtosysteemin suunnittelun tavoitteena tulee olla systeemi, joka asetetut laatuvaatimukset täyttäen pystyy tarjoamaan loppukäyttäjille ja sovelluksille niiden tarvitsemat FTP-siirto- ja muut oheistoiminnot ja - palvelut. FTP-siirtoympäristön rakenne ja toimintojen yleissuunnittelu Seuraavassa on kokonaiskuvan muodostamiseksi esitetty lista asioista, joita FTP-siirtoympäristön rakenteen ja toimintojen yleissuunnittelussa tulee ottaa huomioon aikaisemmin esitetyn lisäksi. Kutakin listalla olevaa asiaa käsitellään tarkemmin artikkelin myöhemmin julkaistavassa jatko-osassa. Yleissuunnitelussa huomioitavia asioita ovat mm: siirrot edustakoneen kautta vai suoraan sovelluspalvelimesta (-palvelimeen) 6

7 asiakaana vai palvelimena toimiminen, vai molemmat siirtojärjestelmän osasysteemit, rajapinnat, ja toimintojen vaiheistus FTP-asiakkaana toimittaessa siirtojärjestelmän osasysteemit, rajapinnat, ja toimintojen vaiheistus FTP-palvelimena toimittaessa sovellus- ja poistumakohtarajapintojen määrittely siirtohakemistojen organisointi, nimeäminen ja hallinta siirtotiedostojen organisointi, nimeäminen ja hallinta integrointi- ja siirtotiedostojen sisällön määrittäminen siirtomoodiin ja -tapaan liittyvät seikat ennen siirtoyhteyttä ja siirtoyhteyden jälkeen paikallis- ja etäjärjestelmässä suoritettavat toiminnot yksittäisen tiedoston siirtoon liittyvät, ennen ja jälkeen siirron paikallis- ja etäjärjestelmässä suoritettavat toiminnot manuaalisesti vs. automaattisesti suoritettavat toiminnot siirtojen ajastus ja priorisointi siirtopyyntöjen ja siirtotöiden sekä niiden tilatietojen seuranta ja hallinta käyttöliittymästä normaalitilanteissa poikkeustilanteiden hallinta, autonominen elvytys, automaattiset uudelleenyritykset, hälytykset lokitoiminnot levytilan hallinta FTP-siirtojärjestelmälle asetettavat laatuvaatimukset Kuten aikaisemmin jo todettiin, siirtojärjestelmän tärkeimmiksi ominaisuuksiksi, joihin laatuvaatimukset voidaan kohdistaa, ovat luotettavuuden ja turvallisuuden ohella nousseet hyvä vikasietoisuus sekä poikkeustilanteiden hallinnan helppous ja nopeus. FTP-siirtojärjestelmän ominaisuuksia, joihin laatuvaatimukset yleensä kohdistetaan, ovat mm. toimintavarmuus ja luotettavuus käytettävyys virheettömyys turvallisuus järjestelmän läpinäkyvyys ja tapahtumien jäljitettävyys suorituskyky ja siirtojen tehokkuus skaalautuvuus, kasvuvara tehokuus ja helppokäyttöisyys kaikkien käyttäjäryhmien, myös toimittajan kannalta liitettävyys yrityksen omin sovelluksiin ja muiden toimittajien ohjelmistoihin perusrakenteen kestävyys, käyttöliitymien sekä sovellus- ja poistumakohtarajapintojen pysyvyys kokoonpanon modulaarisuus ja muunneltavuus, uusien ominaisuuksien lisääminen ohjelmapäivitysten ja korjausten asentaminen, 24/7 käyttö Toimintojen suunnittelun ja laatuvaatimusten tarkempi käsittely jatkuu artikkelin jatko-osassa Commentin seuraavassa numerossa. 7