Jak kombinovat webové aplikace (diskuse)

[Josef Kufner]

Vždycky můžeš jedním webserverem vygenerovat kus stránky a nechat druhý, ať si to od něj stáhne a obalí něčím jiným. Nebo totéž udělat pomocí javascriptu a reverzní proxy, která podle adresářů v url rozpozná, kam s požadavkem.

[mrzout]

• generování HTML a vkládání do něčeho jiného (to co píšete vy)
• JSON, XML a pod. a sám si to celé ošetřit
• obecně nějaký bridge:
  http://php-java-bridge.sourceforge.net/pjb/how_it_works.php
  nebo rovnou Zendovský:
  http://www.zend.com/en/products/platform/product-comparison/java-bridge
• a pak věci jako je:
  http://www-01.ibm.com/software/webservers/smash/features/
  což mi připadá jako kombinace předchozích dvou bodů říznutá s vizuálním programováním. Na samostudium mne to neláká, osvětový článek bych ale skousl

Používám jen to první a to je prasárna.

[Vskutečnosti Saýc]

S komponentami nevim, ale muzes relativne snadno pouzivat sluzby jedne aplikace v jine (treba uzivatelske ucty z jedne v jine, a tak) pomoci RESTu.

[happy barney]

teoreticky áno, prakticky je to horšie. Dispatch sa dá poriešiť na úrovni httpd. Problémom môže byť session, ak nie je v databáze. Potom už ostáva len vyriešiť rôzne typy serializácie, ošetriť "bad style". Inak je to zaujímavý nápad

[Dundee5]

To trochu zavání SOA a podobnými zvrhlostmi :)

[dementni.lojzik]

dají se bezešvě integrovat do jedné webové stránky

zkombinovat libovolne dva frameworky v ruzny jazycich AFAIK bezesve nejde I kdyz zalezi na tom, co si kdo pod tim "bezesve" predstavi. IMHO je nejjednodussi pouzit REST, pripadne SOA. Prvne je ale na miste otazka, proc bych se mel snazit pospojovat komponenty ruznych frameworku v ruznych jazycich dohromady. Pokud je cilem teoreticke zamysleni se nad tim, jak to nejak efektivne udelat, tak to by asi bylo na delsi zamysleni (napr. na nejakou diplomku). Pokud je ale cilem efektivni vyvoj aplikace, jak bylo zmineno v predchozim zapisku, pak snaha kombinovat ruzne frameworky je IMHO jeden z nejjistejsich zpusobu, jak vyvoj aplikace udelat velmi neefektivni(*) - aspon podle me male dosavadni zkusenosti.

(*) to plati v pripade, ze se zacina na "zelene louce", pokud uz mam neco udelano v A a neco zas v B a potrebuju to dat dohromady, tak pak pochopitelne stoji za to zvazovat, jak to nejak efektivne dat dohromady... Ale to uz je nejaky konkretni pripad a ne obecny problem, jak kombinovat komponentu A frameworku X s komponentou B frameworku Y, pricem X a Y jsou kazde v jinem jazyku...

[minix]

ja si myslim, ze pan Literak by chtel vyuzit napr. diskuzni forum z abicka nekde jinde (jak pise). To naprosto chapu, to bych taky chtel. Dokonce jsem to chtel udelat uz driv, vadi mi ta Java, to neumim a taky samozrejme nevim, jak moc je ta diskuze v tom celem systemu zadratovana.

[dementni.lojzik]

ano, to bych taky chapal a ma to smysl, jak ostatne pisu v poznamce sveho predchoziho prispevku. Pak by ale bylo namiste napsat konkretni problem, napr. onen jak skominovat php a javu(*), coz by patrne vedlo k plodnejsi diskuzi nez obecny dotaz, jak skombinovat komponenty nejakych dvou frameworku...

(*) osobne s kombinaci java+php zadnou zkusenost nemam, ale google vyplivne vcelku dost odkazu (napr. php/java bridge nebo zend server) a IMHO je vcelku slusna sance, ze nekdo z mistnich ctenaru s tim zkusenosti ma a podeli se o ne...

[Espinosa]

