Cituji Oto Buchta <[EMAIL PROTECTED]>:
Az bude chtit smenarna webovou sluzbu, tak se prida webova sluzba. Proc by
se kvuli tomu melo prepisovat JSP opravdu nevim.
a) JSP vracejici SOAP Envelope je SOAPova WebServisa, JSP vracejici XML
je mozno povazovat za XML WebServisu
b) pokud bude implementace pomoci JAXB, JavaWS ci neceho podobneho, ano,
nebude se prepisovat JSP, ale "copy&paste z JSP" do nove vzniknuvsi Java
tridy asi delat budes, ne? Nebo to budes znova vymyslet a psat?
Ahoj Tapiku,
musim priznat, ze nechapu jak se bod a) vztahuje k tomu, co jsem napsal a
JSP vracejici SOAP jsou pro me novinkou. Pokud jde o JSP vracejici
XML, tak to samozrejme jde. Ale proc by se kvuli tomu prepisovalo
puvodni JSP jsi mi nevysvetlil.
Ohledne implementace v Java WS: zadne copy&paste tady nebude. Tedy
krome SQL prikazu, pokud bych pouzil JDBC. Pri pouziti JPA ovsem ani
to ne.
Mozna Te to prekvapi, ale nektere metodologie (napr. extremni programovani)
davaji prednost jednoduchym resenim pred resenimi komplexnimi a
univerzalnimi.
Ano, kdyz pisu jednoucelove perlove skripty, taky je nepisu univerzalne.
Ale az ten samy ci velice podobny pisu potreti, spis si vezmu ten stary
a zobecnenim vytvorim skript, ktery zvlada obe ulohy. Takze v pripade
tvorby one WebServisy bych SQL vyextrahoval bokem (byt do nejakeho helperu)
a ten potom volal z obou mist... Pak ale SQL z JSTL prestanu potrebovat...
To JSTL SQL, ktere jsem pouzil v predchozim mailu, melo 13 radku.
Opravdu mas pocit, ze je efektivni vytvaret sofistikovane reseni, abys
budoucnu pri souhre nekolika okolnosti (ktere mohou, ale nemuseji
nastat) nemusel tech 13 radku zahodit?
Nehlede na to, ze vytvareni slozitejsiho reseni na zaklade
vlastni uvahy (v zadani to neni) "co kdyz nekdy mozna...", je ekonomicky
jen tezko zduvoditelne.
Bohuzel mam pro tebe spatnou zpravu: naopak je to velice JEDNODUSE
zduvodnitelne. Ono totizto "co kdyz mozna..." v sobe zahrnuje i neco, jako je
nasledny vyvoj aplikace. Rozsirovani a udrzba software zabere vetsinou vice
casu nez prvotni vytvareni. A neustalym psanim stejneho software
znovu a znovu
si jiste ve vysledku nic neusetris.
K tomuhle mam jednu poznamku: vyvoj "univerzalnich" komponent, ktere
jdou nad ramec zadani, je pomerne castym duvodem selhani projektu.
Z.T.
--
Zdenek Tronicek
Department of Computer Science and Engineering
Prague tel: +420 2 2435 7410
http://cs.felk.cvut.cz/~tronicek
