Certifikace Java EE 6 Web Services Developer

Tak nějak jsem si poslední dobou zvykl, dělat do roka dvě certifikace (asi mi chybí školní dril :-) Takže co to bylo tentokrát? Honosný název, který se nyní skví v mém CV zní: Oracle Certified Expert, Java Platform, Enterprise Edition 6 Web Services Developer, zkráceně (ve stylu někdejších Sunovských certifikací) OCWSD.

Certifikace občas budí (zbytečné) vášně, takže základní otázka asi je: je to vůbec k něčemu? Pro mne je tím největším benefitem, že jsem se něco nového (do hloubky) naučil. A musím říct, že OSWSD je tomto směru opravdu hodnotná. Byť web servisy mastím cca poslední tři roky, ať už v Javě (JAX-WS, Spring WS nebo Axis), nebo v rámci SOA (WebSphere Message Broker, Oracle SOA Suite), tak během přípravy na certifikaci jsem dozvěděl spoustu nových věcí (třeba SOAP Message Handlers) a "dopochopil" lecos již známého.

Témata, která zkouška obsahovala jsou následující:

• Create an SOAP web service in a servlet container
• Create a RESTful web service in a servlet container
• Create a SOAP based web service implemented by an EJB component
• Create a RESTful web service implemented by an EJB component
• Configure JavaEE security for a SOAP web service
• Create a web service client for a SOAP based web service
• Create a web service client for a RESTful web service
• Create a SOAP based web service using Java SE platform
• Create handlers for SOAP web services
• Create low-level SOAP web services
• Use MTOM and MIME in a SOAP web service
• Use WS-Addressing with a SOAP web service
• Configure Message Level security for a SOAP web service
• Apply best practices to design and implement web services

Protože na zkoušku není žádný oficiální certifikační guide, prošel jsem trošku širší okruh materiálů. V praxi jsem zatím neměl nikdy možnost dostat se k RESTovým technologiím, takže jsem s předstihem začal s knížkou Billa Burkeho RESTful Java with JAX-RS, kterou vřele doporučuji - pokud chcete začít s RESTem v Javě (tj. libovolnou implementací JAX-RS), je to ta správná volba. Autor sice popisuje (a je tvůrcem) RESTEasy, ale je objektivní i vůči dalším implementacím.

Další knihou jsem si chtěl oživit druhou Javovskou web servisovou větev - JAX-WS. Tady je knižní situace docela slabá. V podstatě jediná aktuální kniha, která je věnována JAX-WS je Java 7 JAX-WS Web Services. Vzhledem k názvu a rozsahu (64 str.) jsem nečekal nic světoborného, ale zklamání bylo obrovské. Pokud nejste úplně nejzelenější začátečník a nevyhovují vám knížky, tvořené ze 2/3 screenshoty (NetBeansů), není to kniha pro vás. Škoda peněz, škoda času.

Jakou určitý druh přípravy můžu zmínit (celkem nudný) letošní Oracle Java Developer Day, kde jsem se šel podívat na jednu přednášku o JAX-WS a na dvě o JAX-RS. Samozřejmě, že to byly naprosté základy, ale člověk si aspoň udržuje povědomí o tématu.

Pak už začalo jít do tuhého, protože jsem potřeboval něco, co by mě připravilo na certifikaci. Nechal jsem tedy firmu zakoupit zkušební testy. Tentokrát jsem zvolil ještě nevyzkoušené řešení - kit od EPractize Labs. Jejich OCEJWSD Training Lab není úplně špatný. Sice je uživatelsky dost nepohodlný a rozložení témat mi přijde dost nevyvážené, ale myslím, že ho můžu označit jako přínosný. V dnešní době bych spíš volil kit od uCertify, s jejichž přípravnými testy mám dobrou zkušenost, který ale v té době ještě nebyl k dispozici.

Posledním materiálem, který jsem na přípravu použil je OCWSD Study Guide od Mikalaie Zaikina, který pokrývá témata zkoušky velmi pěkně. Linkovaná webová verze je zdarma, za $15 je možné si přikoupit sadu 160 otázek s odpověďmi, plus jednotlivé guidy v PDF podobě. Těch patnáct dolarů jsem investoval a můžu říct, že to stálo za to (aneb jak jsme se učili v angličtině it bang for the buck).

Pokud mám certifikaci OCWSD nějak celkově zhodnotit, musím říct, že je to určitě jedna z těch nejpřínosnějších, co dnes Oracle v oblasti Javy nabízí. Všechna témata byla víceméně ryze praktická, žádná nudná (korporátní) teorie, či dokonce ideologie. Zároveň je to taky jedna z těch, kde je těch Oraclovských technologií jen určité minimum - hodně se tam probírají věci z W3C, jako je SOAP, WSDL, XSD, WS-Addressing, nebo věci, které jsou dílem různých jiných organizací, jsou je WS-I (WS-Interoperability (Basic Profile)), nebo WS-Security.

