www.solita.fi solita@solita.fi
JAVA-SOVELLUSTEN RAKENTAMINEN INTEGROITUUN YMPÄRISTÖÖN Jarno Peltoniemi Solita Oy 10.5.2005
Aiheet Johdanto Portaalit, portletit Oracle Portal Java-sovelluksen rakentaminen portaaliympäristöön Sovellusarkkitehtuuri Erityishuomioita Esimerkkicase: Myyntiportaali Ympäristö: Lähtötilanne, tavoitetila Integraatiopisteet Käytetyt teknologiat Prosessi Päätössanat
Johdanto
Portaali Yritysportaali on keskitetty kanava tiedon jakamiseen ja sovellusten julkaisemiseen web-ympäristössä Integraatioalusta, jolla yrityksen sovellukset koostetaan yhteen
Portaalien ominaispiirteitä Yhtenäinen ulkoasu Monikielisyys Sovellukset käytettävissä yhdellä kirjautumisella Pääsynvalvonta Personoitu sisältö Tiedon koostaminen eri lähteistä Julkaisuprosessi
Portaalin sivukomponentit Staattinen sisältö Portlet - dynaamista sisältöä tuottava portaalisovellus Tietosisältö voidaan hakea portaalin ulkopuolelta Myös koko portletsovellusta voidaan suorittaa portaalin ulkopuolella
Oracle Portal Taustalla Oracle tietokanta, jossa Metadata Staattinen ja dynaaminen sisältö sekä Osa portaalin toimintalogiikasta. Keskitetty käyttäjänhallinta ja kertakirjautumisjärjestelmä Helppokäyttöinen WYSIWYG-editointi portaalisisällölle web-käyttöliittymässä
Sivukomponentit Oracle Portaalissa Staattinen sisältö: teksti, kuvat, linkit, html Lukuisia tapoja tehdä dynaamisia sivukomponentteja: Java-portlet PL/SQL-portlet Portaalin sisällä tehdyt dynaamiset komponentit Tiedon kaappaus muilta web-sivuilta Strukturoidun, ulkopuolisen tiedon esitys (Web Services, XML, SQL) Kaikille tavoille löytyy hyviä käyttökohteita Opettele useampi kuin yksi tapa, valitse tarpeeseen sopivin
Java-sovelluksen rakentaminen portaaliympäristöön
Java-sovellusten rakentaminen portaaliin Java-portletteja ajetaan J2EE-containerissa Portaali ohjaa portlet-sovellusta verkkorajapinnan yli Oracle Portaalissa oma protokolla, standardiprotokollakin on olemassa (WSRP - Web Services for Remote Portlets) Oracle Portaalissa oma portlet API, standardirajapinta Java-portleteille on myös määritelty (JSR-168)
Portaalisovelluksen erot perinteiseen sovellukseen nähden Protokolla määrittelee eri tyyppisiä pyyntöjä (JSR- 168: action ja render) Erillinen API sovellusten rakentamiseen Portaalissa URL-osoitteet eivät osoita suoraan portletin resursseihin vaan ohjaavat portaalia Portaaliympäristössä URL-osoitteiden rakentamiseen oma palvelunsa Eri tiloja portlet-ikkunalla (esim. maximized) ja portletsovelluksella (esim. help) Portlet-sovellus generoi vain osan lopullisesta HTMLsivusta
Java ja portlet-sovellukset Yleinen web-sovellusten arkkitehtuuri Solitassa Miten portlet-rajapinta otetaan mukaan?
Business Service DAO Implementation Java-sovellusten arkkitehtuuri: sovelluslogiikka Sovelluslogiikka koostuu palvelukerroksesta ja Domain Model tietomallista Pelkästään tavallisia Java-olioita Tiedon haku tietokannasta yleensä ORM-työkalulla Uudelleenkäytettävä paketti
Web-sovellusten arkkitehtuuri Kuorrutetaan sovelluslogiikkapaketti web-rajapinnalla Käytetään jotakin MVC-kehystä: Model Sovelluslogiikkapaketti View JSP Controller Liima välissä Vastaavasti kuorruttamalla palveluun voitaisiin toteuttaa etärajapinta esim. Web Services tai EJBtekniikoilla Etäkutsurajapintoja ei ole järkevää käyttää sisäisesti websovelluksessa vaan ainoastaan integraatiorajapintoina
Web-sovellus portlet-maailmaan Protokollien, API:n ja URL-osoitteiden erot aiheuttavat päänvaivaa Protokolla ja rajapinta voidaan sovittaa siltakomponentilla URL-luonti kannattaa kätkeä rajapinnan taakse Sivujen yhteiset osat luodaan ehdollisesti vain web-ympäristössä, portlet-ympäristössä generoidaan vain osittaisia sivuja
Portlet- ja servlet-rajapintojen siltakomponentit Oraclen siltakomponentti StrutsRenderer Välittää sivuosoitteen portlet-parametrinä Strutsin JSP-tagikirjastoa on muutettu toimimaan Oraclen portletympäristössä StrutsRenderer toimii myös muilla sovelluskehyksillä kuin Strutsilla Voidaan yhdistää tagikirjastoon, joka generoi URL:it läpinäkyvästi sekä servlet- että portlet-ympäristössä Standardiportleteilla täysin erillinen API Paljon sillattavia rajapintoja, jos käytetyssä MVC-kehyksessä riippuvuus Servlet-ympäristöön Voidaan kuitenkin ratkaista samalla tavoin kuin Oraclen portlet API:n kanssa Paras ratkaisu olisi MVC-sovelluskehys, jossa servlet/portlet rajapinnat olisi valmiiksi kätketty abstraktion taakse
Esimerkkicase Myyntiportaali
ERP 1 ERP 2 Lähtötilanne: Ympäristö Käytössä useita toiminnanohjausjärjestelmiä Samaa tietoa eri muodoissa eri järjestelmissä ERP 3
Integraatiotietokanta ERP 1 ERP 2 ERP 3 Ympäristö: integraatiokanta Toiminnanohjausjärjestelmät integroitu Oracle-tietokantaan Integraatiokanta toimii läpinäkyvästi yhtenä, yhtenäisenä toiminnanohjausjärjestelmänä, mm. Saatavuushaku Tilausten teko
Tavoitetila: Myyntiportaali Myyntiportaali Integraatiotietokanta Yksi, yhtenäinen käyttöliittymä myyntijärjestelmään Laajennettavuus, uusien sovellusten tuontimahdollisuudet => Portaali ERP 1 ERP 2 ERP 3
Myyntiportaali Oracle Portal 10g Release 1 (9.0.4) Toteutettiin myyntiportaalin sovelluslogiikkapaketti ja sen päälle Javaportletteja Asiakkaille tarkoitetut sovellukset Järjestelmän ylläpitäjien sovellukset Integraatio olemassa olevaan käyttäjänhallintaan
Myyntiportaalin integraatiopisteet Integraatiotietokanta Keskitetty käyttäjänhallinta Microsoft Active Directoryssa Portaalirajapinta
Käyttäjänhallinta Käyttäjien ja ryhmien ylläpito Active Directory Myyntiportaali Oracle Internet Directory Käyttäjätiedot Active Directoryssa Oracle Portal käyttää aina omaa käyttäjähakemistoa Synkronointi Oracle Directory Integration Platformilla Käyttäjien ja ryhmien synkronointi
Käyttäjähakemiston synkronoinnissa huomioitavaa Hakemistopuun rakenne Rakenteiden hierarkkisuus säilyy synkronoitaessa Huomioi synkronointitarve jo lähdehakemiston rakennetta suunniteltaessa Tietosisältö Hakemistoissa pakollisia kenttiä, eri hakemistoissa eri kentät ovat oletusarvona pakollisia Synkronointi Rajaa siirrettävä tieto tarkasti Virhetilanteet, seuranta
Portaalisovellukset Core Customerweb Integraatiotietokanta Admin-web Web-käyttöliittymä, silta portletympäristöön Palvelukerros, tietokantakerros Core-moduulissa palvelu- ja tietokantakerrokset Core-moduulin päälle rakennettu kaksi itsenäistä käyttöliittymämoduulia: customer-web ja admin-web Kumpikin käyttöliittymä toimii sekä portaalissa että itsenäisenä sovelluksena Tulevaisuudessa tarkoituksena toteuttaa Web Services -integraatiorajapinta erillisenä moduulina coremoduulia hyödyntäen
Java-sovelluskehitys: Käytetyt teknologiat Oracle Portal Developer Kit Spring Framework Hibernate Open Solita komponentit Lisäksi muutama pienempi Open Source tuote
Prosessi Kehitysväline Eclipse IDE Yksikkötestaus kehityksen ohessa Jatkuva integraatiotestaus ajastettuna Web-käyttöliittymän testaus Tomcat 5.0:ssa, perinteisenä web-sovelluksena Toimituspaketin luonti Vienti testiympäristöön, hyväksymistestaus portaaliympäristössä portlet-sovelluksena Vienti tuotantoympäristöön
Käyttöönotto Portaalin käyttöönotto ei ollut heti mahdollista Sovellusta käytettiin aluksi perinteisenä websovelluksena Onneksi sovellus toimi myös ilman portaalia Sovellus otettiin käyttöön kahdessa portaalissa Molemmissa oma graafinen ilmeensä Sovellus mukautui helposti kumpaankin portaaliin
Päätössanat
Odotukset lähivuosille Sovelluskehitys portaaliympäristöön yleistyy Oraclen sovelluspalvelimeen vihdoin tuki WSRP-standardille ja JSR-168-portleteille Standardiratkaisut portaalisovellusten tekemiseen Laajempi portlet-tuki valmissovelluksiin standardien avulla sekä omiin että kolmansien osapuolten tuotteisiin
Kiitokset! Kysymyksiä saa lähettää ( jarno.peltoniemi@solita.fi) Hauskaa päivänjatkoa!