Natrafiłem na taki artykuł http://www.alphaworks.ibm.com/tech/dbcjs. W telegraficznym skrócie chodzi o to, że aplikacja kliencka (napisana w javascript) może bezpośrednio połączyć się z bazą danych na serwerze. Innymi słowy - taki ajax, tylko że na nowo. Co o tym sądzicie?

Może dla programistów JavaScript jest to jakieś ułatwienie. Rzuciłem tylko okiem na to i domyślam się ze wszelkie zapytania będą w JS (oczywiście połączenie z bazą w PHP) i czy takie coś będzie bezpieczne? Nie. Po co ktoś ma widzieć z jakiej tabeli pobieram dane? Po co ktoś ma wiedzieć jakie mam kolumny w tabeli? Jak dla mnie bezsensowna praca, bo to się nie przyjmie.

Wszelkie interakcje z bazą powinny być transparentne dla end-usera, moim zdaniem chybiony pomysł.

Dla mnie jest to idealne rozwiązanie. Mam wątpliwości odnośnie bezpieczeństwa, jednak możliwości takiego rozwiązania są ogromne. Przy wykorzystaniu jakiejś biblioteki javascript (jquery, prototype.js, itp) oraz ODC-JS będzie można tworzyć aplikacje praktycznie niezalężne od serwera. Klient raz wpisuje adres, a całą resztą zajmuje się javascript.

Ale korzystając pośrednio z serwera aplikacji (PHP, Tomcat etc...), czyli cały ten AJAX, to też raz się wpisuje adres a resztą zajmuje się JS. Ale mamy większe bezpieczeństwo, nieprzeładowane strony milionem linii kodu w JS (choć korzystając z "AJAX" i tak tego JS jest sporo), nikt nie patrzy jaki burdel mamy w naszym kodzie na serwerze mamy prosty dostęp do statystyk etc. A hosting i tak trzeba mieć do hostowania bazy danych, więc to "praktycznie niezalężne od serwera" to jakaś mrzonka

Jednym słowem - jedno z głupszych rozwiązań, kolejne proponuję stworzyć możliwość przeglądania zasobów komputera klienckiego z poziomu javascript.

Ciekawe czy w ogóle przeczytaliście ten dokument. Jedno ze zdań odnośnie bezpieczeństwa:

Cała komunikacja odbywa się przy pomocy XML poprzez bezpieczne połączenie SSL.

Odnośnie niezależności od serwera. Chodziło mi o to, że tworzeniem strony zajmie się JS a nie PHP, ASP, Ruby (itd.). Całe obciążenie zostaje przeniesione na maszynę klienta. A że nie jest to aż tak duże obciążenie, można przyjąć, że większość komputerów poradzi sobie z tym zadaniem. Inną zaletą takiego rozwiązania jest to, że będzie można zapisać stronę na dysku, uruchomić i nadal się cieszyć tym, że mamy aktualne dane. Daje to bardzo duże możliwości w tworzeniu aplikacji, również pseudo-desktopowych, obsługiwanych z poziomu przeglądarki.

Zgodzę się z tobą że może to znaleźć zastosowanie w aplikacjach pisanych dla konkretnych departamentów jakiejś sporej firmy, np sprawdzanie czy też wklepywanie umów takie plusa, albo obróbka listów przewozowych w firmir kurierskiej.

Pytanie: Po co? JS nie jest ani super wydajny ani super prosty, ani super rozbudowany. To samo można napisać w innych językach i do tego nie trzeba będzie odpalać przeglądarki żeby ta się z JS babrała.

JS sam w sobie nie jest prosty, jednak, przy zastosowaniu odpowiedniej biblioteki, można zrobić praktycznie wszystko. Rozwiązanie to jest na tyle ciekawe, że będzie dawało możliwość tworzenia aplikacji www, które będą niezależne od języka po stronie serwera. Wystarczy napisać sam HTML i JS, który będzie wykonywał większość czynności, które teraz trzeba robić po stronie serwera. Nie twierdzę, że jest to alternatywa do języków skryptowych działających po stronie serwera, lecz uzupełnienie, które pozwoli na jeszcze większą interakcję z użytkownikiem.

Beznadziejny pomysł.
Odpal GMaila na godzinę w FF to będziesz miał przedsmak tego co określasz małym obciążeniem.

Piszesz w kółko że to uniezależni aplikację od języka server-side. Ale powiedz najpierw co rozumiesz pod pojęciem "zależna". Przecież to, że stronę generuje dany język to nie jest żadna zależność. Możesz go podmienić.

Kolejna sprawa, co daje przeniesienie ciężaru na klienta? Poza jego niezadowoleniem że przeglądarka działa wolniej. nic to nie daje.
No w sumie daje, mniej pracy programisty po stronie serwera.

No i ta "możliwość większej interakcji". Co to znaczy? Dla mnie pusty slogan.

Ogólnie pomysł to jakaś dziwna ciekawostka, w mojej opinii nie mająca przyszłości.

I na sam koniec:
To jak? Uniezależniłeś sie od PHP?