Lean ze zákopů

Když už se do něčeho pustím, tak pořádně. Sotva jsem tak dočetl jednu knihu o Kanbanu, už jsem schroustal další. Tentokrát jsem si vybral dílko od Henrika Kniberga, které vyšlo v mojí oblíbené edici The Pragmatic Programmers.

Henrik pracuje jako Agile & Lean coach a v knize Lean from the Trenches, s podtitulem Managing Large-Scale Projects with Kanban, zpracoval formou case study svoji zkušenost s koučováním 60ti členného týmu švédské policie :-) který interně vyvíjel nový "digitální vyšetřovací systém". To zní skoro až exoticky, ale nebojte, slovníček švédštiny hledat nemusíte - celá knížka je napsána s ohledem na projekt a softwarový vývoj a reálie jsou zcela nepodstatné. Co naopak je podstatné, je že tým používal Scrum, XP a Kanban a projekt úspěšně zvládl.

Knížka je rozdělena do dvou částí, z nichž ta první How We Work obsahuje zmiňovanou case study a jednotlivé kapitoly jsou často koncipovány formou How We ..., např:

• How We Sliced the Elephant
• How We Involved the Customer
• How We Handle Urgent Issues
• Why We Limit the Number of Bugs in the Bug Tracker
• Why We Don't Use Story Points
• How We Do Version Control

Druhá část, nazvaná A Closer Look at the Techniques, potom krátce rozebírá jednotlivé techniky, principy: Agile, Lean, Scrum, XP a Kanban.

Knížka se velmi dobře čte a i přes svůj krátký rozsah (176 str.) je nabitá cennými informacemi. Zájemcům o Kanban/Lean rozhodně doporučuji.

Kanban, ultimátní kniha

Posledně jsem psal, jak jsem přišel ke Kanbanu jako slepej k houslím. Jedním ze zmiňovaných zdrojů v článku je knížka Kanban od Davida J. Andersona. David je jedním z pionýrů Kanbanu v softwarovém vývoji a jeho kniha má aspiraci (a velmi slušný potenciál), stát se biblí této zajímavé metody.

Na to, jak je Kanban jednoduchej je kniha poměrně obšírná (280 str.). Tematika je velkoryse rozebrána ve dvaceti kapitolách, rozdělených do čtyř částí:

1. Introduction
2. Benefits of Kanban
3. Implementing Kanban
4. Making Improvements

Každá kapitola je ukončena sekcí Takeaways, kde je v hutných bodech shrnut její obsah. To je šikovná věc, protože až se bude člověk jednou k daným tématům vracet, tak takový rychlý přehled se jednak umožní rychle zorientovat a jednak může sloužit jako reference (bez té omáčky v textu).

Jako zajímavější mi přišly první tři části knihy, které byly zaměřeny velmi prakticky. V poslední části už jsem se občas ztrácel, protože se zde řeší ekonomické modely, teorie omezení (Theory of constraints) apod., což není úplně můj šálek kávy (nicméně, přečet jsem to).

Pokud bych měl z knihy vypíchnout nějaké zajímavé momenty, tak to budou spíše ty, které nesouvisí přímo s Kanbanem (ale velmi dobře mu konvenují) a které rezonují i s mojí osobní zkušeností:

"Issue management and escalation are core disciplines that provide a big return. Improving them should be a priority even for the most immature teams."

"Use of peer reviews, pair programming, unit tests, automated testing frameworks, continuous (or very frequent) integration, small batch sizes, cleanly defined architectures, and well-factored, loosely coupled, highly cohesive code design will greatly reduce defects."

"As we all know, there really is no such thing as multi-tasking in the office; what we do is frequent task switching."

"Many 'softies' prefer conference calls for coordination meetings rather than face-to-face. This has a negative impact on the level of trust and social capital in their workforce, but it facilitates efficiency."

"Trust is a hard thing to define. Sociologists call it social capital. What they've learned is that trust is event driven and that small, frequent gestures or events enhance trust more than larger gestures made only occasionally."

Knihu můžu opravdu vřele doporučit. uvnitř najdete opravdu hard-core Kanban, se spoustou rad, jak jej implementovat, široké uvedení do kontextu, plus navrch i nějaká ta teorie.

Kanban z čistého nebe

