Iwa lepsza od Ajax-u, Ajax skomplikowany w uytkowaniu .. Opcje

[060156]

Kilka lat temu (przed Ajax-em) opracowalem Iwa
(Interactive Web Architecture)
Oparta jest on na wymianie Content Objects (javascript,php,python objekty) uzywajac Iwa servisow zamimplementowanych w POST and GET ktore
korzystajac z frame lub iframe.
Content jest zapisywany podobnie jak w JSON i dopowiednio konwertowny
na javascript, php lub python objekty bez koniecznosci parsowania.

Obecne sa trzy implementacje Iwa
Ligt - do pisania statycznych portali (multi browsers)
Mix - do pisania interatywnych portali (multi browsers)
Heavy - to pisania interatywnych aplikacji z skomplikowanym GUI ( tylko IE)

Polsugiwanie sie Ajax-em to jak poslugiwanie sie telefonem z koniecznosci
znajomosci jak on dziala technicznie.

W Iwa jest to banalnie proste np:

wywolanie service z browsera:

MyIwa.service("ServicePage.php","nazwa_servisu", [
["sa","nazwa_parametru",java script object lub wartosc)],
["sa",".........................",......................................],
["sb",java script object]
["sr",responseFunction]]);

function responseFunction(body, args, error) { // odpowiedz na wywolanie
if(error) return ; // if error
var value=args.get("nazwa_parametru"); // wartosci lub javascript object
}

po stronie php implementacja service w ServicePage.php:

$_iwa = new MyIwa();

if(!$_iwa->is_forward()) // forward service do innego web servera

switch($_iwa->service()) { // jaki servis zostal wywolany z browsera

case "nazwa_servisu":

$nazwa_paramatru = $_iwa->arg("nazwa_parametru"); // pobranie pramateru
z request service

$_iwa->arg("nazwa_parametru",php_object lub wartosc); // odwiedz na service


$_iwa>errror("Ustawienie bledu aplikacji"); // ustawienie bledu jesli jest

$_iwa->response(); // wyslanie odpowiedzi do browera na wywolanie
servisu
break;

}

Iwa service mozna uzywac w dwoch opcjach push and pull.

Iwa umozliwia wywolywanie servisow z browsera umiejscowionych
na roznych web serwerach.Wtedy web server z ktorego zaladowano
strone forwarding ten servis to innych web serwera.
Czyli mozliwe jest tworzenie eco-systemu servisow zaimplementowanych
na roznych web serwerach. (Ajax nie implementuje tej opcji).

Rozmiar podstawowych bibliotek do implemntacj Iwy jest minimalny:

javascript - 500 lini kodu
php - 600 lini kodu
python - 200 lini kodu

Sporo aplikacji zostalo juz napisanych w Iwa i obserwacja moja jest
taka, ze czas ich pisana aplikacja skraca sie okolo 10 razy i
ich jakosc jest zdecydowanie wysoka..

Jesli ktos ma jakies zapytania o IWA prosze o kontakt ..

060157@gmail.com

[hawk]

Ja sobie zdaję sprawę, że IWA posiada wiele funkcjonalności, których nie zawiera AJAX. Bo tak naprawdę to AJAX == XMLHTTPRequest, i wszelkie porównania nie mają sensu, bo porównujemy rzeczy nieporównywalne. Wystarczy popatrzeć na wielkość kodu. Piszesz, że IWA to ok. 1000 linii kodu. Ale przecież AJAX to 0 linii kodu, słownie zero. Ja tam lubię używać gołego XMLHTTPRequest (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) . Ba, obsługa SOAP to również zero linii kodu, przynajmniej w Mozilli. Więc IWA jest rozwiązaniem znacznie bardziej kompleksowym i... większym.

Więc chcę podkreslić, że nie ignoruję zalet IWA, przede wszystkim wspomnianej jednolitości rozwiązania. Niestety nie miałem okazji bliżej się zapoznać, natomiast widzę tutaj dwa zasadnicze problemy:

1) Użycie iframe zamiast XMLHTTPRequest. Pewnie, że to działa, ale problemy z kompatybilnością są. Ponadto funkcjonalność iframe jest ograniczona. Np. nie można (AFAIK) ustawiać nagłówków HTTP. Więc rozwiązanie to jest gorsze od hipotetycznego analogicznego rozwiązania bazującego na XMLHTTPRequest.

2) Piszesz o "dostępie do dowolnego serwisu w enterprise". Otóż nie, tutaj funkcjonalność IWA jest z konieczności bardzo ograniczona. Większość web services opiera się jednak o SOAP. Jak już mówimy o rozwiązaniach "enterprise", to dopiszmy jeszcze do tego np. serwer UDDI i specyfikacje WSDL. IWA wykorzystuje zapewne własny protokół. Teraz są dwa rozwiązania: przepisać istniejącą architekturę na format używany przez IWA lub... wywalić to i oprzeć się jednak o standardy. I to nie jest akurat wada wyłącznie IWA, ale też wszystkich rozwiązań AJAX-owych opartych np. o JSON. Do porządnej implementacji web services potrzebna jest dobra biblioteka SOAP pod JavaScript, a takiej nie udało mi się na razie znaleźć.

A co do dodatkowego nakładu pracy i łatwości użycia: porównaj sobie web service napisany w IWA z obsługą SOAP. Przecież obsługi tego drugiego w ogóle nie trzeba pisać: kod sam się generuje z WSDL (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) .