Jde, pokud vám nevadí mít celou stránku sestavenou JavaScriptem a AJAX. Dokonce ani ten JS nemusí být tak složitý, jednotlivá okénka, layout, si sestavý JS a pak obsah do jednotlivých okének dočte pomocí AJAXu, nějaké REST služby, která dodá přímo hotové HTML, obsah sub-okénka. Dělal jsem Javovou část, čistě content, pak to hnaly přes Freemaker do HTML, a pak na klientovi používali ExtJS, nebo jak se ten JS framework jmenuje. Bez JS nebylo z aplikace na klientovi absolutně nic :) ale zato byl ten layout dost flexibilní, pěkně se to roztahovalo s oknem, jak to snad an pomocí HTML/CSS udělat nejde (teda nevím, já do Web UI nedělal už strašně dlouho). Trochu se to podobá tomu řešení pomocí Flash.

Řada potencilálních problémů:

- řada uživatelů JS only stránky neskousne, musela by se udržovat i jednodušší verze (?)

- knihovny, frameworky jako ExtJS se načítají nějakou dobu na obrazovce nic moc vidět vidět není.

- půjde jednoduše vynechat nechtěné části (reklama, ..) ..ale to jde už teď například pomocí GreaseMonkey a skriptík hned distribouvat komunitě (nezkoušel jsem, ani nevím jestli už pro ABC něco takového někdo stvořil)

[Věroš]

Jak už psal nějaký z předskokanů, můžeš mít na pozadí několik různých webových serverů, které budou vracet fragmenty stránky a s uživatelem bude komunikovat pouze nějaký další webserver a ten si v případě nutnosti ty fragmenty vyžádá.

Frajeři to můžou udělat i asynchronně - front-end si kousky nejprve od všech vyžádá a až potom si je od všech vyzvedne, čímž nejspíš sníží režii navazování spojení.

V pozadí nutně nemusíš používat webový server, ale cokoliv-RPC.

selfpromo: Podobně to má třeba náš Cestovatel - většina kódu je v Pythonu, ale třeba Texy! pro Python zatím neexistuje, takže některé věci pro nás řeší PHP.

Mám pocit, že v nějakém webserveru byla i podpora pro skládání stránky z více částí, pomocí nějakých tagů (podobně jako blahé paměti server-include u Apache), ale už nevím, který to byl. Podezírám nginx, ale nemůžu to nikde najít.

[Leoš Literák]

Pojďme tedy mluvit konkrétně, třeba příklad složitější java aplikace (několik stránek a formulářů) psaných v javě chci přidat do php stránek. Pár problémů tu vidím: mapování URL, aby šlo do správného enginu (to by mohl zvládnout mod-jk) a vložení do šablony stránek. Můžete si sice tu šablonu nakódovat i v javě, ale udržovat dvě verze je noční můra. Tady by byl ideální nějaký serverside include. Jak konkrétně to vidíte?

[sivlk]

<?php
echo file_get_contents('http://server/java/stranka');
?>

[VSi]

Problém je, že takhle se k té Java aplikaci z HTTP requestu od uživatele dostane pouze URL. Pár příkladů, proč je to problém:

• Pokud ta Java aplikace využívá formuláře, bude potřebovat HTTP POST DATA.
• Pokud v té Java aplikaci potřebujeme identifikovat uživatele, nebo dokonce držet jeho session, budeme potřebovat HTTP COOKIES / jinou identifikaci.

Obecně k naznačenému problému vidím několik cest k řešení:

