Miałem wczoraj zaszczyt i przyjemność uczestniczyć w największej w Polsce konferencji poświęconej Java - Java Developers' Day 2009 (JDD) w Krakowie (http://09.jdd.org.pl). Frekwencja jak zwykle dopisała, konferencja jak zwykle udana. Mówiąc krótko było fajnie !
Z racji tego, że Oracle Polska był Złotym Sponsorem JDD 09, dane mi było zaprezentować temat "Asynchroniczne, współbieżne i rozproszone przetwarzanie w Java EE (w przykładach z Oracle WebLogic Server, Coherence i TopLink Grid)".

Po raz drugi mam przyjemność zaprosić na odbywającą się już po raz piętnasty Konferencję Użytkowników i Deweloperów ORACLE organizowaną przez Polish Oracle User Group (PLOUG). W tym roku konferencja odbywa się w Kościelisku niedaleko Zakopanego, w dniach od 20-go do 23-go października (wtorek-piątek). Program można znaleźć tutaj. W trakcie konferencji odbywa się wiele warsztatów i tutoriali - ich opis można znaleźć tutaj, a terminy tutaj. Jak zawsze podczas Konferencji jest okazja do wycieczek - ich listę można znaleźć tutaj.
W tym roku będę miał frajdę poprowadzić aż 5 sesji (chyba ominą mnie wycieczki ;-)) - wszystkie są bezpłatne !

Cześć,