Przy obecnych możliwościach obliczeniowych maszyn klienckich nie będzie to problemem. Sam pomysł jest jak na razie w fazie alfa, więc nim ujrzy światło dzienne, komputery zwiększą swoją moc.

Znaczy to między innymi tyle, że nie będziesz potrzebował wchodzić na daną stronę za każdym razem, gdy będziesz potrzebował jakichś informacji. Uruchomisz zapisaną na dysku stronę, a resztą zajmie się JS.

Nie pisałem, że dzięki temu uniezależnię się całkowicie od PHP. Jednak dzięki takiemu rozwiązaniu, po stronie serwera będzie działał jeden skrypt, a nie kilkanaście/kilkadziesiąt, do obsługi ajaxa.
Moim zdaniem rozwiązanie to zasługuje na uwagę tak samo jak ajax, któremu na początku nikt nie wróżył przyszłości.

No ok, ale przecież AJAX łączy się tylko z localhostem, więc jak będą pobierane dane z innych serwerów?

Jeśli przeczytałbyś to, co zmieszczone jest na stronie, wiedziałbyś jak to działa. JS łączy się nie ze skryptem, który ajaxem pobiera dane, lecz z bazą danych (poprzez brankę napisaną w PHP lub JAVIE). Samą prezentacją danych zajmuje się JS.

Przypomnę, że pomysł jest w fazie alfa, więc sporo może się zmienić.

Ale i tak będziesz musiał mieć połączenie z internetem/intranetem, więc co za różnica dla klienta czy będzie miał stronę zapisaną na dysku, czy ściągnie przez sieć?

Poza tym nie od dziś wiadomo, że najwydajniejszą formą (także cost effective) aplikacji sieciowej/firmowej/corporacyjnej jest mainfreme+terminale. A ty oddalasz się bardzo od tego modelu.

Rożnica jest taka, że nie zawsze na jednym serwerze znajduje się i aplikacja i baza danych. Jak padnie serwer z aplikacją, cały czas masz połączenie z bazą.


Najlepszym przykładem jest tutaj nasza klasa

Poza tym coraz częściej się mówi o przeniesieniu dysku twardego do sieci i pracy na aplikacjach sieciowych (np. google docs), więc to rozwiązanie ma szansę na rozwój.

Jeśli padnie serwer to padnie też Twoja bramka, notabene będąca odpowiednikiem aplikacji. Gdzie jest różnica. Ja nie widzę sensownej.

Zamieniasz aplikację, generującą prezentację lekką dla klienta (wygodniejszą dla klienta) na bramkę która dostarcza dane a całość mieli JS, ciężki dla klienta.
Co zyskujesz? Nic poza frustracją klienta.

No chyba że może chodzi o łącze i transfer?

Różnica jest taka, że bramka będzie znajdować się na serwerze bazodanowym, a nie na serwerze aplikacji.


Przecież nie będzie wyciągane kilka tysięcy wierszy, a jedynie określona ich ilość. Nie powiesz mi, że tworząc stronę, na której znajduje się jakaś tabela z danymi, wyciągasz wszystko z bazy, a dopiero potem ograniczasz ilość wierszy, stosujesz sortowanie, itd?

Ale to jest właśnie architektura mainframe + terminale. Przeglądarka jest tym terminalem. Aplikacja jest, na przykładzie google, po stronie serwera, natomiast klient dostaje tylko to co musi zobaczyć + mechanizmy interakcji. Na stronach na których nie jest to potrzebne, choć zupełnie nie mam pojęcia gdzie widzisz zastosowanie dla rozwiązań o których mówisz, nie ma sensu pakować tonę niewydajnego JS klientowi.

Nie mam nic przeciwko temu żeby projekt się rozwijał, nigdy rozwojowi nie będę przeciwny. Ale na razie nie ma dla mnie żadnego uzasadnienia stosowania takiej architektury w środowisku "produkcyjnym".

Tak samo mówiono o ajax-ie. A dzięki niemu sieć przeszła marketingową rewolucję pod nazwą "łep 2.0".
Nie zrozumcie mnie źle, ale należy zachować otwarte umysły na nowe rozwiązania i szukać sposobów ich zastosowania.

Wydaje mi się że źle do tego podchodzisz. Nie należy na silę szukać pola dla zastosowania konkretnej technologii, ale dla konkretnego "problemu" znaleźć odpowiednią technologię.

Dlatego nie należy na siłę wdrażać technologii o której piszesz w przypadku gdy jej użycie jest wysoce dyskusyjne. Chciałbyś na hop-siup zrewolucjonizować sieć, a nie tędy droga. Dla mnie coś takiego ma sens, gdy np. wyświetlasz ogromne ilości danych tabelarycznych, gdzie tak naprawdę wystarczyłby ci konsolowy klient bazy *sql, ale żeby wyglądało to przejrzyściej. Ale takie przykładowe forum php.pl napisane w JS+*SQL to była by wydajnościowa porażka.

Wcześniej wspominałem, że rozwiązanie to znajduje się w fazie alfa i na pewno będzie się zmieniało. Rację masz pisząc, że

