Päihittääkö J2EE.NETin SOAn pohjana?

Transkriptio

1 Päihittääkö J2EE.NETin SOAn pohjana? Nääsvillen Oliopäivät Pekka Kähkipuro Kehitysjohtaja, FT

2 Sisällys Miksi SOA? Palvelukeskeinen arkkitehtuuri Ratkaiseeko SOA haasteet? Web Services mistä on kysymys? SOA ja Web Services Web Services ja.net Web Services ja Java Web Services ei yksin riitä Kuka voittaa SOA-sodan vai onko sotaa olemassakaan? Yhteiskäytön ydinkonsepti: Enterprise Service Bus Yhteenveto Copyright SysOpen 2

3 Miksi SOA? Haaste Monimutkaisuus Haastava integraatio e-maailma Yhteisen kielen puute Aiemmat ratkaisut Pitkä elinkaari Joustavuusvaatimukset Kuvaus Järjestelmät ovat entistä monimutkaisempia Järjestelmien väliset integraatiot ovat yhä monimutkaisempia toteuttaa, ja monimutkaisuus kasvaa Internet ja liiketoiminnan sähköistyminen ovat tuoneet uusia vaatimuksia ja tarpeita järjestelmien käytölle Järjestelmien väliselle integraatiolle ei ole ollut mitään yhteisesti sovittua mallia ja käytännön toteutustapaa Aiemmat yritykset eivät ole ratkaisseet pulmia, mutta ovat jääneet elämään (olioteknologia, komponentit, middleware) Järjestelmien elinkaari ja varsinkin tiedon säilyvyys on osoittautunut ajateltua pidemmäksi Joustavuusvaatimukset ovat kasvaneet: muutoksia vaaditaan yhä enemmän ja yhä nopeampaan tahtiin Copyright SysOpen 3

4 Esimerkki: elinkaarivaatimukset Data/sisältö Palvelut Käyttöliittymät Tekniset innovaatiot/tuotteet Teknologia (ajoalustat) vuosia Lähde: Enterprise SOA. Service Oriented Architecture Best Practices Copyright SysOpen 4

5 Miksi SOA? Hajautusmiddleware kypsässä iässä Hajautusta tukevilla komponenttimalleilla ja middlewareilla on pitkä historia Open Software Foundation: DCE (1992) Object Management Group: CORBA (1995) Microsoft: OLE 1 (91), OLE 2 (93), COM (95), DNA (97),.NET (2001) Sun: J2EE (1999) Haasteita sekä teknisellä että kaupallisella tasolla Työmäärät lisääntyneet huimasti (uudet käyttöliittymät, integraatio,...) Toivo uudelleenkäytössä, mutta uudelleenkäyttö jäänyt syntymättä Toivo olioiden tms. tuottavuudessa, mutta tuottavuus laskenut Epäyhteensopivuus hämmentävää, ihmeellisiä integraatiovirityksiä Kaupallisten erimielisyyksien myötä sama asia ratkaistu ties kuinka monta (esim. RPC-tekniikat, protokollat ja siirtosyntaksit) Integraatio yhä vaikeampaa ja kalliimpaa Copyright SysOpen 5

6 Miksi SOA? Arkkitehtuurinäkemys murroksessa Olioiden uudelleenkäyttö ei vastannut vaatimuksiin Tehotonta (vain yhden luokan verran) ja työlästä (osattava liikaa) Oliomallinen uudelleenkäyttö sopii sovelluksen sisäiseksi malliksi Uudelleenkäyttö komponenttitasolla ei sekään riittänyt Black box -ajattelu helpottaa ja komponentitkin voivat olla aika suuria Vaikeudet ajoympäristössä, komponenttien keskinäisessä riippuvuudessa, komponenttimarkkinoiden kehittymättömyydessä, komponenttirajapintojen teknisyydessä Uusi toivo: uudelleenkäyttö liiketoimintapalveluiden tasolla Riippuvuutta vähentävät liiketoimintatason rajapinnat Ajoympäristöä helpottaa vahva tuki heterogeenisyydelle (ainakin teoriassa) Komponentit voivat olla eri kokoisia ja eri ikäisiä (keskuskoneesta warriin), kunhan ne tarjoavat sovitun palvelurajapinnan Uuden toivon nimi: SOA Copyright SysOpen 6

