Integrointi? Tavoitteena yhdistää eri tavoin toteutetut ja eri tavoin toimivat järjestelmät; integration & interoperability. Joitain motivaattoreita... 1. Enterprise Application Integration: Eri organisaatioissa (tai saman organisaation osissa) käytettävät sovellukset tai järjestelmät, jotka halutaan yhdistää ts. saattaa toimimaan yhteen. Mutta ei haluta tai voida käyttää samaa järjestelmää kuin esim. yhteistyökumppani: tottumukset, toimintatavat ja -mallit, järjestelmäalustat, kustannussyyt jne.
Integrointi? Motivaattoreita... 2. Uusia käyttökanavia ja -muotoja olemassa oleville sovelluksille, konvergenssi? Esim. mobiili, Web... Pyrkimys pois nk. point-to-point integroinnista Tapauskohtaisiin tarpeisiin vastataan tapauskohtaisilla (purukumi)ratkaisuilla. Kallista, aikaa vievää, ei skaalautuvaa tai toistettavaa.
FYI1. Remote Procedure Call Protokolla, jota käyttäen mahdollista käyttää toiselle tietokoneella sijaitsevia palveluja verkon yli, tuntematta verkon ja palvelun yksityiskohtia. Mahdollistaa sovellukset, jotka käyttävät useita verkossa sijaitsevia ja heterogeenisilla alustoilla toimivia ohjelmia. Kommunikointi asiakkaan (palvelua käyttävä) ja palvelimen (palvelun tarjoava) välillä synkronista (call/wait) RPC:n tehtäviä: määritellä palvelut, vaaditut/hyväksytyt parametrit, vastaukset (pyyntöjen ja vastausten väliset suhteet), autentikointi, virheenhallinta.
Remote Procedure Call Client application Remote server app. Local response Local procedure calls Local response Local procedure call Local response Local application or OS Stub RPC Mechanism Remote procedure calls Stub RPC Mechanism
Enterprise Application Integration Vastauksena point-to-point -integroinnin ongelmiin. Esim. erilaisten ERP-sovellusten yhteentoimivuuden toteuttaminen; yleensä sovittua protokollaa, middlewareja (FYI2) ja kustomoitua koodia käyttäjen EAI-palvelimet: valmiita ratkaisuja, joissa paketoituna sovittimia erilaisille järjestelmille sekä työkaluja esim. in-house -sovelluksia varten. Kehittyneitä ominaisuuksia mm.: datan muunnokset transaktioiden koordinointi kommunikoinnin hallinta liiketoimintaprosessien hallinta Heikkouksia: kustannukset monimutkaisuus suljetut (proprietary) arkkitehtuurit
Enterprise Application Integration Strenghts Challenges Overcomes the limitations of custom point-to-point integration by providing a repetable and scalable framework. Is acknowledged as an established integration approach used by many companies. Has a proven ability to support high transaction volumes, reliability, security, and performance demanded by business-critical applications. Provides a full complement of features such as data transformation and translation, businessprocess management, messaging layer, and transaction coordination. Proprietary architecture and adapters result in platform, programming language, and vendor lockin. Technology is expensive and complex to implement. Adapters between integration servers aren t interoperable and must be updated when a new version of an application is released. Future of this approach is somewhat in doubt as some EAI vendors beging to de-emphasize proprietary adapters as a primary integration method. D. Homan, S. Kalavagunta, C. Klima: Web Services And Integration (http://www.informationweek.com/story/showarticle.jhtml?articleid=6503768)
Trendejä... EAI-sovellusten valmistajien täytyy pysyä mukana EA:iden ja third-party sovellusten julkaisutahdissa: siirtyminen proprietaryratkaisuista kohti avoimia tekniikoita. Kts. esim. http://www.vitria.com/ http://www.webmethods.com/ Esim. J2EE Connector Architecture (JCA) ja Web Services - tekniikat (WS) JCA 3rd-party-ohjelmistotuottajien ohjelmistoille stardardimuotoinen JCA-sovitin, joka toimii kaikkien J2EE-yhteensopivien sovelluspalvelinten ja EAI-tuotteiden kanssa. Strengths Challenges Lets vendors provide a single, reusable standard resource adapter for all J2EE-compliant application servers. Is supported by many EAI vendors and packaged application vendors. Is more cost-effective than maintaining adapters for multiple proprietary integration servers. D. Homan, S. Kalavagunta, C. Klima: Language support is limited to Java and requires J2EE-compatible application servers. Integration via JCA isn t as robust as the native proprietary adapters. Technology is still maturing.
Web Services WS-tekniikka rakennettu avoimien W3C:n standardien varaan Riippumaton käytettävästä alustasta ja ohjelmointikielestä (kirjastot toteutettu tällä hetkellä n. 70 kielelle). Ajatuksena integroinnissa WS-teknologiaa käyttäen on tehdä ohjelmasta tai komponentista itsensäkuvaava palvelu, joka on muiden heterogeenisilla alustoilla toimiven sovellusten saatavilla. Koostuu kolmesta erillisestä tekniikasta: WSDL - Web Services Definition Language UDDI - Universal Description, Discovery and Integration SOAP - Simple Object Access Protocol
WSDL & UDDI Web Services Description Language (WSDL), XML-pohjainen kieli palvelujen kuvaamiseen ja määrittelyyn; palvelun nimi, saantipaikka (URL), vaaditut parametrit ja niiden tyypit jne. http://www.xmlbus.com:9010/wsdlclient/wsdldynami ctestclient.html Universal Description, Discovery and Integration (UDDI) Palvelurekisteri, jota käytetään palvelujen mainostamiseen ja etsimiseen; Keltaiset sivut-tyylinen ratkaisu. https://uddi.ibm.com/testregistry/find
SOAP XML-pohjainen protokolla palvelujen ja sovellusten väliseen tiedonvälitykseen. Voidaan käyttää joko RPC-protokollan tyyliin synkronisena tai dokumenttikeskeisesti asynkronisena. Liikennöinti tavallisesti, mutta ei välttämättä, HTTP:n yli. SOAP-viestinvälityksen toiminta tiivistetysti: 1. Asiakas generoi palvelukutsun, joka paketoidaan SOAP-envelopeen (Se) 2. Palvelinpää vastaan ottaa Se:n, purkaa sen ja välittää kutsun ja parametrit sen suorittavalle ohjelmalle. 3. Ohjelma käsittelee kutsun. Vastaus paketoidaan uudelleen Se:ksi ja lähetetään asiakkaalle. 4. Asiakas vastaanottaa vastauksen sisältävän Se:n, purkaa sen ja välittää vastauksen kutsun tuottaneelle ohjelmalle.
SOAP-envelope Esimerkki SOAP-envelopesta Pyyntö: <?xml version="1.0" encoding="utf-8"?> <SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/xmlschema" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance"> <SOAP-ENV:Body SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <m1:inchtomm xmlns:m1="urn:target-converter-service"> <param0 xsi:type="xsd:float">15.0</param0> </m1:inchtomm> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Vastaus: <?xml version="1.0" encoding="utf-8"?> <SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/xmlschema" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance"> <SOAP-ENV:Body SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <m1:inchtommresponse xmlns:m1="urn:target-converter-service"> <return xsi:type="xsd:float">381.0</return> </m1:inchtommresponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
WS:n toimintamalli UDDI-rekisteri WSDLkuvaus Palvelu Sovellus A SOAPparseri SOAPenvelope SOAPparseri Sovellus B
Web Services EAI:ssa Strenghts Based on open standards supported by most major software companies. Challenges Current Web-service strandards support only simple request/response functionality and lack support for complex multiple transactions. Leverages a company s existing systems, infrastructure, and development skills, and enables reuse of technology components. Offers cost-effective and faster solutions to integration problems than conventional application integration methods. Is platform and programming-language independent. Provides interoperability between J2EE and.net environments and is supported by both J2EE and.net development tools. Web-services integration typically doesn t perform as well as native proprietary adapters. Standards around security and transactions are still emerging, so most Web services are deployed inside the firewall. Lacks inherent notion of data transformation, business-process management, messaging, and transaction capabilities. D. Homan, S. Kalavagunta, C. Klima: Web Services And Integration (http://www.informationweek.com/story/showarticle.jhtml?articleid=6503768)
FYI2: Middleware Monikerrosarkkitehtuurit ja middleware-ratkaisut Erotetaan esityskerros, sovelluskerros ja tietovarastot Asiakaskerros kommunikoi keskimmäisen kerroksen (middleware tai middle-tier) kanssa. Middle-tier kommunikoi edelleen tietovarastojen, backendsovellusten jne. kanssa; suorittaa tarvittavat muunnokset jne. Helpottaa erilaisten arkkitehtuurien yhteensovittamista, sitä kautta uusien julkaisu- ja saantikanavien kehittämistä jne. Järjestelmän muutostarpeet voidaan usein toteuttaa middle-tier -tasolla, puuttumatta muihin osiin.
Three-tier systeemi Asiakas 1 Palvelin 1 Asiakas 2 Asiakas 3 Asiakas 4 API Protokolla Asiakasliittymät, APIt ja protokollat Middleware API Protokolla Palvelinliittymät, APIt ja protokollat Palvelin 2 Palvelin 3 Palvelin 4
AvantGo M-Business Server Esimerkki uuden käyttökanavan (mobiili) mahdollistavasta middle-tier sovelluksesta. AvantGo Client Third party software Compressed web pages Form submissions, page and sync requests AvantGo M-Business server Uncompressed web pages Form submissions, page requests Web server Form submissions Result pages Backend apps: ERP, inventory, GW, etc. Web pages Supporting data Submitted form data Result data Corporate databases
Web & SOAP Esimerkki Web-kanavan toteuttamisesta WS-tekniikalla SOAP msg HTML interface Client app w/ SOAP client HTTP server / listener app. WS interfaces / Server CORBA COM Klara vappen Servlet EJB Backend applications Corporate databases