4.lipca (sobota) od 9:00 do północy w Warszawie, w gmachu Wydziału Biologii Uniwersytetu Warszawskiego (ul. Ilji Miecznikowa 1) odbywa się renomowana, fajna, z tradycjami konferencja pasjonatów technologii Java - JAVArsovia 2009 (http://javarsovia.pl). Jak co roku, są zarówno ciekawe tematy (tu rozkład jazdy), jak i fajni prelegenci.
Organizatorzy byli dla mnie szczodrzy - moja propozycja tematu w ramach Call for Papers została zaakceptowana, czyli poprowadzę sesję pt:
Wirtualizacja wirtualnej maszyny Java - czyli jak uruchamiać aplikacje Java bez systemu operacyjnego.

Najprostsze środowisko do poznawania SIP Servlet API składa się z - jednego komputera, w którym są uruchomione:

• IDE (np. Eclipse)
• serwer aplikacyjny Java EE z obsługą SIP/SIP Servlet (np. Oracle Communications Converged Application Server - OCCAS)
• softphone (np. X-Lite)

Podczas Javarsovia 2008 posługiwałem się troszkę bardziej złożonym "laboratorium", dzięki któremu łatwiej testować ciekawsze aplikacje korzystające z SIP Servlet API. Można je zbudować stosunkowo niewielkim kosztem.
Poniżej opis takiego mikro-laboratorium.

Struktura aplikacji korzystającej z SIP Servlet jest bardzo podobna do struktury aplikacji webowej (opartej o HTTP Servlet). Możliwe jest nawet łączenie servlet'ów SIP i HTTP w jednej aplikacji. Właściwie jedyna różnica polega na tym, że komponenty SIP Servlet są definiowane przy użyciu deployment descriptor'a sip.xml, a komponenty HTTP Servlet za pomocą web.xml (i opcjonalnie deployment descriptor'ów specyficznych dla kontenera - ale tylko dla web.xml, bo specyfikacja SIP Servlet API takich "specyficznych" deployment descriptor'ów nie wprowadza). W tym podejściu widać jedno z głównych założeń SIP Servlet, czyli maksymalne powtórne wykorzystanie znanych już i sprawdzonych od lat sposobów pracy dewelopera, narzędzi, koncepcji, itd. Programiści są też niemal "zachęcani" do tworzenia usług (aplikacji) konwergentnych, tj. takich w których np. dostęp poprzez web miesza się z dostępem poprzez telefon albo w ramach usług telekomunikacyjnych korzysta się z bogatych treści internetowych lub usług systemów IT.

Można użyć dowolnego IDE do budowy aplikacji korzystających z SIP Servlet i uruchamianych na OCCAS. IDE powinno wspierać deployment aplikacji na WebLogic Server 10.3 (gdyż to jest serwer aplikacyjny Java EE na którym "bazuje" OCCAS 4.0). W poniższym opisie będę używać Eclipse 3.4.1 do którego dodano zestaw wtyczek (plugins): Oracle Enterprise Pack for Eclipse (OEPE). Zestaw ten ułatwia pracę z serwerami aplikacyjnymi WebLogic (od 8.1 do 10.3).

SIP Servlet API jest wykorzystywane do budowy aplikacji serwerowych (czyli główna logika usługi jest wykonywana po stronie serwera). Potrzebny jest zatem serwer aplikacyjny z obsługą protokołu SIP (i innych przydatnych w nowoczesnej, tj. opartej o IP, telekomunikacji - np. wykorzystywany do bilingu, czy security protokół Diameter), a także posiadający wbudowany kontener SIP Servlet (do budowy bogatych, konwergentnych usług, łączących światy telekomunikacji i internetu, przydadzą się także inne kontenery, np. webowy, EJB, Spring, web services, czy JMS). Na szczęście jest kilka kontenerów SIP Servlet do wyboru. W moim przykładzie będę się posługiwać serwerem aplikacyjnym WebLogic SIP Server (a właściwie Oracle Communications Converged Application Server, w skrócie OCCAS - znacznie mniej sexy niż "WebLogic SIP Server", ale cóż ;-).

Zainteresowanych budową aplikacji telekomunikacyjnych zapraszam do samodzielnego poeksperymentowania z SIP Servlet API. Temat (a raczej wprowadzenie do tematu) było już prezentowane podczas majowej konferencji Javarsovia 2008 oraz Trójmiasto-JUG. Zagadnienie różnych modeli budowy aplikacji telekomunikacyjnych, a zwłaszcza aplikacji konwergentnych (tj. łączących w sobie zagadnienia telekomunikacyjne i informatyczne, czy związane z internetem) wywołało spore poruszenie podczas niedawnych warsztatów Warsjava 2008, a także dyskusję na łamach Warszawa-JUG. Warto zatem sobie samodzielnie wyrobić zdanie.

Niniejszy wpis jest związany z prowadzoną przeze mnie sesją podczas Warsjava Eclipse Demo Camp 2008 w Warszawie. Więcej informacji: http://jdn.pl/node/1620

VI. DEMONSTRACJA nr VI - JMS handler

Ostatnia demonstracja dotyczy funkcjonalności JMS handler'a, czyli integracji mechanizmu HTTP Publish-Subscribe z JMS. Taka integracja jest korzystna w scenariuszach, w których potrzebne jest podniesienie poziomu niezawodności (klastrowanie), a także możliwość utrzymywania trwałych subskrypcji (czyli nawet, gdy klient Bayeux nie jest aktywnie podłączony do kanału HTTP, po podłączeniu otrzyma opublikowane w czasie jego "nieobecności" komunikaty z tego kanału). Trwałe subskrypcje wymagają przechowywania komunikatów przez podsystem JMS w wybranym zasobniku (plik lub baza danych). Oprócz tego, korzystając z integracji HTTP Pub-Sub z JMS można skorzystać ze wszelkich mechanizmów JMS, tak, aby wzbogacić sposób przetwarzania komunikatów.

Niniejszy wpis jest związany z prowadzoną przeze mnie sesją podczas Warsjava Eclipse Demo Camp 2008 w Warszawie. Więcej informacji: http://jdn.pl/node/1620

V. DEMONSTRACJA nr V - działanie funkcji FastSwap, czyli dynamicznej podmiany klas aplikacji bez redeployment'u aplikacji

Dynamiczna podmiana klas (ang. dynamic class redefinition) nie jest zagadnieniem bezpośrednio związanym z samym mechanizmem HTTP Publish-Subscribe, ale warto z technologią FastSwap poeksperymentować, gdyż znacznie przyspiesza ona proces budowy aplikacji (zwłaszcza operacji deployment'u). Mechanizm FastSwap ma zastosowanie do każdego rodzaju aplikacji (web, EJB, ...).

Niniejszy wpis jest związany z prowadzoną przeze mnie sesją podczas Warsjava Eclipse Demo Camp 2008 w Warszawie. Więcej informacji: http://jdn.pl/node/1620

IV. DEMONSTRACJA nr IV - filtry komunikatów

Mechanizm HTTP Pub-Sub w WebLogic Server 10.3 pozwala na uruchamianie podanego kodu zanim komunikat od klienta zostanie opublikowany do kanału. Takie filtry można łączyć w łańcuchy filtrów. Dowolny filtr może także zablokować dalsze przetwarzanie komunikatu, tak, że komunikat w kanale się nie pojawi. Mechanizm filtrów HTTP Pub-Sub jest bardzo podobny (i taka był intencja deweloperów) do mechanizmu servlet filters.

Niniejszy wpis jest związany z prowadzoną przeze mnie sesją podczas Warsjava Eclipse Demo Camp 2008 w Warszawie. Więcej informacji: http://jdn.pl/node/1620

III. DEMONSTRACJA nr III - zdalne wywołanie usług poprzez kanały "/service/"

Specyfikacja protokołu Bayeux nadaje specjalne znaczenie kanałom "/service/". Dzięki nim możliwa jest realizacja komunikacji typu "request/response" poprzez protokół Bayeux (w odróżnieniu od normalnie realizowanej komunikacji typu "publish/subscribe"). Działa to w ten sposób, że serwer Bayeux nie obsługuje subskrypcji do kanałów, a jedynie może wygenerować odpowiedź do tego klienta, który wysłał ("opublikował") komunikat do kanału. Mechanizm ten można stosować do wywoływania zdalnych metod przez klientów Bayeux (takie RPC - Remote Procedure Call - tyle, że z wykorzystaniem protokołu Bayeux). Tutaj zademonstruję takie proste RPC przy użyciu klienta (Dojo).

Niniejszy wpis jest związany z prowadzoną przeze mnie sesją podczas Warsjava Eclipse Demo Camp 2008 w Warszawie. Więcej informacji: http://jdn.pl/node/1620

II. DEMONSTRACJA nr II - Bayeux po stronie serwera WebLogic Server

Drugie demo, to przykłady skorzystania z HTTP Publish-Subscribe API po stronie serwera.

Niniejszy wpis jest związany z prowadzoną przeze mnie sesją podczas Warsjava Eclipse Demo Camp 2008 w Warszawie. Więcej informacji: http://jdn.pl/node/1620

I. DEMONSTRACJA nr I - klient Bayeux

Pierwsze pokazywane demo to prosta aplikacja przypominająca czat. Celem tego demo jest zapoznanie się z kliencką stroną mechanizmu HTTP Publish-Subscribe, poprzez wykorzystanie funkcjonalności klienta Bayeux, wbudowanej w Dojo.

Dziękuję wszystkim, którzy podczas Warsjava Eclipse Demo Camp 2008 uczestniczyli w prowadzonej przeze mnie sesji Comet, Bayeux i mechanizm Publish-Subscribe poprzez HTTP. Poniżej przebieg pokazywanej podczas tej sesji demonstracji. Na końcu dodałem jeszcze to, czego z braku czasu nie udało się pokazać, czyli współpracę HTTP Publish-Subscribe z JMS i EJB Message-Driven Bean.