Trochu nečekaně jsem dostal na stávajícím projektu na starost nový, teprve vznikající tým. A že prý (nařízeno shora) jedeme Kanbanem. Inu, proč ne. Akorát že o něm nic nevím. Takže jsem se pustil do studia, protože něčemu nerozumět, to pro mne není příjemný stav.

Pročetl jsem několik internetových článků, z nichž bych vypíchnul:

• Introduction to Kanban
• Kanban Applied to Software Development - aneb od tradičního Kanbanu k softwarovému vývoji.
• Vizualizing Agile Projects using Kanban Board - pravidlo č. 1: vizualizovat.
• One day in Kanban land - komiks :-)
• Tutorial - Tracking a Kanban Team - JIRA tutoriál pro GreenHopper.

Dále, protože jsem nelítostný čtenář, jsem zakoupil knihu. Vybral jsem si titul Kanban :-) od Davida J. Andersona, což je jeden z prvních early adopters Kanbanu v SW vývoji, takže jistě člověk povolaný.

Knížku mám zatím rozečtenou, tak se o ní nebudu předčasně rozepisovat. Ale když už jsem ji zmínil, ocituju z ní principy, na kterých Kanban stojí. Principy samotné jsou vysvětleny ve výše uvedeném článku Introduction to Kanban a jelikož k nim zatím nemám z vlastní zkušenosti co podotknout, skromně pomlčím. Tak tedy:

1. Vizualizuj workflow.
2. Limituj rozdělanou práci (work-in-progress).
3. Měř a spravuj flow.
4. Udělej procesní politiky explicitní.
5. Používej modely pro rozpoznání příležitosti ke zlepšení.

Poslední věc, kterou bych zmínil (jako výchozí stanovisko), je nástrojová podpora, kterou máme k dispozici. Jako issue tracking nástroj používáme JIRu, do které máme plugin GreenHopper pro agilní projekt management, který umí mmj. i Kanban.

Zatím jsem si s JIRou dosti hrál, abych vyzkoušel možnosti, které nabízí a prozatím můžu říct, že pro Kanban má dobrou podporu. Jenom není úplně jednoduché to nějak nastavit. Respektive, nastavení je triviální, ale vzhledem k jednoduchosti Kanbanu je potřeba celý proces vymyslet - Kanban vás v tomto nijak nenavede - a to jednoduché nemusí být.

SOA governance, lehký úvod

Vzal jsem si na projektu na starost SOA governance a s tím související nalezení nějakého vhodného nástroje, který by ji podpořil. Protože to budu muset v brzké (a nejspíš i pozdější) době prezentovat, chci si tady k tomu sepsat pár bodů, o čem to vlastně je. Co to je SOA ví každé malé dítě ;-) takže se tím nebudeme zdržovat a jdeme rovnou na věc.

3 P

Tři P můžou znamenat cokoliv, v tomto případě jsou to: lidé (people), procesy a politiky a v těchto kategoriích si můžeme klást následující otázky:

People:

• Kdo je business vlastníkem služeb?
• Kdo používá naše služby?
• Kdo je za služby techn(olog)icky zodpovědný?

Procesy:

• Které procesy definují politiky?
• Jaké business procesy závisí na našich službách?
• Je zde proces pro životní cyklus služeb?

Politiky

• Jaké politiky jsou pro naše služby definované?
• Jak jsou politiky aplikované během design a runtime fáze?

Tyto otázky bychom měli mít do určité míry zodpovězené. S jejich tvorbou a udržováním by nám měl  pomoci vhodný nástroj.

3 části politiky

Politika se skládá ze tří částí:

• tvrzení (policy assertion),
• vlastníka (policy owner)
• a prosazení/vynucení (policy enforcement).

Tvrzení známe i z jiných IT domén, např. unit testy. Tvrzení by mělo být měřitelné a mělo by mít disjunktní odpověď pravdivé/nepravdivé (true/false). Vlastník politiky je jasný - je za politiku zodpovědný, udržuje ji atd.

Prosazování politiky může probíhat dvěma způsoby. Buď technologicky, nějakým automatizovaným nástrojem, nebo pomocí review. Obojí opět známe odjinud, např. automatizovaná statická analýza zdrojového kódu vs. "ruční" review.

3 oblasti podpory SOA governance

Nástroj pro SOA governance by nám měl pomoci ve třech oblastech:

• Vytváření a správa politik.
• Aplikování těchto politik v design fázi.
• Aplikování těchto politik v runtime fázi.

V případě prvních dvou bodů pomůže repository, kde se dají politiky a služby zaregistrovat. V případě služeb (design fáze) bude ještě potřeba o nich udržovat metadata. Pro runtime fázi bude potřeba nějaký monitorovací nástroj, v SOA se běžně používají řešení, která spadají do kategorie Business Activity Monitor (BAM).

