1 / 64

Työpaja 3 SerAPI-työpajaseminaari 6.2.2006, Kuopio Juha Mykkänen, Heli Luostarinen,

Prosessit ja palvelut. Työpaja 3 SerAPI-työpajaseminaari 6.2.2006, Kuopio Juha Mykkänen, Heli Luostarinen, Pasi Riikonen, Assi Pöyhölä, Esa Paakkanen versio julkiseen jakeluun. Työpajan runko. aamupäivä (prosessit, sisällöt, käsitteet, tiedot, toiminta)

makan
Download Presentation

Työpaja 3 SerAPI-työpajaseminaari 6.2.2006, Kuopio Juha Mykkänen, Heli Luostarinen,

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Prosessit ja palvelut Työpaja 3 SerAPI-työpajaseminaari 6.2.2006, Kuopio Juha Mykkänen, Heli Luostarinen, Pasi Riikonen, Assi Pöyhölä, Esa Paakkanen versio julkiseen jakeluun

  2. Työpajan runko • aamupäivä (prosessit, sisällöt, käsitteet, tiedot, toiminta) • Prosessit ja palvelut-kohde: tavoitteet, tilanne jne. • Työpajan ja osallistujien tavoitteet • ProPa-tuotoksista lyhyesti • Prosessikuvausesimerkkejä eri lähteistä: • äitiyshuolto (lyhyesti) / SerAPI, VSshp ja ydintietomäärittelyt • endoskopia, leikkaussali / Satshp • gastroskopia / SerAPI/PlugIT • eri mallien vertailu suhteessa tavoitteisiin, keskustelu mm. työtoiminnan kuvaus, toimintojen linkitys ja kuvaaminen • iltapäivä (arkkitehtuuri, palvelualusta, integraatio) • palvelualustojen käyttö • prosessimoottorin käyttömahdollisuudet • palvelujen luokittelu ja arkkitehtuuri • tarkempaa esimerkin läpikäyntiä / Satshp • jatkotyön tarkennukset ja tarpeet

  3. ProPa-tavoitteet • Mitä tehdään: • toimintaprosessien ja sovelluspalvelujen tunnistamista, nimeämistä, määrittelyä ja kuvaamista • Tavoitteet: ratkaisuja ja esimerkkejä: • prosessien ja toiminnan ymmärtämiseen • palvelujen tunnistamiseen ja erottamiseen prosessimallinnuksesta • SerAPI-määrittelykohteet keskittyneet rajapintojen bottom-up määrittelyyn, tässä prosessilähtöinen palvelumäärittely (top-down)

  4. Osapuolten tavoitteita • esimerkkejä palvelupohjaisista ratkaisuista • esimerkkejä prosessien mallinnuksesta • osastojärjestelmien liittämisen toistettava malli • palvelupohjaisen arkkitehtuurin "blueprint" • prosessimoottorin kokeilu • palvelualustan käytön ja käyttökohteiden tarkennus • Business Activity Monitoring -tiedon kerääminen palvelualustan kautta • yleiskuva terveydenhuollon / sairaalan prosesseista • mihin keskitymme tänään?

  5. ProPa-tuotokset • prosessien ja sovelluspalvelujen kuvauksia tilanteessa, joka liittyy konkreettiseen terveydenhuollon prosessiin ja palvelu/järjestelmähankintaan • ratkaisuja ja esimerkkejä - prosessien mallintamisesta, välineistä ja tekniikoista • tietoa prosessimallinnuksesta ja palveluarkkitehtuurin suunnittelusta terveydenhuollossa • Prosessikartta • Prosessiesimerkit (endoskopia ja äitiyshuolto) • Sovelluspalvelujen tunnistaminen + toiminnalliset määrittelyt • (Sairaalan) SOA-arkkitehtuuri • (siirtymä- ja migraatiovaihtoehdot, ohjeet jne.)

  6. Tilanne • 09/06 SerAPIn Prosessit ja palvelut-työpaja • -> soveltamiskohteen käynnistys + tavoitteiden 1. tarkennus -> ProPa-kohdekuvaus • 11/06 esimerkkiprosessien valinta • tuotettu prosessikartan ja -esimerkkien luonnoksia • koottu materiaalia (palvelupohjaisen määrittelyn menetelmät ja ratkaisut, esimerkkiprosessit, palveluarkkitehtuurin mallit) • 02/07 tavoitteiden 2. tarkennus, ProPa-työpaja • yhteyksiä (osapuolten lisäksi) • ZipIT-hanke: toimintalähtöinen vaatimusmäärittelymenetelmä, työtoiminnan kuvaaminen • Healthcare Services Specification Project (SOA4HL7) -työ etenkin SOA-lähestymistavassa • SerAPI:n SOA- ja web services-soveltamisopas • kansallisen Ajanvarauksen esiselvityshanke

  7. Työpajan tavoitteet • tarkentaa tavoitteita ja toimenpiteitä osallistujien kannalta: • nimettyihin soveltamistarpeisiin • yleisesti prosessimallinnukseen ja palvelujen määrittelyyn prosesseista • arkkitehtuurimäärittelyyn • prosessimoottorin ja alustan käyttöön • yleisistä kysymyksistä kohti "kuinka sovellamme käytännössä" -suunnittelua • jatkoa 09/06 työpajan asioille

  8. Terveydenhuollon yleistetyt prosessit

  9. Prosessikartta - yleinen taso (esh organisaatiossa)

  10. Prosessikartta - pohja tarkennuksille • tarkempia esimerkkejä mm. gastroskopiaan ja äitiyshuoltoon myöhemmin aamupäivällä

  11. Prosessimallinnuksen esimerkit • äitiyshuolto (laaja) ja endoskopia (rajattu) valittu osapuolten aloitteesta tarkemmiksi esimerkeiksi • molemmissa myös valmiin materiaalin hyvä saatavuus vaikuttanut valintaan • lisäksi osapuolten kuvauksia (esim. leikkaussali) • äitiyshuolto aamupäivällä lyhyesti esimerkkinä (kaikki tarvittavat osapuolet ei paikalla) • endoskopiasta tarkempaa esimerkkiä • aamupäivällä prosessimallien ja -tuotosten vertailua (Satshp endoskopian ja leikkaussalin mallinnus ja -integraatio + SerAPI / PlugIT-gastroskopia prosessikartta ja -kuvaukset) • yleistettävyys ja käyttökelpoisuus ratkaisujen + arkkitehtuurin + alustan suunnittelussa • iltapäivällä samoja esimerkkejä integrointi-, alusta- ja arkkitehtuurinäkökulmista?

  12. Prosessikuvausten tuottaminen 1 • Kuvataan prosessin tavoitteet • Nimetään prosessin omistaja (jos mahdollista) • Määritellään, mistä prosessi alkaa, mihin se loppuu ja mitä prosessi "tuottaa" • Tunnistetaan alustavasti prosessin päävaiheet (toiminnot) ja niiden järjestys, hyödyntäen esim. yleisiä hoito- ja tutkimus/toimenpideprosesseja • Tunnistetaan prosessin osallistujat • Kuvataan vaihe vaiheelta prosessin eri vaiheiden yhteydet muihin prosesseihin ja toimintoihin • Tuotetaan prosessikuva (esim. BPMN-notaatiolla), kuvassa esitetään keskeiset toimijat/yksiköt, prosessin vaiheet ja prosessin eteneminen eri vaiheiden välillä

  13. Prosessikuvausten tuottaminen 2 • Tarkennetaan, mitä tietoa prosessin eri vaiheissa liikkuu. • Tarkennetaan, onko jokin prosessin osa (aliprosessi) kuvattava tarkemmin omana prosessinaan. Aliprosesseille kuvataan edeltävät askeleet siten kuin ne soveltuvat. • Kuvataan vaihe vaiheelta prosessin eri vaiheissa tapahtuva tietotekniikan käyttö ja tapahtumat, jotka ovat rajapinta käyttäjän/prosessin ja tietotekniikan välillä. • Tunnistetaan / nimetään yleiset tietojärjestelmä- ja sovelluspalvelut, jotka liittyvät vaiheen 10 tapahtumiin. • Tunnistetaan tietojärjestelmät ja sovellukset, joista sovelluspalveluja voidaan tarjota • Tunnistetaan valmiit palvelumääritykset tai rajapinnat, joita voidaan hyödyntää tai soveltaa • Siirrytään tarkempaan sovelluspalvelujen määrittelyyn tai soveltamiseen

  14. Prosessiesimerkkien läpikäyntiä • äitiyshuolto • SerAPI: toimintatarina äitiyshuollon palvelukokonaisuudesta (taustamateriaalina), synnytys-hoitokokonaisuuden prosessikartta • VSshp: palvelukokonaisuus- ja palvelutapahtuma-esimerkit • endoskopia ja leikkaussalijärjestelmät • Satshp: endoskopian ja leikkaussalin prosessit • SerAPI: gastroskopian prosessikartta, toimintatarina, prosessikuvaukset • pohjana jatkokeskustelulle, palvelujen määrittelylle, yleistämiselle, parhaiden käytäntöjen + tarkkuustason valitsemiselle jne.

  15. Äitiyshuollon palveluketjun tärkeimmät osat [Äitiyshuollon prosessi ja tietotarpeet: Saumattoman palveluketjun tietoteknisen tuen malliratkaisu - hankesuunnitelma, Silvennoinen, Korpela 2004]

  16. Äitiyshuollon prosessikartta (esh)

  17. Synnytys-hoitokokonaisuuden prosessikartta

  18. Esimerkki äitiyshuollon palvelukokonaisuudesta [Pirkko Kortekangas, 2006]

  19. Esimerkki hoitokokonaisuuden tapahtumista/toiminnoista ja niiden tehtävistä [Pirkko Kortekangas, 2006]

  20. Äitiyshuollon rakenteiset tiedot • äitiyshuollon palveluketjun keskeiset rakenteiset tiedot • kuvaa myös äitiyshuollon tyypillisen palveluketjun • dokumentti sisältää prosessikuvauksia (eri lähteistä + päivitetty) • esim. synnytysvastaanotto ja synnytyksen hoito -> • [Äitiyshuollon sähköisen potilaskertomuksen rakenteiset tiedot, luonnos v1.1, 25.10.2006]

  21. Prosessikuvausten esimerkkejä • Satakunnan shp: • endoskopian prosessit • leikkaussaliprosessit • ks. Satshp esitys • endoskopiaosion vertailu: gastroskopian prosessikuvaus -esimerkki / SerAPI • gastroskopian prosessikartta • gastroskopian prosessikaavioiden luonnokset • gastroskopian hoitoprosessin kuvaus / PlugIT

  22. Gastroskopia-esimerkin kokemuksia ja pohdintaa • työpajan pohjamateriaalina hoitoprosessin kuvaus • lähdemateriaalin prosessikuvauksissa ei ole erittelyä, mitä loppujen lopuksi hoidetaan missäkin tarkalleen • olisi mahdollista jaotella organisaatiota toiminnallisesti tarkemmin esim. gastroenterologiassa, mitä missäkin (poliklinikka - mm. esitutkimus, vuodeosasto ja toimenpideyksikkö) - voi poiketa paikallisesti • prosessikartan "organisaatioyksiköt" voivat käytännössä sisältää useita toimipisteitä esim. sisätautien poliklinikka - tutkimusosasto • esi- ja jälkitoimenpiteet voivat poiketa, esim. tarvitseeko potilaan aina käydä poliklinikalla ennen ajanvarausta toimenpiteeseen • lääkityksen tilaus on tehtävä "jossain vaiheessa ennen tutkimusta", mutta ei välttämättä esim. heti ajanvaraukseen liittyen • tarvitaanko esim. skopiatoimenpiteen tarkempaa kuvausta? • hallinnolliset järjestelyt (esim. kuvataanko aina ilmoittautumisen tarkastus omana vaiheenaan ennen toimenpidettä) • jatkotarkennuksia mm. tietokokonaisuuksien erittely, tapahtumat, palvelujen, järjestelmien ja rajapintojen tunnistaminen

  23. Keskusteluaiheita • nykytila vs. tavoitetila: • nykytilan ymmärtäminen välttämätöntä - mutta kuinka tarkalla tasolla? • miten syvälle on uppouduttava työtoiminnan kuvaamiseen? • onko SOA-lähestymistavassa itse asiassa kyseessä "hiukan parannetun nykytilan" mallinnus + toteuttaminen + jatkossa pienillä parannuksilla kehittäminen? • yleistäminen • välttämätöntä, jotta tietotekninen ratkaisu saadaan aikaan + etenkin jos pyritään sovelluspalvelujen uudelleenkäyttöön • hyvät käytännöt • kuvataanko prosessin käynnistävät tapahtumat osana prosessia? • prosessien ohjaus -> guideline, malli josta pitää voida poiketa? • prosessikartan toiminnallinen jaottelu esim. yksiköiden suhteen - pitäisikö "missä" erottaa "mitä"-kysymyksestä?

  24. Keskustelu: työtoiminnan kuvauksen suhde prosessikuvauksiin • työtoiminta = esim. organisaatioyksikön, ammattiryhmän tai henkilön tekemät toiminnot tai tehtävät • poikkeaa prosessikuvauksesta: prosessi kulkee monien työtoimintojen läpi, työtoiminnassa toistuvat pienet osat useista eri prosesseista ja saman prosessin instansseista • työtoiminnan kuvaukseen eri kuvaustavat kuin prosessin (työnkulku, tiedonkulku, henkilöiden, materiaalin kulku) kuvaukseen • työtoiminnan kautta toisistaan täysin irralliset eri prosessit liittyvät toisiinsa ja vaikuttavat toisiinsa • työtoimintaa ei automaattisesti huomioida työnkulkujen ja tietovirtojen optimoinnissa ja automatisoinnissa

  25. Keskustelu: tapahtuma/toiminto-käsitteen suhde prosessien kuvauksiin ja toteutuksiin • "palvelutapahtuma"-käsite on tietyn palvelun järjestäminen tai toteuttaminen - kansallisia määritelmiä liittyen mm. lainsäädäntöön, hoitojaksoihin ja ydintietoihin • prosessimallinnuksen kannalta tarvitaan toiminto (/ tapahtuma), joka kuvaa tietyn palvelun toteuttamiseksi tarvittavat tehtävät • terminä "toiminto" [JHS 152] tai "palvelutoiminto"? • ei "tapahtuma" (jolla prosessimallinnuksessa yleensä käännöksenä "event")? • jos yksi toiminto kuvataan tehtävinä, päästään riittävälle tarkkuustasolle palvelujen tunnistamista (/prosessin koordinointia?) varten? • toinen vaihtoehto keskittyä vain yksiköiden / toimintojen / ihmisen ja sovelluksen rajapintoihin • myös eri asiakirjat on saatava liittymään toisiinsa • palvelutoiminnon sisällä, hoitojakson, palvelukokonaisuuden sisällä...

  26. Toiminto [kansallinen ajanvarauspalvelu - käsitemalli (yleinen)]

  27. Työpajan runko • aamupäivä (prosessit, sisällöt, käsitteet, tiedot, toiminta) • Prosessit ja palvelut-kohde: tavoitteet, tilanne jne. • Työpajan ja osallistujien tavoitteet • ProPa-tuotoksista lyhyesti • Prosessikuvausesimerkkejä eri lähteistä: • äitiyshuolto (lyhyesti) / SerAPI, VSshp ja ydintietomäärittelyt • endoskopia, leikkaussali / Satshp • gastroskopia / SerAPI/PlugIT • eri mallien vertailu suhteessa tavoitteisiin, keskustelu mm. työtoiminnan kuvaus, toimintojen kuvaaminen • iltapäivä (arkkitehtuuri, palvelualusta, integraatio) • viitearkkitehtuuri • tarkempaa esimerkin läpikäyntiä / Satshp <- tässä kohden? • palvelujen luokittelu • palvelualustojen käyttö • prosessimoottorin käyttömahdollisuudet • jatkotyön tarkennukset ja tarpeet

  28. Iltapäivän lähestymistapa • viime kerralla keskityttiin mallinnusnotaatioiden lisäksi palvelupohjaiseen kehitysprosessiin • nyt prosessin sijaan (/ lisäksi) eri arkkitehtuurinäkökulmien pohjalta etenemistä • viitearkkitehtuurin kerrokset / näkökulmat • erityishuomion kohteena tänään: • palvelualustat • prosessimoottori • palvelujen luokittelu • sovelluspalvelut • järjestelmät • järjestelmien komponentit / rajapinnat • prosessikerros • käyttöliittymät • integraatioarkkitehtuuri • hallintamekanismit

  29. Kertausta: vaiheet (soddm) vaihtoehtojen tarkastelu prosessien toteuttamiseksi tavoitteet, mittarit, lähtökohdat, suunnitelma web-sovelluspalveluiden ja prosessien tunnistaminen ja määrittely asteittain web-sovelluspalveluiden ja prosessien kehittäminen ja kuvaaminen, teknisten rajapintojen kuvaaminen, palveluja käyttävien osien kehittäminen palvelutason seuranta, mittaus, raportointi, parantaminen kehitettyjen palveluiden ja prosessien toiminnallisen oikeellisuuden ja täydellisyyden sekä yhteentoimivuuden testaaminen web-sovelluspalveluiden käyttö, prosessien määrittelyjen mukainen suorittaminen hallinta- (keskitetty/hajautettu), sertifiointi-, mittaus- ja laskutusmallien määrittely palveluiden ja prosessien käyttöönotto sovelluksissa, käyttäjillä ja kumppaneilla [Michael P. Papazoglou ja Willem-Jan van den Heuvel.International Journal of Web Engineering and Technology (IJWET), 2006.]

  30. Viitearkkitehtuuri-käsittelyn runkona

  31. Viitearkkitehtuuri: perusteet • viitearkkitehtuuri ohjaa miettimään ja ratkaisemaan tietyn tyyppisiä seikkoja kerrallaan, ei kaikkea yhtä aikaa • myös muiden seikkojen kuin "palvelut" huomiointi • "riittävän vähäinen" määrä kerroksia ja näkökulmia • pohjana useita arkkitehtuurikuvauksia, mukana useissa kuvauksissa näkyvät kerrokset / näkökulmat • esimerkkejä • ei "ainoa oikea" lähestymistapa • lisäksi tarvitaan mm. kehitysprosessin ja hallinnan näkökulmia • esim. CBDI "meta model for service architecture and engineering" -näkökulmat: • business modelling, solution modelling, specification of BSA, service specification detail, planning and provisioning policy, implementation, deployment, runtime • tässä vaiheessa kuitenkin keskitytään vielä lähinnä analyysi- ja suunnitteluvaiheeseen

  32. Viitearkkitehtuuri: ehdotus [Arsanjani A. Service-oriented modeling and architecture.]

  33. Viitearkkitehtuurin soveltaminen:sovelluspalvelut (services) -palvelujen luokittelu -hiukan määrittelyprosessista -palvelujen tunnistamisesta lisää "alakerrosten" yhteydessä

  34. Palvelujen luokittelun perusteet • luokittelun tarkoitus: samantyyppisiä ratkaisuja samantyyppisiin tarpeisiin • kaikki palvelut eivät voi olla samantyyppisiä (ja ratkaisuissa tarvitaan muutakin kuin palveluja) • erilaisia luokittelulähtökohtia • teknisyys ja yleiskäyttöisyys: infrastruktuuri / ydinpalvelut / lisäpalvelut • arkkitehtuurin kerrokset + karkeajakoisuus: järjestelmäpalvelut, business services, process services • palvelun kattamien integrointivaatimusten ensisijainen luonne: tietopalvelut, toiminnalliset palvelut, käyttäjäkeskeiset palvelut, prosessipalvelut • toiminnallinen luokittelu: tekniset palvelut (viestinvälitys), yleispalvelut (ajanvaraus), toimintokohtaiset palvelut (radiologian sovelluspalvelut) • rakenteisuuden ja "epävarmuuden" aste

  35. Palvelujen luokittelu - ehdotus • luokittelu tehty lähinnä services-kerrosta varten hyödyntäjänäkökulmasta • luokitellaan tunnistettavat palvelut kahden erillisen näkökulman mukaisesti [SOA4HL7, Herzum&Sims, CBDI, RM-ODP, Linthicum] • palvelun integrointitapa - koska tarvitaan erilaisia palveluita • prosessipalvelu: toteuttaa suoraan prosessia tai osaprosessia • tietopalvelu: liittyy suoraan tietokokonaisuuteen, tietyn tyyppisiin dokumentteihin jne. • toiminnallinen palvelu: keskeistä tarjottava toiminnallisuus (business capability) • tukipalvelu • palvelun yleiskäyttöisyys - koska on määriteltävä uudelleenkäyttöä • yleispalvelut - hyödynnettävissä hyvin monien eri tyyppisten palvelujen, sovellusten ja prosessien toteutuksissa (utility service) • ydinpalvelut - monissa prosesseissa ja yksiköissä / sovelluksissa hyödynnettäviä toiminnallisia tai tietopalveluja (common service) • erikoispalvelut - tiettyihin erikoistilanteisiin vastaavia toimintoja, voi olla osasto/sovellus/tehtäväkohtainen (specialized service)

  36. Esimerkkejä (eri kokoisia) • kansallinen arkistopalvelu (tieto- ja ydinpalvelu) • DRG-ryhmittelijä (toiminnallinen- ja erikoispalvelu) • viestinvälityspalvelu (tuki- ja yleispalvelu) • kontekstinhallinta (toiminnallinen- ja yleispalvelu) • kansallinen koodistopalvelu (tieto- ja yleispalvelu) • koodistojen CodeAPI-rajapinnan toteuttava palvelu sairaalassa (toiminnallinen- ja ydinpalvelu) • alueellinen viitetietopalvelu (tieto- ja yleispalvelu) • ajanvarauspalvelu (toiminnallinen- ja ydinpalvelu) • diabetes-hoitoketjua ohjaava käypä hoito-palvelu (prosessi- ja erikoispalvelu) • sosiaalihuollon yleinen asiointiprosessin ohjauspalvelu (prosessi- ja yleispalvelu) • keskitetty käyttöoikeuksien hallintapalvelu (toiminnallinen- ja ydinpalvelu)

  37. Palvelujen suunnittelu: vaiheet (1/2) Lähtökohtana vaatimukset ja olemassa olevat sovellukset + ratkaisut • tarvittavan toiminnallisuuden kartoitus (vaatimukset, prosessit) • palvelun rajaus ja päävaatimusten valinta • sisällöllisten standardien ja valmiiden mallien tutkiminen + valinta • osallistuvien sovellusten vastuiden määrittely • keskittyminen vain palvelun tarjoajaan - uudelleenkäyttö? • rajapintojen tunnistaminen ja toimintojen ryhmittely niihin

  38. Palvelujen suunnittelu: vaiheet (2/2) • toimintokohtaisesti operaatioiden "koko" + tarvittava / käytettävissä oleva infrastruktuuri • vuorovaikutuksen määrittely (rajapinta + käyttäjä) • palvelukuvauksen määrittely (rajapinnat, toiminnot, tiedot) • pakollisten ja vapaaehtoisten ominaisuuksien ja sallittujen laajennusten määrittely • vaatimusten tarkentaminen teknisille määrittelyille ja toteutuksille  tuloksena palvelun rajapinnan määrittely ja suuntaviivat teknisille ratkaisuille

  39. palvelu- ja viestimäärittelyn toimenpiteet (valkea) ja tuotokset (värillinen) • A generic process for HL7 Messaging Dynamic Model and SOA approach (viestinvälityksen ja palvelulähestymistavan lähentämistä) • [Healthcare Services Specification Project: Services and the HL7 V3 Messaging Dynamic Model, v. 0.98]

  40. Viitearkkitehtuurin soveltaminen:integrointiarkkitehtuuri+ hallintamekanismit -erityisesti palvelualusta (ESB)

  41. Integrointiarkkitehtuurin rajapintojen ja liitäntöjen tyyppejä • keskitetyt, jaetut palvelut (ydinpalvelut) • lisäpalvelut, kontekstinhallinta jne. • löysästi kytketyt, yksiköiden ja organisaatioiden väliset palvelut [Mykkänen, Korpela, Ripatti, Rannanheimo, Sorri. Local, Regional and National Interoperability in Hospital-Level Systems Architecture. Meth Inf Med, 2007, under revision]

  42. Palvelualustojen käyttö • palvelualusta (ESB) perusteet [mukaillen Gartner + Bea + Chappell]: • lähettäjien ja vastaanottajien välissä (intermediary) • ohjelmistojen välinen kommunikointi • aina SOAP/http • yleensä myös viestipohjainen middleware (MOM) • eri viestinvälitysmallit: synkroninen, ei-synkroninen, publish/subscribe • tukee Web services-standardeja (XML, WSDL, SOAP, http) • reititys (mm. palveluntarjoajien löytäminen / korvaaminen, ajonaikainen sidonta) • muunnokset (tietomuotojen + viestinvälitysprotokollien välillä) • metatietojen käyttö (osoitteet, rajapinnat, skeemat, policy-määrittelyt) • seuranta (esim. Business Activity Monitoring, tekninen toimivuus, SLA-valvonta), turvallisuusominaisuudet • (usein) prosessimoottorin käyttö • ESB ei ole yhtä kuin hub and spoke-integrointialusta: myös integrointikomponentit hajautettu palveluiksi palveluväylän kautta

  43. Palvelualusta: Basic SOA [SOA4HL7]

  44. Palvelualusta: Orchestrated (& statically & dynamically intermediated) SOA [SOA4HL7] Static intermed. Dynamic intermed.

  45. Palvelualustan vaikutukset suunnittelupäätöksiin • vaikuttaa • protokollasopimukset • rajapintojen syntaksi, kommunikaatioprotokollat, vaatimukset sovellusten teknisille adaptereille, joskus myös eri viestintämuotojen mäppäys mahdollista • reititys oikealle palvelulle vs. palvelurekisteri • loogisten osoitteiden asettaminen viestiin vs. palvelun käyttäjän vastuu paikallistaa vastaanottaja • ympäristön hallittavuus • keskitetty yhteys-, valvonta- (ja virhetilanne-) piste vai hajautetut integrointipalvelut • lisää joustavuutta ja erilaisia soveltamismahdollisuuksia, mutta myös uuden kerroksen järjestelmään ja eri soveltamistapoja • ei vaikuta • semanttiset ja toiminnalliset perusratkaisut (tietoelementtien ja kokonaisuuksien merkitykset, pl. yksinkertaiset yhdistelyt ja jaot, toiminnallisten vaatimusten perusluonne (integrointitapa))

  46. Filosofinen ero (tai USA-Ruotsi-maaottelu)

  47. Palvelualustojen käyttöön liittyviä kysymyksiä • palvelujen (toiminnallisessa) määrittelyssä tehtävät oletukset alustan hoitamista seikoista • esim. "pyynnön vastaanottajan" määrittelyn eri tasot - onko osa palvelun rajapintaa vai alustan / hakemiston hoidettava asia? • kulkeeko "kaikki" palvelualustan kautta, vai tehdäänkö suoria liitäntöjä esim. ydinpalveluihin - esim. kontekstinhallinta ei ole ESB-palvelu? • vaatimusten luonne • esim. vuorovaikutteisuus vs. viestipohjaisuus • infrastruktuuriresurssit vs. sovellushankintaresurssit • policy-määritysten suhde toiminnallisiin määrityksiin • periaatteessa kaikki voi olla joko rajapintaa tai konfiguraatiota • arvio [Bea]: 20 palvelun sovellukset onnistuvat vielä point-to-point-tavalla, laajemmat sovellukset vaativat keskitetyn väylän • mitä erityisesti jää "yhteisesti sovittavaksi" palvelualustoja käytettäessä • sisältö ja perusratkaisut • toiminnalliset palvelumäärittelyt

  48. Viitearkkitehtuurin soveltaminen:prosessikerros (business process / choreography) -erityisesti prosessimoottori

  49. Viitearkkitehtuurin soveltaminen: business process / choreography • vaihtoehtoja • prosessimoottori - orchestration • keskitetty prosessin ohjaus, oma kerros arkkitehtuurissa, prosessin osana olevien palvelujen ei tarvitse tuntea prosessimäärittelyä • prosessin dokumenttien kunkin osapuolen tuntemat prosessimäärittelyt - choreography • hajautettu prosessin ohjaus, kaikkien osapuolten mukauduttava määrittelyihin • prosessimäärittelyjä voi myös kuljettaa dokumenttien "mukana"? • erikseen rakennetut prosessipalvelut osana arkkitehtuuria - kuten prosessimoottori • käyttöliittymäsovellus (myös vanhat sovellukset) / asianhallintasovellus / portaali prosessin ohjaajana

  50. Prosessimoottorin käyttökohteet ja edellytykset • prosessimoottori: keskitetty prosessin kontrolloija • ohjaa ennalta määritellyllä tavalla viestien ja vastausten liikkumista • säilyttää tiedon prosessin tilasta • prosessin seuranta, poikkeamien hallinta ym. • teknistä tietoa prosessien etenemisestä, virhetilanteista jne. • toiminnallista tietoa prosessien kulusta, läpimenoajoista, määristä jne. • prosessin askelten deterministinen määrittely • tunnettava, kuinka prosessi etenee • ottaa usein kantaa sekä tiedonkulun että työnkulun etenemiseen • prosessimäärittelyn hienojakoinen karkeustaso

More Related