27. června 2008

Přechod z Acegi na Spring security

Na minulých projektech jsme používali Acegi security se spoustou vlastních doplňků a vychytávek. Teď začínáme psát nový projekt a tak jsme si řekli, že je už čas se posunout dát a začít použít Spring security (jeden z důvodů byla podpora NTLM ve Spring security, ale o tom budu psát v dalších příspěvku).

V tomto článku bych rád uvedl moje zkušenosti s touto migrace. Základní naše konfigurace vypadala asi jako ta uvedená v článku Ukázka konfigurace Acegi security plus jsme si vytvořili tzv. bezpečností modul, který obsahuje různá rozšíření, které standardně v Acegi implementovány nejsou (např. zablokování účtu po třech špatných přihlášeních, kontrola na existenci rolí při přihlašování apod.).

Vzal jsem tedy konfiguraci a pár stránek ze starého projektu a nasadil do nového. Musel jsem provést následující úpravy:

  • přejmenovat balíky org.acegisecurity na org.springframework.security. Takže když jsem měl v konfiguraci org.acegisecurity.ui.ExceptionTranslationFilter, tak jsem to musel změnit na org.springframework.security.ui.ExceptionTranslationFilter.

  • přejmenovat některé statické proměnné, např. AbstractProcessingFilter.ACEGI_SECURITY_LAST_EXCEPTION_KEY na AbstractProcessingFilter.SPRING_SECURITY_LAST_EXCEPTION_KEY nebo AuthenticationProcessingFilter.ACEGI_SECURITY_LAST_USERNAME_KEY na AuthenticationProcessingFilter.SPRING_SECURITY_LAST_USERNAME_KEY. Tyto proměnné nepoužívám přímo v konfiguraci, ale již v rámci našeho kódu.

  • přejmenovat URL pro odhlášení z j_acegi_logout na j_spring_security_logout.

  • přejmenovat URL pro zpracování přihlašovacího formuláře z j_acegi_security_check na j_spring_security_check.


A to je všechno, vše bez problémů. Zatím jsem migroval vše kromě naší knihovny, ale tam již žádné problémy neočekávám. Pouze bude nutné všechny použité třídy z Acegi přejmenovat na Spring security.
Jediné co mě překvapilo je, že jsem nikde na stránkách Springu, ani v dokumentaci Spring security nenašel návod k migraci.

Zdroje informací:

20. června 2008

OSGi: Použít nebo nepoužít?

Hned na začátku článku musím říci, že jsem velký fanda modulárních systémů a OSGi především. Ale to hned nemusí znamenat, že OSGi budu používat vždy a za všech okolností - pro mě je důležité za použitím jakékoliv technologie vidět určitý přínos a tedy důvod, proč danou technologii použít. Samozřejmě to také musí být vyvážené rozumnou pracností.

O OSGi je v poslední době hodně slyšet. Málokdo asi ví, že tato věc vznikla už někdy v roce 1999, takže se nejedná o žádnou novinku. Určitě znáte resp. používáte Eclipse nebo IBM WebSphere - to jsou asi dva hlavní představitelé produktů, které jsou postaveny nad OSGi. Přijde mi, že to správné buzzword z toho udělal až Spring, protože Spring si OSGi vybral jako nosné řešení pro své všechny projekty, pro svoji vlastní aplikační serverovou platformu SpringSource Application Platform. Základem je projekt Spring Dynamic modules, který zase funguje jako nástavba na "čistým" API OSGi a nabízí spoustu ulehčení - prostě standardní Spring :). Možná ještě více publicitě OSGi pomohl sám Sun, který přišel s něčím podobným přímo do JVM - Java Module System. Do teď není zcela jasné, které řešení nakonec zvítězí, ale řekl bych, že OSGi má v současné době navrch.

Cílem článku není vysvětlovat možnosti OSGi, na to jsou jiné weby. Tento článek shrnuje mé osobní poznatky z průzkumu OSGi, jakožto možné platformy pro vývoj naší nové aplikace. Připravujeme vývoj nové webové aplikace (možná by se dalo říci i produktu), která technologicky nevybočuje nijak z průměru (Spring, Hibernate, JSF). Nejedná se také o aplikaci nijak zásadně kritickou, spíše o podpůrný nástroj pro menší skupinku lidí ve firmě. Aplikace to nebude (aspoň na začátku) nijak rozsáhlá.

