sobota 15. května 2010

Mračna, sluníčko a nebo smrádek a teploučko nad Javou

Honza Novotný a Lukáš Křečan se vypravili na letošní GeeCON a zprostředkovali nám své postřehy z tamního dění GeeCON – cast prvni, GeeCON 2010 – den první a GeeCON 2010 – Den druhý. Jestli mě něco z těch zpráv zarazilo, pak to byla neutuchající víra ve světlé zítřky Javy. Musím se tedy přiznat, že po přečtení rozhovoru s A Discussion with Josh Bloch on the Future of Java a toho co jsem se dozvěděl od kluků, vidím několik zásadních problémů.

Jedno vcelku jednoduché pravidlo říká, že ten kdo neinovuje, bude koukat na svět leda zpod kytek. Nemusí se inovat příliš, ale inovovat se prostě musí, jinak vás konkurence dříve nebo později zadupe do země. Jenže my se dozvídáme pouze samé Jobovy zvěsti. JCP jako hlavní standardizační hybatel dění v Jave je v podivném klinči zájmů jednotlivých skupin a s nevyřešenými problémy ohledně licencí k TCK. Sun evidentně vývoj Javy 7 podcenil a tak se dozvíme, že bylo uvolněno málo zdrojů ať již lidských a nebo finančních. Dnes jsme v situaci, kdy se pořádně neví co v Jave 7 vlastně bude. O nějakém datu vypuštění nemůže být řeč. Při prezentaci o clusures jsem měl mžitky před očima, když jsem viděl jakým amatérským způsobem se řídí věc tak zásadní jako tato (přidávají se do bety!). V tomto kontextu je jistě zajímavé zjištění, na jaké všechny oblasti má dopad rozšíření jazyka.

Korunu všemu nasadí chystané zaříznutí dvou implementací JVM pod jednou střechou (JRockit a HotSpot). Chápu, že není ekonomické, živit dva různé týmy dělající stejnou věc. Na druhou stranu, kde by byly obě JVM bez toho, aniž by si konkurovaly? To co je dobra zpráva pro lidi držící kasičku, není dobrá zpráva pro nás uživatele. Nedokážu si dost dobře představit, jak se budou obě řešení spojovat ani technicky ani lidsky.

Nic neplatí v ITt víc, než že stav věcí není ani tak dobrý, jak se prezentuje na konferencích, ale ani tak zoufalý, jak jej vidí lidé uvnitř dění (insideři ze Sunu). Java teď neleží ve stádiu klinické smrti, ale ani nad ní nesvítí sluníčko na cestě k lepším zítřkům. Pravda je tak někde uprostřed, nazval bych to ne zrovna moc poeticky: smrádek, ale teploučko. Bohužel tenhle vegetativní stav má tendenci se zhoršovat. A přiznejme si to upřímně, jestli nepřijde někdo, kdo s tím začne pořádně hýbat, tak se nic nezmění. Trochu mám obavy, že to nebude Oracle, minimálně pokud napne síly k JavaFX. To by mohlo pomoci jednotlivým částem platformy, ale nikoliv celku.

čtvrtek 13. května 2010

CZ Podcast 35 - startup Korekt.me

V dalším díle naší/vaší oblíbené show jsem vyzpovídali Martina Adámka. Martin se pokoušel prorazit s online službou korekt.me na korekturu cizojazyčného textu. Protože nejsme jenom banda geeku, přišlo nám zajímavé položit mu pár otázek na téma, jak se takový startup rozjíždí, co je důležité, kde udělal chyby, jak daleko je od první myšlenky k realizaci a jaké si odnesl ponaučení.

neděle 9. května 2010

Jak jsem si užil Service Oriented Architecture v praxi