• Mapování [aplikace / URL prefix] na úrovní HTTP serveru. Výhodou je nulová nutnost upravovat zpracování request/response části. Nevýhod vidím podstatně víc - dvojí udržování šablon (nebo jejich sjednocení, což půjde těžko); nemožnost v rámci jedné stránky zobrazovat informace z více "modulů" - třeba na titulní straně webu napsané v PHP můžu chtít zobrazovat počet nepřečtených vláken z fóra, což bude Java aplikace.
• Zastřešující aplikace bude zpracovávat veškeré HTTP požadavky, a pro určité komponenty (např. to fórum) je bude přeposílat "backend" aplikaci třeba v té Javě. Může to být přes HTTP, nebo klidně jiný protokol. Je třeba ale myslet na to, že posílat se musí URL, GET a POST data, a buď celé cookies, nebo jen nějaký identifikátor uživatele a session. Tady záleží na tom, jak moc lze / jak moc se hodí upravovat tu backend aplikaci.
• Něco na bázi RPC / Web Services, což se pro hotovou věc, které do teď fungovala přímo nad HTTP asi nehodí.
• Už byla uvedená i možnost skládat stránku na straně klienta javascriptem. Je to taková lepší varianta iframe (což by byla také možnost, vhodná pro nějaké speciální případy - používá se to třeba pro facebookové widgety vkládané na vlastní web). Sám bych se téhle cestě asi vyhnul, pokud má jít o web pro široké použití. Takový přístup může snadno odříznout uživatele minoritních nebo mobilních prohlížečů.

Uvedené cesty lze určitě i vhodně kombinovat. Tady skutečně záleží na konkrétním případu.

Dám příklad: mám v Javě hotové třeba nějaké fórum, co do teď fungovalo samostatně, tj. Java aplikace přímo zpracovávala HTTP požadavky. Teď to chci integrovat do webu udělaného v PHP.

Na stránce, kde chci zobrazovat fórum bych z PHP volal Java aplikaci (přístupnou jen "interně") normálně přes HTTP třeba pomocí CURL. Nebo lze využít jiný, rychlejší způsob volání, a v Java aplikaci emulovat HTTP request. Je třeba předávat veškerá GET a POST DATA, pokud nechci tu backend aplikaci zásadně upravovat. Pak je třeba ošetřit i zpracování odpovědi - Java plikace může vracet "HTML fragment" nebo třeba i přesměrování, u kterého můžu potřebovat upravit URL nebo přidat nějaké parametry. Další problém mohou být URL uvnitř vráceného HTML - např. u odkazů, formulářů apod.

Každopádně bude třeba řešit autentizaci a správu session, a databázi uživatelů, aby se uživatel nemusel přihlašovat dvakrát. Tady jde zase vymyslet zase mnoho způsobů, podle potřeby konkrétních aplikací a možnosti/nutnosti/snadnosti jejich úprav.

[Josef Kufner]

Základem úspěchu je dobře definovat a omezit rozhraní, které bude aplikace propojovat. Jinak v tom bude bordel a bude to neudržovatelné.

Ty URL moc velký problém nejsou – stačí si předat prefix do té vnořené aplikace (ale je na to třeba myslet).

[Věroš]

Nevím o konkrétním hotovém řešení či enginu, ale hádám, že budeš potřebovat definovat si nějaké rozhraní, jak ty jednotlivé enginy budou mezi sebou komunikovat.

Víc konkrétně si to teď nedokážu představit, omlouvám se.

[Filip Jirsák]

Pokud můžeš ovlivnit, kde to PHP poběží, nešlo by použít Quercus? Je to implementace PHP v Javě, je pak prý možné z PHP volat Javovský kód.

[Grunt]

No, ne že bych tomu moc rozuměl, ale co se pamatuju, tak PHP se dalo normálně cpát do HTML (nebo XHTML nebo plain textu nebo vlastně čehokoliv) s tím, že PHP kód začíná po oddělovači (delemiteru) <?php a končí oddělovačem ?>. Cokoliv mimo tyto dva oddělovače se neinterpretuje, ale je zkopírováno beze změny na standardní výstup. Schválně, jak těžké by bylo upravit ostatní interprety (samozřejmě ty otevřené), aby reagovaly na takové oddělovače? IMHO ani moc ne. Stránka pak může klidně vypadat takto:

<!doctype html>
<html>
  <head>
    …
  </head>
  <body>
    _nejaky HTML kod_
    <?php
      …
    ?>
    …
    <?java
      …
    ?>
    …
    <?c
      …
    ?>
    </body>
</html>

[mrzout]

Čímž by jazyky degradujete k pouhému formátování. Tady je řeč o aplikacích.

