ARKKITEHTUURIESITTELY JA KOULUTUS 26.3.2007 PLUSTERVEYS Dentego-palvelin.

Esitys aiheesta: "ARKKITEHTUURIESITTELY JA KOULUTUS 26.3.2007 PLUSTERVEYS Dentego-palvelin."— Esityksen transkriptio:

1 ARKKITEHTUURIESITTELY JA KOULUTUS 26.3.2007 PLUSTERVEYS Dentego-palvelin

2 Agenda Järjestelmän yleisrakenne  Sovelluksen osat ja rakenne  Tietokanta  Sovelluspalvelin Käytetyt tekniikat  Hibernate  Axis  Spring  Wicket Asennus ja ylläpito  Asennus ja konfigurointi  Ylläpitokäyttöliittymä Jatkokehitys  Jatkokehitysmahdollisuuksien esittely

3 Järjestelmän yleisrakenne

4 Sovelluksen osat

5 Järjestelmä koostuu kolmesta sovelluskokonaisuudesta, jotka paketoidaan omiin war-paketteihinsa ja asennetaan Tomcat- palvelimelle omina kokonaisuuksinaan. DentegoService (Dentego.war)  Kuuntelee palvelulle osoitettuja Web Services -viestejä  Rajapinta Doctoral-järjestelmille viestien toimitukseen ja hakuun

6 Sovelluksen osat ClientTimer (DentegoClienttimer.war)  Käynnistää ajastetusti asiakassuorituksia konfiguraationsa mukaisesti  Välittää viestit TE-palvelimen ja Dentego-palvelimen välillä Administration (DentegoAdministration.war)  Ylläpitokäyttöliittymän Wicket-pohjainen toteutus

7 Sovelluksen kerrosarkkitehtuuri

8 Service, Client ja UI muodostavat tiedonsiirto- ja käyttöliittymäkerroksen Application ja Administration muodostavat sovelluskerroksen Persistence yhdessä SQL-palvelimen kanssa muodostaa tietovarastokerroksen Kerrosmallissa ylempi kerros käyttää alemman kerroksen palveluita riippumattomasti Esimerkiksi uusi viestityyppi, tai HL7 mukainen action (kuten REFDIS, jne) ei tarvitsisi muutoksia Service- tai Client- moduuliin vaan ainoastaan Application-moduuliin.

9 Pakettirakenne sovelluskoodissa

10 communication.client – Web Services - lähetyspalvelu communication.service – Web Services –viestien vastaanotto administration - Ylläpitokäyttöliittymä clienttimer – Logiikka ajastuspalveluiden konfiguraatiolle ja suoritukselle. Html- raportointisivun generointi application – Sovelluslogiikka vastaanotettujen viestien prosessointiin ja vastausten luontiin

11 Pakettirakenne sovelluskoodissa persistence – Palveluita persistentin tiedon tallentamiseen ja hakemiseen. objects – Sovelluksen domain-objektit, joita käsitellään application- ja administration-paketissa ja joita tallennetaan ja ladataan tietokannasta persistence-paketissa. Kaikki paketit kuvattu ja selitetty tarkemmin Arkkitehtuuri-dokumentissa

12 Tietokannan rakenne

13 Sovelluspalvelimet Sovelluksia ajetaan Apache Tomcat 5.5 –palvelimessa Toteuttaa J2EE 1.4 mukaisen Servlet Container - spesifikaation mutta ei ole täysi toteutus Application Server - spesifikaatiosta (EJB, JMS, jne.) Kevyt, luotettava, laajasti käytetty Sovelluspaketin asennus palvelimelle tapahtuu kopioimalla.war-tiedosto $TOMCAT_HOME/webapps –hakemistoon. Palvelin huolehtii lopusta. Logi-tiedostos tuotetaan hakemistoon $TOMCAT_HOME/logs, josta palvelimen suoritusta voi seurata. Kaikki konfiguraatiotiedostot paketoitu.war –tiedostoihin. Lisää konfiguraatiosta ja asennuksesta myöhemmin

14 Käytetyt tekniikat Hibernate 3 Apache Axis 2 Spring Framework Wicket