Poslední půlrok jsem strávil na zajímavých projektech v jedné z největších bank tady v Česku. Musím říci, že největším zjištěním pro mě bylo něco co bych nazval SOA v praxi. Musím se upřimně přiznat, že před tím, než jsem poznal praxi, přišla mi SOA jako věc příliš abstraktní, pod kterou jsem si nedokázal představit nic konkrétního. Bohužel tato třípísmenná zkratka je natolik zprofanovaná, že těžko najít něco zprofanovanějšího. Pokud se oprostíme od nánosu všeho toho květnatého humusu, myšlenka jako taková se skutečně realizuje. Jak to funguje v praxi se pokusím nastínit na následujících řádcích.

V bankách se donedávna stavěly aplikace s monolitickou architekturou. Ta byla tvořena dvěma částmi frontend a backend, které byly úzce spjaté.

Tohle architektonické rozložení sil vám hází nejeden klacek pod nohy. Především je to špatná znovupoužitelnost toho co nabízejí krabičky s názvem backend a frontend. Pokud to chcete změnit, pak je prakticky nemožné vzít páteř bankovních systému v podobě backendu a začít z ní vytrhávat jednotlivé obratle a ty měnit za něco nového. Jediný možný způsob provedení je vystavení funkcionalit backendu pomocí služeb. Vnímavý čtenář pochopil, zde přichází přerod v SOA. Bohužel backendy jsou často prehistorické systémy, kde schopnost vrátit data v XML je čestnou výjimko. Povětšinou se používají se textové či binární zprávy.

V praxi to znamená, že je potřeba služby vystavit na nějaké infrastruktuře, která umožní použít prostředky, jenž považuje naše doba za standardní. K tomutu účelu se používá Enterprise Service Bus (ESB), která hravě zvládne konverze na úrovni transportního i aplikačního protokolu. Jako technologie se používají Webové služby (SOAP over HTTP).

Takto použité uspořádání znamená, že služby vystavené na ESB definují model. V případě SOAP over HTTP se jedná o model zpráv, které služby přijímají a vracejí. Tento model musí jednak respektovat všechny informace, které potřebují backendy a jednak musí být dostatečně obecný, aby klient nebyl svázaný s konkrétní implementací backendu, nechceme vytvářet příliš těsné vazby. Tento model se nazývá Canonical Data Model (zkráceně CDM).

CDM je jakýmsi lingua franca, pomocí kterého si systémy vyměňují zprávy. Ačkoliv to není na první pohled patrné, CDM je coarse grained, tedy nemusí vždy obsahovat všechny co potřebuje konkrétní klient případně to nemusí být úplně ve vhodném formátu pro interní aplikační použití. Jako příklad může posloužit entita Adresa. Ta je v CDM definována určitým způsobem, ale frontend (klient obecně) může mít různé požadavky na to co všechno si ještě k adrese potřebuje navěsit, například Skype účet, IM účet apod. V takovém případě už máme modely tři, ten poslední je již specifický pro danou aplikaci.

Aplikační model již bývá interně namapován na technologie použité uvnitř aplikace pro ukládání nebo zobrazení. To znamená, že se na něj lepí různé technologické anotace případně je ohýbán, aby se dobře používal. Každá aplikace si musí vyřešit přemapování z aplikačního modelu do CDM modelu. Což lze udělat ručně programově a nebo pomocí šikovné knihovny Dozer.

Samozřejmě, aby to nebylo ještě málo složité, tak máme různé verze modelů a k nim potřebujeme nějakou governance (správu). A to už se dostáváme za rámec tohoto článku a pro mě oblastí neprobádaných.

Na závěr bych ještě pár vět věnoval něčemu málo patrnému, ale o to více důležitému. Žádný vývoj neprobíhá velkým třeskem, to znamená, že služby se průběžně vytvářejí a objevují. Stejně tak služby nejsou vždy dostupné a nebo není možné pro vývoj použít jejich živé systémy. Z tohoto důvodu velkou pozornost získávají simulátory služeb, které vůbec umožňují a výrazně zjednodušují vlastní vývoj aplikací postavených v SOA prostředí. Povídání o simulátorech služeb si ovšem nechám na někdy příště.