Například Zend Server umí volat z PHP třídy Javy. Potom by neměl být problém na serverové straně nechat do PHP aplikace generovat určité části z Java aplikace, či prostě jen volat nativně aplikační logiku v Javě.

Tam kde takový bridge nebude, tam komunikovat přes stack či síťově (webservices atd.)

A poslední možnost je volat Javascriptem různé služby ze šablony.

[Grunt]

Já vycházel z toho:

Představte si, že byste třeba blogy a diskuse z Abíčka psaného v javě chtěli vložit do webu nad drupalem či přímo PHP.

Přiznávám, že jinak jsem celou reakci nepochopil (vždyť volat třídy Javy a ještě z PHP a nechat si do něj generovat určité části musí být šíleně pomalé a přibližně rovné emulaci OSS nad PulseAudiem, které má jako backend kombinaci dmixu s ALSou, ne?).

[Josef Kufner]

Jo, bude to pomalé. Ono je už samotné <?php ... ?> v PHP není zrovna moc rychlé (ve srovnání s prostým echo).

[Grunt]

Ono je už samotné <?php ... ? > v PHP není zrovna moc rychlé (ve srovnání s prostým echo).

?

[Bedňa]

Nechápeš, killer fjučúra bashu :D Web v bashi, to má niekto :D

[Grunt]

Nechápeš

No to skutečně teda ne.

[pavlix]

Mno, zrovna ty myslím víš, že já mám web v kombinaci bashe a awk (přeloženo do češtiny, byl jsem zatím línej se naučit perl).

[Josef Kufner]

Ale houby

prostě okolo <? ... ?> je moc práce, takže když děláś nějaké šablony, je lepší používat echo, se kterým má php méně starostí. Zejména to platí u výpisu většího množství položek v cyklu. Bylo to jen trošku offtopic rejpnutí...

[Bedňa]

Medzi <? php ... ?> alebo <? java ... ?> budú operácie s databázami, ukladanie súborov, tak o jakej degradácií je reč? Však to bude to isté, ako keby bežali klasickým spôsobom a výstup je vždy HTML. Pokiaľ budú potrebovať spoločné dáta, to zabezpečí databáza.

[pavlix]

Tebou uvedený přístup je velmi zajímavý, a taky relativně omezený. I když to je popravdě CGI-like skriptování vždycky. A CGI-like skriptování s persistencí db spojení mi přijde z toho všeho skoro největší prasárna. Větší prasárna už je jenom vlastnost PHP, že podobné věci závisí primárně na konfiguraci PHP, a některé sekundárně na aplikaci, jiné nejdou v aplikaci změnit.

V tomhle se PHP ukazuje jako dost nepřenositelné... a bohužel mám s tím i zkušenosti z praxe.

[Bedňa]

Tak to ťa poteší PHP6, tam práve tie prasárny, ala "bezpečný mód ..." budú odstránené.

[pavlix]

Mno, potěší, nepotěší :), už jsem si u PHP4 zvykl, že PHP nemám rád... takže pozdější verze, která mi sebere argumenty, mě zase tak nepotěší :D. Jsem línej měnit názor na něco, čeho jsem se s chutí zbavil :D, to narovinu.

Ale na druhou stranu je pravda, že po mě nikdo chtít, abych něco takového řešil, což mě těší.

A zase vyhodí pár PHPkových adminů, protože s tím nebudou mít už tolik práce :).

[Pavel Stárek]

No myslím si, že to bude taková pěkná směska Apache httpd bude servírovat statický obsah, a přes různé mod_proxy, mod_rewrite, mod_jk a mod_python (pokud by byl kousek v Pythonu) servírovat tu vlastní aplikaci.

Ale co jsem to sledoval na internetu (třeba u některých bank nebo u webů velkých korporací) tak to funguje tak, že "úvodní" web je nakódován staticky (nebo s použitím např.PHP nebo Flashe) a na specializované subweby (například nějaký eShop, issue tracker, bugzilla, downloady pouze pro některé zákazníky apod.) vede nějaký hyperlink z té "úvodní" webové prezentace, která například ještě udělá login do těch dalších aplikací.