SOA - ajattelutapa vai teknologia
Tieturi OY Sakari Olli FM Ohjelmistoarkkitehtuureiden sekä teknologioiden asiantuntija Tieturi OY Suomen johtava koulutusyritys Konsultointipalveluiden tarjoaja aiheina mm. systeemityö, arkkitehtuurit ja tietojärjestelmäintegraatio Integraatioratkaisujen toimittaja yhteistyössä Appelsiinin kanssa Kannattaa vierailla - www.tieturi.fi Karkkia ja tietoa tarjolla salin takaosassa
Agenda - SOA - ajattelutapa vai teknologia Mitä SOA tarkoittaa? Miksi nyt? SOA arkkitehtuuri käytännössä Teknologiat - alustariippumattomuus Web Services - ajattelutapa SOA - ajattelutapa vai teknologia
Rakentamisen - hyödyntämisen oravanpyörä Liiketoiminnalliset lähtökohdat ASIAKAS TALOUS VISIO + STATEGIAT PROSESSI Rakennettaessa ja uusittaessa tietojärjestelmiä niiden täysipainoinen hyödyntäminen ei ole aina mahdollista. OPPIMINEN- JA KASVU TIETOTEKNIIKKA-ARKKITEHTUURIN UUDISTAMISEN TARVE Tietotekniset lähtökohdat Nykyisten järjestelmien toiminnalliset puutteellisuudet Nykyisten ratkaisujen teknologinen vanhanaikaisuus Nykyisten ratkaisujen heikko kustannustehokkuus Nykyisten järjestelmien joustamattomuus tuleviin tarpeisiin Tietojärjestelmien hyödyntäminen nostaa esille kehittämistarpeita, jotka laukaisevat järjestelmän uusimisen.
SOA (Service Oriented Architecture) - ideologia Liiketoiminta tuo tarpeet ja IT - järjestelmät pyrkivät tukemaan toimintaa tarjoamalla liiketoimintaa tukevia palveluita Aikaisempaa parempi tuki päätöksenteolle Usein yhdistellään monimutkaisia useisiin järjestelmiin hajautuvia prosesseja Tavoitteena rakentaa entistä selkeämpiä korkean tason palveluita liiketoiminnalle tarjoavia järjestelmiä Järjestelmä koostuu palveluista, joiden taustalla ovat liiketoimintoprosessit Liiketoimintaprosessien ja niiden vaatimusten ymmärtäminen avainasemassa Hankalaa monimutkaisissa ympäristöissä Käytännössä korkeamman tason palveluiden luominen tarkoittaa, että useita järjestelmiä joudutaan integroimaan toisiinsa Tyypillisessä organisaatiossa on vuosien mittaan syntynyt paljon erillisiä sovellussaarekkeita, jotka eivät usein keskustele keskenään
Liiketoimintaprosessit kaiken lähtökohta! Organisaatiopohjainen nykytila Yritys Matkatoimisto Tulosyksikkö Matkasihteeri Taloushallinto Matkan järjestäjä Matkan tarve Matka Prosessipohjainen uusi ratkaisu Matkatoimisto / Internet-paikanvaraus Matkustus Matkan varaus Matkalasku Asiakkaan laskutus Myös liiketoimintaprosesseilla on arkkitehtuuri
Tietojärjestelmien nykytila ja integraatio Sovelluksia ERP Taloushallinto Logistiikka Tuotanto Varasto Sähköposti Kalenteri Räätälöityjä omatarvesovelluksia Linux NT Tietovarasto SQL- Server Oracle Tietojärjestelmän palvelut Prosessi Järjestelmä tarjoaa luontevalla tavalla palveluja liiketoimintaprosessin edetessä Järjestelmä tarjoaa myös tukea prosessin valvonnalle
Käytäntö paljon erillisiä saarekkeita WEB SHOP CORBA SOCKETS DCOM RMI BILLING SYSTEM CREDIT CHECK RETYPE FAX COPY-PASTE PHONE IDENTITY SERVER WAREHOUSE
Mitä uutta?!? Näinhän olisi pitänyt olla aina! Samasta liiketoiminnan ja IT järjestelmien linkittämisestä ollaan puhuttu jo pitkään Eikö tämä ole vuonna 2005 jo todellisuutta? Ollaan järjestelmiä pystytty integroimaan aikaisemminkin Se on ollut kuitenkin yleensä hankalaa ja kallista
Miksi nyt? SOA ajattelutapa on ollut pitkään suuri tavoite, jota on ollut hankala toteuttaa puuttuvien teknisten ratkaisujen ja työkalujen takia Teknisenä ratkaisuna saattaa kulminoitua Web Services tekniikkaan, mutta on vaihtoehtojakin tuki löyhälle kytkeytyvyydelle Toisaalta tarjolla on valmiita palvelintuotteita, jotka mahdollistavat liiketoimintoprosessien jakamisen useisiin järjestelmiin vähällä vaivalla Käytännössä tietojärjestelmien integrointiin liittyvien standardirajapintojen kehittyminen on luonut mahdollisuuden toteuttaa visiot käytännössä Nimenomaan avoimet ratkaisut ovat kehittyneet valtavasti
Miksi avoimet teknologiat - Muuttuva maailma Arkkitehtuurit kehittyvät DNA Arkkitehtuuri,.NET Arkkitehtuuri, J2EE arkkitehtuuri Arkkitehtuurittomat ratkaisut Kielet ja tekniikat kehittyvät Cobol, C, C++, Visual Basic, Java, C# Yritysorganisaatiot muuttuvat Arkkitehtuuri- ja tekniikkavalinnat muuttuvat Strategisia kauppoja, tytäryhtiöitä, uusia toiminta-aloja,... Uutta palveluntarjontaa kumppanien kanssa Uusia kirjanpitosäädöksiä, verosäädöksiä,... Yritysjärjestelmissä syntyy vuosien varrella toisiinsa liittymättömiä saarekkeita jotka eivät keskustele keskenään! Joskus tieto sovellusten välillä liikkuu vain copy-paste tekniikalla
SOA (Service Oriented Architecture) - ideologia SOA - pohjaisessa suunnittelussa komponenttien rajapintojen suunnittelu lähtee liikkeelle prosessien tukemisesta Komponenttien rajapinnoista tulee parhaimmillaan karkeita ja selkeästi uudelleenkäytettäviä Pohjaudutaan siis hyvän suunnittelun perusperiaatteisiin Näinhän oli komponenttienkin kanssa Aikaisemmin liitäntä komponentteihin oli teknologiasidonnainen (DCOM,RMI,ORB) SOA:ssa pyrkimys on sanoutua irti teknologiasta Tavallisesti SOA:a tukeva arkkitehtuuri rakentuu prosesseista vastaavan keskittimen varaan Message Broker - arkkitehtuuri Kapseloidaan liiketoiminnan tarpeet uuteen kerrokseen, joka vastaa prosesseista sekä palveluista
Service-oriented integration architecture Application A Application A Prensentation Business Integration Business Prensentation Data Data Business Service interface Service interface Business
SOA arkkitehtuuri(message brokers) Middleware Data Message Broker Omat sovellukset Muunnos Säännöt Reititys Ratkaistavat kysymykset Business prosessin hallinta Data Siirtotiet Integrointi Valmiit sovellukset
SOA palveluarkkitehtuuri Ylläpidettävyys tärkeintä Tärkeimmät suunnittelumallit Riippuvuuksien vähentäminen Rajapinnat Fasadit Välittäjät (factory, broker) Ymmärrettävyyden parantaminen olioajattelu Komponenttikeskeisyys olioajattelu ja riippuvuuksien vähentäminen Asiakaskyselyt (www) Asiakastietojen ylläpito (office) Asiakastiedot
SOA (Service Oriented Architecture) - tilattomuus Tyypillisesti yksittäinen palvelu on tilaton Olio- ja komponenttimaailmassa tieto ja sen käsittely paketoidaan yhteen SOA - maailmassa palvelupyynnön takana varmasti myös tapahtuu tiedon prosessointia, mutta yksittäinen palvelu on itseriittoinen kokonaisuus Tavoitteena, että prosessit voidaan muodostaa koostuviksi yksittäisistä tilattomista palveluista Palvelun suorituksen jälkeen käsitelty informaatio järjestelmän näkökulmasta unohtuu Prosessin tilatieto kapseloidaan tyypillisesti integraatiokeskittimeen, joka ohjaa prosessien toimintaa Tilattomina palveluista voidaan luoda yleiskäyttöisiä
SOA - teknologiat SOA ajattelumalli on teknologiariippumaton Käytännössä tarvitaan kuitenkin välineet, joilla kaunis visio voidaan toteuttaa Useimmiten vuonna 2005 SOA toteutusten taustalta löytyy paljon teknologioita ja ratkaisuja Web Service teknologiat ovat kuitenkin lyönyt itsensä vahvasti läpi Alustariippumaton Yksinkertainen tekniikka Data liikkuu paikasta toiseen tekstimuodossa Integraatiokeskitin tarjoaa tyypillisesti palvelurajapinnat ulospäin Web Service palveluina Avoin teknologia ei suljeta pois mitään tekniikkaa Ei sitoutuda parhaimmillaan myöskään mihinkään valmistajaan tai tuotteeseen
SOA (Service Oriented Architecture) - 2005 Yhä useampi tuote tarjoaa helppoja tapoja integroitua Web Service teknologia avulla J2EE Session Bean komponenteista Web Service - palveluita helposti.net komponenttien luontainen kommunikaatiomenetelmä SOAP Web Service palveluita tarjolla jopa Office sovelluksista Paljon valmiita tuotteita liiketoimintoprosessien mallintamiseen ja hallintaan, jos selkeä tapa integroitua on tarjolla MS Biztalk Server prosessit ja tiedonvälitys helppo hallitaan RosettaNet liiketoimintoprosessipohjainen XML -sanasto Integraatioratkaisujen toteuttaminen tukemaan aidosti liiketoimintaa muuttuu taloudellisesti kiinnostavammaksi
Services Järjestelmät rakennetaan palveluista, jotka noudattavat seuraavia periaatteita: Palvelut ovat autonomisia. Rajat ovat explisiittisiä (tarkkoja) Jaetaan vain: Schema = tietorakenteiden kuvaus. Contract = sopimus siitä miten, milloin ja missä järjestyksessä tietorakenteita lähetetään. Policy: menettelytapa. Kertoo mitä kommunikointi edellyttää (esim. turvallisuus, transaktiot, tilallisuus yms.) Rakenteet voivat olla XML-kieltä, mutta ne voivat olla myös jotain muuta. Web Service on kyseisen ajattelumallin ensimmäinen ilmentymä, joka ei ole nykyisellään täydellinen.
Web Service Web Service on uudenlainen palvelu; Tyypillisesti julkisessa Internetissä saatavana oleva palvelu jota ohjelmat voivat automaattisesti hyödyntää Taustalla xml joten palvelu on alusta ja kieliriippumaton Voidaan käyttää etäkutsuihin tai tiedonsiirtoon Toimii myös palomuurin läpi, mahdollista käyttää pitkälti olemassaolevia investointeja ja tekniikoita Mahdollistaa esim. Java-sovelluksen kutsumaan.net-sovellusta Internetin yli, tai Perl-web sovellusta Mahdollistaa esim..net tai Perl-sovelluksen kutsumaan Java-sovellusta Internetin yli
XML integraatiossa.net.net System SOAP RPC etäkutsu SOAP dokumenttien siirto OMA XML Protokolla J2EE J2EE System (MS (MS SQL, SQL, Oracle, DB2,...) XML tietokannasta, ADO.NET
Palvelupyyntö - mikä on viesti (message)? Kutsu: <Customer> <CustomerID>123</CustomerID> </Customer> Paluu: <Customer> <CustomerID>123</CustomerID> <Name>John</Name> </Customer> Vanha idea uusissa kuorissa?
Web Service toimintaidea 1. Palvelua etsitään UDDI:sta UDDI 3. Web Service palvelupyyntö SOAP:lla 2. WSDL kuvauksen perusteella tiedetään miten yhteys otetaan ja mitä palveluita löytyy WS EndPoint Palvelun Tarjoaja WSDL
Web Service tekniikoista Extensible Markup Language (XML) Simple Object Access Protocol (SOAP) W3C:n standardoima protokolla (Myös XML Protocol) Määrittelee yksinkertaisen kirjekuoren jossa tietoa liikkuu verkon yli alustariippumattomasti Käyttää XML-muotoa ja schemoja, ei ota kantaa mm. tietoturva-asioihin tai palvelun laatuun Web Service Description Language (WSDL) Määrittelee xml-pohjaisen web-palvelun Ei vielä standardi, w3c:ssä vasta työn alla - IBM ja Microsoft tehneet paljon työtä sen parissa WSDL kertoo mitä palveluita on tarjolla ja miten niitä voi kutsua alustariippumattomasti Universal Description, Discovery, Integration (UDDI) Kuvailee yrityksiä ja niiden toimintoja, matalimmalla tasolla aina teknisiin palvelukuvauksiin asti UDDI-rekisteristä voi hakea automaattisesti palvelun esim. nimen, sijainnin tai tyypin perusteella
Web Service ja SOA On ensiaskel kohti SOA:a. Suunta on oikea, mutta olemme vasta tien alussa. Tuki perustasolla kaikkialla. Mukana kaikissa.net sovelluksissa. Erittäin helppo toteuttaa ja käyttää. Jatkossa WinFX indigo, joka on osa Windows Longhorn käyttöjärjestelmää. Microsoft on ollut mukana massiivisesti standardintyössä. Java Sun WSDP v.1.5 J2EE 1.4.Tärkein uudistus on Web Service standardointi osaksi J2EE sovelluspalvelinta. Apache Axis. Tätä junaa vetää IBM. Ei Sun. Windows DNA (Microsoftin vanha sovellusarkkitehtuuri, joka korvautui vuonna 2002.NET:llä). Sisältää tuen noin vuodesta 2001.
Miksi Web Services? Vain yksi integraatioratkaisu muiden joukossa Mikään ei pakota ottamaan käyttöön sovelluksissa ellei se anna jotain hyötyä Ratkaisuna poikkeuksellisen avoin ja "low-tech" Parhaat edut alusta ja kieliriippumattomuus ja mahdollisuus tehdä helposti kutsuja vaikka Internetin yli - läpi useamman palomuurin Esim..NET ja Java integraatiot, Applet tai Midlet tai XLet kutsuu internetin yli yrityspalveluita,... SOA periaatteet voidaan kuitenkin toteuttaa myös muilla välineillä
Web Services sudenkuoppia Tietoturva ja palvelun laatukysymykset etenkin Internetin yli toimittaessa Web Services määrittelee vain siirtotavat ja kanavan, vielä tärkeämpää on määritellä MITÄ sillä siirretään Esim. ebxml XML-viestejä vai tyypitettyjä etäkutsuja? (DOC/RPC) Kaikki toteutukset eivät tue kaikkia SOAP tyyppejä, esim. rakenteiset tyypit Suorituskykyä tulee valvoa ja mitata Onnistumisen mahdollisuudet parhaat WS-I yhteensopivilla alustoilla, muilla tuurista kiinni Osa XML standardeista kesken, muuttuva kenttä Yksinkertaisuus oli syy miksi XML ja Web Services onnistuivat, riskinä tekniikoiden monimutkaistuminen
WS-* protocols Joukko standardiehdotuksia, jotka pyrkivät tuomaan Web Service palveluihin mm. -Tietoturvan, transaktiot, reitityksen, luotettavuuden yms. Modulaarinen rakenne. Ei yhtä jättimäistä spesifikaatiota. Standardien luomisessa mukana mm. IBM ja Microsoft. Useat tekniikat perustuvat SOAP Header tiedon käyttöön, jossa voidaan siirtää varsinaisen datan ulkopuolista tietoa. SOAP-ENV:Envelope SOAP-ENV:Header SOAP-ENV:Body
WS-I Alunperin Web Service toteutukset olivat kirjavia ja niiden yhteensopivuus onnesta kiinni WS-I eli Web Service Interoperability määrittelee profiileja joita pyritään toteuttamaan, ne lyövät lukkoon mitä versioita XMLstandardeista käytetään J2EE 1.4 rakentuu WS-I Basic Profile 1.0:n varaan Myös Microsoft.NET tukee tätä tasoa
WS-I Basic Profile 1.0 SOAP 1.1 WSDL 1.1 UDDI 2.0 XML 1.0 (Second Edition) XML Schema Part 1: Structures XML Schema Part 2: Datatypes RFC2246: The Transport Layer Security Protocol Version 1.0 RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile RFC2616: HyperText Transfer Protocol 1.1 RFC2818: HTTP over TLS RFC2965: HTTP State Management Mechanism The Secure Sockets Layer Protocol Version 3.0
WS-Security WS-Security ottaa kantaa XML turva-asioihin kuten digitaaliset allekirjoitukset, XML osien kryptaus, jne EI ole osa J2EE standardia! Silti toteutettu osalla palvelimista
Esim.
SOA - ajattelutapa vai teknologia SOA on ajattelutapa, joka on tullut ajankohtaiseksi kehittyneiden teknologioiden tarjotessa tavan rakentaa konseptin mukaisia järjestelmiä SOA:n ajattelutapa liiketoimintaa tukevista järjestelmistä ei sinällään ole mitenkään uusi Toisaalta myös tietojärjestelmien integrointi on ollut arkipäivää jo vuosia Tosin projektit ovat olleet kalliita sekä tuottaneet usein pettymyksiä SOA:n periaatteiden uusi tuleminen rakentuu pitkälti standardiintegraatiorajapintojen kehittymiseen Web Service standardirajapintojen syntyminen sekä yleistyminen on merkittävä syy periaatteiden leviämiseen Tarjolla on paljon välineitä, jotka tarjoavat tavan yhdistää järjestelmiä toisiinsa
Sakari.olli@tieturi.fi Kiitos!