A teď jsme před rozhodnutím, zda použít nebo nepoužít OSGi. Ještě jsme se finálně nerozhodli, ale spíše to vidím tak, že OSGi pro tento projekt zatím nepoužijeme. Mám k tomu následující důvody:

  • Sice jsem psal, že OSGi bude mít příští rok 10 let, ale v oblasti serverové Javy tak dlouho nepůsobí. Nejdříve tato technologie byla vyvíjena pro mobilní aplikace (to je záruka, že OSGi je opravdu lightweigth řešení), poté se adaptovala v oblasti standalone aplikací (např. Eclipse, kontejner Equinox) a teď v poslední době je snaha o adaptaci v oblasti serverových aplikací. To je trochu složitější, protože jsou potřeba minimálně dva kontejnery - pro Javu resp. servlety a pro OSGi. Jsou plně podporovány kontejnery Tomcat, Jetty a prý další nejsou problém, ale nikde jsem k tomu moc informací nenašel. OSGi kontejner může být vložen do webového kontejneru a naopak, více zde. Jak je možné integrovat do OSGi+webového kontejneru stávající MVC řešení? Co když budu chtít použít další kontejner pro EJB? Tak v tomto vůbec jasno nemám.

  • Abych mohl aplikaci modularizovat pomocí OSGi, tak pak musím mít vše rozdělené do tzv. bundlů - moje i všechny knihovny třetích stran musí být bundly. Vznikají tedy různá repository (např. 1, 2), kde je možné si stáhnout bundly známých knihoven, např. pro Hibernate, Jakarta Commons apod. Nicméně určitě všechny knihovny tam v podobě bundlů nenajdete. Pak jsou dvě možnosti - buď si počkáte až bundle bude a nebo si bundle z jar souborů vytvoříte sami. Buď ručně nebo s pomocí nástroje Bnd.

  • Pokud tedy budu mít OSGi aplikaci, tak mohu za běhu aplikace instalovat, nahrávat, rušit jednotlivé moduly resp. bundly, mohu efektivně řešit verzování apod. Na to se dá říci jen SUPER. Ale potřebuji to tak zrovna pro mojí aplikaci? Nikdy jsem to zrovna nepotřeboval a pro tuto aplikaci to asi také nepotřebuji. Aplikace není kritická, takže ji v pohodě mohu celou otočit. Ani velká moc nebude, takže upgrade bude otázka chvilky. Na druhou stranu mě hned napadá, že se bude jednat o aplikaci s instalacemi a úpravami u více zákazníků, což by se hezky dalo řešit pomocí modulů. Také hromadný upgrade všech instalací z jednoho místa by nemusel být k zahození.

  • Nikdy neříkej nikdy - možná přijde doba, kdy z malé počáteční aplikace bude velký systém, který bude potřebovat modularizovat. Nemám s tím žádnou zkušenost, ale řekl bych, že nebude tak velký problém z již existující aplikace vytvořit OSGi aplikaci. Příkladem mohou být např. Spring projekty, které jsou nyní plně OSGi - jednotlivé jar soubory jsou zároveň bundly exportující a importující potřebné služby resp. balíky.

Nějaké zdroje k OSGi:

13. června 2008

Nástroje SoapUI a JMeter

Uvedené nástroje používám již několik let a myslel jsem si, že jsou natolik známé a rozšířené mezi programátory, že ani nemá cenu se psát, jestli je někdo zná. Překvapivě jsem se mýlil.

JMeter je nástroj pro měření výkonnosti a pro vytváření umělé zátěže na webových projektech. Je to spíše nástroj "pro začátek" - tím myslím to, že kdo opravdu řeší problematiku výkonnosti, robustnosti a škálovatelnosti aplikací, tak asi bude používat jiné, komerční nástroje. Já si většinou pouze chci ověřit, že mnou napsaná aplikace běhá dle očekávání, že tam není vyloženě nějaký problém třeba v konkurenčním přístupu více uživatelů apod. V tomto ohledu naprosto dostačující nástroj.

Bez nástroje SoapUI si vývoj webových služeb vůbec nedovedu představit. Vždy když se vytvoří nová webová služba nebo se nějaká již existující integruje, tak je potřeba si ověřit komunikaci pomocí nějakého klienta. SoupUI není pouze klientem webové služby, ale celkem sofistikovaný nástroj pro jejich vytváření a testování.

Oba dva nástroje jsou samozřejmě open-source, tedy zdarma.

9. června 2008

Znáte Daisy?

Mě tento CMS nástroj doporučil kolega, já ho úspěšně použil pro jednoho zákazníka a tak pozitivní zkušenost šířím dál.

Je to již nějaký čas, co jsem Daisy používal, ale zrovna minulý týden se na mě kamarád obrátil pro radu, tak jsem si na Daisy znovu vzpomněl.