7 Palvelukeskeinen arkkitehtuuri, SOA Palvelukeskeinen arkkitehtuuri pyrkii ratkaisemaan edellä mainitut ongelmat Mitä on SOA? Service Oriented Architecture is an architectural style whose goal is to achieve loose coupling among interactive software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Dr. Hao He, W3C Web Services Architecture Working Group Copyright SysOpen 7

8 Palvelukeskeinen arkkitehtuuri, SOA Toiminnallisuus kootaan palveluihin Vältetään osajärjestelmäjako (siilot) ja monoliitit Käytetään uudelleen samoja palveluita eri sovelluksissa Palvelut kerrostetaan Kerrosten elinkaaret ja toteutustekniikat voivat vaihdella Nopeat syklit mahdollisia koosteisissa palveluissa Liiketoimintaprosessit palveluiden määrityksen pohjana Palvelut kuvataan liiketoimintatason käsitteillä Löyhä sidonta palveluiden käyttäjän ja toteutuksen välillä Ajonaikainen sidonta Palvelut toteutetaan mustina laatikoina Toteutus ja rajapinta erotetaan toisistaan Uudelleenkäyttö tapahtuu palveluina Helpompi jäsentää, toteuttaa ja hallita kuin muut uudelleenkäytön muodot Järjestelmän rakentaminen muuttuu integraatioksi Integraation pohjana sopimus (eikä havaittu toiminta) Copyright SysOpen 8

9 Ratkaiseeko SOA haasteet? Haaste Monimutkaisuus Haastava integraatio e-maailma Yhteisen kielen puute Aiemmat ratkaisut Pitkä elinkaari Joustavuusvaatimukset Ratkaisu Monimutkaisuus eristetään palvelurajapintojen taakse Integraatiolle annetaan ensimmäistä kertaa yhtenäinen arkkitehtuurimalli toteutusteknologiasta riippumatta Liiketoimintatason Internet-käyttö ja sähköiset palvelut ovat käännettävissä palvelukeskeisen arkkitehtuurin teknisiksi palveluiksi Ensimmäinen taso yhteisessä kielessä on yhteinen metatason arkkitehtuurimalli (SOA), tämän jälkeen voidaan etsiä yhteistä kieltä tai edes kielten välisiä käännöksiä SOA on lähtökohtaisesti aiemmat teknologiat säilyttävä ja niiden päälle rakentava malli Palvelurajapinta ei ota kantaa se takana olevan toteutuksen tai tiedon ikään; samakin toteutus voi tarjota monen sukupolven palvelurajapintoja Palveluiden uudelleenkäyttö antaa mahdollisuuden nopeasti lisätä tai muuttaa liiketoiminnalle näkyvää toiminnallisuutta Copyright SysOpen 9

10 Web Services lyhyesti Lähtökohta: Web Services on sähköinen palvelu, joka Kuvataan WSDL-dokumentin avulla Rekisteröidään UDDI-palvelurekisteriin Käyttää liikennöintiin SOAP-protokollaa Web Services lupaa samaa sovellusten väliselle kommunikoinnille kuin WWW tarjosi sovelluksen ja ihmisen kommunikoinnille Yksinkertainen Kaikkien hyväksymä ja toimittajariippumaton Toimii nykyisen verkkoinfrastruktuurin jatkeena Ei edellytä tiukkaa sidosta osapuolten välillä Toimii monenlaisten kommunikointimallien kanssa Lupauksen seurauksena on syntynyt Web Services -huuma Monia standardoijia: W3C, Oasis, yritykset, WS-I Paljon uusia protokollia: Copyright SysOpen 10

