2.5 X-tee andmeteenuste arendamise sammud

2.5.1   Ärivajaduste väljaselgitamine

Etapi eesmärk on välja selgitada ärivajadused ning tõlkida need veebiteenuste nõueteks (omadused, funktsionaalsed ja mittefunktsionaalsed nõuded, kitsendused). Selles faasis peaks kaasama kõik osapooled (sh lõppkasutajaid).

Etapi tulemiks on nõuete spetsifikatsioonid.

2.5.2   Analüüsi ja disaini etapp

Selles etapis tuvastatakse sobivad olemasolevad andmeteenused, nende puudumisel määratakse kindlaks andmeteenuse tehnoloogiline platvorm, koostatakse loodava tarkvaralahenduse arhitektuurispetsifikatsioon ja kirjeldatakse detailselt ära loodavad X-tee andmeteenused, kusjuures andmeteenuste spetsifitseerimisel jälgitakse, et kirjeldatavad andmeteenused vastaksid SOA põhimõtetele (vt ka eelnevad peatükid):

  • korduvkasutatavus (andmeteenus on kirjeldatud selliselt, et soodustada selle korduvkasutust, seega andmeteenuse loogika on pigem universaalset laadi, mitte mingil viisil liiga eriline);
  • nõrk sidestus (andmeteenus ei sõltu mingist kindlast andmeteenuse kasutajast ja teistest andmeteenustest);
  • komponeeritavus (andmeteenuste loogika on jaotatud selliselt, et andmeteenuseid saaks kasutada erinevate suuremate ülesannete lahendamiseks, seega iga andmeteenus eraldi võiks lahendada lihtsama probleemi).

Teenuste identifitseerimisel ja kirjeldamisel võib olla kasulik kasutada ka X-tee mustrikataloogi (vt pt 2.5).

Luuakse andmeteenuse liideste detailne kirjeldus (sealhulgas, millised on elemendid ja andmetüübid) ja koostatakse ka XSD ja/või WSDL formaadis andmeteenuse liidese kirjeldused.

Etapi tulemid on tarkvara arhitektuuri ja andmeteenuste detailsed spetsifikatsioonid.

2.5.3   Arenduse etapp

Realiseeritakse eelmises etapis loodud spetsifikatsioonide põhjal tarkvaralahendus.

X-tee andmeteenuste arendamisel on võimalik kasutada erinevaid meetodeid:

2.5.3.1 Lähtekood -> WSDL  (Bottom Up)

Selle meetodi puhul:

  • luuakse kõigepealt andmeteenuse lähtekood;
  • seejärel genereeritakse lähtekoodist WSDL.

Mitmed tänapäevased arenduskeskkonnad ehk IDE’d toetavad veebiteenuse ja WSDL-i loomist valmiskirjutatud lähtekoodi (näiteks Java) baasil.

Selle meetodi miinuseks on:

  • olemasolevad vahendid loovad standardse WSDL-i, mis ei sisalda X-tee kohustuslikke WSDL elemente (näiteks X-tee sõnumi päiseväljad, xrd:version, xrd:title). Seega on vaja WSDL-i täiendada ning täiendamist tuleb teha uuesti algusest pärast igat WSDL-i muudatust.
  • eelnevast tulenevalt antud meetodit X-tee teenuse loomiseks üldjuhul kasutada ei soovitata, v.a. juhul kui on leitud sobiv tööriist WSDL-i automaatseks täiendamiseks.
2.5.3.2 WSDL -> lähtekood (Top Down, Contract-first)

Antud meetodi puhul:

  • Luuakse kõigepealt andmeteenuse WSDL kirjeldus

WSDL-i saab luua kas käsitsi (tavalise tekstiredaktori abil) või spetsiaalse WSDL-i redaktori abil. WSDL-i loomine käsitsi on tülikas, samas olemasoleva malli/näidise baasil võib ka käsitsi WSDL-i loomine olla efektiivne.

On olemas ka graafilised WSDL-i redaktorid erinevatele platvormidele, nt Eclipse IDE jaoks.

  • WSDL-st genereeritakse veebiteenuse lähtekoodi skelett (Java, .NET vms platvormi jaoks), kus on realiseeritud andmeteenuse SOAP liidese osa. Seda lähtekoodi skeletti peab arendaja täiendama, lisades juurde äriloogika, mis täidab genereeritud skeleti andmetega.

Seda meetodit kasutatakse ka koolituse praktilises osas X-tee andmeteenuse realiseerimiseks, seega täpsemad juhendid antud meetodi kasutamiseks erinevates arenduskeskkondades leiad moodulis 6.

2.5.3.3 Agiilne meetod (Meet in the middle)

Antud meetod kombineerib eelnevalt nimetatud kahte meetodit:

  • Alguses luuakse teenuse WSDL.
  • WSDL-st genereeritakse X-tee andmeteenuse lähtekoodi skelett.
  • Juhul kui äriloogika komponendid ei ole eelnevast olemas (n-ö pärandtarkvarana), siis realiseeritakse nad sobival viisil.
  • Realiseeritakse konverteerimine äriloogika komponentide ja genereeritud teenuse komponentide vahel.

Etapi tulemid: valideeritud ja kommenteeritud WSDL ning andmeteenuse realisatsioon.

2.5.4 Testimine

Selles faasis tuleb läbi viia:

  • funktsionaalsuse testimine (vastavus funktsionaalsetele tingimustele);
  • koostöövõime testimine (ühilduvus erinevate platvormide ja klientidega);
  • jõudluse testimine (mittefunktsionaalsed tingimused).

2.5.5 Lansseerimine

Teenuse registreerimine RIHA süsteemis ja teenuse kasutusele võtmine.


Last modified: Wednesday, 1 March 2017, 5:13 PM