Na Daisy jsem oceňoval hlavně tyto věci:

  • aplikace je napsaná v Javě, takže pro mě není problém aplikaci kustomizovat

  • přišla mi velice intuitivní, takže jsem se s tím velice rychle naučil

  • udělal jsem tam vše, co jsem potřeboval - zákazníkovi jsme pomocí Daisy vytvářeli skladiště dokumentace k projektům. Bylo tedy potřeba vytvořit nějakou základní strukturu úložiště pro uložení dat včetně nastavení přístupových práv. Vložené dokumenty (zejména MS Word) se automaticky indexují a lze přes ně fulltextově vyhledávat. Daisy je natolik uživatelsky přívětivé, že zákazník po zaškolení používá aplikaci sám.

Ve svých poznámkách jsem našel jedinou nevýhodu, se kterou jsem se potkal - měl jsem občas problém s češtinou při fulltextovém vyhledávání (používal jsem verzi 2.1). Neměl jsem čas a ani prostor to moc řešit, takže ani nevím, jak to dopadlo.

2. června 2008

Open-source ESBs

Integrace, SOA, ESB - to jsou buzzwords poslední doby. Není to jen módní vlna, která hlavně vychází z marketingových snah velkých firem, ale také realita současnosti - existuje spousta starých či nových systémů, které je potřeba propojovat. Pokud je těch systémů více (více jak 5), tak už nemá cenu to propojovat přímo mezi sebou, ale využít nějaké ESB řešení.

Pro náročná řešení a náročné zákazníky máme v portfóliu naší firmy produkty od IBM - WebSphere Process Server, WebSphere Integration Developer a WebSphere Enterprise Service Bus.

Kromě toho ale potřebujeme i dostupná řešení pro širokou škálu zákazníků, takže jsem se začal dívat po nějakých open-source ESB řešeních. Dal jsem dohromady krátký seznam řešení, na která jsem narazil spolu s body, které mě zaujaly. Hned říkám, že žádné praktické zkušenosti s uvedenými systémy nemám a za jakékoliv informace tohoto typu budu velice rád.

MuleESB

  • URL: http://www.mulesource.com, http://www.muleforge.org
  • konfigurace pomoci Springu, systém postaven nad Springem
  • velice úspěšný a rozšířený open-source projekt (7 firem z fortune 50)
  • kromě ESB mají další produkty zaměřené na SOA. Některé z nich jsou dostupné v rámci podpory.
  • OSGi ready
  • MuleForge - web pro hostování projektu pro Mule rozšíření, např. různé konektory k systémům třetích stran

JBoss ESB

  • URL: http://www.jboss.org/jbossesb/, http://www.jboss.com/products/platforms/soa
  • podpora od české firmy - lokální partner firma Servodata
  • možnost školení v češtině
  • postaveno na základech Rosetta ESB, které JBoss získal v roce 2006. Rosetta ESB je prověřené řešení vyvinuté a používané ve velké Kanadské pojišťovací společnosti.
  • součástí podpory jsou i nastroje pro monitorování a další věci, které normálně volně dostupné nejsou
  • actions mohou byt instalovány/odinstalovány za běhu
  • JBoss nabízí celkem velké portfolio technologií a platforem, se kterými se dá vystavět aplikace od A do Z včetně integrace

WSO2 ESB

  • URL: http://wso2.com/products/esb/, http://synapse.apache.org/
  • řešení je postaveno nad Apache Synapse, pouze je rozšířeno o administrátorské rozhraní. Autoři WSO2 ESB jsou i autory Apache Synapse.
  • jednoduché, malé řešení určené zejména pro mediace a transformace zpráv, není k dispozici orchestrace.

OpenESB

  • URL: https://open-esb.dev.java.net/
  • Uvádím jen pro úplnost, ale s ohledem na předchozí řešení mi toto již nepřipadá tolik zajímavé, a proto jsem ho dal pryč z užšího výběru.


Závěr

Ještě jsme nic nevybrali. Není to ovšem vždy jen o technologické úrovni, ale hodně také o politice - jaké naše firma má partnery, koho můžeme podporovat a koho ne atd.
Mě je zatím nejsympatičtější ESB od Mule. Proč? To nedokážu přesně popsat, zatím jen pocit :). Finální výběr vidím mezi MuleESB a JBoss ESB. Apache Synapse se mi moc libí hlavně z toho důvodu, že je to malé, lehké řešení a to že nemá orchestrace zase tak vadit nemusí, na to jsou větší řešení (říká se, že dává smysl něco orchestrovat pro více než 5 služeb což odpovídá spíše středním firmám). Proti mluví to, že nemá cenu se učit tolik systému (něco pro velké zákazníky, něco pro střední a něco jen pro lehké věci), proto asi Synapsi také vyřazuji z výběru.