11 Palvelukeskeinen arkkitehtuuri ja Web Services Web Services näyttää muodostuvan teknologiariippuvuuden aidosti poistavaksi konseptiksi HTTP/SOAP ja XML ovat toteutusteknologian suhteen puolueettomia Riittävä kilpailevien vendorien tuki taustalla (IBM, MS, BEA, Oracle,...) XML luonnollinen tapa kuvata siirrettävä rakenteellinen tieto Palveluluonteen takia sekä rajapinnan kutsuparametrit että paluuarvot saattavat sisältää paljon tietoa XML-skeeman muuttaminen ei muuta itse rajapintaa Palvelurajapinnasta saadaan helposti luonnollinen (ei getter/setter-sillisalaattia) Malli on laajennettavissa moneen muuhun Esim. BPEL4WS (Business Process Execution Language for Web Services) tarjoaa mahdollisuuden koostaa korkeamman tason liiketoimintapalveluja deklaratiivisesti Web Services = palvelukeskeisen arkkitehtuurin standarditoteutus Through 2008, SOA and Web services will be implemented together in more than 75 percent of new SOA or Web services projects (0.7 probability). Gartner, Copyright SysOpen 11

12 Web Services -protokollia Lähde: Web Services Roadmap, Copyright SysOpen 12

13 ... Ja valmiusasteita Specification - Exists only as draft specification. Any usage requires hand coding. Experimentation - Early implementations provided by vendors permit experimentation, but are not recommended for production use. (e.g. technologies available from IBM Alphaworks do not support production use) Early adoption - More robust implementations available and protocol well into standards process, encourages production usage by end user organizations Mainstream - Standard ratified, or wide scale de facto adoption Lähde: Web Services Roadmap, Copyright SysOpen 13

14 Web Services ja.net.net-arkkitehtuuri perustuu monen ohjelmointikielen rinnakkaiseen käyttöön yhdessä käyttöjärjestelmässä (vrt. Java tai CORBA) Luonnollinen tarve ohjelmointikieliriippumattomalle rajapintojen kuvausmekanismille: Web Services Integraatio.NETissä ON Web Services, muita keinoja ei ole Microsoft alusta pitäen vahvasti mukana.net-kehityksessä Esim. Sun tuli mukaan vasta myöhemmin Microsoft vakioi Web Service -käytön omissa kehitysvälineissään Yhdenmukaisempi malli kuin Java-maailmassa Haasteena perinnemaailman integrointi Web Services ei ole käytettävissä kaikkialla Copyright SysOpen 14

15 Web Services ja Java Keskeiset Java-toimittajat vahvasti Web Services -junassa Sun tuli tosin mukaan vasta Pasilassa Joukko standardeja Java Web Services Developer Pack (Java WSDP) Java API for XML-Based RPC (JAX-RPC) Java API for XML Messaging (JAXM) Java API for XML Registries (JAXR) Java API for XML Processing (JAXP) Java Architecture for XML Binding (JAXB) SOAP with Attachments API for Java (SAAJ) Nyt myös WS-pohjainen EJB-palvelu (stateless session bean) Vendoreilla hyvä tuki WS-peruseväille SOAP tuettuna käytännössä kaikissa tuotteissa Myös Open source -toteutuksia Laaja valikoima mekanismeja XML-dokumenttien käsittelyyn SOAP-toteutus: Apache AXIS Kasvava tuki edistyneemmille Web Services -piirteille Esim. AlphaWorks: IBM Business Process Execution Language for Web Services JavaTM Run Time (BPWS4J) Copyright SysOpen 15

16 Java Web Services -tuotteita Copyright SysOpen 16

