JAIN SLEE vs. SIP Servlet
105 views
Skip to first unread message
Tomasz Zieleniewski
Dec 2, 2008, 10:15:23 AM12/2/08
to Warszawa Java User Group (Warszawa JUG), te...@touk.pl
Niestety po samej konferencji nie miałem zbyt wiele czasu,
żeby coś więcej napisać, a teraz mam chwilkę:)
Na wstępie warto jest powiedzieć, że czasami bardzo ciężko jest
odseparować
decyzje podejmowane ze względów czysto politycznych od tych
praktycznych:)
Bardzo często to co z biznesowego punktu widzenia wydaje się być
zaletą z
technicznej strony jawi się jako słabość. Np zgodność platformy
aplikacyjnej z
modelem aplikacji Servletowych w kontekście "marketingowej
konwergencji" jest
lekkim nadużyciem pojęciowym, które w praktyce wcale nie musi być
zaletą dla
tworzonej aplikacji telco.
Pytanie wokół, którego nawiązała się dyskusja to dlaczego kontener
JAIN SLEE
jest lepszy niż SIP Servlet. Uważam, że oba rozwiązania mają swoje
zalety i wady,
które w określonych przypadkach mają większe bądź mniejsze znaczenie.
Dla jasności, będę się wyłącznie skupiał na aspektach praktycznych tzn
tych
"nisko poziomowych" niuansach istotnych dla deweloperów i twórców
aplikacji.
Poniżej przedstawię zalety SLEE wobec SIP Servletu, o które jak
pamiętam na
konferencji byłem zapytany. Nie znaczy to, że SIP Servlet nie ma zalet
nad JAIN SLEE:)
Ale to jest temat na oddzielny post:)
Pierwsza rzecz, którą chce podkreślić to to, że SIP jako protokół jest
o wiele bardziej
złożony niż HTTP. Wynika to z faktu, że HTTP jest protokołem
aplikacyjnym a SIP
protokołem sesyjnym. Aplikacje oparte na protokole SIP to mnóstwo
wiadomości,
równoległych i krótkich transakcji, sesji oraz połączeń. SIP nie jest
protokołem
asymetrycznym tzn. takim, w którym wyłącznie strona kliencka
(inicjator) wysyła
żądania, na które odpowiada serwer. W protokole SIP adresat ma również
możliwość
wysyłania żądań, wielokrotnego odpowiadania oraz przekierowywania i
pośredniczenia
na drodze wiadomości w ramach danego przepływu. W takim przypadku
szeroko rozumiany
stan aplikacji jest znacznie bardziej złożony niż w przypadku HTTP.
Ponieważ SIP Servlet
jest mutacją HTTP Servletu jest w swojej naturze bezstanowy. Aby
osiagnąc persystencje
stanu aplikacji na poziomie Servletu musimy odwoływać się do kontekstu
i przywracać jej
stan dla kolejnych wiadomości. W JAIN SLEE instancja serwisu
reprezentowana jest
przez logiczny twór "SBB Entity". Stan usługi jest persystentny na
poziomie danej instancji
SBB i dostępny poprzez pola CMP lub byty ACI (Activity Context
Interface) widziane przez
wiele instancji SBB jednocześnie. Fizyczne umiejscowienie stanu może
być w pamięci procesu,
pamięci dyskowej, itp ale jest ono transparentne z punktu widzenia
logiki aplikacji.
Aby osiągnąć wysoką skalowalność rozwiązania, w którym aspekty takie
jak czas
odpowiedzi są kluczowe, bardzo ważne jest, żeby poszczególne
częścilogiki aplikacji
w najmniejszym stopniu blokowały wykonywanie innych jej fragmentów.
Innymi słowy
kontener powinien udostępniać najoptymalniejszy mechanizm
"zrównoleglenia". Zarówno
SLEE jak i Servlety umożliwiają wykorzystanie puli wątków, z których
każdy dynamicznie
w miarę potrzeb jest rezerwowany. Różnica polega na tym, że w
Servlecie poza obsługa
protokołu SIP, która jest zrealizowana na poziomie implementacji stosu
SIP, logika
jest synchroniczna, czyli wstrzymuje wątek w ramach którego jest
wykonywana. SLEE
dzięki swojej architekturze (warstwie RA do komunikowania się ze
światem zewnętrznym
oraz wewnętrznym asynchronicznym modelu komunikacyjnym opartym na
zdarzeniach)
umożliwia optymalniejszą granulacje poszczególnych fragmentów logiki
aplikacji. Można
np. poszczególne części logiki aplikacji zaimplementować w oddzielnych
SBB i
zdefiniować zdarzenia za pomocą których będą się komunikować.
Tak jak już wspominałem zarówno SIP Servlet jak i JAIN SLEE mają swoje
wady i zalety.
Sama decyzja który kontener jest lepszym wyborem dla danego
rozwiązania jest kwestia
o wiele bardziej złożoną i nie ma sensu stawiać bezwarunkowych tez, że
jeden czy drugi
nie ma prawa bytu. Można się natomiast spierać który jest fajniejszy;]
Tomek
żeby coś więcej napisać, a teraz mam chwilkę:)
Na wstępie warto jest powiedzieć, że czasami bardzo ciężko jest
odseparować
decyzje podejmowane ze względów czysto politycznych od tych
praktycznych:)
Bardzo często to co z biznesowego punktu widzenia wydaje się być
zaletą z
technicznej strony jawi się jako słabość. Np zgodność platformy
aplikacyjnej z
modelem aplikacji Servletowych w kontekście "marketingowej
konwergencji" jest
lekkim nadużyciem pojęciowym, które w praktyce wcale nie musi być
zaletą dla
tworzonej aplikacji telco.
Pytanie wokół, którego nawiązała się dyskusja to dlaczego kontener
JAIN SLEE
jest lepszy niż SIP Servlet. Uważam, że oba rozwiązania mają swoje
zalety i wady,
które w określonych przypadkach mają większe bądź mniejsze znaczenie.
Dla jasności, będę się wyłącznie skupiał na aspektach praktycznych tzn
tych
"nisko poziomowych" niuansach istotnych dla deweloperów i twórców
aplikacji.
Poniżej przedstawię zalety SLEE wobec SIP Servletu, o które jak
pamiętam na
konferencji byłem zapytany. Nie znaczy to, że SIP Servlet nie ma zalet
nad JAIN SLEE:)
Ale to jest temat na oddzielny post:)
Pierwsza rzecz, którą chce podkreślić to to, że SIP jako protokół jest
o wiele bardziej
złożony niż HTTP. Wynika to z faktu, że HTTP jest protokołem
aplikacyjnym a SIP
protokołem sesyjnym. Aplikacje oparte na protokole SIP to mnóstwo
wiadomości,
równoległych i krótkich transakcji, sesji oraz połączeń. SIP nie jest
protokołem
asymetrycznym tzn. takim, w którym wyłącznie strona kliencka
(inicjator) wysyła
żądania, na które odpowiada serwer. W protokole SIP adresat ma również
możliwość
wysyłania żądań, wielokrotnego odpowiadania oraz przekierowywania i
pośredniczenia
na drodze wiadomości w ramach danego przepływu. W takim przypadku
szeroko rozumiany
stan aplikacji jest znacznie bardziej złożony niż w przypadku HTTP.
Ponieważ SIP Servlet
jest mutacją HTTP Servletu jest w swojej naturze bezstanowy. Aby
osiagnąc persystencje
stanu aplikacji na poziomie Servletu musimy odwoływać się do kontekstu
i przywracać jej
stan dla kolejnych wiadomości. W JAIN SLEE instancja serwisu
reprezentowana jest
przez logiczny twór "SBB Entity". Stan usługi jest persystentny na
poziomie danej instancji
SBB i dostępny poprzez pola CMP lub byty ACI (Activity Context
Interface) widziane przez
wiele instancji SBB jednocześnie. Fizyczne umiejscowienie stanu może
być w pamięci procesu,
pamięci dyskowej, itp ale jest ono transparentne z punktu widzenia
logiki aplikacji.
Aby osiągnąć wysoką skalowalność rozwiązania, w którym aspekty takie
jak czas
odpowiedzi są kluczowe, bardzo ważne jest, żeby poszczególne
częścilogiki aplikacji
w najmniejszym stopniu blokowały wykonywanie innych jej fragmentów.
Innymi słowy
kontener powinien udostępniać najoptymalniejszy mechanizm
"zrównoleglenia". Zarówno
SLEE jak i Servlety umożliwiają wykorzystanie puli wątków, z których
każdy dynamicznie
w miarę potrzeb jest rezerwowany. Różnica polega na tym, że w
Servlecie poza obsługa
protokołu SIP, która jest zrealizowana na poziomie implementacji stosu
SIP, logika
jest synchroniczna, czyli wstrzymuje wątek w ramach którego jest
wykonywana. SLEE
dzięki swojej architekturze (warstwie RA do komunikowania się ze
światem zewnętrznym
oraz wewnętrznym asynchronicznym modelu komunikacyjnym opartym na
zdarzeniach)
umożliwia optymalniejszą granulacje poszczególnych fragmentów logiki
aplikacji. Można
np. poszczególne części logiki aplikacji zaimplementować w oddzielnych
SBB i
zdefiniować zdarzenia za pomocą których będą się komunikować.
Tak jak już wspominałem zarówno SIP Servlet jak i JAIN SLEE mają swoje
wady i zalety.
Sama decyzja który kontener jest lepszym wyborem dla danego
rozwiązania jest kwestia
o wiele bardziej złożoną i nie ma sensu stawiać bezwarunkowych tez, że
jeden czy drugi
nie ma prawa bytu. Można się natomiast spierać który jest fajniejszy;]
Tomek
Waldek Kot
Dec 6, 2008, 11:26:06 AM12/6/08
to Warszawa Java User Group (Warszawa JUG)
Cześć,
Odpowiadam późno, bo też mi się trochę spraw w zeszłym tygodniu
ponakładało...
Przede wszystkim dzięki za wypowiedź ! Podczas Twojego wystąpienia na
Warsjava 2008 spór pojawił się w momencie porównania SIP Servlet i
JAIN SLEE (skądinąd, do tego momentu uważam, że była to bardzo dobra
prezentacja i kilka z analogii, których użyłeś, oceniam na bardzo
trafne). Spór powstał, gdy podsumowałeś, że - luźno cytując: "SIP
Servlet API nadaje się do budowy prostych usług telekomunikacyjnych,
natomiast JAIN SLEE jest platformą i wspiera budowę zaawansowanych
usług". To wywołało moje pytanie "dlaczego", no i poszło... Taka
opinia stoi bowiem w kompletnej sprzeczności z moją wiedzą i moimi
osobistymi doświadczeniami w robionych od kilku lat projektach, a
także z opiniami osób (z obu stron, tj. wdrażających, jak i tych u
których wdrażano). Zresztą, także osób, które brały aktywny udział w
rozwoju samego JAIN SLEE. Ten argument o "SIP Servletach nadających
się do prostych usług", to zresztą typowy marketingowy argument ludzi
z obozu JAIN SLEE (jakoś mity trzeba budować...).
Pewnie też pamiętasz, że postawiłem tezę, że "SIP Servlet ma się tak
do JAIN SLEE, jak Spring do EJB 2.1 i wcześniejszych". Będę tej tezy
bronić. Specyfikacja JAIN SLEE jest bardzo mocno wzorowana na
specyfikacji EJB (ale nie 3.0, tylko tych wcześniejszych). Mimo, iż
wersja 1.1 JAIN SLEE pojawiła się w tym roku, to niestety NIE czerpie
z doświadczeń EJB i NIE wprowadza podobnych ulepszeń, jakie w EJB 3.0
wprowadzono. Także większość "argumentów" za JAIN SLEE, bardzo
przypomina argumentację o wyższości EJB z dawnych czasów m.in. nad
Springiem (pastwieniem się byłoby tu i teraz przypominać o tym gdzie
jest dzisiaj EJB a gdzie jest Spring). W tym co napisałem poniżej,
można odnaleźć ducha tej postawionej tezy. Do większości mitów o
"wyższości" JAIN SLEE można odnaleźć analogiczny mit o wyższości EJB.
Spring i ORMy (Hibernate, Kodo, Toplink, iBatis, ...) skutecznie te
mity obaliły (swoją drogą ciekawe jak podniósłby się poziom emocji
wśród ludzi na sali, gdyby usłyszeli, że "Spring nadaje się do budowy
prostych aplikacji, natomiast EJB ..."). Podobnie, w JAIN SLEE można
odnaleźć większość "grzechów" EJB (2.1 i wcześniejszych).
Poniżej bardziej merytoryczne opinie o obu technologiach, w tym moje
trzy grosze do dyskusji o mitach wokół JAIN SLEE i SIP Servlet.
Niestety, wypowiedź będzie z tych dłuższych, ale chciałem też, aby
byli ją w stanie śledzić ludzie, którzy NIC o telekomunikacji, w tym o
SIP Servlet i JAIN SLEE nie wiedzą. A gdy pojawi się żargon, to żeby
spróbować go trochę odczarować...
W każdym razie, moja krótka odpowiedź: w zakresie asynchroniczności,
stanowości, czasu odpowiedzi, skalowalności, wydajności, ani lepszego
jakościowo dopasowania do zagadnień telco, JAIN SLEE NIE wykazuje
ŻADNYCH przewag nad SIP Servlet. W stopniu skomplikowania i
programistycznej egzotyce faktycznie, przewaga jest duża.
Wersja dłuższa odpowiedzi poniżej.
On 2 Gru, 16:15, Tomasz Zieleniewski <tzieleniew...@gmail.com> wrote:
> Na wstępie warto jest powiedzieć, że czasami bardzo ciężko jest
> odseparować decyzje podejmowane ze względów czysto politycznych od tych
> praktycznych:)
> Bardzo często to co z biznesowego punktu widzenia wydaje się być
> zaletą z technicznej strony jawi się jako słabość. Np zgodność platformy
> aplikacyjnej z modelem aplikacji Servletowych w kontekście "marketingowej
> konwergencji" jest lekkim nadużyciem pojęciowym, które w praktyce wcale nie musi być
> zaletą dla tworzonej aplikacji telco.
Przyznam, że nie zrozumiałem tego co napisałeś. Prośba o wyjaśnienie.
Niestety, ale dużo mitów i niezgodności pojawiło się w tej części.
Słychać tu echa tego co piszą marketingowcy z firm wokół JAIN SLEE,
choćby OpenCloud, jNetx, czy Mobicents (RedHat/JBoss). Notabene - ten
ostatni mam wrażenie od pewnego czasu zaczyna się jakby dystansować i
zmierza w stronę SIP Servlet, na razie pod mantrą "dajemy Ci
deweloperze oba API - JAIN SLEE i SIP Servlet - sam wybierz sobie,
które wolisz". Symptomatyczna odmiana. Ale popieram, popieram ;-).
Podobną drogę w stronę SIP Servlet obrały wcześniej choćby IBM
(WebSphere Application Server 6.x) i Sun (projekt Glassfish Sailfin).
Różnice między protokołami HTTP i SIP są oczywiście OCZYWISTE i
przynajmniej niektóre z nich przytoczyłeś. Te "protokołowe" różnice
jednak, w żadnej mierze NIE przekładają się na poziom API. SIP Servlet
API NIE jest żadną mutacją HTTP Servlet API, ani NIE wywodzi się z
HTTP Servlet API (notabene - oba wywodzą się ze wspólnego
"bezprotokołowego" Servlet API). Rzut oka na specyfikacje servlet'ów,
pozwala szybko zrozumieć czego ona głównie dotyczy:
- zwolnienie programisty z konieczności samodzielnego parsowania
komunikatów danego protokołu
- zwolnienie programisty z konieczności obsługi wielu,
niskopoziomowych mechanizmów danego protokołu
- wprowadzenie trochę wyższego (ale celowo tylko nieznacznie
wyższego !) poziomu abstrakcji danego protokołu, poprzez udostępnienie
"naturalnych", zrozumiałych dla programisty obiektów programistycznych
(np. Request, Response, Message, ...)
- wprowadzenie (przydatnych w praktyce budowy aplikacji) obiektów
programistycznych - np. "ulepszających" protokół (przykład: koncepcja
sesji)
- wprowadza model security
- wprowadza model zarządzania życiem komponentów
- opisuje strukturę i deployment aplikacji
- precyzuje inne tematy, które mają polepszyć przenośność aplikacji
Z racji tego, iż bardzo wiele elementów protokołu SIP było wzorowanych
na HTTP i SMTP (głównie w zakresie SPOSOBU opisu komunikatów, kodów
błędów, paradygmatu request-response, itp), to można zaobserwować
znaczne podobieństwo w wielu miejscach na poziomie obu API (podobne
obiekty, podobne mechanizmy security, podobny opis struktury
aplikacji, itd.). Ma to OGROMNĄ praktyczną zaletę, bo ktoś kto rozumie
model budowy aplikacji webowych opartych o servlet'y (jakieś kilka
milionów deweloperów), będzie mógł SPORĄ część tej wiedzy powtórnie
wykorzystać i znacznie szybciej zacznie budować aplikacje
komunikacyjne (co wiele osób, które dotknęły SIP Servlet API - np.
widziały moje skromne prezentacje podczas Javarsovii 2008, czy JUGów -
potwierdza. O klientach na tych łamach mówić nie wypada). Bariera
wejścia w przypadku SIP Servlet API jest NIEPORÓWNANIE niższa niż dla
JAIN SLEE API także i z powodu tych podobieństw.
Poza tym, skoro w opisanych w specyfikacji zagadnieniach model
servlet'owy sprawdza się od kilkunastu lat, to po co wymyślać koło
powtórnie (a że się sprawdza, to chyba nie muszę przekonywać - nie ma
drugiego tak akceptowanego podejścia niż servlet'y - mimo iż "ponad"
servlet'ami są nakładane dodatkowe warstwy (np. w ramach
framework'ów), to jednak 99% z tych warstw pełnymi garściami czerpie z
podejścia servlet'owego).
Servlet jako API i specyfikacja, jest moim zdaniem odpowiednio
zrównoważony - nie jest zbyt abstrakcyjny (i to jest mój zarzut dla
JAIN SLEE), jest blisko danego protokołu komunikacyjnego (przez co
oddaje jego naturę) i jest zwięzły (tj. skupia się na rozwiązaniu
konkretnych problemów, zamiast rozwiązywać wszelkie, w tym czasem
abstrakcyjne, problemy budowy aplikacji - vide JAIN SLEE). Jest
oczywiste, że jedno API nie podoła wszystkim problemom, stąd powinno
integrować się i czerpać z tego co inne API oferują.
Ale - i tu kluczowa sprawa dla tej części Twojej wypowiedzi - to
podobieństwo SIP Servlet do HTTP Servlet NIE DOTYCZY sposobu
przetwarzania komunikatów, w tym zarządzania stanem
"protokołowym" (SIP Servlet API honoruje w tym zakresie WSZELKIE
wymagania protokołu SIP, między innymi opisaną w specyfikacji
protokołu SIP transakcyjność, maszynę stanów, itd. - w TYM zakresie
SIP Servlet NIE ma żadnych związków z HTTP Servlet i z bezstanową
naturą protokołu HTTP). Powtórzę - SIP Servlet NIE jest bezstanowy, bo
protokół SIP NIE jest bezstanowy. Kontener SIP Servlet MUSI tym stanem
zarządzać. Zresztą tutaj widać jedną z ról jaką pełni kontener, czyli
zwolnienie programisty aplikacyjnego z konieczności ręcznego
zarządzania tym stanem. Ta wiedza jest (w dużym stopniu) niepotrzebna
deweloperowi, kto buduje logikę aplikacji, więc najlepiej niech
operacje związane z zarządzaniem maszyną stanów protokołu "dzieją" się
w tle (podnosimy poziom abstrakcji w nadziei na lepszą produktywność
programisty).
Drugi wątek w tej części Twojej wypowiedzi dotyczy stanu, ale to o
czym piszesz dotyczy stanu APLIKACJI (czyli DODATKOWEGO stanu, który
wynika ze specyfiki danej logiki biznesowej). Tak, tutaj HTTP Servlet
API "wzbogaca" protokół HTTP i udostępnia komponentom aplikacyjnym
(servlet'om) mechanizm sesji, w tym sposób śledzenia sesji,
widoczności danych w sesji, timeout'ów, itd. Logika umieszczona w HTTP
Servlet'ach może z tego stanu ("danych", czy obiektów) skorzystać, czy
zmodyfikować. Podobnie (i znowu to jest ZALETA, że podobnie) czyni SIP
Servlet API - logika umieszczona w SIP Servletach może przechować stan
APLIKACYJNY w takiej sesji (notabene - SIP Servlet idzie nawet trochę
dalej i udostępnia mechanizm sesji aplikacyjnej, czyli możliwość
skojarzenia ze sobą wielu różnych sesji, w tym pochodzących z
komponentów obsługujących różne protokoły, np. pod jednym parasolem
byłby stan tworzony przez HTTP servlet'y i SIP servlet'y w ramach
jednej aplikacji konwergentnej, np. udostępniającej interfejs webowy i
telefoniczny/"SIP-owy"). W tym sensie, NIEKTÓRE (i to jest bardzo
istotne podkreślenie) servlet'y SĄ stanowe, tj. korzystają ze stanu.
Podobnie, jak niektóre komponenty JAIN SLEE (np. SBB - Service
Building Block, czyli taki "odpowiednik" EJB w JAIN SLEE) mogą być
bezstanowe. To jest decyzja DEWELOPERA, nie API.
Wbrew temu co piszesz, mechanizm zarządzania stanem komponentów
aplikacyjnych w JAIN SLEE w gruncie rzeczy DZIAŁA podobnie (choć opis
tego DZIAŁANIA jest - podobnie jak i większość specyfikacji JAIN SLEE,
do której poczytania ZAWSZE zachęcam - dosyć skutecznie zagmatwany,
przez co wygląda "naukowo"). Tutaj także komponent aplikacyjny (na tym
etapie jest nieistotne, czy jest to SBB, kontener, czy RA - Resource
Adapter, czyli komponent, który pośredniczy pomiędzy konkretnym
protokołem komunikacyjnym a JAIN SLEE) decyduje czy i jaki stan
utworzyć i gdzie go umieścić (np. bardziej lokalnie, tj. w polach CMP,
czy bardziej globalnie, czyli w ACI lub nawet w profilu - na tym
etapie także, nie jest istotne co to jest CMP, ACI, czy Profil - ot,
upraszczając, miejsce przechowywania stanu, o różnych zakresach
"widzialności" i ewentualnych dodatkowych możliwościach). W tym sensie
- tak samo jak w SIP Servlet ! - niektóre komponenty są stanowe a
niektóre bezstanowe. W JAIN SLEE marketingowana różnica polega na tym,
że ten stan będzie automatycznie zarządzany przez kontener. Pewnie
wiele osób, które zetknęły się z EJB już widzi podobieństwo do EJB
Entity Beans i CMP (Container Managed Bean). JAIN SLEE powstawało w
epoce euforycznego zachłyśnięcia się EJB, w tym wiary iż jedynym
słusznym podejściem na problem persystencji obiektów są właśnie Entity
Beans i CMP. Po kilku latach eksperymentów i dokonywania cudów w
kontenerach EJB (znam parę osób, które napisały o tym doktoraty),
wiemy jako społeczność deweloperów, iż EJB CMP okazały się kompletną
porażką (polecam popatrzeć na "klimat" wokół nich w Java EE 6, gdzie
NAJPRAWDOPODOBNIEJ będzie to jedna z pierwszych w historii Java EE
technologii, które zostaną z Java EE WYCOFANE. Już w EJB 3.0, znane z
wcześniejszych edycji Entity Beany są w trybie maintanance i NIE ma w
tym zakresie rozwoju. Mam mało wiary w to, że JAIN SLEE wskrzeszy i
uzdrowi to podejście). Zresztą, CMP w JAIN SLEE jest bardzo prymitywne
- nie ma tutaj mowy o bardziej złożonym stanie (np. relacji pomiędzy
obiektami stanu - choćby znanego z EJB 2.1 i wcześniejszych CMR -
Container Managed Relationship). Czyżby autorzy JAIN SLEE zakładali,
iż logika biznesowa w komponentach nie potrzebuje bardziej złożonego
stanu niż "odpowiednik" jednego wiersza z jednej tabeli ?
Śmiem twierdzić, że połączenie SIP Servlet i z innymi technologiami
zarządzania stanem da ten sam efekt co mechanizm CMP w JAIN SLEE. Z
tym, że deweloper będzie miał tutaj większy wybór (od prostych
mechanizmów przez ORM (JPA ?), po distributed cache lub in-memory data
grid). A przy tym, jest spora szansa, że będzie to coś co jest mu
znane (powraca argument o produktywności).
Tym bardziej, że zarządzanie stanem to jest bardzo złożony problem.
Generalnie, jako świat ludzi budujących systemy, wiemy, że im mniej
stanu, tym lepiej dla skalowalności aplikacji, a także (choć to mniej
widoczne) dla jej wydajności. Podobnie, im mniej współdzielonego
stanu, tym lepiej, bo takie współdzielenie wymaga kontroli (np.
synchronizacji) i obniża możliwości zrównoleglenia operacji w
aplikacji. Zresztą - zarządzaniem stanem NIE jest przedmiotem ŻADNEJ
specyfikacji Java EE. Bo to jest kwestia implementacyjna i w gestii
kontenera - efektywnością implementacji zarządzania stanem mają
dostawcy kontenerów ze sobą konkurować. API jest tu wtórne (w
większości przypadków wystarczy to, co daje interfejs Map). Z tego
faktu, że JAIN SLEE daje kilka API zarządzania stanem (w gruncie
rzeczy sprowadzają się to do kontroli widoczności stanu) NIE wynika
większa przydatność tego API do obsługi takiego protokołu jak SIP.
Podobnie, NIE można wysnuć ŻADNYCH wniosków co do (większej)
efektywności zarządzania stanem. Niektóre z benchmarków kontenerów SIP
Servlet'ów są dostępne publicznie (np.
http://www.oracle.com/technology/pub/articles/dev2arch/2007/10/wl-sip-server-benchmark.html).
Jak widać, większych problemów ze skalowalnością i wydajnością NIE
obserwuje się (tu można poczytać o innym wyniku, który prawdopodobnie
przekraczałby cały ruch telefoniczny w Polsce - to jest oczywiście
symulacja, a więc z uproszczeniami - ale zrobiona na stosunkowo
niewielkim sprzęcie, z tego co pamiętam, to chyba 40 blade'ów po 4 CPU
single-core: http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/story/09-27-2005/0004133037&EDATE=
- i to w Java, he he, tak a propos mitów o wydajności Java. W skrócie:
10 mln prób połączeń na godzinę (http://en.wikipedia.org/wiki/
Busy_hour_call_attempts), przy opóźnieniach poniżej 40 ms. I to jest
benchmark sprzed 3 lat. W tej chwili jest dużo lepiej...). Wspomnę
także, że jedna z największych na świecie (o ile nie największa)
komercyjna sieć konsumenckiego VoIP działa od kilku lat z
wykorzystaniem tej technologii (zarówno w warstwie sygnałowej, czyli
zastępując sprzętowe przełączniki, jak i usługowej). Jakieś parę
milionów użytkowników non-stop...
Będzie o tym dalej, ale zgodzę się przy tym, że w zakresie wydajności
JAIN SLEE ma pewien większy POTENCJAŁ niż SIP Servlet (ach, jakiż
POTENCJAŁ miały EJB Entity Beans). POTENCJAŁ, bo o faktach na razie
dyskutować nie można. Potencjał, który wynika z bardziej zdarzeniowego
charakteru tego API. Jednak, nawet gdyby okazało się, że dzięki temu
potencjałowi JAIN SLEE jest szybsze o nawet 25% (a co tam - nawet dwa
razy szybsze), to ciężkość, zagmatwanie i skomplikowanie tego API
sprawiają, że sprawa nie będzie moim zdaniem opłacalna (teoria Darwina
ma się dobrze - przetrwają najbardziej elastyczni, a nie najszybsi).
Podsumowując tą część: JAIN SLEE w zakresie obsługi stanowości nie
oferuje ŻADNEJ przewagi nad SIP Servlet.
> Aby osiągnąć wysoką skalowalność rozwiązania, w którym aspekty takie
> jak czas odpowiedzi są kluczowe, bardzo ważne jest, żeby poszczególne
> części logiki aplikacji w najmniejszym stopniu blokowały wykonywanie innych jej fragmentów.
synchroniczności i czasu odpowiedzi...
Tu także postawię tezę, że wielkich różnic pomiędzy JAIN SLEE a SIP
Servlet NIE ma. Zresztą, niektóre aspekty o których piszesz NIE
dotyczą zresztą samego SIP Servlet API, a w ogóle CAŁEGO Java EE. Ale
po kolei...
Podobnie jak wcześniej ze stanowością - SIP Servlet API JEST
asynchroniczny, bo protokół SIP jest asynchroniczny. Pojawienie się
komunikatu SIPowego powoduje wykonanie zdefiniowanej dla niego metody
obsługi (handlera). Dla tych, którzy znają HTTP i HTTP Servlet API:
gdy przychodzi (np. z przeglądarki) komunikat HTTP GET, to w HTTP
Servlecie (zdefiniowanym jako handler dla danego URL) wykonuje się
metoda doGet(). W SIP Servlet podobnie: przychodzi (np. z telefonu SIP/
VoIP) komunikat SIP INVITE, w SIP Servlecie (zdefiniowanym jako
handler dla danego URI - nie mylić z URL) wykonuje się metoda doInvite
(). Ponieważ SIP jest asynchroniczny a HTTP synchroniczny, to i SIP
Servlet działa asynchronicznie a HTTP Servlet synchronicznie (dla
przykładu: w SIP może do jednego request'u przyjść wiele response'ów.
W HTTP dla requestu ZAWSZE przychodzi jeden response. W SIP Servlet
może zatem być tak, że równocześnie wykonuje się kilka metod SIP
servlet'u, a servlet może zarówno odbierać żądania od klienta, jak i
je generować).
Problem o którym Tomek piszesz dotyczy sposobu wykonywania kodu W
RAMACH JEDNEJ METODY servlet'u- No cóż - DOKŁADNIE tak samo będzie się
to odbywać w JAIN SLEE - kod pojedynczej metody w SBB też będzie się
tak wykonywać. JAIN SLEE nie daje automagicznego sposobu na
zrównoleglenie kodu wewnątrz metody w SBB. Ryzyko, że deweloper
napisze kod w sposób blokujący jest więc TAKIE SAMO. JAIN SLEE jest
wzorowany na EJB (2.1 i wcześniejszych) i NIC nowego w zakresie
zrównoleglania i synchronizacji operacji nie wnosi. Dla przykładu:
zalecenia o niepowoływaniu samodzielnie wątków w SBB, są takie same w
specyfikacji JAIN SLEE, jak w specyfikacji EJB.
Masz też rację, że wiele zależy tu od kontenera. Sensowny kontener
będzie robił co może, by oddać wątek do puli, nawet, gdy NIE skończyła
się jeszcze metoda obiektu. Takie sytuacje są możliwe, np. gdy kod w
metodzie czeka na odpowiedź z zewnętrznego systemu. Nie ma to jednak
związku z przyjętym API...
Tak jak napisałem, to jest problem CAŁEGO J2EE/Java EE, które nie
dorobiło się przez tyle lat ustandaryzowanego mechanizmu zarządzania
wątkami z poziomu aplikacji. Spustoszenie (i mity) robią tu od dawna
Blueprint'y Sun'a, które wręcz zakazują powoływania wątków przez
servlety czy EJB. Z tym, że to, że Sun nawalił w tym zakresie, nie
oznacza, że inni (zresztą znacznie bardziej angażujący się w rozwój
Java Enterprise niż Sun) nie oferują w tym zakresie wsparcia. Od paru
lat IBM i BEA (teraz Oracle) promują np. WorkManager API w ramach
inicjatywy CommonJ. To API pozwala w KONTROLOWANY (czytaj: bezpieczny)
sposób zarządzać wątkami i np. uruchomić asynchronicznie kod,
wstrzymywać przetwarzanie w oczekiwaniu na jego zakończenie (oddając
podczas tego oczekiwania wątek do puli). Parę dni temu wpadł mi gdzieś
do oczu news o Java EE 6. W sumie, to - dla mnie - poza modularyzacją,
to póki co JEDYNYM interesującym rozszerzeniem Java EE 6 jest właśnie
dodanie obu API CommonJ ! Obu, bo oprócz Work Manager API, jest
jeszcze Timer API. Nie ma zbyt wielu szczegółów jak te rozszerzenia
będą wyglądać (np. w dokumencie Java EE 6 Early Draft Review nie ma o
tych API mowy), ale w opisie motywacji "po co Java EE 6" na jcp.org
mówi się o wykorzystaniu doświadczeń z CommonJ. Z tego co autorzy
CommonJ zrobili skorzystają przy tym wszyscy - i servlet'y, i EJB, i
JAIN SLEE. I to jest przykład właściwego podejścia do budowy
specyfikacji: rozwiązanie konkretnego, wybranego problemu, zamiast
superabstrakcyjnego i wszystkomającego API JAIN SLEE. EJB też zresztą
na tym poległo, bo w jeden wór wrzucono zbyt dużo...
Zgodzę się przy tym, że - poza dosyć prymitywnym Observer/Observable w
Java SE - JAIN SLEE jest chyba jedynym ustandaryzowanym modelem budowy
aplikacji zdarzeniowych (event-driven). Rzeczywiście, dokonując
stosownej granulacji logiki (uproszczenie: rozbicia na SBB, oraz na
metody w SBB), deweloper w JAIN SLEE dostaje mechanizm asynchronicznej
komunikacji komponentów między sobą i pisania logiki w sposób
zdarzeniowy (tj. kodu wykonywanego w wyniku pojawienia się zdarzeń).
Jednak - przyznam od razu, że poziom złożoności tego modelu
zdarzeniowego jest przygniatający. Nie wierzę, aby tak skomplikowany i
zagmatwany model znalazł uznanie wśród deweloperów. Liczę na to, że -
podobnie jak to się stało z EJB CMP, który też swego czasu był jedynym
ustandaryzowanym modelem persystencji obiektów - pojawi się tu coś
lżejszego, łatwiejszego w użyciu (i zrozumieniu). I coś, co - podobnie
jak Spring - powstało w wyniku doświadczeń praktyków, a nie - podobnie
jak EJB - w głowach specyfikatorów-teoretyków.
Do zalet JAIN SLEE na pewno zaliczyłbym pewne rozszerzenia
transakcyjności, np. możliwość użycia przez programistę
asynchronicznego commit'u i rollback'u transakcji. Swoją drogą, to
przyszło łatwo, bo JAIN SLEE transakcji rozproszonych NIE wspiera.
Cytat ze specyfikacji JAIN SLEE: "The need for distributed
transactions within SLEE has yet to be required by SLEE users and
vendors. However, if at some future stage these requirements are
evident it is possible that XAResource operations may be included in
the SLEE". Pożyjemy, zobaczymy. Z drugiej strony, uważam, że tego
rodzaju rozszerzenia powinny być tak specyfikowane, aby można z nich
skorzystać w innych miejscach (np. w aplikacjach, w których
zastosowano inny model programistyczny). Bardziej przydatne dla
społeczności Java byłoby zatem ulepszenie dedykowanych zagadnieniu
tranakcyjności API, np. JTA (bardzo by się to przydało, ale niestety
nie ma wzmianki, aby cokolwiek w Java EE 6 się w zakresie JTA
ruszyło).
Co do czasu odpowiedzi, to specjalnego wsparcia w tym zakresie JAIN
SLEE także NIE daje. Model zdarzeniowy potencjalnie daje tu wsparcie,
choć znowu będę się upierać, czy akurat model zdarzeniowy oferowany
przez JAIN SLEE jest najszczęśliwszy. Czas odpowiedzi w Java zależy
też od kontenera. Pomagają tu choćby specjalne algorytmy
deterministycznego Garbage Collection (http://www.oracle.com/
technology/products/jrockit/jrrt/index.html), czy wirtualizacja (wątek
o pozytywnym efekcie wyrzucenia systemu operacyjnego "spod" JVM, czyli
bare-metal JVM pojawił się jakiś czas temu na pl.comp.lang.java).
Podsumowując tą część: JAIN SLEE w zakresie skalowalności, czy
asynchroniczności nie ma ŻADNEJ przewagi nad SIP Servlet. Jest
propozycją w zakresie programowania event-driven, ale czy użyteczną
(=podnoszącą produktywność programisty), to moim zdaniem raczej
wątpliwe.
> Tak jak już wspominałem zarówno SIP Servlet jak i JAIN SLEE mają swoje wady i zalety. Sama decyzja który kontener jest lepszym wyborem dla danego
> rozwiązania jest kwestia o wiele bardziej złożoną i nie ma sensu stawiać bezwarunkowych tez, że jeden czy drugi nie ma prawa bytu. Można się natomiast spierać który jest fajniejszy;]
O tak, o to ostatnie z pewnością. Ja ZAWSZE rekomenduję osobom
zainteresowanym przeczytać obie specyfikacje. Wnioski szybko się
wyciąga...
Z pewnością, wiele zależy od tego jakiego rodzaju usługi się buduje.
Jeśli zastępuje się niskopoziomową logikę wewnątrz urządzeń
sieciowych, to BYĆ MOŻE (choć sam nie jestem do tego przekonany, że to
właściwy kierunek) model zdarzeniowy JAIN SLEE będzie bardziej
przydatny. Jeśli usługa jest wyższego, zwłaszcza jeśli (jak przystało
na konwergencję) obejmuje zarówno internet, jak i telco, to uważam SIP
Servlet za bardziej przydatny. Na podobnej zasadzie, jak programista
piszący kod driver'a potrzeb ma inne oczekiwania niż programista
piszący aplikację.
O jakich usługach myślę ? Łączących treści (content) webowy (np.
Google Maps) i usługi IT (np. bazy danych) z usługami
telekomunikacyjnymi. Jedną z ciekawszych jakie widziałem, to usługa w
Telecom Italia dająca możliwość dzwonienia i wysyłania SMSów pomiędzy
światem realnym a światem wirtualnym (SecondLife):
http://www.italtel.com/ShowContent?item=2129. W Polsce, Ericpol także
stworzył bardzo fajne usługi (http://www.ericpol.pl/pl/ims/), np.
teległosowanie z pokazywaniem wyników na żywo na stronach webowych,
czy video-blog albo przesyłanie obrazu z telefonu komórkowego w czasie
rzeczywistym na stronę internetową... Dla mnie wizja, że zdecydowaną
większość takiej konwergentnej aplikacji będę mógł zbudować
korzystając ze znanych i przez lata sprawdzonych metod, API i narzędzi
jest bardzo przekonująca....
Pozdrawiam,
Waldek Kot
PS
Moim ulubionym "argumentem" używanym przez ludzi z OpenCloud
(pracownik tej firmy jest głównym specyfikatorem JAIN SLEE) jest
rzekomy brak wsparcia w SIP Servlet innego ważnego w telekomunikacji
protokołu - Diameter (https://developer.opencloud.com/devportal/
display/RD2v0/2.2+SIP+Servlet). Diameter jest protokołem zajmującym
się m.in. billingiem (np. kontaktem do systemów naliczających opłaty,
pre-paid, post-paid, itd), security, czy profilem użytkownika (np.
odczytem i zapisem danych kontaktowych abonenta, czy informacjami do
jakich usług ma dostęp). To jest mój ulubiony argument, bo faktycznie
- w specyfikacji SIP Servlet nie ma mowy o Diameter, co nie oznacza,
że aplikacje SIP Servlet nie mogą korzystać z Diameter - mogą, tak
samo, jak z każdego innego API (i przyzwoity kontener, zwłaszcza
pozycjonujący się jako nadający się do architektury IMS musi obsługę
protokołu Diameter i API wokół Diameter udostępniać). Tyle, że
specyfikacja SIP Servlet nie o tym nie wspomina (bo nie musi). Żeby
było jednak śmieszniej, to specyfikacja JAIN SLEE o Diameter TAKŻE NIE
wspomina !!!. Ale dla celów marketingowych takie "semantyczne
nadużycie" wolno przecież robić ;-)
Podobnie jest np. z argumentami w rodzaju (dokładny cytat):
- Promotes good software architecture
- Handles complex programming tasks
- Promotes re-use
Po prostu API cud, programista jest tu już jakby zbędny...
Odpowiadam późno, bo też mi się trochę spraw w zeszłym tygodniu
ponakładało...
Przede wszystkim dzięki za wypowiedź ! Podczas Twojego wystąpienia na
Warsjava 2008 spór pojawił się w momencie porównania SIP Servlet i
JAIN SLEE (skądinąd, do tego momentu uważam, że była to bardzo dobra
prezentacja i kilka z analogii, których użyłeś, oceniam na bardzo
trafne). Spór powstał, gdy podsumowałeś, że - luźno cytując: "SIP
Servlet API nadaje się do budowy prostych usług telekomunikacyjnych,
natomiast JAIN SLEE jest platformą i wspiera budowę zaawansowanych
usług". To wywołało moje pytanie "dlaczego", no i poszło... Taka
opinia stoi bowiem w kompletnej sprzeczności z moją wiedzą i moimi
osobistymi doświadczeniami w robionych od kilku lat projektach, a
także z opiniami osób (z obu stron, tj. wdrażających, jak i tych u
których wdrażano). Zresztą, także osób, które brały aktywny udział w
rozwoju samego JAIN SLEE. Ten argument o "SIP Servletach nadających
się do prostych usług", to zresztą typowy marketingowy argument ludzi
z obozu JAIN SLEE (jakoś mity trzeba budować...).
Pewnie też pamiętasz, że postawiłem tezę, że "SIP Servlet ma się tak
do JAIN SLEE, jak Spring do EJB 2.1 i wcześniejszych". Będę tej tezy
bronić. Specyfikacja JAIN SLEE jest bardzo mocno wzorowana na
specyfikacji EJB (ale nie 3.0, tylko tych wcześniejszych). Mimo, iż
wersja 1.1 JAIN SLEE pojawiła się w tym roku, to niestety NIE czerpie
z doświadczeń EJB i NIE wprowadza podobnych ulepszeń, jakie w EJB 3.0
wprowadzono. Także większość "argumentów" za JAIN SLEE, bardzo
przypomina argumentację o wyższości EJB z dawnych czasów m.in. nad
Springiem (pastwieniem się byłoby tu i teraz przypominać o tym gdzie
jest dzisiaj EJB a gdzie jest Spring). W tym co napisałem poniżej,
można odnaleźć ducha tej postawionej tezy. Do większości mitów o
"wyższości" JAIN SLEE można odnaleźć analogiczny mit o wyższości EJB.
Spring i ORMy (Hibernate, Kodo, Toplink, iBatis, ...) skutecznie te
mity obaliły (swoją drogą ciekawe jak podniósłby się poziom emocji
wśród ludzi na sali, gdyby usłyszeli, że "Spring nadaje się do budowy
prostych aplikacji, natomiast EJB ..."). Podobnie, w JAIN SLEE można
odnaleźć większość "grzechów" EJB (2.1 i wcześniejszych).
Poniżej bardziej merytoryczne opinie o obu technologiach, w tym moje
trzy grosze do dyskusji o mitach wokół JAIN SLEE i SIP Servlet.
Niestety, wypowiedź będzie z tych dłuższych, ale chciałem też, aby
byli ją w stanie śledzić ludzie, którzy NIC o telekomunikacji, w tym o
SIP Servlet i JAIN SLEE nie wiedzą. A gdy pojawi się żargon, to żeby
spróbować go trochę odczarować...
W każdym razie, moja krótka odpowiedź: w zakresie asynchroniczności,
stanowości, czasu odpowiedzi, skalowalności, wydajności, ani lepszego
jakościowo dopasowania do zagadnień telco, JAIN SLEE NIE wykazuje
ŻADNYCH przewag nad SIP Servlet. W stopniu skomplikowania i
programistycznej egzotyce faktycznie, przewaga jest duża.
Wersja dłuższa odpowiedzi poniżej.
On 2 Gru, 16:15, Tomasz Zieleniewski <tzieleniew...@gmail.com> wrote:
> Na wstępie warto jest powiedzieć, że czasami bardzo ciężko jest
> odseparować decyzje podejmowane ze względów czysto politycznych od tych
> praktycznych:)
> Bardzo często to co z biznesowego punktu widzenia wydaje się być
> zaletą z technicznej strony jawi się jako słabość. Np zgodność platformy
> aplikacyjnej z modelem aplikacji Servletowych w kontekście "marketingowej
> konwergencji" jest lekkim nadużyciem pojęciowym, które w praktyce wcale nie musi być
> zaletą dla tworzonej aplikacji telco.
Słychać tu echa tego co piszą marketingowcy z firm wokół JAIN SLEE,
choćby OpenCloud, jNetx, czy Mobicents (RedHat/JBoss). Notabene - ten
ostatni mam wrażenie od pewnego czasu zaczyna się jakby dystansować i
zmierza w stronę SIP Servlet, na razie pod mantrą "dajemy Ci
deweloperze oba API - JAIN SLEE i SIP Servlet - sam wybierz sobie,
które wolisz". Symptomatyczna odmiana. Ale popieram, popieram ;-).
Podobną drogę w stronę SIP Servlet obrały wcześniej choćby IBM
(WebSphere Application Server 6.x) i Sun (projekt Glassfish Sailfin).
Różnice między protokołami HTTP i SIP są oczywiście OCZYWISTE i
przynajmniej niektóre z nich przytoczyłeś. Te "protokołowe" różnice
jednak, w żadnej mierze NIE przekładają się na poziom API. SIP Servlet
API NIE jest żadną mutacją HTTP Servlet API, ani NIE wywodzi się z
HTTP Servlet API (notabene - oba wywodzą się ze wspólnego
"bezprotokołowego" Servlet API). Rzut oka na specyfikacje servlet'ów,
pozwala szybko zrozumieć czego ona głównie dotyczy:
- zwolnienie programisty z konieczności samodzielnego parsowania
komunikatów danego protokołu
- zwolnienie programisty z konieczności obsługi wielu,
niskopoziomowych mechanizmów danego protokołu
- wprowadzenie trochę wyższego (ale celowo tylko nieznacznie
wyższego !) poziomu abstrakcji danego protokołu, poprzez udostępnienie
"naturalnych", zrozumiałych dla programisty obiektów programistycznych
(np. Request, Response, Message, ...)
- wprowadzenie (przydatnych w praktyce budowy aplikacji) obiektów
programistycznych - np. "ulepszających" protokół (przykład: koncepcja
sesji)
- wprowadza model security
- wprowadza model zarządzania życiem komponentów
- opisuje strukturę i deployment aplikacji
- precyzuje inne tematy, które mają polepszyć przenośność aplikacji
Z racji tego, iż bardzo wiele elementów protokołu SIP było wzorowanych
na HTTP i SMTP (głównie w zakresie SPOSOBU opisu komunikatów, kodów
błędów, paradygmatu request-response, itp), to można zaobserwować
znaczne podobieństwo w wielu miejscach na poziomie obu API (podobne
obiekty, podobne mechanizmy security, podobny opis struktury
aplikacji, itd.). Ma to OGROMNĄ praktyczną zaletę, bo ktoś kto rozumie
model budowy aplikacji webowych opartych o servlet'y (jakieś kilka
milionów deweloperów), będzie mógł SPORĄ część tej wiedzy powtórnie
wykorzystać i znacznie szybciej zacznie budować aplikacje
komunikacyjne (co wiele osób, które dotknęły SIP Servlet API - np.
widziały moje skromne prezentacje podczas Javarsovii 2008, czy JUGów -
potwierdza. O klientach na tych łamach mówić nie wypada). Bariera
wejścia w przypadku SIP Servlet API jest NIEPORÓWNANIE niższa niż dla
JAIN SLEE API także i z powodu tych podobieństw.
Poza tym, skoro w opisanych w specyfikacji zagadnieniach model
servlet'owy sprawdza się od kilkunastu lat, to po co wymyślać koło
powtórnie (a że się sprawdza, to chyba nie muszę przekonywać - nie ma
drugiego tak akceptowanego podejścia niż servlet'y - mimo iż "ponad"
servlet'ami są nakładane dodatkowe warstwy (np. w ramach
framework'ów), to jednak 99% z tych warstw pełnymi garściami czerpie z
podejścia servlet'owego).
Servlet jako API i specyfikacja, jest moim zdaniem odpowiednio
zrównoważony - nie jest zbyt abstrakcyjny (i to jest mój zarzut dla
JAIN SLEE), jest blisko danego protokołu komunikacyjnego (przez co
oddaje jego naturę) i jest zwięzły (tj. skupia się na rozwiązaniu
konkretnych problemów, zamiast rozwiązywać wszelkie, w tym czasem
abstrakcyjne, problemy budowy aplikacji - vide JAIN SLEE). Jest
oczywiste, że jedno API nie podoła wszystkim problemom, stąd powinno
integrować się i czerpać z tego co inne API oferują.
Ale - i tu kluczowa sprawa dla tej części Twojej wypowiedzi - to
podobieństwo SIP Servlet do HTTP Servlet NIE DOTYCZY sposobu
przetwarzania komunikatów, w tym zarządzania stanem
"protokołowym" (SIP Servlet API honoruje w tym zakresie WSZELKIE
wymagania protokołu SIP, między innymi opisaną w specyfikacji
protokołu SIP transakcyjność, maszynę stanów, itd. - w TYM zakresie
SIP Servlet NIE ma żadnych związków z HTTP Servlet i z bezstanową
naturą protokołu HTTP). Powtórzę - SIP Servlet NIE jest bezstanowy, bo
protokół SIP NIE jest bezstanowy. Kontener SIP Servlet MUSI tym stanem
zarządzać. Zresztą tutaj widać jedną z ról jaką pełni kontener, czyli
zwolnienie programisty aplikacyjnego z konieczności ręcznego
zarządzania tym stanem. Ta wiedza jest (w dużym stopniu) niepotrzebna
deweloperowi, kto buduje logikę aplikacji, więc najlepiej niech
operacje związane z zarządzaniem maszyną stanów protokołu "dzieją" się
w tle (podnosimy poziom abstrakcji w nadziei na lepszą produktywność
programisty).
Drugi wątek w tej części Twojej wypowiedzi dotyczy stanu, ale to o
czym piszesz dotyczy stanu APLIKACJI (czyli DODATKOWEGO stanu, który
wynika ze specyfiki danej logiki biznesowej). Tak, tutaj HTTP Servlet
API "wzbogaca" protokół HTTP i udostępnia komponentom aplikacyjnym
(servlet'om) mechanizm sesji, w tym sposób śledzenia sesji,
widoczności danych w sesji, timeout'ów, itd. Logika umieszczona w HTTP
Servlet'ach może z tego stanu ("danych", czy obiektów) skorzystać, czy
zmodyfikować. Podobnie (i znowu to jest ZALETA, że podobnie) czyni SIP
Servlet API - logika umieszczona w SIP Servletach może przechować stan
APLIKACYJNY w takiej sesji (notabene - SIP Servlet idzie nawet trochę
dalej i udostępnia mechanizm sesji aplikacyjnej, czyli możliwość
skojarzenia ze sobą wielu różnych sesji, w tym pochodzących z
komponentów obsługujących różne protokoły, np. pod jednym parasolem
byłby stan tworzony przez HTTP servlet'y i SIP servlet'y w ramach
jednej aplikacji konwergentnej, np. udostępniającej interfejs webowy i
telefoniczny/"SIP-owy"). W tym sensie, NIEKTÓRE (i to jest bardzo
istotne podkreślenie) servlet'y SĄ stanowe, tj. korzystają ze stanu.
Podobnie, jak niektóre komponenty JAIN SLEE (np. SBB - Service
Building Block, czyli taki "odpowiednik" EJB w JAIN SLEE) mogą być
bezstanowe. To jest decyzja DEWELOPERA, nie API.
Wbrew temu co piszesz, mechanizm zarządzania stanem komponentów
aplikacyjnych w JAIN SLEE w gruncie rzeczy DZIAŁA podobnie (choć opis
tego DZIAŁANIA jest - podobnie jak i większość specyfikacji JAIN SLEE,
do której poczytania ZAWSZE zachęcam - dosyć skutecznie zagmatwany,
przez co wygląda "naukowo"). Tutaj także komponent aplikacyjny (na tym
etapie jest nieistotne, czy jest to SBB, kontener, czy RA - Resource
Adapter, czyli komponent, który pośredniczy pomiędzy konkretnym
protokołem komunikacyjnym a JAIN SLEE) decyduje czy i jaki stan
utworzyć i gdzie go umieścić (np. bardziej lokalnie, tj. w polach CMP,
czy bardziej globalnie, czyli w ACI lub nawet w profilu - na tym
etapie także, nie jest istotne co to jest CMP, ACI, czy Profil - ot,
upraszczając, miejsce przechowywania stanu, o różnych zakresach
"widzialności" i ewentualnych dodatkowych możliwościach). W tym sensie
- tak samo jak w SIP Servlet ! - niektóre komponenty są stanowe a
niektóre bezstanowe. W JAIN SLEE marketingowana różnica polega na tym,
że ten stan będzie automatycznie zarządzany przez kontener. Pewnie
wiele osób, które zetknęły się z EJB już widzi podobieństwo do EJB
Entity Beans i CMP (Container Managed Bean). JAIN SLEE powstawało w
epoce euforycznego zachłyśnięcia się EJB, w tym wiary iż jedynym
słusznym podejściem na problem persystencji obiektów są właśnie Entity
Beans i CMP. Po kilku latach eksperymentów i dokonywania cudów w
kontenerach EJB (znam parę osób, które napisały o tym doktoraty),
wiemy jako społeczność deweloperów, iż EJB CMP okazały się kompletną
porażką (polecam popatrzeć na "klimat" wokół nich w Java EE 6, gdzie
NAJPRAWDOPODOBNIEJ będzie to jedna z pierwszych w historii Java EE
technologii, które zostaną z Java EE WYCOFANE. Już w EJB 3.0, znane z
wcześniejszych edycji Entity Beany są w trybie maintanance i NIE ma w
tym zakresie rozwoju. Mam mało wiary w to, że JAIN SLEE wskrzeszy i
uzdrowi to podejście). Zresztą, CMP w JAIN SLEE jest bardzo prymitywne
- nie ma tutaj mowy o bardziej złożonym stanie (np. relacji pomiędzy
obiektami stanu - choćby znanego z EJB 2.1 i wcześniejszych CMR -
Container Managed Relationship). Czyżby autorzy JAIN SLEE zakładali,
iż logika biznesowa w komponentach nie potrzebuje bardziej złożonego
stanu niż "odpowiednik" jednego wiersza z jednej tabeli ?
Śmiem twierdzić, że połączenie SIP Servlet i z innymi technologiami
zarządzania stanem da ten sam efekt co mechanizm CMP w JAIN SLEE. Z
tym, że deweloper będzie miał tutaj większy wybór (od prostych
mechanizmów przez ORM (JPA ?), po distributed cache lub in-memory data
grid). A przy tym, jest spora szansa, że będzie to coś co jest mu
znane (powraca argument o produktywności).
Tym bardziej, że zarządzanie stanem to jest bardzo złożony problem.
Generalnie, jako świat ludzi budujących systemy, wiemy, że im mniej
stanu, tym lepiej dla skalowalności aplikacji, a także (choć to mniej
widoczne) dla jej wydajności. Podobnie, im mniej współdzielonego
stanu, tym lepiej, bo takie współdzielenie wymaga kontroli (np.
synchronizacji) i obniża możliwości zrównoleglenia operacji w
aplikacji. Zresztą - zarządzaniem stanem NIE jest przedmiotem ŻADNEJ
specyfikacji Java EE. Bo to jest kwestia implementacyjna i w gestii
kontenera - efektywnością implementacji zarządzania stanem mają
dostawcy kontenerów ze sobą konkurować. API jest tu wtórne (w
większości przypadków wystarczy to, co daje interfejs Map). Z tego
faktu, że JAIN SLEE daje kilka API zarządzania stanem (w gruncie
rzeczy sprowadzają się to do kontroli widoczności stanu) NIE wynika
większa przydatność tego API do obsługi takiego protokołu jak SIP.
Podobnie, NIE można wysnuć ŻADNYCH wniosków co do (większej)
efektywności zarządzania stanem. Niektóre z benchmarków kontenerów SIP
Servlet'ów są dostępne publicznie (np.
http://www.oracle.com/technology/pub/articles/dev2arch/2007/10/wl-sip-server-benchmark.html).
Jak widać, większych problemów ze skalowalnością i wydajnością NIE
obserwuje się (tu można poczytać o innym wyniku, który prawdopodobnie
przekraczałby cały ruch telefoniczny w Polsce - to jest oczywiście
symulacja, a więc z uproszczeniami - ale zrobiona na stosunkowo
niewielkim sprzęcie, z tego co pamiętam, to chyba 40 blade'ów po 4 CPU
single-core: http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/story/09-27-2005/0004133037&EDATE=
- i to w Java, he he, tak a propos mitów o wydajności Java. W skrócie:
10 mln prób połączeń na godzinę (http://en.wikipedia.org/wiki/
Busy_hour_call_attempts), przy opóźnieniach poniżej 40 ms. I to jest
benchmark sprzed 3 lat. W tej chwili jest dużo lepiej...). Wspomnę
także, że jedna z największych na świecie (o ile nie największa)
komercyjna sieć konsumenckiego VoIP działa od kilku lat z
wykorzystaniem tej technologii (zarówno w warstwie sygnałowej, czyli
zastępując sprzętowe przełączniki, jak i usługowej). Jakieś parę
milionów użytkowników non-stop...
Będzie o tym dalej, ale zgodzę się przy tym, że w zakresie wydajności
JAIN SLEE ma pewien większy POTENCJAŁ niż SIP Servlet (ach, jakiż
POTENCJAŁ miały EJB Entity Beans). POTENCJAŁ, bo o faktach na razie
dyskutować nie można. Potencjał, który wynika z bardziej zdarzeniowego
charakteru tego API. Jednak, nawet gdyby okazało się, że dzięki temu
potencjałowi JAIN SLEE jest szybsze o nawet 25% (a co tam - nawet dwa
razy szybsze), to ciężkość, zagmatwanie i skomplikowanie tego API
sprawiają, że sprawa nie będzie moim zdaniem opłacalna (teoria Darwina
ma się dobrze - przetrwają najbardziej elastyczni, a nie najszybsi).
Podsumowując tą część: JAIN SLEE w zakresie obsługi stanowości nie
oferuje ŻADNEJ przewagi nad SIP Servlet.
> Aby osiągnąć wysoką skalowalność rozwiązania, w którym aspekty takie
> jak czas odpowiedzi są kluczowe, bardzo ważne jest, żeby poszczególne
> Innymi słowy kontener powinien udostępniać najoptymalniejszy mechanizm
> "zrównoleglenia". Zarówno SLEE jak i Servlety umożliwiają wykorzystanie puli wątków, z których każdy dynamicznie
> w miarę potrzeb jest rezerwowany. Różnica polega na tym, że w
> Servlecie poza obsługa protokołu SIP, która jest zrealizowana na poziomie implementacji stosu SIP, logika jest synchroniczna, czyli wstrzymuje wątek w ramach którego jest
> wykonywana. SLEE dzięki swojej architekturze (warstwie RA do komunikowania się ze
> światem zewnętrznym oraz wewnętrznym asynchronicznym modelu komunikacyjnym opartym na
> zdarzeniach) umożliwia optymalniejszą granulacje poszczególnych fragmentów logiki
> aplikacji. Można np. poszczególne części logiki aplikacji zaimplementować w oddzielnych
> SBB i zdefiniować zdarzenia za pomocą których będą się komunikować.
Tutaj kolejne mity i przemieszanie skalowalności, równoległości,
> "zrównoleglenia". Zarówno SLEE jak i Servlety umożliwiają wykorzystanie puli wątków, z których każdy dynamicznie
> w miarę potrzeb jest rezerwowany. Różnica polega na tym, że w
> Servlecie poza obsługa protokołu SIP, która jest zrealizowana na poziomie implementacji stosu SIP, logika jest synchroniczna, czyli wstrzymuje wątek w ramach którego jest
> wykonywana. SLEE dzięki swojej architekturze (warstwie RA do komunikowania się ze
> światem zewnętrznym oraz wewnętrznym asynchronicznym modelu komunikacyjnym opartym na
> zdarzeniach) umożliwia optymalniejszą granulacje poszczególnych fragmentów logiki
> aplikacji. Można np. poszczególne części logiki aplikacji zaimplementować w oddzielnych
> SBB i zdefiniować zdarzenia za pomocą których będą się komunikować.
synchroniczności i czasu odpowiedzi...
Tu także postawię tezę, że wielkich różnic pomiędzy JAIN SLEE a SIP
Servlet NIE ma. Zresztą, niektóre aspekty o których piszesz NIE
dotyczą zresztą samego SIP Servlet API, a w ogóle CAŁEGO Java EE. Ale
po kolei...
Podobnie jak wcześniej ze stanowością - SIP Servlet API JEST
asynchroniczny, bo protokół SIP jest asynchroniczny. Pojawienie się
komunikatu SIPowego powoduje wykonanie zdefiniowanej dla niego metody
obsługi (handlera). Dla tych, którzy znają HTTP i HTTP Servlet API:
gdy przychodzi (np. z przeglądarki) komunikat HTTP GET, to w HTTP
Servlecie (zdefiniowanym jako handler dla danego URL) wykonuje się
metoda doGet(). W SIP Servlet podobnie: przychodzi (np. z telefonu SIP/
VoIP) komunikat SIP INVITE, w SIP Servlecie (zdefiniowanym jako
handler dla danego URI - nie mylić z URL) wykonuje się metoda doInvite
(). Ponieważ SIP jest asynchroniczny a HTTP synchroniczny, to i SIP
Servlet działa asynchronicznie a HTTP Servlet synchronicznie (dla
przykładu: w SIP może do jednego request'u przyjść wiele response'ów.
W HTTP dla requestu ZAWSZE przychodzi jeden response. W SIP Servlet
może zatem być tak, że równocześnie wykonuje się kilka metod SIP
servlet'u, a servlet może zarówno odbierać żądania od klienta, jak i
je generować).
Problem o którym Tomek piszesz dotyczy sposobu wykonywania kodu W
RAMACH JEDNEJ METODY servlet'u- No cóż - DOKŁADNIE tak samo będzie się
to odbywać w JAIN SLEE - kod pojedynczej metody w SBB też będzie się
tak wykonywać. JAIN SLEE nie daje automagicznego sposobu na
zrównoleglenie kodu wewnątrz metody w SBB. Ryzyko, że deweloper
napisze kod w sposób blokujący jest więc TAKIE SAMO. JAIN SLEE jest
wzorowany na EJB (2.1 i wcześniejszych) i NIC nowego w zakresie
zrównoleglania i synchronizacji operacji nie wnosi. Dla przykładu:
zalecenia o niepowoływaniu samodzielnie wątków w SBB, są takie same w
specyfikacji JAIN SLEE, jak w specyfikacji EJB.
Masz też rację, że wiele zależy tu od kontenera. Sensowny kontener
będzie robił co może, by oddać wątek do puli, nawet, gdy NIE skończyła
się jeszcze metoda obiektu. Takie sytuacje są możliwe, np. gdy kod w
metodzie czeka na odpowiedź z zewnętrznego systemu. Nie ma to jednak
związku z przyjętym API...
Tak jak napisałem, to jest problem CAŁEGO J2EE/Java EE, które nie
dorobiło się przez tyle lat ustandaryzowanego mechanizmu zarządzania
wątkami z poziomu aplikacji. Spustoszenie (i mity) robią tu od dawna
Blueprint'y Sun'a, które wręcz zakazują powoływania wątków przez
servlety czy EJB. Z tym, że to, że Sun nawalił w tym zakresie, nie
oznacza, że inni (zresztą znacznie bardziej angażujący się w rozwój
Java Enterprise niż Sun) nie oferują w tym zakresie wsparcia. Od paru
lat IBM i BEA (teraz Oracle) promują np. WorkManager API w ramach
inicjatywy CommonJ. To API pozwala w KONTROLOWANY (czytaj: bezpieczny)
sposób zarządzać wątkami i np. uruchomić asynchronicznie kod,
wstrzymywać przetwarzanie w oczekiwaniu na jego zakończenie (oddając
podczas tego oczekiwania wątek do puli). Parę dni temu wpadł mi gdzieś
do oczu news o Java EE 6. W sumie, to - dla mnie - poza modularyzacją,
to póki co JEDYNYM interesującym rozszerzeniem Java EE 6 jest właśnie
dodanie obu API CommonJ ! Obu, bo oprócz Work Manager API, jest
jeszcze Timer API. Nie ma zbyt wielu szczegółów jak te rozszerzenia
będą wyglądać (np. w dokumencie Java EE 6 Early Draft Review nie ma o
tych API mowy), ale w opisie motywacji "po co Java EE 6" na jcp.org
mówi się o wykorzystaniu doświadczeń z CommonJ. Z tego co autorzy
CommonJ zrobili skorzystają przy tym wszyscy - i servlet'y, i EJB, i
JAIN SLEE. I to jest przykład właściwego podejścia do budowy
specyfikacji: rozwiązanie konkretnego, wybranego problemu, zamiast
superabstrakcyjnego i wszystkomającego API JAIN SLEE. EJB też zresztą
na tym poległo, bo w jeden wór wrzucono zbyt dużo...
Zgodzę się przy tym, że - poza dosyć prymitywnym Observer/Observable w
Java SE - JAIN SLEE jest chyba jedynym ustandaryzowanym modelem budowy
aplikacji zdarzeniowych (event-driven). Rzeczywiście, dokonując
stosownej granulacji logiki (uproszczenie: rozbicia na SBB, oraz na
metody w SBB), deweloper w JAIN SLEE dostaje mechanizm asynchronicznej
komunikacji komponentów między sobą i pisania logiki w sposób
zdarzeniowy (tj. kodu wykonywanego w wyniku pojawienia się zdarzeń).
Jednak - przyznam od razu, że poziom złożoności tego modelu
zdarzeniowego jest przygniatający. Nie wierzę, aby tak skomplikowany i
zagmatwany model znalazł uznanie wśród deweloperów. Liczę na to, że -
podobnie jak to się stało z EJB CMP, który też swego czasu był jedynym
ustandaryzowanym modelem persystencji obiektów - pojawi się tu coś
lżejszego, łatwiejszego w użyciu (i zrozumieniu). I coś, co - podobnie
jak Spring - powstało w wyniku doświadczeń praktyków, a nie - podobnie
jak EJB - w głowach specyfikatorów-teoretyków.
Do zalet JAIN SLEE na pewno zaliczyłbym pewne rozszerzenia
transakcyjności, np. możliwość użycia przez programistę
asynchronicznego commit'u i rollback'u transakcji. Swoją drogą, to
przyszło łatwo, bo JAIN SLEE transakcji rozproszonych NIE wspiera.
Cytat ze specyfikacji JAIN SLEE: "The need for distributed
transactions within SLEE has yet to be required by SLEE users and
vendors. However, if at some future stage these requirements are
evident it is possible that XAResource operations may be included in
the SLEE". Pożyjemy, zobaczymy. Z drugiej strony, uważam, że tego
rodzaju rozszerzenia powinny być tak specyfikowane, aby można z nich
skorzystać w innych miejscach (np. w aplikacjach, w których
zastosowano inny model programistyczny). Bardziej przydatne dla
społeczności Java byłoby zatem ulepszenie dedykowanych zagadnieniu
tranakcyjności API, np. JTA (bardzo by się to przydało, ale niestety
nie ma wzmianki, aby cokolwiek w Java EE 6 się w zakresie JTA
ruszyło).
Co do czasu odpowiedzi, to specjalnego wsparcia w tym zakresie JAIN
SLEE także NIE daje. Model zdarzeniowy potencjalnie daje tu wsparcie,
choć znowu będę się upierać, czy akurat model zdarzeniowy oferowany
przez JAIN SLEE jest najszczęśliwszy. Czas odpowiedzi w Java zależy
też od kontenera. Pomagają tu choćby specjalne algorytmy
deterministycznego Garbage Collection (http://www.oracle.com/
technology/products/jrockit/jrrt/index.html), czy wirtualizacja (wątek
o pozytywnym efekcie wyrzucenia systemu operacyjnego "spod" JVM, czyli
bare-metal JVM pojawił się jakiś czas temu na pl.comp.lang.java).
Podsumowując tą część: JAIN SLEE w zakresie skalowalności, czy
asynchroniczności nie ma ŻADNEJ przewagi nad SIP Servlet. Jest
propozycją w zakresie programowania event-driven, ale czy użyteczną
(=podnoszącą produktywność programisty), to moim zdaniem raczej
wątpliwe.
> Tak jak już wspominałem zarówno SIP Servlet jak i JAIN SLEE mają swoje wady i zalety. Sama decyzja który kontener jest lepszym wyborem dla danego
> rozwiązania jest kwestia o wiele bardziej złożoną i nie ma sensu stawiać bezwarunkowych tez, że jeden czy drugi nie ma prawa bytu. Można się natomiast spierać który jest fajniejszy;]
zainteresowanym przeczytać obie specyfikacje. Wnioski szybko się
wyciąga...
Z pewnością, wiele zależy od tego jakiego rodzaju usługi się buduje.
Jeśli zastępuje się niskopoziomową logikę wewnątrz urządzeń
sieciowych, to BYĆ MOŻE (choć sam nie jestem do tego przekonany, że to
właściwy kierunek) model zdarzeniowy JAIN SLEE będzie bardziej
przydatny. Jeśli usługa jest wyższego, zwłaszcza jeśli (jak przystało
na konwergencję) obejmuje zarówno internet, jak i telco, to uważam SIP
Servlet za bardziej przydatny. Na podobnej zasadzie, jak programista
piszący kod driver'a potrzeb ma inne oczekiwania niż programista
piszący aplikację.
O jakich usługach myślę ? Łączących treści (content) webowy (np.
Google Maps) i usługi IT (np. bazy danych) z usługami
telekomunikacyjnymi. Jedną z ciekawszych jakie widziałem, to usługa w
Telecom Italia dająca możliwość dzwonienia i wysyłania SMSów pomiędzy
światem realnym a światem wirtualnym (SecondLife):
http://www.italtel.com/ShowContent?item=2129. W Polsce, Ericpol także
stworzył bardzo fajne usługi (http://www.ericpol.pl/pl/ims/), np.
teległosowanie z pokazywaniem wyników na żywo na stronach webowych,
czy video-blog albo przesyłanie obrazu z telefonu komórkowego w czasie
rzeczywistym na stronę internetową... Dla mnie wizja, że zdecydowaną
większość takiej konwergentnej aplikacji będę mógł zbudować
korzystając ze znanych i przez lata sprawdzonych metod, API i narzędzi
jest bardzo przekonująca....
Pozdrawiam,
Waldek Kot
PS
Moim ulubionym "argumentem" używanym przez ludzi z OpenCloud
(pracownik tej firmy jest głównym specyfikatorem JAIN SLEE) jest
rzekomy brak wsparcia w SIP Servlet innego ważnego w telekomunikacji
protokołu - Diameter (https://developer.opencloud.com/devportal/
display/RD2v0/2.2+SIP+Servlet). Diameter jest protokołem zajmującym
się m.in. billingiem (np. kontaktem do systemów naliczających opłaty,
pre-paid, post-paid, itd), security, czy profilem użytkownika (np.
odczytem i zapisem danych kontaktowych abonenta, czy informacjami do
jakich usług ma dostęp). To jest mój ulubiony argument, bo faktycznie
- w specyfikacji SIP Servlet nie ma mowy o Diameter, co nie oznacza,
że aplikacje SIP Servlet nie mogą korzystać z Diameter - mogą, tak
samo, jak z każdego innego API (i przyzwoity kontener, zwłaszcza
pozycjonujący się jako nadający się do architektury IMS musi obsługę
protokołu Diameter i API wokół Diameter udostępniać). Tyle, że
specyfikacja SIP Servlet nie o tym nie wspomina (bo nie musi). Żeby
było jednak śmieszniej, to specyfikacja JAIN SLEE o Diameter TAKŻE NIE
wspomina !!!. Ale dla celów marketingowych takie "semantyczne
nadużycie" wolno przecież robić ;-)
Podobnie jest np. z argumentami w rodzaju (dokładny cytat):
- Promotes good software architecture
- Handles complex programming tasks
- Promotes re-use
Po prostu API cud, programista jest tu już jakby zbędny...
Waldek Kot
Dec 11, 2008, 5:26:04 AM12/11/08
to Warszawa Java User Group (Warszawa JUG)
Cześć,
Na http://jdn.pl dodałem krótki opis jak w praktyce pobawić się SIP
Servlet API...
Link: http://jdn.pl/node/1642
Pozdrawiam,
Waldek Kot
Na http://jdn.pl dodałem krótki opis jak w praktyce pobawić się SIP
Servlet API...
Link: http://jdn.pl/node/1642
Pozdrawiam,
Waldek Kot
Michal Margiel
Dec 11, 2008, 5:30:45 AM12/11/08
to warsza...@googlegroups.com
2008/12/11 Waldek Kot <walde...@googlemail.com>
Cześć,
Na http://jdn.pl dodałem krótki opis jak w praktyce pobawić się SIP
Servlet API...
Link: http://jdn.pl/node/1642
ja pierdziu! aż trudno uwierzyć. naprawdę jest krótki :)
Waldek Kot
Dec 11, 2008, 5:59:28 AM12/11/08
to Warszawa Java User Group (Warszawa JUG)
On 11 Gru, 11:30, "Michal Margiel" <michal.marg...@gmail.com> wrote:
> > Link:http://jdn.pl/node/1642
>
> ja pierdziu! aż trudno uwierzyć. naprawdę jest krótki :)
:-)
> > Link:http://jdn.pl/node/1642
>
> ja pierdziu! aż trudno uwierzyć. naprawdę jest krótki :)
Wykonanie nie powinno zająć więcej niż 15 minut (pomijając czas
ściągania softu z sieci)...
Pozdrawiam,
Waldek Kot
Reply all
Reply to author
Forward
0 new messages