Příklady politik

Aby jsme si pod politikami představili něco konkrétního, uvedu pár příkladů.

Design-time politiky:

• Nevytváříme duplicitní služby. Tohle bývá těžký, nápomocná může být impact analýza. Služba se většinou v čase mění, přibývají nové funkčnosti a využití a tak časem může dojít i k rozštěpení služby na dvě. Při změnách v čase je potřeba mít neustále na paměti zpětnou kompatibilitu kontraktu služby.
• Technologická standardizace. Velkou část za nás řeší zvolená SOA platforma, ale některé věci je potřeba definovat politikou. Např. interní služby používají REST, externí služby jedou přes WS-*.
• Validace zpráv. Celkem jasný. Problém bývá validaci vůbec zapnout.

Runtime politiky:

• Dostupnout služby 24x7. Služba buď běží, nebo neběží. Tohle souvisí se Service Level Agreement (SLA).
• Služby používají zabezpečený kanál. HTTPS atd.
• Služby jsou "sebe-popisné" (self-describing). Tohle může být i součástí design fáze. V runtime je to myšleno tak, že po deploymentu je služba použitelná i bez dodatečné dokumentace.

Co dál?

Tak. To je momentálně asi všechno, co k tomu můžu obecně napsat, aniž bych zmiňoval konkrétní nástroj. Jestli se nám nějaký podaří na projektu rozjet, tak nějaký článeček určitě přibude.

Perforce, ignorování souborů a adresářů ve streamu

Jak se nám tak rozrůstá aktuální projekt (a postupuje k nasazování na další prostředí), vyvstala nám potřeba branchovat zdrojový kód. V Perforce (P4) se dá jednak klasicky branchovat, nebo se dají používat streamy. Protože streamy poskytují pro správu kódu daleko větší komfort, vybrali jsme si právě tento způsob.

Pro používání streamů je potřeba mít vytvořený streamovaný depot. Ten jsme vytvořili, naimportovali data a ... bylo ještě potřeba nastavit ignore list, protože způsob popsaný v minulém zápisku pro streamovaný depot nefunguje. OK, jak na to?

1. V menu View -> Streams, nebo ikona .
2. Kliknout pravým tlačítkem na daný stream (obvykle mainline) -> Edit stream <stream>.
3. Na záložce Advanced nastavit sekci Ignore.

P4 stream s nastaveným ignore-listem

Jednou z výhod streamovaného depotu je, že ignore list je nastavený na úrovni streamu. Není tedy potřeba jej nastavovat pro každý workspace zvlášť, tak jako v případě nestreamovaného depotu.

Perforce, instalace serveru P4D

Prozatím jsem byl pouhým uživatelem Perforce (P4). Používám ho už na druhém projektu a začínám mu přicházet na chuť :-)  Chtěl jsem si něco nastudovat ohledně streamů, které asi začneme brzy používat, ale protože nemám na projektu administrátorský práva, který jsou pro založene stream depotu potřeba, nainstaloval jsem si P4 lokálně. O streamech určitě napíšu někdy příště, nyní něco k jednoduché instalaci.

Instalace Perforce Serveru

Instalace Perfoce Serveru (P4D) je velmi rychlá a jednoduchá. Popíšu instalaci pro vývojářské účely - do domovského adresáře. Pro "opravdový" nasazení by přibyly pouze dva kroky: vytvoření uživatele (a ev. skupiny), pod kterým P4D poběží a vytvoření root adresáře pro depot.

Instalaci zahájíme stažením serveru (P4D) a řádkového klienta (P4) z download stránky. Doporučuji stáhnou i grafického klienta (P4V).

1. Vytvoříme pracovní adresář (root depotu).
2. Zkopírujeme soubory p4d a p4 do $PATH a nastavíme spustitelný příznak.
3. Nastavíme proměnnou P4PORT, port na kterém P4D naslouchá. (P4PORT je důležitá i pro klienta a nastavuje se v ní host i port.)
4. Nastavíme proměnnou P4ROOT, root adresář depotu.
5. Spustíme server jako daemon příkazem p4d -d.
6. Server můžeme zastavit příkazem p4 admin stop.

Instalace P4D

Přidání souborů do depotu

Pokud se poprvé přihlásíme grafickým klientem P4V k serveru, který má prázdný depot, nabídne nám možnost tam nějaké soubory umístit:

Přidání souborů do depotu

Hotovo! Server běží, soubory máme naimportovány. Můžeme začít vyšívat...

P4 depot