15 Hibernate 3 objects-paketin luokat persistoidaan Hibernate mappausten avulla persistence-paketissa PersistenceDAO-rajapinnasta hibernate-pohjainen toteutus. Tarjoaa metodeita objektien hakuun tietokannasta ja tallennukseen Hyviä puolia Dentego-sovelluksessa  Tiedon pysyväistallennus vaati vain vähän lisätyötä ohjelmoinnissa. Esimerkiksi SQL-kyselyitä ei tarvinnut juuri kirjoittaa  Oliopohjainen suunnittelu oli vapaata kun Hibernate saatiin taipumaan suunniteltuun oliorakenteeseen sellaisenaan.  Muutokset objekteissa nopeasti toteutettavissa ja testattavissa (vrt. lukuisten SQL-kyselyiden uudelleenkirjoitus)

16 Hibernate 3 Ongelmia  Hibernate sessioiden ja transaktioiden hallinta aiheutti päänvaivaa. Transaktion avaus ja sulkeminen tulisi tehdä vain yhdellä tasolla mielellään yhdessä ja samassa metodissa. Näin myös virhetilanteessa mahdollisesti tarvittava rollback voidaan tehdä siististi.  LazyInitializationException. Session sulkeuduttua lataamattomiin relaatioihin ei voi koskea. Huolehdittava asiakasohjelmalle palauttavassa kerroksessa että kaikki tarvittava tieto on ladattu kannasta. Tämä aiheuttaa ongelmia erityisesti request-response käyttöliittymissä (selainpohjaiset).

17 Apache Axis 2 Web Services –palvelun toteutus communication.service-paketissa (DentegoService.java) Hyviä puolia  Koko Web Services –rajapinta voitiin toteuttaa yhdessä metodissa, joka saa parametrikseen viestin body-osan ja jonka paluuarvo lähetetään vastausviestin body-osuutena.  AXIOM-oliomalli XML-dokumentista huomattavasti ohjelmoijaystävällisempi kuin org.w3c.dom. Lisäksi se on muistinkäytön ja suorituskyvyn kannalta tehokas PullParsing- menetelmän ansiosta. Näistä syistä AXIOM-mallia käytetään myös sovelluksen sisällä.

18 Apache Axis 2 Huonoja puolia  Dokumentaation taso ala-arvoinen. Tästä seurasi runsaasti päänvaivaa projektin aikana.  Ongelmia kaksisuuntaisen SSL:n kanssa, jonka vuoksi client- toteutuksessa jouduttiin käyttämään SAAJia.  Ajatellusta kaavasta poikkeaminen hankalaa. Soap-viestin headerit eivät tyypillisessä Web Service –toteutuksessa ole kiinnostavia mutta OpenCDA välittää niissä tärkeää tietoa. Headereihin käsiksi pääseminen vaati lisätyötä, jota huono dokumentaatio ei ainakaan helpottanut.

19 Spring Framework Käytetään clienttimer-paketissa ajastettujen asiakassuoritusten konfigurointiin. Tarjoaisi valtavasti mahdollisuuksia mutta opetteluun ei valitettavasti riittänyt aikaa tämän projektin puitteissa. IoC-container on kuitenkin näppärä tapa konfiguroida luokkien välisiä riippuvuuksia ja kompositioita. Ajastettujen asiakasohjelmien konfiguroitavuus saavutettiin Springin ja koodin fiksun oliorakenteen ansiosta käytännössä ilmaiseksi.

20 Wicket administration-paketin käyttöliittymätoteutus perustuu Wicket-kehykseen. Hyviä puolia Dentego-projektissa  Eristää esityksen ja kontrollin siten, että staattisen html-sivun voi ensin suunnitella ja tämän jälkeen vain muuntaa dynaamiseksi. Vastaavasti dynaamisen sivun voi koristella koodiin koskematta.  Valmiita komponentteja dynaamisen sisällön luontiin ja käyttäjän toimintoihin reagoimiseen ilman että kehittäjän tarvitsee tuntea http-protokollan toimintaa juuri lainkaan (vrt. servletit, joissa request-parametrit parsittava itse)

21 Wicket Ongelmia  Vaati ehkä opettelua turhan paljon verrattuna käyttöliittymän yksinkertaisuuteen. Yksinkertaisessa käyttöliittymässä Wicket:n potentiaali ei varmastikaan tullut kunnolla esiin.