J2EE on tätä päivää, ota, käytä ja nauti!

Transkriptio

1 J2EE on tätä päivää, ota, käytä ja nauti! Arkkitehtuurit vastakkain:.net vastaan Java Pekka Kähkipuro Sisällys Arkkitehtuurien vertailu on helppoa mutta niin vaikeaa Vaihtoehtoja Tasapainotettu mittaristo Toteutustekniikan turvallisuus PetStore-sovelluksen suorituskyky PetStore-sovelluksen koodin määrä Mutta mikä onkaan oleellista? Sovelluspalvelinhankkeiden oikeat haasteet Vertailu hankkeen onnistumisen näkökulmasta Yhteenveto Copyright SysOpen 2 1

2 Arkkitehtuurien vertailu on helppoa... Miksi vertailu on liiankin helppoa Karkealla tasolla arkkitehtuureissa samat elementit samassa roolissa, vain nimet vaihtuvat Sovellusarkkitehtuuriltaan saman monitasoisen sovelluksen voi vaikeuksitta toteuttaa kummalla tahansa Kuva: EAI Journal, January Copyright SysOpen 3... mutta niin vaikeaa Erilainen kohdemarkkina Microsoftilla pienet ja keskisuuret sovellukset (Office-liittymät jne.) Java-vendoreilla operatiiviset yritysympäristöt (M/F-liittymät jne.) Erilainen kehitysvälinefilosofia Microsoft panostaa aloituskynnyksen mataluuteen ja RADiin Java-vendoreilla erilaisia malleja (Eclipse, WSAD, JBuilder, XDE,...) Kypsyysasteet erilaiset Microsoft etsinyt painopistettä pitkään (OLE, COM, COM+,.NET) Java edennyt kohtuullisen pitkään samalla raiteella Syväteknologian tasolla ratkaisuissa selkeitä eroja Bytekoodin tulkkaus vs. välikielen käännös Tuloksena n-ulotteinen avaruus, jossa arkkitehtuurit ovat kussakin ulottuvuudessa hiukan eri pisteessä Todellinen vertailu on mahdotonta, ellei valitse tiukasti näkökulmaa ja rajaa samalla ulos muita tärkeitä näkökulmia Copyright SysOpen 4 2

3 Eräs vertailuvaihtoehto Tasapainotettu mittaristo Kuva: EAI Journal, January Copyright SysOpen 5 Eräs vertailuvaihtoehto Toteutustekniikan turvallisuus Thomas Novers, Java bytecode is run through a virtual machine or just-in-time compiler, while C# is tied into the IL (intermediate language) common language runtime (CLR).... Java still relies on a sandbox security model to keep Java code from going rogue. Microsoft, however, has moved away from the sandbox to a code-signing paradigm, where security is enforced through an "evidencebased" system that determines whether the code is safe based on where it comes from and not on runtime security checks. Another important factor to consider from a security standpoint is that Java has been running the Internet gauntlet for nearly a decade and has the benefit of years of testing and bug fixing behind it. C# is still a fledging language.... core premise for these two companies, the "security through obscurity [Microsoft] versus "open source security" model [Sun]. Vahvasti värittynyt näkemys, jossa kolikon toisella puolella on C#:n hienoinen tehokkuusetu Copyright SysOpen 6 3

4 Eräs näkökulma PetStore-sovelluksen suorituskyky Kuva: Middleware Company, October Copyright SysOpen 7 Eräs näkökulma PetStore-sovelluksen koodin määrä Kuva: Middleware Company, October Copyright SysOpen 8 4

5 Mutta mikä onkaan oleellista? Milloin bytekoodi/välikielitason turvallisuus on ollut keskeistä sovellusprojektin onnistumiselle? Kokemus: ei kertaakaan Mikä on keskeinen suorituskykyhaaste: sovellussuunnittelun oikeat ratkaisut vai platformin sisällä olevat hitausmomentit Kokemus: kaikki keskeiset suorituskykypulmat ovat olleet lähtöisin sovellussuunnittelun virheistä (platformista riippumatta) Kokemus: Jokainen platformi edellyttää oman tapansa tehdä sovellussuunnittelun, sovellusarkkitehtuurin ja koodauksen tasolla Onko kertaluonteisen piensovelluksen koodin vertailtavissa todelliseen laajaan sovellukseen? Ei: laajat sovellukset perustuvat lähes aina sisäiseen kehikkoon, joka hyvin tehtynä poistaa toisteisen koodin sovellustasolta Mikä onkaan TPC-vertailun price/performance-mittarin käyttökelpoisuus Kokemus: 70 % ohjelmistokustannuksista tulee käyttöönoton jälkeen, price/performance ei ota tähän osuuteen kantaa Copyright SysOpen 9 Uusi näkökulma Sovelluspalvelinhankkeiden arkipäivä Uuden teknologian projektit menevät johdonmukaisesti pitkiksi Silti suoranaista virhettä ei tunnu löytyvän Siispä yritetään uudestaan samoilla eväillä -- samalla tuloksella Projektipäälliköt putoavat kelkasta Kulttuurierot liian suuria, koodarit karkaavat projektijohdon käsistä Liiketoiminnan muutosnopeus ja komponenttiteknologian lupaukset eivät kohtaa -- projektipäällikkö yrittää venyä välissä Teknologia juoksee alta pois Projekti on vanhentunut valmistuessaan Jatkuva päivityskierre -- ja virheiden jäljityskierre Uudelleenkäyttöä ei saavuteta Komponenttimarkkinoita ei ole syntynyt Projektikohtaisia komponentteja ei osata käyttää uudelleen Toivotut tuottavuushyödyt toteutuvat vain harvoin Copyright SysOpen 10 5