17 Web Services ei yksin riitä Web Services tarjoaa palvelupohjaisen integraatioarkkitehtuurin uusille heterogeenisille ratkaisuille Web Services tarjoaa järjestelmien väliselle kommunikoinnille saman kuin WWW tarjosi järjestelmän ja ihmisen väliselle kommunikoinnille Internetissä toimiva, teknologiariippumaton, helppo toteuttaa... Perinteinen integraatio on edelleen olemassa Legacy-järjestelmät, paketit Laaja joukko vakiintuneita integraatiomalleja Homogeenisten järjestelmien sisäinen integraatio Web Services soveltuu näiden hoitoon kehnosti Hyvä integraatioratkaisu tarjoaa Keinot heterogeenisen kokonaisympäristön hoitoon Keinot osajärjestelmien sisäiseen integraatioon Mekanismin, jolla edelliset voidaan yhdistää CASE: Numeron siirrettävyys SysOpen mukana mm. Radiolinjan ja DNA:n (ent. Telia Mobile) osissa Copyright SysOpen 17

18 Teknologialeirien integraatioratkaisujen vertailua Integration tyyppi J2EE-ratkaisumalli.NET-ratkaisumalli Uusi integraatio heterogeenisessa maailmassa Web Services Web Services Integraatio homogeenisessä ympäristössä Java-pohjaiset integraatiotekniikat (RMI, JMS, jne.) Web Services, ohjelmointikielten sisäiset mekanismit Integraatio perinneympäristöissä J2EE:n perinneintegraatiotekniikat (J2EE CA, JMS, integraatiobrokerit jne.) Web Services, BizTalk Copyright SysOpen 18

19 SOA on kaikkea muuta kuin tekniikkaa Lähtökohtana liiketoimintaprosessit Palvelut etsitään prosessien kautta Liiketoiminnan kannalta merkityksellisiä palveluita Jäljitettävyys liiketoiminnan vaatimuksiin ja omistajaan Palvelut määrittävät kokonaisarkkitehtuurin Business Service Bus IT-arkkitehtuurin ja liiketoiminnan rakenteet lähestyvät toisiaan Tuloksena mm. joustavuutta liiketoiminnan vaatimuksiin Kokonaisarkkitehtuuri määrittää toteutustekniikat Palveluittain valitaan sopivin toteutus Paketti Räätälöity Ostettu palvelu Toteutus voidaan tarvittaessa myös vaihtaa Copyright SysOpen 19

20 SOA muuttaa maailmaa Service-oriented development of applications (SODA) Lähtökohtana palveluiden koostaminen ja tarvittavan koodin generointi sopivista kuvauksista (mm. Model Driven Architecture, MDA) Ohjelmointi vähenee, tilalle tekniikoita, joilla erikseen toteutettuja palveluita sovitetaan toisiinsa Service-oriented business applications (SOBA) Yritystason järjestelmien ja valmispakettien rakenne muuttuu monoliiteistä aitoon modulaarisuuteen (mm. SAP/xApps) Valmispakettien ja räätälöidyn toiminnallisuuden yhdistäminen muuttuu SODA-työksi Mahdollisia uusia toimintamalleja Software as Services: ohjelmisto tai sen osa voi muuttua ostettavaksi palveluksi (ASP ei ole lähtenyt lentoon koska ohjelmistot eivät ole sitä tukeneet; SOA tekee tämän muutoksen mahdolliseksi) Myös liiketoiminnan osien ulkoistaminen voi helpottua, kun sitä tukeva IT-ratkaisu voidaan ohjata palveluna muualle Copyright SysOpen 20

21 Mikä teknologia voittaa SOA-sodan? SOA-sotaa ei olekaan, sillä SOA on lähtökohtaisesti heterogeenisuuden mahdollistaja ja vahvistaja.netin sisäinen Web Services -käyttö on hyvä mainos, mutta helpottaako se sittenkään kokonaisarkkitehtuurin rakentamista? Java-maailman (liiankin) monipuoliset Web Services -tekniikat ovat nekin jännittäviä asioita, mutta auttavatko nekään kokonaisuuden hallinnassa pitkällä aikajänteellä? Web Services on yksi toteutus SOAlle Keskeinen toteutus lähiaikojen standardiympäristöissä Aiemmat toteutukset jatkavat elämäänsä legacy-maailman kanssa Todennäköisesti jatkossa kehitetään suorituskykyisempiä ja monimuotoisempia (mutta yhteensopivia) SOA-toteutustekniikoita (esim. mobile SOA ) Paras SOA-teknologia on se, joka Tarjoaa eväät SOA-mallin toteutukseen liiketoimintatasolla Tarjoaa parhaan toteutustavan järjestelmän sisäiselle toteutukselle Absoluuttisesti parasta teknologiaa ei siis ole Copyright SysOpen 21

