Názory k článku
Java na webovém serveru: Komentáře a integrace s Texy

A v cem je problem? Tohle bylo asi nejjednodussi nastavit a hlavne si to muze vyzkouset kazdy. Pokud budes chtit rychlost, proste si naimplementujes navrhnuty interface jinym zpusobem. Autor, ale timto ukazal pouziti nekolika technologii, ktere pravdepodobne bude ctenar v budoucnu pouzivat.

Vzhledem k tomu, že se ta operace provádí jen při psaní nových komentářů (což bude výrazně méně časté než čtení) a vzhledem k tomu, kolik HTTP požadavků musí proběhnout při načtené každé stránky*, mi to přijde zanedbatelné. Výhody spouštění php jako podprocesu mi přijdou menší než nevýhody – jednak to snižuje bezpečnost (php běží pod stejným uživatelem jako javový server) a jednak tam to PHP musím mít. Když to proložíme HTTP protokolem, tak je to sice na první pohled nehospodárné, ale dělat něco jako SOA v malém – mít jednu (nebo několik málo) službu v rámci organizace/firmy, která bude zodpovědná za Texy a ostatní ji budou využívat – na jiných serverech nemusí být PHP vůbec nainstalované, nikdo ho nemusí konfigurovat a udržovat. Než php-cli to by spíš stál za zvážení ten javovský port texy – pořádně ho otestovat a průběžně sledovat jestli je kompatibilní, jestli se s novými verzemi nerozchází od originálu. Případně zkusit jestli by PHP verze nešla rozchodit v Quercusu…
*) a tím nemyslím jen tuhle konkrétní aplikaci, ale weby obecně – navíc tam se nekomunikuje v rámci localhostu, ale s vnější (pomalou) sítí. I když většina těch požadavků dostane odpověď „304 Not Modified“, ty hlavičky tam stejně proletí – vedle toho ta jedna komunikace navíc s Texy opravdu nic není.

Vypadlo mi tam:
„ale dělat něco jako SOA“ → „ale umožňuje nám dělat něco jako SOA“

Ve Quercu se mi podařilo rozchodit jen starou verzi Texy pro PHP4 a to ještě jen špatně s nutností několika úprav.
Výborně naopak funguje PHP/Java bridge pomocí JSR 223. Jen nedoporučuji používat přímo na aplikačním serveru. Lépe vytvořit jednoduchý Texy-miniserver komunikovat nativními zprávami s ním.

Provokace, nebo neznalost?

skor borec, co si precital clanok o „pomalosti java 1.1“ z 12.3.1998 a zbuchal uz 3 webshopy v php v celkovom objeme 12.4kB zdrojoveho kodu, co ho nepochybne radi medzi odbornikov :-)

A k tomu má nejspíš dojem, že java na webovém serveru = java na webu = java applet ve stránce. :-)

Zkusime to jinak: Jaka je vyrazna nevyhoda Java EE?

Velmi špatná architektura, viz
http://www.springsource.org/about
Java EE chce být univerzální, ale není, zato je ale složitá. Podobně jsou na tom i další technologie, třeba XML nebo MS LINQ to SQL.

zložitá je len pre toho kto má v hlave nasraté, my ostatní sa neustále vzdelávame. a čo je prosím ťa zložité na LINQ to SQL ?

nemam ziaden vyhraneny nazor ani na php ani na javu … len ak by bol nejaky priklad na nejaku komplikovanejsiu webaplikaciu v jave… lebo zatial co si pamatam resp. nepamatam ziadnu stranku v jsp, ktora by dokazala odpovedat … ako to povedat … svizne… Neviem ci to je teda sposobene javou alebo len zlou konektivitou serverov – i ked tie by sa dali pomocou pingu odmerat a odpocitat.
Nemusi to byt ziadna wikipedia ani facebook, len nieco co je navstevovane a nieco jednoznacne vykonava okrem vracania statickeho textu.

java na webu neznamena pouze jsp, jsp je v podstate mrtva vec

Java bude rychlejsie ako PHP.

je dost, např. LinkedIn.com.
Facebook.com zvažoval Javu jako jednu z alternativ k ukrutně pomalému PHP, nakonec začali překládádat PHP kód do C++ a kompilovat do binárek.

Proč? (no flame plz.)

Protože existují lepší jazyky s lepšími knihovnami.
Porovnávám podle následujících kritérií: znovupoužitelnost, přehlednost, typová kontrola, možnost paralelismu.

Jaké konkrétně jazyky?

Třeba Haskell, F#. Pro JVM třeba Clojure, Scala.

hmm, v tom jsem asi žádný produkční web napsaný neviděl. A co třeba GNUstep? Nad ním jsem viděl jednu pěknou webovou aplikaci, působilo to dost svižně a vůbec fajn :-) Neví někdo jak dobře se v tom píše? (Objective-C zatím leží na mém TODO seznamu věcí, ke kterým se snad jednou dostanu, časem)

Ve Scalle jsou psane nektere komponenty (ne frontend) Twitteru, Novell ve Scale (framework Lift) implementoval Pulse, FourSquare take pouziva Scalu i Lift.
To ale samozrejme ani zdaleka neznamena, ze je Java vzdy spatna volba. Ma vyzrale knihovny a ekosystem (trebas Apache odvedl uzasny kus prace), komu nevyhovuje aktualni podoba Java EE „podle Sunu“, tak muze sahnout po Springu, neni problem, pokud mate penize, sehnat slusne programatory, jsou k dispozici knihy, navody, IDEs, servery pro CI…

Prosím o vyšší četnost těchto článku!
Jsou výborné, děkuji.

Myslím samozřejmě o Java na straně serveru ;-)

u výpisů zdrojového kódu není obarvena syntaxe a vůbec je to nějaké „smrsklé“, u tohoto – http://zdrojak.root.cz/clanky/happstack-cast-treti/ je to v pořádku, Opera 10.53 win, takže asi chyba redakce/autora.

Opraveno, díky za upozornění.

Hoj,
rád bych podotknul, že JTexy je ve vývoji… tj. rozhodně nepřeparsuje vše.
Není čas… Pokud by se někdo chtěl přidat, jen uvítám :)
Ondra