Należy jednak wziąć pod uwagę to, że za stworzeniem tej technologii stoi nie kto inny jak IBM, a oni raczej nie robią czegoś tylko po to, by to zrobić. Tak więc na pewno powstało to w jakimś celu, tylko że nie wiemy jeszcze jakim.
Każda nowa technologia powstała nieco na wyrost, a nie jako konieczny wymóg jakieś grupy odbiorców. Owszem, należy kierować się oczekiwaniami użytkowników, jednak nie można zapomnieć, by "sięgać gdzie wzrok nie sięga".

nie do konca ... uwazasz ze jak jak tysiace(setki tys ...) ludzi odpali taka js-aplikacje i bedzie walilo zapytaniami "niby-bezposrednio" do bazy, to kazda baza to wytrzyma ? to kwestia skali ... kazdorazowe nawiazanie polaczenia z baza "kosztuje" czas i zasoby (dlatego jesli mozna cache'uje sie wyniki zapytan, badz cache'uje sie juz przygotowane kawalki strony wygenerowane w oparciu o dane z bazy ...)
pewnie zaraz mnie "skontrujesz" mowiac ze mozna sobie wprowadzic cache do tych zapytan ... tylko wtedy coraz bardziej oddalamy sie od przedstawionej "rewolucyjnej" koncepcji w kierunku "tradycyjnego" generowania stron )
przeciez dzis nic nie stoi na przeszkodzie by cala strone renderowac z poziomu JS, a dane pobierac ze skryptow, ktory zwracaja np: xml'e



hmm to jednak sie laczy ze skryptem php'owym czy nie mozemy sobie go nazywac "bramka", ale i tak sprowadza sie to do wywolania skryptu )

Całość to moim zdaniem ciekawostka, która znajdzie zastosowanie przy bardzo niewielu projektach.

Wywalając aplikację po stronie serwera tracisz ogrom możliwości. Chętnie popatrzę jak JS zacznie maile wysyłać, generować pdf'y, operować na obrazkach, robić upload, ...
I to wszystko za cenę "uniezależnienia się"

a czym to sie rozni od "zwyklego AJAXA" ? bo jak dla mnie to jest to samo,
odbieram to jako nowa biblioteke (i nic wiecej), ktora pewne rzeczy ulatwia, automatyzuje, standaryzuje (tak jak do wywolan XMLHttpRequest, mozesz napisac podstawowa obsluge sam, badz uzywac jakiejs biblioteki np: advAjax ...)

Tym, że do ajax-a trzeba wejść na stronę wygenerowaną przez serwer, a w tym przypadku możesz mieć zapisaną stronę na dysku. I też będzie działać.


Nie twierdzę, że to ma zastąpić całkowicie języki skryptowe po stronie serwera,lecz je uzupełnić o nową funkcjonalność. Podobnie jak w wielu innych przypadkach, rozwiązanie to nie nadaje się do wszystkich projektów.


Łączy się do skryptu, który stanowi bramę między JS a bazą danych, jednak w tym przypadku nie będą wykonywane dodatkowe operacje - pętle, generowanie kodu, itp.

nie do konca, moge miec strone
...
<body onLoad="generujStrone()";>
</body>
</html>

gdzie mam podpiete wywolania Ajaxowe, ktore z bazy pobiora odpowiednie dane i wygeneruja zawartosc strony, jesli ktos ma potrzebe to wszelkie templejty moze miec w JS zapisane ...

a w obu sytuacjach, jest wymagane polaczenie z siecia, inaczej strona nie ma co sciagnac i zaprezentowac uzytkownikowi ...



przeciez jesli masz taka potrzebe to dzis mozesz tak swoja strone napisac ... w czym problem ? Twoja "brama" i moj "skrypt" moga w wyniku dac identyczna zawartosc (xml) ...

Różnica polega na tym, że ~batman pozbywając się wszelkich ograniczeń ograniczy się do bazy IBM a ty "ograniczysz się" do dowolnej.

I to właśnie jest powód dlaczego IBM chce wprowadzić na rynek takie coś.

@mike


@pafka
Jeśli w wywołaniach ajaxowych będziesz miał podany pełny adres skąd ma pobierać dane, to może to zadziała.

to kwestia jak masz napisana strone, w obu sytuacjach musisz podac skad pobrac dane ( localhost czy inny serwer ), mozesz to zrobic jawnie w wywolaniu JS, mozesz przez pewne atrybuty, ktore pozniej w skrypcie sa odpowiednio odczytywane i interpretowane

roznica miedzy obluga Ajaxowa ktora sobie bym napisal a rozwiazaniem IBM jest taka, ze IBM opracuje pewne API, ktorego musisz sie trzymac w projektach, API narzuci ci pewne standardy zachowan, wywolan, obslugi, udostepni CI zapewne pare podstawowych narzedzi do obslugi otrzymanych danych (np: automatyczna konwersja otrzymanych danych w xml do tablicy ... ) zebys nie musial na nowo "odkrywac Ameryki" )