22 Yhteiskäytön eräs malli: SOA Web Service Framework WS-Management WS-Orchestration (Process-BPEL) WS-Security (Agreements, Federation, Policy, WS-Sec) ENTERPRISE SOA WS-Reliability (Pub-Sub, Peer-To-Peer) WS-Transactions Service Registry (UDDI,WSIL) APIs (JAX*, XML*, ) APIs (.NET*, ) SOA FOUNDATION WS-I Profile (SOAP,WSDL) Lähde: Oracle Copyright SysOpen 22

23 Yhteiskäytön ydinkonsepti: Enterprise Service Bus Win App..NET App. Java App. Web App. Mobile App. Prosessipalvelut BPEL(4WS), WS- Coreagraphy, WS-Orchestration, jne. Enterprise Service Bus (ESB) Business Service Bus (BSB) Yhdistää eri middleware-teknologiat Palvelut: Tilan hallinta, transaktiot, muunnokset, sanomaliikenne, jne. J2EE Web Service Service interface Common encapsulation Common alphabet, language, format Common Security Common error handling, ASP.NET Web Service Service interface Common encapsulation Common alphabet, language, format Common Security Common error handling, Business Layer Business Layer Data Access Layer Data Access Layer Data Data Copyright SysOpen 23

24 Yhteenveto SOA-huuman taustalla on aito hätä Suuri joukko haasteita, joita edellisen sukupolven teknologiat eivät ole osanneet ratkaista SOA tarjoaa ratkaisuja ainakin teoriatasolla Lähtökohtana heterogeenisuus aiemman homogeenisuuden asemesta Uudelleenkäytön joustavuutta palveluiden tasolla aiemman komponenttitason k Lähes kaikille sopiva yhteinen malli käsitteellisellä tasolla Web Services on SOAn standarditoteutus Sopii sekä.net- että Java-ympäristöihin Yhteisesti hyväksytty ja teknisellä tasolla riittävä Web Services ei yksin riitä Legacy-maailmakin on hoidettava SOA on arkkitehtuuri, joka voi elää usean teknologian päällä SOA-sotaa ei voi voittaa, sillä kyseessä on yhteistyömalli Yhteiskäytön ydinkonsepti: Enterprise Service Bus Copyright SysOpen 24

25 Lyhenteitä SOA, SOBA, SODA, SOIA, ESB, BCA, BPM, BAM, BPML, BPEL, BPEL4WS, SOAP, UDDI, WSDL, WSRM, WSM, WS-I, J2EE, WSCI, WS-CAF, DIME, WSDM, WSIL, WSIA, WSRP, WS-CDL, Service-Oriented Architecture Service-Oriented Business Application Service-Oriented Development of Applications Service-oriented integration architecture Enterprise Service Bus Business Component Architecture Business Process Management Business activity monitoring Business Process Modelling Language Business Process Execution Language Business Process Execution Language for Web Services Simple Object Access Protocol Universal Description, Discovery And Integration Web Services Description Language Web Services-ReliableMessaging Web services management Web Services-Interoperability Java 2 Platform, Enterprise Edition Web Services Choreography Interface Web Service Composite Application Framework Direct Internet Message Encapsulation (Microsoft) Web Services Distributed Management Web Service Inspection Language Web Services For Interactive Applications Web Services For Remote Portlets Web Services Choreography Description Language Copyright SysOpen 25

26 Linkkejä Copyright SysOpen 26