6 Miksi sovelluspalvelinhankkeilla on niin vaikeaa? Sovellusarkkitehtuuri määrääväksi onnistumisen osatekijäksi Perinteisissä malleissa arkkitehtuurivaihtoehtoja oli merkittävästi vähemmän kuin nyt - arkkitehtuurin saattoi lukea vendorin manuaalista Oikeita valintoja on nyt monta, mutta samassa ratkaisussa on perusteltua käyttää vain yhtä (tai enintään kahta) Vendorit eivät enää ole oikeassa Raadolliset markkinat edistävät hypetystä -- tähän syyllistyvät kaikki Ratkaisun toimivuuden takaa vasta parin vuoden käyttö Kaikki keinot ovat sallittuja, myös kilpailijan virheiden toisto (ASP, JSP) Tekijöiltä edellytetään enemmän kuin ennen Liiketoiminnan vaatimukset muuttuvat aiempaa nopeammin Tietotekniikka on lähempänä operatiivista toimintaa Tuloksena on merkittävästi tiiviimpi suhde operatiiviseen toimintaan ja sen muutoksiin Myös teknologian (näennäis)kehitys kiihtyy koko ajan Copyright SysOpen 11 Keskeisiä ratkaisuja Kokemuksen pohjalta tarvitaan seuraavia ratkaisuja Sovellusarkkitehtuurille uusi keskeinen rooli Sovelluskehys käytöön perusarkkitehtuurin päälle Kehitysmenetelmän komponentointi Lisää koulutusta ja osaamista ennen kaikkea yritystason ratkaisuissa (Gartner: 70 % Java-koodareista osaa liian vähän) Projektiorganisaatioon uusia rooleja (arkkitehti, mentori) Uudelleenkäytön organisointi (uudelleenkäytön tuki projektin aikana, sadonkorjuu projektin jälkeen, integraatiotiimi, hankintaprosessi) Listasta puuttuvat ne keinot, joita riepostellaan julkisuudessa RAD-välineet (oikeasti tarvitaan sovellussuunnittelua) Suorituskyky (oikeasti tarvitaan arkkitehtuurisuunnittelua) Tietoturvadetaljit (oikeasti tietoturvakin on osa arkkitehtuuria, yksityiskohdat saadaan aina kuntoon jos kokonaisuus on hallussa) Web Services (oikeasti siirtosyntaksista sopiminen ei vielä auta) Copyright SysOpen 12 6

7 Hankkeen onnistumisen näkökulma Sovellusarkkitehtuuri Sovelluskehys Menetelmä Osaamistase Aloituskynnys J2EE Käytännössä kokeiltuja arkkitehtuurimalleja (J2EE patterns) Valmiita kehyksiä moneen lähtöön (sekä maksullisia että ilmaisia) Valmiita Java-kehitykseen räätälöityjä OOADmenetelmiä 2.5 miljoonaa Javakoodaria, oppilaitoksista koko ajan lisää Korkea: olioajattelu täytyy oppia ensin; lopuksi vielä IDE-välineet.NET MS:llä esimerkkeja, edessä silti runsaasti harjoittelua ja kokeilua Tehtävä tässä vaiheessa itse Sovitettava itse; hyväkään RAD-väline ei yksin toimi yritystason järjestelmissä Edellisen sukupolven COM+tekijät uuden oppimisen edessä Matala: Studio + VB; yritystason työhön korkeampi (C#,J#) Copyright SysOpen 13 Hankkeen onnistumisen näkökulma Integraatio Teknologiariski Projektiriski Ihanteellinen sovelluskohde Ihanteellinen organisaatio J2EE Vahva tuki legacyintegraatioon: J2EE CA, laaja joukko eri tasoisia integraatiotuotteita, Web Services (huomenna) Uusilla teknikoilla suuri, vakiintuneilla tekniikoilla kohtuullinen (J2EE-ydin) Teknologiariippumaton Laaja kokonaisjärjestelmä, jossa liittymiä legacymaailmaan, keskuskoneita, minikoneita jne. Puhdasta keskuskone- tai minikonearkkitehtuuria käyttävä organisaatio.net Vahva tuki työpöydän suuntaan. Legacy-integraatio: matalan tason liittymät (tänään), Web Services (huomenna) Suuri, muuttumassa kohtuulliseksi Teknologiariippumaton Itsenäinen sovellus, jopa laaja ERP, joka ennen olisi tehty C/Stekniikoilla Puhtaan MS client/server-mallin omaksunut organisaatio Copyright SysOpen 14 7

8 Yhteenveto Julkisuudessa olleet vertailut mielenkiintoisia mutta epäoleellisia Vertailut keskeinen osa markkinointia ja tuotteiden positiointia Selkeitä eroja kuitenkin nähtävissä Painopistealueet erilaisia Elinkaari eri vaiheessa Kohdemarkkinat erilaiset Oleellinen vertailunäkökulma: kuinka onnistun hankkeessa tai kokonaisjärjestelmän rakentamisessa J2EE selkeästi pidemmällä tässä suhteessa.netin kohdealue on kuitenkin selvä ja siellä toimiva Copyright SysOpen 15 8