WYDZIAŁ ELEKTRONIKI TELEKOMUNIKACJI I INFORMATYKI

Politechnika Gdańska WYDZIAŁ ELEKTRONIKI TELEKOMUNIKACJI I INFORMATYKI Praca dyplomowa. Zastosowanie protokołu XCAP do integracji nowoczesnych serwisów WWW z serwerami XDMS (na podstawie platformy Mobicents SIP Presence Server). Piotr Kowalski 113403 Opiekun pracy: doc. Dr inż. Krzysztof Nowicki. Katedra opiekuna pracy: Katedra Teleinformatyki. Kierunek Studiów : Informatyka, II stopień. Abstrakt : Praca dyplomowa ma na celu poznanie oraz opisanie zastosowań serwerów typu XDM S w sieciach. W pracy zostanie przedstawiona charakterystyka serwera XDMS, protokołu XCAP oraz możliwości jakie prezentują te technologie w sieciach IMS. Dodatkowo informację zawarte opisują możliwość integracji serwerów www z w.w. serwerem xdm. Opis technologii jest oparty o otwartą platformę Mobicents SIP Presence Server bazującą na serwerze Jboss i w pełni stworzoną w języku JAVA. Gdańsk, 2012 rok Strona 1 / 101

I. OŚWIADCZENIE Oświadczam, że niniejszą pracę dyplomową wykonałem samodzielnie. Wszystkie informacje umieszczone w pracy uzyskane ze źródeł pisanych oraz informacje ustne pochodzące od innych osób zostały udokumentowane w wykazie literatury odpowiednimi odnośnikami.... podpis dyplomanta Strona 2 / 101

TEMAT PRACY MAGISTERSKIEJ : Zastosowanie protokołu XCAP do integracji nowoczesnych serwisów WWW z serwerami XDMS (na podstawie - Piotr Kowalski. Strona 3 / 101

Spis treści : 1. Mobicents...7 1. 1 Firmy wpierające Mobicents (rozbudować?)...8 1.2 Społeczność...8 2. Mobicents JAIN SLEE (JSLEE)...9 2.1 JAIN Java APIs for Integrated Networks...9 2.2 JSLEE JAIN Service Logic Execution Environment...12 2.3 Główne elementy JAIN SLEE...15 2.4 JBOSS i mobicents...16 2.5 Możliwości JSLEE oraz XDMS...21 3. Elementy systemu Mobicents Sip Presence Server...22 3.1 Serwer obecności (SIP Presence Server)...23 3.2 Serwer list zasobów (Resource List Serwer)...24 3.3 Serwer XDM (XML Data Manipulation Server)...25 3.4 Funkcjonalna architektura serwera Mobicents XDMS....26 3.4 Architektura implementacji serwera Mobicents XDMS...28 4. Technologia XML....31 4.1 XML wersja 1.1...32 4.2 Przykładowy dokument XML...32 4.3 Dokumenty XML w sieci...33 5. Protokół XCAP XML Control Access Protocol...34 5.0.1 XCAP GET pobranie całego dokumentu...36 5.0.2 XCAP GET pobranie elementu...37 5.0.3 XCAP GET pobranie atrybutu...37 5.0.4 XCAP PUT dopisanie / nadpisanie elementu. (dokładnie zbadać)...37 5.0.5 XCAP PUT dopisanie / nadpisanie atrybutu...37 Strona 4 / 101

5.0.6 XCAP PUT nadpisanie / dodanie nowego dokumentu...38 5.0.7 XCAP DELETE usunięcie dokumentu...38 5.0.8 XCAP DELETE usunięcie elementu....38 5.0.9 XCAP DELETE usunięcie atrybutu...39 5.1 Zastosowania protokołu XCAP w aplikacjach. Application Usages...39 5.1.1 Resource Lists Listy zasobów...40 5.1.2 Presence Rules zasady obecności...40 5.1.3 RLS Services serwisy list zasobów...40 5.1.4 PIDF Manipulation...40 5.2 XML Namespace przestrzeń nazw plików XML...41 5.3 Definiowanie własnych plików XML do wykorzystań dla aplikacji...41 7. Pozostałe elementy platformy Mobicents...43 7.1 Mobicents Sip Servlets...43 7.2 Mobicents Media Server...43 7.3 Mobicents Diameter...44 7.4 Mobicents SS7...44 7.5 Mobicents Incubator...45 8 Projekty o podobnej ideologii...46 8.1 Rhino Open Cloud główny konkurent platformy Mobicents...46 8.2 IBM WebSphere XML Document Management Server...46 Część praktyczna realizacja i kod źródłowy...48 1. Środowisko uruchomieniowe i narzędzia...48 2.AppUsage class (klasa wykorzystań aplikacji)...51 2.1. App Usage Factory Class...52 2.3. App Usage Deployer Class oraz deskryptor XML...53 2.4. Pakiet oraz uruchamianie aplikacji wykorzystującej XCAP...54 Strona 5 / 101

2.5. Dodawanie własnych XCAP AppUsage dla systemu Mobicents...55 4. Realizacja i przykład wykorzystania protokołu XCAP....56 4.2 Opis kodu klienta XCAP. (opisać różnice SYNC i ASYNC) asynchroniczne dziala ale nie ma jak zwrocic w servlecie info oddzielnie po naglowkach?...56 Mobicents JAIN SLEE Client Resource Adaptor...56 4.3 Schemat przesyłania danych przez formularz HTML...58 4.4 Blok SBB...59 4.4.1 Komponent SBB...59 4.4.2 Metody zaimplementowane w bloku SBB opis klasy....62 4.4.3 Opis metod zawartych w interfejsie Sbb (wymagających implementacji) :...64 4.5 Deskryptor uruchomienia (ang. Deployer Descriptor)...67 4.6 Kod źródłowy opis elementów bloku SBB...69 4.6.1. Zmienne interfejsu...69 4.6.2. Metoda setsbbcontext...70 4.6.3. Metoda onget...71 4.7 Przykładowe AppUsage dla serwera XDM...75 4.8 Restrykcje programistyczne komponentów SLEE...79 5. Podsumowanie...80 A. Słownik...82 B. Wykaz skrótów...87 C. Lista ilustracji...90 D. Strony www...91 E. Bibliografia...93 D. Załączniki...94 Załącznik 1 opis projektu JSLEE, narzędzia Maven i wtyczki JSLEE Maven plugin...94 Załącznik 2 przykłady systemu mobicents...99 Strona 6 / 101

1. Mobicents 1. Mobicents Mobicents to platforma komunikacyjna open source, dostarcza kompletne środowisko uruchomieniowe oraz zestaw narzędzi do projektowania, uruchamiania i zarządzania serwisami integrujących usługi głosu, video oraz przesyłanie wiadomości. Pozwala na konwergencję sieci www, sieci firmowych oraz aplikacji komunikacyjnych. System składa się z kilku modułów, z których każdy dostarcza inną funkcjonalność jako pojedyncze serwery. Wszystkie moduły zostały stworzone z myślą o ich wzajemnej współpracy, są one ze sobą kompatybilne, działają w oparciu o serwer Jboss. Ilustracja 1: Składowe systemy platformy Mobicents. Strona 7 / 101

1. Mobicents Mobicents jest certyfikowany dla przemysłowych standardów VoIP oraz JAIN SLEE 1.1 oraz SIP Servlets 1.1. Stworzenie i rozwój standardu odbywa się dzięki firmie Oracle (dawniej Sun Microsystem), która wydaje JSR ( ang. Java Specification Requests). Są to normy dla referencyjnych implementacji dla platformy języka Java. JSR spełniają podobną funkcję do dokumentów RFC. Jego pliki źródłowe są dostępne na licencji LGPL 2.1. System stworzono w technologii Java, jednakże pozwala on na zastosowanie aplikacji napisanych w innych językach. Kryterium kompatybilności to dostosowanie interfejsów programowych aplikacji co pozwoli na ich komunikację pomiędzy różnymi elementami systemu. Popularne wykorzystanie systemu Mobicents to zastosowania typu : Kontrola połączeń VoIP polegająca na możliwości zarządzania siecią VoIP. Komunikatory sieciowe. Wieloosobowe gry sieciowe. Giełda finansowa np. forex. Sieci sensorowe i ich integracja. Własne zastosowania w oparciu o założoną funkcjonalność.. System powstał w 2003 roku jego fundatorem jest Ivelin Ivanov. W 2007 roku projekt wykupiła firma Red Hat Inc. W 2011 Red Hat zawiesił wsparcie dla projektu, fundator oraz kluczowi członkowie zespołu developerów stworzyli firmę TeleStax Inc. i dalej zapewniają profesjonalne wsparcie. 1. 1 Firmy wpierające Mobicents. MoBitE SoftMill Rancore Technologies NetDev EmblaCom 1.2 Społeczność System Mobicents jest rozwijany przez grupę developerów na czele z fundatorem systemu. Wraz z głównym zespołem programiści i użytkownicy z całego świata wspierają rozwój systemu. Publiczna biblioteka systemu przechowuje materiały odnośnie systemu badania nad nim, testy, opis użycia, patenty i itp. Każdy może wesprzeć projekt oraz porozmawiać z ludźmi zaangażowanymi poprzez serwer IRC lub grupy dyskusyjne. Głównym forum które skupia ludzi związanych z systemem są grupy dyskusyjne1 na serwerach Google.com. Jest to główne źródło informacji o systemie, polecane dla nowych użytkowników. Zawiera najnowsze informacje o rozwoju aplikacji, błędach, adaptorach i wiele postów o zmaganiach użytkowników z systemem. 1 http://groups.google.com/group/mobicents-public/ Strona 8 / 101

2. Mobicents JAIN SLEE (JSLEE). 2. Mobicents JAIN SLEE (JSLEE). Ilustracja 2: Architektura Jain Slee. 2.1 JAIN Java APIs for Integrated Networks. Jest to idea rozwijania języka JAVA bazując na potrzebach tworzenia nowych otwartych standardów do komunikacji dla sieci inteligentnych. Ma to na celu przyśpieszenie rozwoju aplikacji oraz ich zastosowań. Większa liczba użytkowników i twórców pozwoli na tworzenie większej ilości aplikacji oraz lepsze sprecyzowaniu funkcjonalności potrzebnej w sieciach NGN. Projektowanie API ma na celu ułatwienie budowania aplikacji co pozwoli na większą dynamikę wprowadzanych zmian w sieci, serwerach i klientach. Strona 9 / 101

2. Mobicents JAIN SLEE (JSLEE). Zbiór API w projekcie JAIN to oprogramowanie pośredniczace (middleware) pozwalające na zapewnienie komunikacji między różnymi protokołami, aplikacjami oraz usługami w sieciach inteligentnych. Inicjatywa JAIN stworzyła wiele różnych interfejsów API : JAIN SIP 1.1 JAIN Service Logic Execution Environment (JSLEE) 1.0 SIP API for J2ME 1.0 SIP Servlets 1.0 JAIN MGCP 1.0 JAIN MEGACO JAIN SDP JAIN ENUM JAIN TCAP 1.1 JAIN INAP 1.0 JAIN JCC 1.1 JAIN JCAT Java Payment API (JPay) JAIN Presence JAIN Instant Messaging JAIN SIMPLE Instant Messaging JAIN SIMPLE Presence JAIN SIP Lite Zbiór bibliotek JAIN został zaprojektoway i stworzony w języku Java ze względu na specyfikacje językowe. Obiektowość, szerokie użycie, przenośność oraz możliwość budowy modułowej czynią z Javy idealny język dla założeń JAIN. Architektura JAIN składa się z trzech wartstw : Protokoł / sieć. Sterowania : sesja / połączenie. Usługi. Każda warstwa wprowadza coraz wyższy poziom abstrakcji, im wyższy poziom tym mniejsza zapewniana funkcjonalność. Wymaga to jednak mniejszej wiedzy o danym API. Rozbicie na warstwy zapewnia możliwość niezależnej implementacji, liczy się wykorzystanie funkcji w zgodności z systemem. Każdy protokół posiada niezależne API, które zapewnia pełną funkcjonalność protokołu. Wykorzystanie bibliotek wymaga szczegółowej znajomości bibliotek oraz funkcji. Strona 10 / 101

2. Mobicents JAIN SLEE (JSLEE). Ilustracja 3: Schemat i warstwy JSLEE.* Dwie niższe warstwy znajdują się po stronie operatora. To on zapewnia do nich dostęp oraz zapewnia bezpieczeństwo ich wykorzystania. Sieci posiadają wyjściowe interfejsy dla niezależnych dostawców oprogramowania. Połączenia te mogą być zaufane oraz niezaufane. Standaryzacja interfejsów przebiega powoli z uwagi na inne metody otwierania sieci, które są preferowanie przez operatorów. * Ilutracja pochodzi z pracy dyplomowej M. Kościesza,M. Misiak "Modele implementacji usług w architekturze IMS" Strona 11 / 101

2. Mobicents JAIN SLEE (JSLEE). 2.2 JSLEE JAIN Service Logic Execution Environment. Ilustracja 4: Architektura JSLEE. Jest to koncepcja środowiska przetwarzania, o wysokiej przepustowości i niskim opóźnieniu,dedykowana dla zastosowań w telekomunikacji. Specyfikacja JSLEE pozwala na zachowanie skalowalności oraz rozproszenia przetwarzania dla tworzonych aplikacji. JSLEE to standard przemysłowy, umożliwiający przenośność stworzonych narzędzi w języku JAVA na maszyny które obsługują ten standard. Przenośność uzyskujemy dzięki API w języku Java, specyfikacjom technicznym, referencyjnej implementacji oraz zestawowi testów. JSLEE ma za zadanie integrować różne zasoby oraz protokoły sieciowe. SLEE jest projektem znajdującym się w inicjatywie JAIN. Pełna dokumentacja biblioteki JAIN SLEE jest dostępna do pobrania na stronach Oracle.Specyfikacja zawiera pełen kod źródłowy w języku Java, dokumentację Javadoc opisującą elementy konstruktorów, metod, parametrów klas oraz dokument opisujący wykorzystanie kodu i mechanizmy działania systemu. 2 Kod źródłowy stworzony przez inicjatywę JSLEE wymaga od programistów obiektowego podejścia do programowania oraz dokładnej znajomości sposobu pisania programów dla tego rodzaju środowisk. Projekt został zrealizowany poprzez proces społeczności Java (ang Java Communit Process (JCP)), osoby prywatne, firmy telelekomunikacyjne oraz fimę Red Hat. 2 http://download.oracle.com/otndocs/jcp/jain_slee-1_1-final-eval-oth-jspec/ Strona 12 / 101

2. Mobicents JAIN SLEE (JSLEE). Ilustracja 5: Związanie warstwy JSLEE z warstwą operatora. Serwer aplikacyjny dla środowiska JSLEE jest kontenerem oferującym środowisko wykonawcze (ang. Run Time Environment) dla aplikacji zapewniających usługi. Środowisko składa się z modułów w ramach różnych aplikacji. Dla JSLEE komponenenty to SBB Bloki Budujące Serwisy (ang. Service Building Blocks). Przy wykorzystaniu JSLEE, kontener opiera się na J2EE. JSLEE wspiera inne edycje Javy jak np. J2SE, pozwala to na szeroką integrację różnych rozwiązań. JSLEE glównie wspiera aplikacje oparte o architekturę sterowania zdarzeniami (ang. message driven application). Jest to warunek obsługi komunikacji asynchronicznej w sieciach. Wymagania stawiane przez standard JSLEE dla aplikacji : Asynchroniczność, przetwarzanie zorientowane na zdarzenia. Kod aplikacji jest realizowany w oparciu o asynchroniczne zdarzenia sterujące danymi aplikacjami. Strona 13 / 101

2. Mobicents JAIN SLEE (JSLEE). Krótki czas reakcji i duża przepustowość. Czasy odpowiedzi powinny być krótsze niż 100 ms oraz JSLEE powinien zapewniać obsługę równocześnie od setek do tysięcy transakcji (prostych operacji). Skomplikowane zadania mogą wymagać kilku transakcji do zapewnienia wyniku. Duża niezawodność. Zgodnie ze standardami telekomunikacyjnymi powinna być zagwarantowana bezawaryjność na poziomie 99.999%. Sposobem na jej osiągnięcie jest replikacja stanów i wykorzystanie grup serwerów. Łatwość integracji z innymi systemami i sieciami. JSLEE wykorzystuje Adaptery Zasobów (ang. Resource Adapters), które są źródłem i ujściem dla zdarzeń pochodzących z innych systemów. Taka architektura pozwala na dołożenie dodatkowego elementu obsługi np. protokołu lub aplikacji bez konieczności modyfikowania całego środowiska. Przenośność. Stworzone aplikacje w środowisku JSLEE zachowują niezależność od platformy sprzętowej oraz systemu operacyjnego jak długo zachowana jest obsługa wirtualnej maszyny języka Java. Przenoszenie aplikacji między środowiskami nie wymaga modyfikacji kodu. Wbudowany mechanizm zarządzania. JSLEE posiada konsole zarządzania JMX (ang. Java Management Extensions). JMX pozwala na listę ziaren MBeans, które są uruchomione na serwerze. Konsola zapewnia dostęp do podstawowych informacji oraz konfiguracji serwera. Pozwala na zarządzanie komponentami jak np. uruchamianie, restartowanie lub zatrzymywanie usług. Skalowalność JSLEE zaprojektowano z myślą i skalowalności oraz implementacji klastrowej rozwiązań sieciowych. Zapewnia to redundancję, lepszą dostępność oraz zwiększa niezawodność szybkość działania. Strona 14 / 101

2. Mobicents JAIN SLEE (JSLEE). 2.3 Główne elementy JAIN SLEE.3 Usługa (ang. Service) Usługa w terminologii JSLEE to zarządzana,wymienna jednostka oprogramowania. Administrator kontroluje cykl życia aplikacji uruchomienie, wyłączenie oraz zarządzanie i aktualizację usług. Zarządzaniem cyklem aplikacji jest osiągnięte poprzez standardowe interfejsy dostępne w tandardzie. Usługa udostępnia informacje, które ją opisują np. nazwę, twórcę, wersję. Kod programu może zawierać klasy Java, Profile oraz bloki SBB. Profile (ang. Profile) Profil JSLEE zawiera zarezerwowane dane. Te informację posiadają schemat z zestawem parametrów oraz właściwości np. numer telefonu i mail mogą być uznane za atrybuty Profilu JSLEE. JAIN SLEE również definiuje specyfikację profilu. Specyfikacja określa interfejsy zarządzania dla modyfikowania oraz aktualizacji profilu, zdefiniowanie schematu danych profilu oraz logiki zarządzania walidującej profil. Bloki SBB działające wewnątrz domeny JSLEE posiadają również profile dostępu jako część logiki aplikacji. SBB (ang. Service Building Block) Blok SBB to komponent oprogramowania, który wysyła i odbiera zdarzenia systemowe, wykonuje logikę aplikację bazując na typie zdarzenia jakie zaszło. SBB to stanowe komponenty, pamiętają swoje przeszłe stany i wykorzystują te dane w przyszłych obliczeniach. SBB może być złożone z kilku innych bloków SBB co pozwala na budowanie złożonych aplikacji z wielu różnych bloków. Ułatwia to tworzenie oprogramowania i nim zarządzanie. SBB zapewnia wykonywanie aplikacji zgodnie z otrzymanym zdarzeniem. Zdarzenia są wykorzystywane do reprezentowania zmian zachodzących w sieci np. Zdarzenia wywołania żądania połączenia. Kod programu SBB składa się z klas Java. Zdarzenie (ang. Event) Zdarzenie reprezentuje wystąpienie określonych warunków w systemie, pozwala na reakcję systemu zgodnie z zaimplementowana logiką aplikacji obsługujących. Zdarzenie zawiera informację opisujące dany incydent jak np. Jego pochodzenie. Zdarzenia mogą być generowane z różnych źródeł, są one pojęciem używanym do modelowania zachowań systemu. Przykładowo dwójka abonentów dzwoniących do siebie może generować zdarzenia : wywołania żądania połaszenia, oraz zdarzenie odebrania dzwoniącej słuchawki. Zasoby i adaptory zasobów (ang. Resources and Resource Adaptors) Zasoby mogą być wewnętrznymi lub zewnętrznymi danymi, które podlegają interakcji w systemie pomiędzy jego różnymi komponentami np. stos protokołów, bazy 3 Informację na podstawie JSLEE.org Strona 15 / 101

2. Mobicents JAIN SLEE (JSLEE). danych, konsole zarządzania. Adaptor zasobów pozwala na adaptację określonych interfejsów i wymagań dla zasobów pomiędzy oryginalną aplikacją a środowiskiem JSLEE. Ilustracja 6: JSLEE w zestawieniu z innymi technologiami. 2.4 JBOSS i mobicents. Serwer aplikacyjny Jboss. (ang. Jboss Application Server) to otwarta (ang. open source) implementacja zestawu funkcjonalności Java EE (zbiór bibliotek oraz API) dla usług. Obejmuje on zestaw predefiniowanych usług oraz modułów powstałych z myślą o twórcach oraz klientach aplikacji biznesowych. Oferowane komponenty middleware4 zostały przetestowane oraz certyfikowane np. JSLEE 1.1. Wysoki poziom abstrakcji oraz duża elastyczność serwera pozwala na implementację technologii na różnorakie sposoby. Bazując na Javie serwer pozwala na wysoką przenośność stworzonych rozwiązań. Łatwa instalacja oraz uruchomienie jest możliwe na systemie wykorzystującym technologię Java. Dostępność kodu pozwala na dogłębną analizę działania i tworzenie wysoce wyspecjalizowanych rozwiązań. Jboss AS (ang. Jboss Application Server) jest oparty na Mikrokontenerze Jboss. Jest to lekki kontener służący do zarządzania POJO, ich uruchamianiem, konfiguracją oraz cyklem życia. Jest to oddzielny projekt zastąpiający mikrokernel JMX serii 3 i 4. Wersje serwerów JBOSS AS : Jboss AS 5.1 udostępniony w 2009 r., wspiera JEE 5. Jest to aktualizacja serwera 5.0 rozwijanego przez 3 lata. 4 Definicja w słowniku. Strona 16 / 101

2. Mobicents JAIN SLEE (JSLEE). Jboss AS 6 nieoficjalna implementacja JEE 6 (brak certfyikatów Oracle, jednakże wspiera większość standardów, certfykowany dla JEE 6 Web Profile), ustostępniony pod koniec 2010 r. Jboss AS 7 - udostępniony w lipcu 2011 r. Ostatnia stabilna wersja pochodzi ze stycznia 2012. Posiada pełny certyfikat JEE6 (ang. Java EE 6 Full Profile). Serwer może zostać zintegrowany z różnymi technologiami wspierającymi oraz rozszerzającymi jego możliwości i innymi językami programowania.5 Platforma serwera Jboss pozwala na wykorzystanie wielu narzędzi do tworzenia aplikacji co ma ułatwić pracę programistów oraz zwiększyć zyski z szybkiego budowania nowych rozwiązań. Jednym z głównym narzędzi programistycznych (IDE ang. Integrated Developement Environment) jest środowisko Eclipse. Posiada dedykowane wtyczki dla tworzenia aplikacji na serwery Jboss przy wykorzystaniu np. Jboss Tools, EclipSLEE. Jboss Tools wspiera takie aplikację jak : Hibernate, JBoss AS, Drools, jbpm, JSF, (X)HTML, Seam, Maven, JBoss ESB, JBoss Portal i inne. Pełna specyfikacja poszczególnych serwerów, opisy oraz podstawowe informację o wykorzystaniu oprogramowania znajdują się na oficjalnych stronach projektu Jboss oraz Redhat.6 5 http://docs.jboss.org/jbossas/docs/installation_and_getting_started_guide/5/html_single/index.html rozdział 1.3. 6 http://docs.jboss.org oraz http://docs.redhat.com Strona 17 / 101

2. Mobicents JAIN SLEE (JSLEE). Ilustracja 7: Położenie platformy Mobicents w sieci NGN. Jboss Application Serwer to serwer aplikacji stworzony w języku Java. Jego celem jest zapewnienie wysokiej wydajności i efektywności działania dla aplikacji na nim uruchomionych. Bazuje na technologii ziaren (ang. Enterprise Java Beans) udostępniających odpowiednie kontenery dla usług lub serwisów wraz z API do innych elementów działających na serwerze. Od strony programistycznej ważne jest napisanie aplikacji w sposób standaryzowany dla ziaren (ang. Java Beans) co pozwoli to na komunikację między ziarnami dla własnych autorskich aplikacji. Serwer posiada pełną implementację usług JavaEE Java Enterprise Enviroment. JavaEE definiuje zasady tworzenia aplikacji opartych o wielowarstwową architekturę modułową. Standard określa również zestaw interfejsów programistycznych jakich musi dostarczać zgodny serwer aplikacyjny. Zachowanie zgody ze standardami wytyczonymi przez Java powinno zapewnić pełną przenośność rozwiązań programistycznych. Realizacja autorskich aplikacji jest możliwa dzięki zastosowaniu mikrokontenera jboss (ang. Jboss Microcontainer). Zapewnia on interfejs między prostymi obiektami, klasami Javy SE. Mikrokontenerem steruje mikrokernel obsługujący tworzenie oraz zarządzanie POJO. Strona 18 / 101

2. Mobicents JAIN SLEE (JSLEE). Ilustracja 8: Zależność mikrokontenera oraz aplikacji na serwerze Java. Ilustracja 9: Elementy Systemu Mobicents operające się na mikrokontrolerze JBoss. Mobicents zawiera implementację JSLEE oraz dodatkowych narzędzi : Adaptory Zasobów (ang. Resource Adaptors). Pozwalaja aplikacjom SLEE na interakcję z zewnętrznymi zasobami poprzez własne lub standardowe protokoły. Mobicents dostarcza wiele adaptorów wbudowanych w system, np. dla protokołu SIP. Istnieją też firmy trzecie, które tworza własne adaptory zasobów. Strona 19 / 101

2. Mobicents JAIN SLEE (JSLEE). Narzędzia do zarządzania JMX, JSLEE managment console. Mobicents manager zapewnia graficzny interfejs do zarządzania, uruchamiania oraz monitorowania usług dedykowanych dla Jboss AS oraz aplikacji JSLEE.Slee managment console jest oddzielnym oprogramowaniem, które możemy zainstalować dla monitorowania usług SLEE oraz elementów SBB. Instalacja odbywa się poprzez wykonanie polecenia mvn install w katalogu z projektem i plikami źródłowymi konsoli. Konsola dostępna jest pod adresem 127.0.0.1/slee-management-console. Ilustracja 10: Zrzut ekranu : Konsola zarządzania SLEE. Plugin EclipSLEE do środowiska programistycznego (IDE) Eclipse. Wtyczka ma za zadanie wspierać tworzenie aplikacji JSLEE. Pozwala na tworzenie wszystkich elementów wymaganych do funkcjonowania aplikacji SLEE np. SBB, Deskryptory i inne. Strona 20 / 101

2. Mobicents JAIN SLEE (JSLEE). 2.5 Możliwości JSLEE oraz XDMS. JAIN SLEE oraz serwer XMDS tworzą razem niezależne środowisko do przechowywania danych zgodnie z potrzebami wynikającymi z profilu działalności systemu. Otwartość projektu zapewnia dostęp do kodu źródłowego oraz możliwości modyfikowania działania oprogramowania zgodnie z naszymi potrzebami. Projekt nie wymaga nakładów finansowych poza czasem potrzebnym programistom na dostosowanie się i poznanie nowego środowiska programistycznego jakim jest domena JSLEE. Zbiór API JSLEE oraz serwer XMDS pozwalają na bardzo elastyczną implementację wykorzystania platformy Mobicents. Różnorodność wspieranych protokołów sieciowych zezwala na wykorzystanie najwygodniejszych sposobów na realizację założeń projektowych. XDMS domyślnie wspiera standardy przechowywanych dokumentów potrzebnych przy realizacji usług obecności ( ang. presence service) w siecaich SIP. System przechowywania informacji opiera się o bazę danych SQL (Hypersonic SQL). Baza HSQL została stworzona z naciskiem na szybkość działania wymaganą przez systemy obsługujące duży ruch sieciowy i wielu użytkowników. Możliwości i zalety połączenia JSLEE oraz serwera XDM : Zapewnia podstawowe środowisko i możliwości usług obecności w sieciach SIP. Wsparcie wielu protokołów sieciowych. JSLEE zapewnia wysoką przepustowość, niezawodność i płynne działanie systemu na niemalże stu procentowym poziomie. Badania przeprowadzone przez firmę OpenCloud wskazują na opłacalność wprowadzenia JSLEE do firm.7 Łatwość implementacji i modularność aplikacji bazujących na blokach SBB. Serwer XMD może przechowywać dane w plikach XML zgodnie ze zdefiniowanym przez nas schematem. Mechanizm implementacji pozwala na weryfikację tych plików przez schemat i obsługę wyjątków podczas zapisu do bazy różnych typów danych. Informacje przechowywane na serwer mogą dotyczyć takich danych jak : - dane użytkowników wykorzystane przez serwisy www - dane z elementami stron www - tabele sql z danymi systemów działającymi na serwerze - informację zapisane przez użytkowników - dowolne informacje jakie są udostępniane dla użytkowników 7 https://developer.opencloud.com/devportal/display/ocdev/jain+slee+is+simple Strona 21 / 101

3. Elementy systemu Mobicents Sip Presence Server. 3. Elementy systemu Mobicents Sip Presence Server. System Mobicents jest modułowym rozwiązaniem dla sieci NGN. Rozdział zadań na różne moduły pozwala na wykorzystanie tylko potrzebnych elementów systemów. Pozwala to zaoszczędzić sprzęt oraz koszty utrzymania. Poszczególne elementy pozwalają ponadto zapewnić rozproszone przetwarzanie w chmurze. Dzięki modułowości istnieją lepsze warunki skalowalności systemów zbudowanych w oparciu o Mobicents. Ilustracja 11: Schemat integracji MSPS. Wszystkie elementy SIP Presence Server są zintegrowane aczkolwiek istnieje możliwość rozdziału poszczególnych funkcjonalności na inne maszyny. Ilustracja 12: Podział funkcjonalności MSPS. Strona 22 / 101

3. Elementy systemu Mobicents Sip Presence Server. 3.1 Serwer obecności (SIP Presence Server). Wykorzystuje szereg standardów opracowanych przez : IETF Internet Ingeenering Task Force OMA Open Mobile Alliance 3GGP - 3rd Generation Partnership Project ETSI - European Telecommunications Standards Institute. Serwer SIP potrafi przechowywać, pobierać i przetwarzać informację dotyczące obecności w sieci SIP. Główne funkcję to : Zarządzanie danymi publikowanymi w sieci dla wielu różnych źródeł oraz konkretnych subskrypcji. Potrafi odświeżać informację, zamieniać aktualne z nowo opublikowanymi, usuwać i przetwarzać. Informacje składowane są w plikach XML. Zarządza subskrypcjami abonentów dla konkretnych informacji i generuje wiadomości o stanie subskrypcji. Przetwarzanie może być wywołane po stronie serwera oraz przez subskrybenta. SIP Presence Server ( ang. Serwer obecności SIP) składa się z następujących elementów : Kontrola publikacji obecności ( ang. Presence Publication Control) : Ten element zarządza publikacją zdarzeń obecności (ang. presence events) w tym : nowe publikacje, odświeżanie nformacji, modyfikacje i usuwanie informacji opublikowanych. Dodatkowo Presence Publication Control jest odpowiedzialny za składanie różnych publikacji ze zbioru danych. Pozwala to na wiele równoległych publikacji np. statusy urządzenia lub klienta czy dane lokalizacyjne np. gps realizowanych przez agenta sieci obecności (ang. Presence Network Agent). W niektórych sieciach może być przydatne przypisanie poszczególnym danym na serwerze XDM statycznej informacji o stanie poszczególnych zasobów w plikach XML np. podczas formowania finalnego dokumentu obecności przed wysłaniem do użytkowników. Presence Rules Cache (cache zasad obecności). Ten element jest odpowedzialny za interfejs pomiędzy serwerem XDM, który zarządza dokumentami zasad obecności (ang. presence rules documents). Zapewnia dane dotyczące zasad obecności (ang. presence rules) do elementu Presence Subscription Control, które służą do autoryzacji sybskrybcji, którymi zarządzają. SSB klienta obecności (Presence Client SBB) Presence Client SBB jest interfejsem do domeny JAIN SLEE SBB, założenie pozwala to na stworzenie oprogramowania klienckiego dla platformy MSPS (i instalacjach Strona 23 / 101

3. Elementy systemu Mobicents Sip Presence Server. wspierających standard). Pozwala na wykorzystanie dwóch interejsów : zewnętrznego i wewnętrznego dla różnych kontenerów i zastosować aplikacyjnych. 3.2 Serwer list zasobów (ang. Resource List Serwer). Pozwala na tworzenie subskrypcji dla list obecności (ang. presence lists). Tworzy i zarządza subskrypcjami dla wszystkich zasobów w listach. Zawartość wszystkich list jest pobierana z serwera XDM. Serwer ten przetwarza również subskrypcje SIP zgodnie ze stanem poszczególnych zasobów. Zapewnia informacje użytkownikom o stanie danych informacji na serwerze. Zazwyczaj RLS jest używany do przechowywania list zasobó jakie są sybskrybowane przez poszczególnych użytkowników systemu oraz listy z informacjami o danych, które mogą zostać zasybskrybowane. Mobicents Resuorce Lists Server rozszerza funkcjonalność serwera obecności (Presence Server) o dodatkowy element RLS Service Cache (Cache usług RLS). Ten element jest odpowiedzialny za zarządzanie listami encji, na które wskazują usługi RLS oraz zapisuje zmiany subskrypcji w referencyjnych dokumentach. Za każdą zmianą stanu usługi RLS element cache powiadamia subskrypcję, aby zapewnić zgodność pomiędzy sybskrybowaną listą zasobów a odpowiednim dokumentami XML. SIP Presence Server jest zbudowany w oparciu o specyfikację JAIN SLEE 2.x. Zapewnia to wysoką wydajność, skalowalność i wykorzystanie wielu dodatkowych technologii JEE jak np. Java Persistence AIP co pozwala na mapowanie obiektowej struktury systemu na relacyjny model bazy danych. Server posiada także wewnętrzne interfejsy klienckie dla każdego serwera osobno. Pozwala to na interakcję tylko z interesującym nas API np. presence server lub tylko serwerem xdm. Serwer list zasobów (ang. Resource List Server ) został zdefiniowany w RFC 5367. Strona 24 / 101

3. Elementy systemu Mobicents Sip Presence Server. 3.3 Serwer XDM (XML Data Manipulation Server). XML Document Managment Serwer (XDMS) serwer zarządzania dokumentami XML jest elementem sieci IP w sieciach następnej generacji. Jego zadanie to zarządzanie dokumentami XML składowanymi na serwerze po stronie sieci. W plikach znajdują się informację takie jak: zasady obecności, polityka bezpieczeństwa, reguły autoryzacji, listy kontaktów, listy grup, listy zasobów. Serwer wspiera następujące standardy : IETF Presence Rules (RFC 5025) OMA Presence Rules (OMA Presence Simple v1.1) IETF Resource Lists OMA Group Usage List (OMA XDM v1.1) IETF RLS Services (RFC 4826) OMA User Profile (OMA XDM v2.0) OMA Locked User Profile (OMA XDM v2.0) IETF XCAP-CAPS (RFC 4825) OMA XCAP Directory (OMA XDM v1.1) Protokół XCAP XML Configuration Access Protocol jest głównym protokołem warstwy aplikacji wykorzystywanym przy przetwarzaniu danych w plikach XML składowanych na serwerze. Protokół zapewnia nam nieograniczone możliwości w modyfikowaniu informacji przechowywanych w plikach. Protokół XCAP mapuje dokumenty XML jako poddrzewa oraz elementy atrybutów do formatu HTTP URL. Pozwala to na dostęp do elementów poprzez zapytania HTTP. Adresowanie plików XML bazuje na mechanizmie XPath. XPath to język zapytań pozwalający na pobieranie danych z pliku XML. Pozwala on również na wstępne przetwarzanie pobranych danych, bazuje na strukturze plików XML strukturze drzewa. Protokół XCAP opiera się o standardy RFC : RFC4825, RFC4826, RFC4827, RFC5025. Platforma Mobicents pozwala na pobieranie danych poprzez protokół http/xcap i zapis ich do plików XML na serwerze XDMS. Pozwala to na bardzo łatwe zarządzanie różnymi zmiennymi oraz informacjami zawartymi w serwisach internetowych. Strona 25 / 101

3. Elementy systemu Mobicents Sip Presence Server. Informację możemy pobrać przykładowo przez zapytanie do skryptu PHP który pobierze na podstawie przesłanych zmiennych konkretne informacje z bazy danych SQL. Ważne jest, aby znać API udostępniane przez serwer zewnętrzny z którego pobierane są informację, pozwoli nam to na generowanie konkretnych zapytań i otrzymania interesujących nas informacji. 3.4 Funkcjonalna architektura serwera Mobicents XDMS. Ilustracja 13: Funkcjonalna architektura serwera XDM.* Architektura przedstawiona na rysunku ukazuje struktury wewnętrzne serwera XDM i przepływ danych. Główne dane sterujące zachowaniem serwerem pochodzą z zewnątrz, od : Klientów protokołu XCAP. Mechanizmów zarządzania bezpośrednio na bazie danych. Systemu autoryzacji użytkowników. Obserwacji dokumentów poprzez użytkowników subskrybujących informację. Strona 26 / 101

3. Elementy systemu Mobicents Sip Presence Server. *Ilustracja pochodzi z dokumentacji serwera SIP Presence Server : http://docs.redhat.com/docs/enus/jboss_communications_platform/5.0/html-single/sip_presence_service_user_guide/images/msps-xdmfunctionalarchitecture.jpg Elementy funkcjonalne tworzące serwer XDMS : Źródła danych (ang. data sources) Źródło danych to miejsce gdzie przechowywane są wszystkie pliki XML. Informację na temat serwera są również przechowane w bazie danych. Źródła danych obsługują również subskrypcje, aktualizacje specyficznych dokumentów oraz pełne wykorzystania aplikacyjne protokołu XCAP. Proxy agregacji (ang. Aggregation Proxy) Proxy jest odpowiedzialne za obsługę żądań XCAP razem z ich autentykacją. Procesor Żądań (ang. Request Processor) Element zawiera logikę serwera XCAP pozwalającą na przetwarzanie zapytań protokołu i zwracanie odpowiedniej odpowiedzi. Zawiera też mechanizmy autoryzacji i autentykacji. Kontrola subskrypcji zdarzeń XCAP (ang. XDM Event Subscription Control) Komponent serwera wykorzystujący protokół SIP, jest on odpowiedzialny za subskrypcję dokumentów zarządzanych przez serwer. Funkcję komponenty zapewniają autoryzację, autentykację, subskrypcję zdarzeń dla danych dokumentów, obsługę wykorzystań aplikacyjnych oraz powiadomienia generowane podczas zmian dokumentów. Strona 27 / 101

3. Elementy systemu Mobicents Sip Presence Server. 3.4 Architektura implementacji serwera Mobicents XDMS. Ilustracja 14: Architektura implementacji serwera XDM.* Strona 28 / 101

3. Elementy systemu Mobicents Sip Presence Server. *Ilustracja pochodzi z dokumentacji serwera SIP Presence Server : http://docs.redhat.com/docs/enus/jboss_communications_platform/1.2/html-single/sip_presence_service_user_guide/images/mspsxdmsimplementationarchitecture.jpg Adapter implementujący komponent źródeł danych. (Data Source). Typ adaptora zasobów określa dwa obiekty aktywności : DocumentActivity oraz AppUsageActivity. Oba obiekty pozwalają na odpalania zdarzeń sygnalizujących aktualizację dokumentu, elementu albo atrybutu. Typ adaptera zsobów (RA Type) definiuje także interfejs adaptera zasobów dla SBB, który służy do zarządzania użytkownikami, dokumentami przechowywanymi na serwerze. Pozwala tez na na uruchamianie zdarzeń, które zachodzą w systemie. RA Type zezwala też na wykorzystanie wewnętrznego sterownika do bazy danych JDBC dla serwera Jboss AS. Cache AppUsage adaptora zasobów (ang. AppUsage Cache Resource Adaptor ) Ten adapter zasobów przechowuje wykorzystania aplikacyjne XCAP zainstalowane na serwerze. Każde AppUsage jest obiektem, który zawiera logikę walidującą dokumenty XCAP, które znajdują się w zapytaniach XCAP. Nie posiada zdarzeń ani aktywności (activities). Usługa AppUsage (ang. AppUsage Service) Wykorzystanie aplikacyjne XCAP są instalowane przez usługę JAIN SLEE i zapewniają możliwość do dodawania oraz usuwania nowych podczas pracy serwera. Usługa proxy agregacji (ang. Aggregtion Proxy Service). Ta usługa JAIN SLEE obsługuję zdarzenia wywoływane przez adapter zasobów JBCP HTTP Servlet i korzysta z dwóch bloków SBB : User Profile Enabler Sbb, który zwraca informacje na temat autoryzacji użytkownika dla zapytania XCAP., Request Processor Sbb, który obsługuję zapytanie XCAP. SBB procesora żądań. (ang. Request Processor SBB). Blok procesora żądań zapewnia synchroniczny interfejs SBB do przetwarzania zapytań XCAP. Wykorzystuje zasoby adaptora AppUsage Cache, aby otrzymać obiekty AppUsage oraz adapter Data Source aby odzyskać dokumentu z bazy danych. Aktywacja profili użytownika (ang. User Profile Enabler SBB). Strona 29 / 101

3. Elementy systemu Mobicents Sip Presence Server. Ten komponent bloku SBB zapewnia synchroniczny interfejs wykorzystywany w relacjach dziedziczenia obiektów potomnych JAIN SLEE w celu uzyskania danych do autoryzacji użytkownika. Dwa różne implementacje tego interfejsu są zapewnione : Uzyskanie danych z lokalnego serwera XDM. Interfejs dla Diameter Mobicents Server pracujący jako IMS HSS8. XCAP Diff Subscription Control Service Usługa JSLEE rozszerza abstrakcyjny komponent SIP Event Subscription Control pozwalający na subskrypcję xcap-diff. XCAP Client Klient XCAP to proste API zapewniające możliwość interakcji z serwerem, który wewnętrznie używa klienta HTTP Apache. XCAP Client Resource Adaptor Adapter pozwala na połączenie API klienta XCAP z domeną JAIN SLEE. Zapewnia synchroniczne i asynchroniczne metody działania. XDM Client Sbb Blok XDM Client Sbb jest interfejsem JAIN SLEE SBB, stworzonym do wykorzystania jako klient dla serwera JBXP XDM oraz innych zgodnych implementacji standardu. Interfejs posiada dwie implementacje : Wewnętrzny klient (ang. InternalXDMClientSBB) służy do wykorzystania z lokalnym serwerem JBCP XDMS. Zewnętrzny klient (ang. ExternalXDMClientSBB) ma na celu zapewnienie współpracę z domeną JSLEE zaimplementowaną na innym serwerze XDM niż JBCP XMD Serwer. 8 IMS HSS - IP Multimedia Subsystem Home Subscriber Server Strona 30 / 101

4. Technologia XML. 4. Technologia XML. XML extensible Markup Language rozszerzalny język znaczników przeznaczony do reprezentowania różnych danych w pewnej strukturze. Język i dokumenty XML są niezależne od platformy co pozwala na łatwą wymianę dokumentów między systemami. Standard języka XML oraz SGML jest opisany przez organizację W3C. XML powstał poprzez uproszczenie języka SGML (Standard Generalized Markup Language) służącego do ujednolicania różnych formatów i struktur danych. Język SGML to pierwowzór języka XML o dużo większej złożoności. Aby uprościć proces tworzenia dokumentów język SGML został uproszczony do języka XML. Dokumenty XML należy tworzyć zgodnie z zaleceniami standardu. Dokument jest poprawny składniowo (ang. well-formed), gdy spełnia zalecanie standardu np. odpowiednia zamykanie znaczników. Dokument może też być poprawny strukturalnie (valid) jeżeli jest zgodny z definicją dodatkowych reguł, określanych przez użytkownika. Do określania własnych reguł służą języki takie jak np. : DTD, XML Schema. Poprawny składniowo (ang. well-formed) dokument XML powinien być tworzony zgodnie z kilkoma zasadami: Musi posiadać deklarację XML, umieszczoną na samym początku pliku (nie może być poprzedzona np. komentarzem) oraz musi posiadać atrybut wersji 1.0 lub 1.1 oraz opcjonalnie atrybuty: Kodowanie (ang. encoding) deklaruje zestaw znaków użytych w dokumencie, domyślnie UTF-8 w systemie Unicode. Samodzielny (ang. standalone) określa tryb dokumentu. Przyjmuje wartości tak i nie. Oznacza on, iż nie potrzeba przetwarzać innych plików (np. arkusz styli lub definicje DTD) poza plikiem xml. musi zawierać tylko jeden element główny (ang. root element) każdy element musi zaczynać się znacznikiem początku elementu np. <data> oraz kończyć identycznym znacznikiem kończącym np. </data>, wyjątek stanowią elementy puste (<element-pusty />), czyli takie które nie zawierają żadnych danych, ani innych elementów, mogą zawierać atrybuty; nazwy elementów mogą zawierać znaki alfanumeryczne, znaki ideograficzne (ą, ó, ń ) oraz 3 znaki interpunkcyjne (podkreślenie _, łącznik -, kropka.). Znak dwukropka zarezerwowany jest dla identyfikacji przestrzeni nazw, której nazwa Strona 31 / 101

4. Technologia XML. dopisywana jest przed nazwą elementu np. <przestrzeń1:element>, nazwy elementów nie mogą zaczynać się od znaku łącznika -, kropki, czy cyfry. Dodatkowo nie mogą zaczynać się od xml, XML, xml itp. (wielkość liter bez znaczenia). elementy można zagnieżdżać w sobie i wtedy każdy element znajdujący się wewnątrz innego elementu jest nazywany "dzieckiem" tego elementu, a element wewnątrz którego znajdują się inne elementy zwany jest "rodzicem" tych elementów. elementy mogą zawierać atrybuty, definiowane w znaczniku początku elementu np. atrybutem elementu <news potwierdz="yes"> jest atrybut o nazwie potwierdz oraz wartości yes. Wartości atrybutów podaje się w cudzysłowach albo apostrofach (pojedynczych cudzysłowach). informacje, które zawiera element muszą być zapisane pomiędzy znacznikiem początku i końca elementu, w danych, atrybutach oraz nazwach elementów nie mogą pojawiać się niektóre znaki. Przykładem może być znak mniejszości (<), lub ampersand (&). jeżeli nie chcemy używać predefiniowanych odniesień jednostek możemy część danych, które zawierają np. kod html lub xml zapisać w sekcji danych znakowych, która nie będzie przetwarzana przez analizator składni XML. Znacznik początku sekcji danych znakowych to: <![CDATA[, a znacznik końca: ]]>. w dokumencie XML możemy wykorzystywać komentarze, które zaczynają się znakami: <!--, a kończą: - - >. specyfikacja XML zezwala na wstawianie instrukcji przetwarzania, które są wykorzystywane do przeniesienia informacji do aplikacji. Instrukcje przetwarzania rozpoczynają się znakami: <?, a kończą:?>. Przykładem takiej instrukcji może być odniesienie do arkusza stylów, który jest powiązany z dokumentem XML: <?xmlstylesheet type="text/xsl" href="newsy.xsl"?>. 4.1 XML wersja 1.1 Wprowadza zmiany w zestawie dopuszczanych znaków, co ma związek z modyfikacjami standardu Unicode przeprowadzanymi po publikacji wersji 1.0. Wersja 1.1 nie jest kompatybilna z wersją 1.0. Wersja 1.1 jest odmianą do bardzo specyficznych zastosowań. Wciąż zalecane jest korzystanie z wersji 1.0 wszędzie, gdzie to możliwe. Obie wersje wciąż są wspierane i rozwijane przez W3C. Strona 32 / 101

4. Technologia XML. 4.2 Przykładowy dokument XML. <?xml version="1.0" encoding="utf-8"?> <ksiazka-telefoniczna kategoria="bohaterowie książek"> <! komentarz testowy --> <osoba charakter="dobry"> <imie>ambroży</imie> <nazwisko>kleks</nazwisko> <telefon>123-456-789</telefon> </osoba> <osoba charakter="zły"> <imie>alojzy</imie> <nazwisko>bąbel</nazwisko> <telefon/> </osoba> </ksiazka-telefoniczna> Dokument rozpoczyna definicją wersji standardu XML, z jakim jest zgodny, oraz sposobie kodowania znaków. Informacje te są opcjonalne w razie braku którejś z danych przyjmuje się wartość domyślną, jakimi są właśnie wersja 1.0 oraz standard kodowania UTF8. Korzeniem dokumentu jest element (root element) o nazwie ksiazka-telefoniczna. Ma przypisany jeden atrybut o nazwie kategoria i wartości bohaterowie książek. Korzeń jest rodzicem dwóch innych elementów, oba mają tę samą nazwę osoba i przypisany atrybut o nazwie charakter. Każdy z elementów o nazwie osoba jest rodzicem dla trzech innych elementów o nazwach imie, nazwisko i telefon, które zawierają konkretne dane w postaci tekstu. Element o nazwie telefon w dwunastym wierszu dokumentu jest pusty. Zapis <telefon/> jest równoważny zapisowi <telefon></telefon>. W trzecim wierszu dokumentu znajduje się komentarz. 4.3 Dokumenty XML w sieci. Dokument XML traktowany jest przez przeglądarki jako zwykły plik tekstowy. Wygodne i przyjazne dla użytkownika prezentowanie danych jest osiągalne np. poprzez zastosowanie arkusza stylów CSS. Arkusz styli CSS definiujemy w pierwszej linijce pliku XML, przykładowo : <?xml-stylesheet type="text/css" href="moj-styl.css"?> Strona 33 / 101

5. Protokół XCAP XML Control Access Protocol 5. Protokół XCAP XML Control Access Protocol Protokół xcap mapuje elementy i atrybuty dokumentów XML do postaci adresów http URI co pozwala na bezpośredni dostęp do danych za pomocą klientów wykorzystujących protokół http. Serwer XCAP jest wykorzystywany przez aplikacje klienckie do przechowywania, modyfikowania i zarządzania danymi. W serwerze MSPS dodatkowo serwer XDM jest zintegrowany z funkcjonalnością SIP Presence Server co pozwala na publikacja, subskrypcje i powiadomienia za pomocą protokołu SIP. Funkcje zapewnione to : Pobranie Usunięcie Modyfikacja Dodawania Możemy je zastosować do elementów : Dokumentów Elementów Atrybutów Manipulacja dokumentami XML na serwerze XDM opiera się o wywołanie funkcji API protokołu XCAP. Głównym elementem określającym wywołanie mechanizmów jest : Wykorzystana metoda dla obiektów klasy XCAP Response. Wykorzystany adres URI wskazujący element albo atrybut do edycji. Przykłady działania różnych żądań XCAP dla dokumentów xml : Przykładowy dokument XML(zapisany przez użytkownika o nazwie user,nazwie pliku index1 wykorzystujący pliki XML o schemacie ksiazka : 1. <?xml="1.0" encoding="utf-8"?> 2. <ksiazka> 3. <entry> 4. <imie> imie nazwisko</imie> 5. <email> imnazw@qwe.qwe </email> 6. <adres> 7. <ulica glowna="true"> Jagiellonska 1234 </ulica> 8. <miasto> Gdansk </miasto> 9. <wojewodztwo>pomorskie</wojewodztwo> 10. <kraj>polska</kraj> Strona 34 / 101

5. Protokół XCAP XML Control Access Protocol 11. </adres> 12. <ietf-czlonek/> 13. </entry> 14. </ksiazka> Najpopularniejsze kody odpowiedzi HTTP wykorzystane przy implementacji serwera XDM : Kod Wiadomość Opis 200 OK Żądanie GET, DELETE, PUT zakończone sukcesem. 201 Stworzono(ang. Created) Udane stworzenie dokumentu, elementu albo atrybutu XML. 403 Wstęp wzbroniony (ang. Serwer list grup (ang. Group List Server) nie był wstanie Forbidden) autoryzować żądania. 404 Nie znaleziono (ang. Not Adres HTTP URI nie wskazuje na istniejące zasoby. Found) 405 Metoda niedozwolona (ang. Method Not Allowed) Metoda POST nie wspierana. 409 Konflikt (ang. Conflict) Odpowiedź zawiera dane odnośnie błędu w żądaniu XCAP. 9 415 Nie wspierany typ mediów. (ang. Unsupported Media Type) A PUT request contains an element and Content-Type is not application/xcap-el+xml, or a PUT request contains an attribute and Content-Type is not application/xcapel+xml. 500 Błąd wewnętrzny (ang. Internal Error) Wystąpił błąd, który nie ma związku z żądaniem np. błąd w komunikacji protokołem LDAP. 9 Sekcja 11 RFC 4825. Strona 35 / 101

5. Protokół XCAP XML Control Access Protocol Ilustracja 15: Ogólny schemat żądań i odpowiedzi serwera XDM. 5.0.1 XCAP GET pobranie całego dokumentu. GET http://127.0.0.1:8080/mobicents/www/users/user/index1 Pozwoli na pobranie całego dokumentu XML. Dodatkowo może być wymagane podanie danych uwierzytelniających loginu i hasła dla użytkownika posiadającego dostęp. 1. 2. <?xml="1.0" encoding="utf-8"?> 3. <ksiazka> 4. <entry> 5. <imie> imie nazwisko</imie> 6. <email> imnazw@qwe.qwe </email> 7. <adres> 8. <ulica glowna="true"> Jagiellonska 1234 </ulica> 9. <miasto> Gdansk </miasto> 10. <wojewodztwo>pomorskie</wojewodztwo> 11. <kraj>polska</kraj> Strona 36 / 101

5. Protokół XCAP XML Control Access Protocol 12. </adres> 13. <ietf-czlonek/> 14. </entry> 15. </ksiazka> 5.0.2 XCAP GET pobranie elementu. GET http://127.0.0.1:8080/mobicents/www/users/user/index1/~~/ksiazka/entry//ulica Żądanie zwraca wartość elementu ulica. <ulica glowna="true"> Jagiellonska 1234 </ulica> W odpowiedzi otrzymujemy cały element XML. Metody zawarte w API pozwalają na otrzymanie wartości elementu z pominięciem atrybutów i tagów. 5.0.3 XCAP GET pobranie atrybutu. GET http://127.0.0.1:8080/mobicents/www/users/user/index1/~~/ksiazka/entry/adres/ulica/@glow na Żądanie zwraca wartość atrybutu główna dla elementu ulica : true 5.0.4 XCAP PUT dopisanie / nadpisanie elementu. (dokładnie zbadać) PUT http://127.0.0.1:8080/mobicents/www/users/user/index1/~~/ksiazka/entry/imie <imie> Nowe imie </imie> Jeżeli element istnieje, zostaje on nadpisany w całości jaką chcemy zachować na serwerze. Stary element i jego atrybuty są zastąpione. Dopisanie nowego elementu zachodzi wtedy gdy adres URI nowego dopisanego elementu pokrywa się z tym wywołanym podczas metody PUT. 5.0.5 XCAP PUT dopisanie / nadpisanie atrybutu. PUT http://127.0.0.1:8080/mobicents/www/users/user/index1/~~/ksiazka/entry/ulica/@glowna=no wawartosc Strona 37 / 101

5. Protokół XCAP XML Control Access Protocol Element dokumentu po edycji : <ulica glowna="no"> Jagiellonska 1234 </ulica> Jeżeli element istnieje, zostaje on nadpisany w całości wartością jaką chcemy zachować na serwerze. Cały stary element i wszystkie jego atrybuty są zastąpione. 5.0.6 XCAP PUT nadpisanie / dodanie nowego dokumentu. PUT http://127.0.0.1:8080/mobicents/www/users/user/index1 Nowy przykładowy zapisany dokument (zmodyfikowany) : 1. <?xml="1.0" encoding="utf-8"?> 2. <ksiazka> 3. <entry> 4. <imie> imie nazwisko</imie> 5. <email> imnazw@qwe.qwe </email> 6. <adres> 7. <ulica glowna="true"> Jagiellonska 1234 </ulica> 8. <miasto> Gdansk </miasto> 9. <wojewodztwo>pomorskie</wojewodztwo> 10. <kraj>polska</kraj> 11. </adres> 12. <ietf-czlonek/> 13. </entry> 14. </ksiazka> 5.0.7 XCAP DELETE usunięcie dokumentu. DELETE http://127.0.0.1:8080/mobicents/www/users/user/index1 Usuwa cały plik XML z serwera. Próba pobrania go zwróci błąd HTTP 404. 5.0.8 XCAP DELETE usunięcie elementu. DELETE http://127.0.0.1:8080/mobicents/www/users/user/index1/~~/ksiazka/entry/imie Usunięcie elementu imię z pliku XML. 1. <?xml="1.0" encoding="utf-8"?> 2. <ksiazka> 3. <entry> Strona 38 / 101

5. Protokół XCAP XML Control Access Protocol 4. <email> imnazw@qwe.qwe </email> 5. <adres> 6. <ulica glowna="true"> Jagiellonska 1234 </ulica> 7. <miasto> Gdansk </miasto> 8. <wojewodztwo>pomorskie</wojewodztwo> 9. <kraj>polska</kraj> 10. </adres> 11. <ietf-czlonek/> 12. </entry> 13. </ksiazka> 5.0.9 XCAP DELETE usunięcie atrybutu. DELETE http://127.0.0.1:8080/mobicents/www/users/user/index1/~~/ksiazka/entry/adres/ulica/@glow na Usunięcie atrybutu z elementu zwraca dokument : 1. <?xml="1.0" encoding="utf-8"?> 2. <ksiazka> 3. <entry> 4. <imie> imie nazwisko</imie> 5. <email> imnazw@qwe.qwe </email> 6. <adres> 7. <ulica> Jagiellonska 1234 </ulica> 8. <miasto> Gdansk </miasto> 9. <wojewodztwo>pomorskie</wojewodztwo> 10. <kraj>polska</kraj> 11. </adres> 12. <ietf-czlonek/> 13. </entry> 14. </ksiazka> 5.1 Zastosowania protokołu XCAP w aplikacjach. Application Usages. Wykorzystania protokołu XCAP są określone poprzez specyficzne AUID (ang. Application Unique ID). Strona 39 / 101

5. Protokół XCAP XML Control Access Protocol XCAP capabilities (możliwości XCAP) (auid = xcap-caps). Aplikacja określająca możliwości serwera XDM. Następujące standardy są wspierdane przez XDMS w systemie mobicents. 5.1.1 Resource Lists Listy zasobów. Resource Lists (Listy Zasobów) (auid = resource-lists). Aplikacja (element oprogramowania) list zasobów jest każdą aplikacją, która potrzebuje dostępu do list zasobów określonych przez adres URI oraz, do których można zastosować operacje takie jak subskrypcja. 5.1.2 Presence Rules zasady obecności Zasady obecności (ang. presence rules) (audi = Pres-rules, org.openmobilealliance.pres-rules). Aplikacje zasad obecności to aplikacje wykorzystujące zasady (politykę) autoryzacji do określenia, które informacje mogą być wysłane do subskrybentów (watchers) i kiedy. 5.1.3 RLS Services serwisy list zasobów RLS Services (usługi list zasobów) (auid = rls-service). Aplikacja serwera list zasobów jest aplikacją protokołu SIP kiedy zapewnia możliwość obsługi polecenia subskrypcji protokołu SIP i generuje subskrypcje względem list zasobów. 5.1.4 PIDF Manipulation PIDF Manipulation (ang. presence information data format manipulation) Manipulacja informacjami obecności (auid = pidf manipulation). Aplikacja określa sposoby w jakie XCAP manipuluje zawartość dokumentów PIDF. Własne standardy zdefiniowane zgodnie z potrzebami dla konkretnych rozwiązań. Strona 40 / 101

5. Protokół XCAP XML Control Access Protocol 5.2 XML Namespace przestrzeń nazw plików XML. Określenie przestrzeni nazw pozwala na stosowanie wielu danych z różnych plików XML w jednym dokumencie. Przestrzenie stworzyło W3C w celu zapobiegnięciu powstawania problemów w związku z tymi samymi nazwami elementów w różnych plikach XML. Rozróżnienie bazuje na prefiksach zapewnianych przez przestrzeń nazw. Identyfikatorem przestrzeni może być dowolna referencja IRI (poza pustą referencją). Referencje są identyczne, gdy sekwencje znaków są identyczne, porównywana jest też wielkość znaków. Przestrzeń nazw w plikach xml określa atrybut XMLNS:prefix. Prefix to odpowiednia nazwa dla zbioru nazw. Wykorzystanie przestrzeni nazw polega na zaimportowaniu przestrzeni nazw w pliku xml oraz o dodanie odpowiedniego prefixu dla importowanych elementów. 5.3 Definiowanie własnych plików XML do wykorzystań dla aplikacji. Każdy zasób na serwerze powinien być przypisany do odpowiedniej aplikacji jaka z niego korzysta. Aby aplikacja mogła wykorzystywać dane zasoby potrzebne jest ich dokładne określenie poprzez definicje struktury plików XML (xml schema). Schemat pliku XML określa elementy, atrybutu oraz typy wartości dla danych encji. Znana struktura pozwala na określanie adresów URI. Specyfikacje tworzenia określa RFC 4825. Każde wykorzystanie aplikacyjne (ang. App Usage) protokołu XCAP definiuje : Application Unique ID (Unikalny identyfikator aplikacji -auid). AUID wykorzystuje się w adresie URI do wskazania dokumentów z zasobami. Default Namespace (Domyślna przestrzeń nazw dokumentów). Definiuje przestrzeń nazw dla elementów i atrybutów bez prefixów w adresa XCAP URI. Zazwyczaj jest zbieżna z nazwą przestrzeni nazw dla wykorzystywanej aplikacji. MIME Type ( Multipurpose Internet Mail Extensions Type) Określa typ danych wykorzystywanych przy przesyłaniu dokumentów XML. Strona 41 / 101

5. Protokół XCAP XML Control Access Protocol XML Schema and Data Constraints (Schemat pliku xml oraz ograniczenia zawartości pliku). Schemat XML pozwala na walidacje dokumentów, elementów i atrybutów przesyłanych plików XML. Data Semantics (Semantyka dokumentów). Określa znaki oraz możliwości nazywania elementów dokumentu XML. Wykorzystywana przez aplikacje, nie weryfikowane przez serwer. Naming conventions. (konwencje nazewnictwa). Określa nazewnictwo plików XML dla każdego użytkownika, dokumenty globalne. Resource Interdependencies (Zależności między plikami XML). Określa zależności między modyfikowaniem różnych dokumentów dla użytkowników, dokumentów globalnych, plikach rls. Authorization Policies (polityka autoryzacji). Określa zasady dostępu do danych dla różnych plików i dokumentów. Domyślnie użytkownik może odczytywać i edytować swoje określone dokumentu. Każde wykorzystanie aplikacji (Application Usage) jest reprezentowane przez klasę Java rozszerzająca klasę org.mobicents.xdm.server.appusage.appusage. Strona 42 / 101

7. Pozostałe elementy platformy Mobicents. 7. Pozostałe elementy platformy Mobicents. 7.1 Mobicents Sip Servlets Otwarta platforma służąca szybkiemu rozwojowi oraz uruchamianiu aplikacji opierających się na protokole SIP oraz aplikacji konwergentnych JEE. Pierwsza implementacja SIP servlets v1.1 może być uruchomiona w środowiskach Tomcat, Jboss i itp. kontenerów Java Enterprise. Serwlety Mobicents dostarczają wysoką wydajność, bezpieczeństwo oraz szybszy rozwój aplikacji, serwisów poprzez kooperatywność ze standardami SIP Servlets oraz JAIN SLEE (JSLEE). Środowisko wspiera referencyjną implementację JAIN-SIP jest to biblioteka Javy wspierająca protokół SIP. Najnowsza wersja Mobicents SIP Servlets 1.6.0 jest certyfikowana ze standardami SIP Servlets 1.1. 7.2 Mobicents Media Server Serwer multimedialny w języku Java kontrolowany poprzez MGCP. Serwer ten powstał z myślą o możliwości połączenia różnych sieci VoIP w jednej bramie medialnej. Założenia projektowe : Dostarczenie kompletnej funkcjonalności bramy medialnej o jak najwyższej jakości. Spełnienie wymagań sieci konwergentnych i NGN. Wzrost elastyczności co do możliwości funkcjonalnej bramy. Szybka możliwość rekonfiguracji sieci i serwera. Serwer wspiera najpopularniejsze kodeki takie jak : G.711 au, GSM, Speex nb, G.729. Możliwości : Wspieranie SSS7 Wspieranie H.261 video. IVR i detekcja DTMF. Tworzenie punktów dostępowych konferencje. Ogłaszanie punktów dostępowych. Punkt dostępowy / pośredniczący dla sieci pakietowych. Kontroler protokół MGCP, MEGACO, MSML. Strona 43 / 101

7. Pozostałe elementy platformy Mobicents. 7.3 Mobicents Diameter Implementacja serwera oraz klientów dla rodziny protokołów typu Diameter. Jest to technologia AAA (Authorisation, Authentication, Accoutning) czyli Autoryzacja, Autentykacja i Naliczanie. Implementacja spełnia normy IETF, pozwala na elastyczniejsze oraz lepiej dostosowane polityki bezpieczeństwa niż RADIUS. Diameter jest przyjęty przez organizację 3GPP oraz 3GPP2 aby zapewnić techniki AAA w sieciach IMS zgodnie z założeniami projektowymi danych zastosowań. Otwartość standardów pozwala w oparciu o nie tworzyć autorskie systemu bezpieczeństwa zgodnie z potrzebami. Diameter zapewnia otwartą (open source) implementację podstawowego protokołu oraz najpopularniejszych aplikacji co pozwala na szybki rozwój potrzebnych technologii w oparciu o gotowe podstawowe rozwiązania. Moduł ten zawiera m.in. : Serwer aplikacji (AS Application Server), Serwer subskrybentów (HSS Home Subscriber Server), Kontrolę sesji (CSCF Call Session Control Function), Funkcja lokalizacji użytkownika (SLF Subscrier Location Function). Zalety serwera : Wysoki współczynnik dostępności usługi. Generacja statystyk. Monitorowanie przeciążenia. Różne interfejsy do zarządzania serwerem. Walidacja wiadomości na serwerze. Rozszerzenia pozwalające testować specyficzne implementacje. Łatwo rozszerzalne aplikację Diameter. 7.4 Mobicents SS7 Jest to zbiór zaimplementowanych w Javie adapterów dla technologii SS7 oraz ISDN : MTP2,3, ISUP, SCCP, TCAP, CAMEL oraz MAP. Pozwala to na łączenie sieci SS7 z sieciami TCP/IP. Elementy modułu SS7 są kompatybilne z częściami sieci telekomunikacyjnych takimi jak: ISDN User Part (ISUP) definiuje protokół do zarządzania łączami dla telefonii ISDN pomiędzy dwoma abonentami. Wykorzystywany jest nie tylko dla połączeń ISDN. Strona 44 / 101

7. Pozostałe elementy platformy Mobicents. Telephone User Part (TUP) zapewnia wsparcie podstawowym wiadomościom sygnalizacyjnym zestawiającym połączenie takimi jak np. setup. Przetwarza sygnały analogowo, najczęściej wyniesiony do elementu ISUP. Signalling Connection Control Protocol (SCCP) zapewnia usługi połączeniowe oraz bezpołączeniowe oraz transfer połączeń globalnych. SCCP wykorzystywany jest jaka warstwa transportowa dla serwisów wykorzystujących TCAP. Transaction Capabilities Application Part (TCAP) Wspiera przenoszenie informacji nie sygnalizacyjnych pomiędzy aplikacjami w sieci SS7 wykorzystując bezpołączeniowo SCCP. Wykorzystywany przy odpytywaniu o numer abonenta, systemie AAA, identyfikacji i itp. 7.5 Mobicents Incubator Incubator to platforma na której rozwijane są różne projekty, które jeszcze nie posiadają działających wersji udostępnionych szerszej publice. Tutaj projekty mogą się rozwijać do stabilnych wersji oraz uzyskać certyfikację zgodności zresztą systemu. Niektóre aktualnie rozwijane projekty : Mobients Telco Cloud pozwala na wykorzystanie infrastruktury Mobicentsa jako usługi. IaaS Infrastructre as a Service. Mobicents RestComm ma na celu udostępnienie Mobicentsa jako Saas Software as a Service. SIP Load Balancer pozwala na kształtowanie obciążenia serwera przez zapytania SIP, może być zintegrowany z klastrowym systemem Mobicents. Mobicents Stream Library Ma na celu stworzenie API pozwalającego na różnego rodzaju operację wejścia i wyjścia (I/O). Pozwala to na realizację wysoce asynchronicznego środowiska do wykorzystania dla użytkowników. SMPP Stack Pozwala na wykorzystanie protokołu Short Message Peer to Peer, który jest otwartym standardem mającym na celu zapewnić elastyczną i bezproblemową wymianę wiadomości tekstowych. Wiadomości te mają być docelowo wysyłana przez różnego rodzaje sieci GMS, IP, WAP i itp. Ma to zapewnić bardzo elastyczne i nieograniczone możliwości w przesyłaniu podstawowych informacji. Strona 45 / 101

8 Projekty o podobnej ideologii. 8 Projekty o podobnej ideologii. 8.1 Rhino Open Cloud główny konkurent platformy Mobicents. Projekt powstały w 2000 roku w Wellington w Nowej Zelandii. Wykorzystując JSLEE ma na celu zapewnić integrację między sieciami IP i telekomunikacyjnymi (głównie SS7) różnych technologii. OpenCloud posiada zgodność ze standardem JSLEE 1.1 i jest częścią grupy eksperckiej dla procesów społeczności Java (Java Community Process). System posiada własne SDK, firma zapewnia komercyjne wsparcie. Portal systemu posiada bogate zasoby odnośnie platformy i jej rozwoju. Specyfikacje i dokumentacje dostępne są dla każdego. Podobnie jak Mobicents ma budowę modułową : Rhino Telecom Application Server serwer JAIN SLEE. Rhine Service Interaction Server broker serwisów telekomunikacyjnych. Rhino Sentinel kontroler sesji czasu rzeczywistego dla systemów naliczania. 8.2 IBM WebSphere XML Document Management Server IBM WebSphere XML Document Management Server jest niezależnym od aplikacji i usług środowiskiem zarządzania dowolnymi dokumentami XML. Wlicza się w to typy : listy grup, profile użytkowników, informacje kontaktowe, zasady autoryzacji i inne. Ułatwia wykorzystanie najczęściej dostępnych danych. Używa standaryzowanych mechanizmów dostępu. Ułątwia zarządzanie aplikacjami poprzez centralizowany punkt wykorzystujący standardy IETF, OMA, ETFI oraz 3GGP.vendors applications, using IETF, OMA, ETSI and 3GPP standards. Niezależność serwera od usług i aplikacji. Strona 46 / 101

8 Projekty o podobnej ideologii. Strona 47 / 101

Część praktyczna realizacja i kod źródłowy. Część praktyczna realizacja i kod źródłowy. 1. Środowisko uruchomieniowe i narzędzia. Podstawą do uruchomienia systemu Mobicents SIP Presence Server jest system klasy Windows albo Linux. Aby dodatkowo instalować aplikacje wymagany jest pakiet Maven oraz repozytorium SVN, z którego możemy skompilować oraz zainstalować interesujące nas biblioteki i funkcjonalności. Realizacja środowiska uruchomieniowego i w oparciu o : System Ubuntu 10.04 Maverick : Jeden z najbardziej popularnych systemów opartych o system Debian. Szerokie grono użytkowników pozwala na łatwy dostęp do wielu informacji odnośnie działania systemu. Aktualnie jego popularność spada na rzecz systemu Linux Mint (również baza Debian). Oprogramowanie : Maven narzędzie automatyzujące kompilacje i budowę oprogramowania. Kody źródłowe platformy Mobicents są tworzone w oparciu o narzędzie automatyzujące projekt budowy oprogramowania Apache Maven. Poszczególne funkcjonalności realizują biblioteki (wtyczki), które są automatyczne pobierane z repozytoriów przy ich pierwszym wykorzystaniu. Każdy projekt posiada plik XML określający sposób budowy oprogramowania POM.xml Project Object Model. Przedstawia on wszystkie potrzebne informację do budowy programu. W nim zawarte są zależności odnośnie plików JAR z klasami, obiektami jakie są wymagane, aby bezproblemowo skompilować kod. Platforma Mobicents SIP Presence Server. Mobicents SIP Presence Server -pakiet oprogramowania zawiera zintegrowany serwer XDMS, serwer list zasobów oraz Serwer Obecności (Presence Server) oraz wbudowane biblioteki JSLEE. Nazwa pliku : mobicents-sip-presence-integrated-1.0.0.final.zip Strona 48 /(101)

1. Środowisko uruchomieniowe i narzędzia. Eclipse Helios.. Środowisko programistyczne dla JavaEE. Dodatkowo zawiera pluginy : Maven2Eclipse oraz EclipSLEE. Maven2Eclipse pozwala na integrację sposobu kompilacji Maven a dodatek EclipSLEE pozwala na łatwe generowanie podstawowego kodu aplikacji JSLEE i tworzenie bloków usług SBB. Repozytorium Subversion zawierające kod źródłowy. Subversion to system kontroli wersji oprogramowania. Pozwala na zarządzanie wersjami rozwijanego oprogramowania i przechowywania ich na zewnętrznych serwerach. Kod źródłowy wykorzystany do kompilacji potrzebnych pakietów pochodzi z repozytorium : http://mobicents.googlecode.com/svn/trunk/. Możemy go pobrać za pomocą klienta svn przy użyciu komendy : # svn checkout http://mobicents.googlecode.com/svn/trunk/ Wireshark. Popularny program do obserwacji pakietów IP. Skompilowano i uruchomiono : Mobicents JAIN SLEE XDMS Client Enabler, Mobicents JAIN SLEE XCAP Client Resource Adaptor znajdują się prekompilowane w pakiecie Mobicents SIP Presence Server Integrated 1.0.0.Zostały one jednak rekompilowane i zainstalowane w celu sprawdzenia czy kod aktualnie znajdujący się w repozytorium jest kompatybilny z wersją MSPS udostępnianą do pobrania na stronie www projektu. Jedyną wymaganą rzeczą do instalacji, aby móc zaobserwować podstawowe działanie oraz wiadomości protokołu XCAP jest aplikacja kliencka protokołu XCAP znajdujące się w repozytorium. Mobicents JAIN SLEE XDM Client Enabler JAIN SLEE XDM Client Enabler pozwala aplikacjom JSLEE na współpracę z serwerem XDM pomijając złożoność protokołów sieciowych. Enabler składa się z bloku SBB, który może być wykorzystywany do tworzenia asynchronicznych interfejsów. Serwer XDMS jest elementem funkcjonalnym wykorzystywanym w sieciach obecności (Presence Networks) SIP OMA oraz 3GPP do zarządzania dokumentami XML. Serwer XDMS jest głównie działa z dodatkowymi interfejsami jak np. XCAP Diff pozwalającymi na subskrypcję kiedy zmieniono zawartość dokumentów poprzez protokół XCAP. http://mobicents.googlecode.com/svn/trunk/servers/jain-slee/resources/xcap-client/ Strona 49 /(101)

1. Środowisko uruchomieniowe i narzędzia. Mobicents JAIN SLEE XCAP Client Resource Adaptor Adaptor zasobów JAIN SLEE XCAP adaptuje API klienta protokołu XCAP do domeny JSLEE. Adaptor pozwala na wysyłanie zapytań XCAP do XCAP serwera np. Mobicents XCAP Serwer. Adaptor pozwala na wysyłanie oraz odbieranie zapytań synchronicznie, asynchronicznie oraz blokowanie zapytań dopóki nie serwer nie otrzyma odpowiedzi na wysłane dane. Preferowane użycie w domenie JAIN SLEE to model asynchroniczny. http://mobicents.googlecode.com/svn/trunk/servers/jain-slee/enablers/xdm-client/ Mobicents XCAP Client Example Przykładowa realizacja wykorzystania technologii JAIN SLEE do zarządzania plikami XML na serwerze XDMS. Realizacja funkcji synchronicznej i asynchronicznej. Program pozwala na obserwację tworzenia dokumentu XML w bazie serwera oraz otrzymania odpowiedzi na zapytanie XCAP. Dodatkowo przy pomocy programu Wireshark możliwe jest obserwowanie pakietów IP. http://mobicents.googlecode.com/svn/trunk/servers/jain-slee/examples/xcap-client/ Strona 50 /(101)

2.AppUsage class (klasa wykorzystań aplikacji). 2.AppUsage class (klasa wykorzystań aplikacji). Tworzenie włanych wykorzystań aplikacyjnych dla protkołu xcap na serwerze xdm. Mobicents XDM Server XCAP Application Usage (wykorzystanie aplikacji xcap w serwerze mpsp) wymaga na zaimplementowani kilku prostych klas Java oraz pewnych meta informacji. Każde wykorzystanie aplikacyjne (AppUsage) jest określane przez klasę Java rozszerzającą klase abstrakcyjną org.mobicents.xdm.server.appusage.appusage class. Kod : 1. package org.mobicents.xcap.server.slee.appusage.presrules; 2. public class PresRulesAppUsage extends AppUsage { 3. public static final String ID = "pres-rules"; 4. public static final String DEFAULT_DOC_NAMESPACE = "urn:ietf:params:xml: ns:pres-rules"; 5. public static final String MIMETYPE = "application/auth-policy+xml"; 6. private static final String AUTH_ONLY_DOCUMENT_NAME = #index#; 7. 8. public PresRulesAppUsage(Validator schemavalidator) { 9. super(id,default_doc_namespace,mimetype,schemavalidator,auth _ONLY_DOCUMENT_NAME); 10. } 11. } Metody dostępne dla walidacji schematu, wartości danych oraz zależności zasobów mogą być stworzone zgodnie z potrzebami : 1. 2. 3. 4. 5. 6. public void validateschema(...); public void checkconstraintsonput(...); public void checkconstraintsondelete(...); public void processresourceinterdependenciesonputdocument(...); public void processresourceinterdependenciesondeleteelement(...); //... Gotowe przykłady wykorzystania tych klas możemy znaleźć w kodzie źródłowym w repozytorium kodu projektu. Klasa zawiera też różne konstruktory, ich wykorzystanie zależy on naszych potrzeb i założeń projektowych. Strona 51 /(101)

2.AppUsage class (klasa wykorzystań aplikacji). 1. public AppUsage(String auid, String defaultdocumentnamespace, String mimetype, 2. Validator schemavalidator, String authorizeduserdocumentname); 3. 4. public AppUsage(String auid, String defaultdocumentnamespace, String mimetype, 5. Validator schemavalidator, AuthorizationPolicy authorizationpolicy); 6. 7. public AppUsage(String auid, String defaultdocumentnamespace, String mimetype, 8. Validator schemavalidator, Validator uniquenessschemavalidator, 9. String authorizeduserdocumentname); 10. 11. public AppUsage(String auid, String defaultdocumentnamespace, String mimetype, 12. Validator schemavalidator, Validator uniquenessschemavalidator, 13. AuthorizationPolicy authorizationpolicy); Domyślnie użytkownik może odczytywać i edytować swoje określone dokumenty. 2.1. App Usage Factory Class Implementacja objektu typu Object Factory *(fabryka obiektów) jest wymagana. Powinna rozszerzać klasę interfejsu org.mobicents.xdm.server.appusage.appusagefactory. Klasa AppUsageFactory pozwala nam na uproszczenie w tworzeniu kodu, gdzie do zmiennej możemy przypisać polecenie stworzenia nowego obiektu danego typu. Klasa AppUsageFactory : 1. package org.mobicents.xcap.server.slee.appusage.presrules; 2. 3. public class PresRulesAppUsageFactory implements AppUsageFactory { 4. private Schema schema = null; 5. public PresRulesAppUsageFactory(Schema schema) { 6. this.schema = schema; 7. } 8. public AppUsage getappusageinstance() { 9. return new PresRulesAppUsage(schema.newValidator()); 10. } 11. public String getappusageid() { 12. return PresRulesAppUsage.ID; 13. } 14. public AppUsageDataSourceInterceptor getdatasourceinterceptor() { 15. return null; 16. } 17. } Strona 52 /(101)

2.AppUsage class (klasa wykorzystań aplikacji). Fabryka objektów pozwala na utrzymanie pamięci / puli obiektów dla naszej aplikacji ponieważ obiekty walidatora są kosztowne w tworzeniu pod względem zasobów. Fabryka pozwala również na łątwe generowanie obiektów na żadanie, np. Dokumentów XML lub odpowiedzi na żądania. Odpowiednio zaimplementowane zapewnia łatwą zgodność z wcześniejszymi wersjami klas. 2.2. App Usage Deployer Class oraz deskryptor XML. Deployer to klasa służąca do załadowania I usuwania aplikacji xcap z serwera XDM. Powinien rozszerzać klasę org.mobicents.xdm.server.appusage.appusagedeployer: 1. package org.mobicents.xcap.server.slee.appusage.presrules; 2. public class PresRulesAppUsageDeployer extends AppUsageDeployer { 3. 4. @Override 5. public AppUsageFactory createappusagefactory(schema schema) { 6. return new PresRulesAppUsageFactory(schema); 7. } 8. @Override 9. public String getschemarootnamespace() { 10. return PresRulesAppUsage.DEFAULT_DOC_NAMESPACE; 11. } 12. } Wiele plików XML z różnymi schematami może być mieszane ze soba. Punktem wyjścia jest przestrzeń nazw zwracana przez funkcję getschemarootnamepsace() co nie zawsze jest zgodne z przestrzenią nazwe dla naszej aplikacji. Deployer to ziarno Jboss Microcontainer Bean oraz plik jboss-bean.xml umiejscowiony w folderze META-INF pliku bilioteki JAR. Jboss Microcontainer Bean (Ziarno mikrokontrolera Jboss zapewnia obsługę prostych objektów javy (POJO plain old java object) w infrastrukturze Java Enterprise. Może być uruchamiane jako oddzielne środowiko dla tych właśnie elementów. Plik jboss-bean.xml: Strona 53 /(101)

2.AppUsage class (klasa wykorzystań aplikacji). 1. <?xml version="1.0" encoding="utf-8"?> 2. <deployment xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" 3. xmlns="urn:jboss:bean-deployer:2.0"> 4. <!-- Registers the APP USAGE DEPLOYER AS JBOSS MICROCONTAINER BEA N --> 5. <bean name="mobicents.xdms.appusage.deployer.presrules" class="org.mobi cents.xcap.server.slee.appusage.presrules.presrulesappusagedeployer"> 6. <!-- this app usage depends on app usage management only --> 7. <depends>mobicents.xdms.appusagemanagement</depends> 8. </bean> 9. </deployment> Wymagane stworzenie jest unikalnej nazwy ziarna oraz klasy obiektu Deployer. Nic innego nie wymaga zmian. Struktura jest bardzo uniwersalna. 2.3. Pakiet oraz uruchamianie aplikacji wykorzystującej XCAP. Klasy aplikacji i meta dane powinny być zawarte w pliku JAR zgodnie ze strukturą : example-appusage.jar -META-INF ---jboss-beans.xml (jboss mc bean descriptor) -org ---mobicents ------xdm ---------server ------------appusage ---------------example ------------------ExampleAppUsage (app usage class) ------------------ExampleAppUsageFactory (factory class) ------------------ExampleAppUsageDeployer (deployer class) ------------------ExampleAuthorizationPolicy (optional auth policy class) Abu uruchomić aplikację wystarczy skopiować plik JAR do folderu : $JBOSS_HOME/server/default/deploy/mobicents-xdms(albo mobicents-sippresence)/3.beans/appusages. Aby usunąć obsługę danej aplikacji wystarczy usunąć plik deployer dla danego zastosowania. Strona 54 /(101)

2.AppUsage class (klasa wykorzystań aplikacji). Plik *.xsd ze schematem plików XML należy skopiować do folderu XSD znajdującym się w $JBOSS_HOME/server/default/deploy/mobicents-xdms(albo mobicents-sippresence)/3.beans/appusages. Należy pamiętać : Referencje między plikami XML należy podać przez stosowanie elementu <import>. Przestrzeń nazw może być definiowana tylko w pojedyńczym pliku XSD. 2.4. Dodawanie własnych XCAP AppUsage dla systemu Mobicents. Jako własny wkład do systemu Mobicents można stworzyć implementację XCAP AppUsage dla standardowych aplikacji wedle standardów IETF, OMA oraz innych organizacji standaryzujących. Powinno się zatwierdzać gotową aplikację, pliki schematów XSD oraz aplikację testującą daną implementację. Strona 55 /(101)

4. Realizacja i przykład wykorzystania protokołu XCAP. 4. Realizacja i przykład wykorzystania protokołu XCAP. Wykorzystanie protokołu xcap opiera się o realizację formularza html, przechwytywaniu zmiennych GET przez SBB oraz zwracanie wyniku w postaci prostej strony HTML. Stworzono dla celów realizacji : Formularz html przyjmujący i przekazujący dane do SBB. SBB rozszerzając interfejs JSLEE SBB przyjmujący zmienne GET. Następnie przetwarzanie danych zapewnia wymagany rezultat. Klasa deployer wymagana do uruchomienia SBB. 4.2 Opis kodu klienta XCAP. (opisać różnice SYNC i ASYNC) asynchroniczne dziala ale nie ma jak zwrocic w servlecie info oddzielnie po naglowkach? Mobicents JAIN SLEE Client Resource Adaptor. Klient XCAP jest zintegrowany z domeną JAIN poprzez adaptor zasobów. Adaptor zasobów (Ra Resource Adaptor) pozwala na przesyłanie żądań XCAP do serwera. Możliwe są dwa wykorzystania tego komponentu. Wysyłanie i odbieranie żądań synchronicznie, blokując możliwość obsługi innych zgłoszeń do czasu otrzymania odpowiedzi. Obsługa zdarzeń asynchroniczna preferowana ze względu na charakter modelu sieci. Adaptor zasobów to klasa typu interfejs zapewnia zbiór metod wymagających implementacji. Metody te stanowią klasę XCAP CLIENT. Metody te pozwalają na pełną manipulację dokumentami XML na serwerze XDM. Lista metod interfejsu org.mobicents.xcap.client.xcapclient : Metody zwracają obiekt org.mobicents.xcap.client.xcapresponse, z którego odczytujemy dane otrzymaniu w wyniku odpowiedzi serwera na żądanie XCAP. The setauthenticationcredentials(credentials) method: Jeżeli nie są podane dane autentykacyjne (login i hasło) ustawiana jest wartość domyślna dla żądań XCAP. Strona 56 /(101)

4. Realizacja i przykład wykorzystania protokołu XCAP. The unsetauthenticationcredentials() method: Usuwa dane autoryzacyjne. The shutdown() method: Brak implementacji. The get(uri, Header[], Credentials) method: Uzyskuje zasoby XCAP zgodne z adresem URI. Można też dodać dodatkowe nagłówki HTTP. The put(uri, String, String, Header[], Credentials) method: Zapisuje podane dane XML do zasobów XCAP podanych w adresie URI. Mimetype musi być zgodny z treścią zapisywanych danych. Można określić dodatkowe nagłówki oraz dane autoryzacyjne. The put(uri, String, byte[], Header[], Credentials) method: Zapisuje dane XML w formacie byte[]10. The putifmatch(uri, String, String, String, Header[], Credentials) method: Zapisuje dane XML jeżeli tag etag zgadza się z tym podanym jako parametr funkcji służy do nadpisywania. Dodatkowo definiujemy : mimetype, dane uwierzytelniające, nagłówek dodatkowy. The putifmatch(uri, String, String, byte[], Header[], Credentials) method: Zapisuje dane XML w formacie byte[]. The putifnonematch(uri, String, String, String, Header[], Credentials) method: Zapisuje dane jeżeli podany etag nie istnieje. The putifnonematch(uri, String, String, byte[], Header[], Credentials) method: Zapisuje dane w formacie byte[]. The delete(uri, Header[], Credentials) method: Usuwa zasoby XML zgodnie z podanym adresem URI w żądaniu XCAP. The deleteifmatch(uri, String, Header[], Credentials) method: Usuwa zasoby zgodnie z podanym tagiem etag. The deleteifnonematch(uri, String, Header[], Credentials) method: Usuwa dane XML jeżeli nie znaleziono podanego taga etag. 10 Format byte[] przechowuje znaki w formacie ASCII zamiast Unicode. Wartości znaków przujmują wartośći 0-255. Strona 57 /(101)

4. Realizacja i przykład wykorzystania protokołu XCAP. 4.3 Schemat przesyłania danych przez formularz HTML. Podstawowa komunikacja z serwerem XDM zaczyna się przez wypełnienie formularza HTML, którym zostaną przesłane dane odnosnie akcji jakie ma wykonać blok SBB. Metoda formularza to GET (istnieje możliwość implementacji również metody POST i innych). Blok obsługuje zdarzenie przyjścia danych wysłanych metodą GET z formularza HTML. Obsługa zdarzenia zaimplementowano z funkcjonalności servletów java. Po przekazaniu danych do bloku SBB uruchomiony jest klient XCAP, który przesyła odpowiednie żądanie do serwera XDM. Obsługa zdarzenia odpowiedzi pozwala na pobranie interesujących elementów z dokumentów XML a następnie zwrócenie ich w postaci prostej strony HTML. Ilustracja 16: Schemat fromularza html i serwera XDM. Strona 58 /(101)

4. Realizacja i przykład wykorzystania protokołu XCAP. 4.4 Blok SBB. Service Building Block blok oprogramowania zawierający kod oraz logikę wykonywanych zadań w systemie. 4.4.1 Komponent SBB. SBB definiuje i składa się z elementów11 : Typów zdarzeń (ang. Event types) otrzymywanych i wysyłanych przez komponent SBB. Stan instancji bloku Sbb przechowywany w polu CMP Kontenerze stanu zarządzanego (ang. Container Managed Persistent). Metody zdarzeń (ang. Event methods). Komponent SBB obsługuje zdarzenia zgodnie z zaimplementowanymi ich typami oraz zdarzenia dla jakich jest źródłem. Interfejs lokalny i jego metody określają synchroniczne zastosowanie bloku SBB. Lokalne metody interfejsu SBB mogą zostać uruchomione tylko i wyłącznie przez inny blok SBB. Relacje rodzic - dziecko. Komponent SBB może posiadać relacje z wieloma elementami SBB. Połączenia między elementami opisane są w deskryptorach XML. Współdzielone dane. Komponent SBB określa poprzez atrybutu kontekstu aktywności (ang. Activity Context Attributes) zmienne i dane współdzielone. Każdy atrybut posiada nazwę i typ. Dostępność zapewniają interfejsy dla różnych kontekstów aktywności. Relację pomiędzy elementami SBB w relacjach rodzic dziecko przyjmują postać grafu. Elementy SBB są węzłami grafu, krawędzie (skierowane lub nieskierowane) pokazują relację pomiędzy komponentami. Wartości krawędzi wskazują na priorytet relacji podczas przetwarzania. 11 JAIN SLEE 1.1 Specification Proposed Final Draft, rozdział 2.2.1. Strona 59 /(101)

4. Realizacja i przykład wykorzystania protokołu XCAP. Ilustracja 17: Graf ukazujący relacje rodzic - dziecko elementów SBB. Priorytet w grafach wskazuje na kolejność w jakiej SLEE przesyła do elementów SBB przychodzące zdarzenia. Rodzic SBB zawsze otrzymuje zdarzenie przed elementami dzieci, w przypadku braku ustawienia priorytetów (na krawędziach grafu) ustawiana jest wartość domyślna. Obiekt SBB Obiekt SBB jest instancją SLEE wygenerowanej klasy rozszerzającej abstrakcyjną klasę SBB (javax.slee.sbb). Podczas uruchomienia SLEE system uruchamia bloki SBB i dodaje je do puli komponentów uruchomionych. Komponenty po uruchomieniu znajdują się w stanie gotowości (ang. Ready state) i są gotowe na przyjmowanie i obsługę zdarzeń oraz wykonywania logiki w nich zawartej.. Każdy element SBB posiada interfejs lokalny. Uruchamianie metod w blokach potomnych (dzieciach) jest synchroniczne i możliwe tylko w drzewie bloków. Aktywność (Activity) Aktywność reprezentuje skorelowany strumień zdarzeń. Przykładowo wybieranie numeru do osoby może być aktywnością (ang. Activity). Obiekt aktywności (ang. Activity object) jest to obiekt klasy Java enkapsulujący aktywność oraz może on zapewniać metody zapewniające dostęp do danych i przetwarzania Strona 60 /(101)

4. Realizacja i przykład wykorzystania protokołu XCAP. ich. Przykładowo klasa Jcc (ang. Java Call Control ) jest aktywnością reprezentującą dzwonienie do kogoś. Kontekst Aktywności (ang. Activity Context) Kontekst aktywności reprezentuje i enkapsuluje obiekt aktywności. Zachodzi relacja jeden do jednego pomiędzy kontekstem i daną aktywnością. Kontekst zawiera atrybuty, które mogą być współdzielone przez wiele elementów SBB, które wykorzystują obiekt aktywności. Encję SBB mogą odczytywać i zapisywać dane przechowywane w kontekście. Kontekst jest kanałem dla zdarzeń, który akceptuje zdarzenia uruchamiane w kontekście i przesyła je do odpowiednich bloków SBB przypisanych do kontekstu. SBB może wywoływać funkcję innych bloków SBB w sposób asynchroniczny poprzez wywoływanie zdarzeń do kontekstu aktywności, który odpowiednio je rozdysponuje pomiędzy bloki. Encja SBB może być przypisana do wielu kontekstów co zapewnia możliwość obsługi wielu zdarzeń. SBB może otrzymać zdarzenia tylko od kontekstów, do których jest przypisany. SLEE dodaje oraz usuwa encję SBB z kontekstów w sytuacji12 : Podczas tworzenia nowego obiektu SBB (rodzic, ang. Root ) w czasie uruchomienia metody setsbbcontext. Usuwa podczas zakończenia życia obiektu aktywności w kontekście. Podczas usuwania SBB z drzewa komponentów, niszczone są wszystkie połączenia z kontekstami. Bloki SBB mogą przypisywać się do kontekstów aktywności oraz z nich usuwać. Pozwala to na modyfikowanie zdarzeń obsługiwanych przez blok SBB w trakcie jego działania. 12 JAIN SLEE 1.1 Specification, Proposed Final Draft, rozdział 2.2.11 Strona 61 /(101)

4. Realizacja i przykład wykorzystania protokołu XCAP. Strona 62 /(101)

4. Realizacja i przykład wykorzystania protokołu XCAP. Ilustracja 18: Relacje pomiędzy SBB oraz kontekstem aktywności. 4.4.2 Metody zaimplementowane w bloku SBB opis klasy. Domyślne metody interfejsu Sbb : public void sbbactivate() {} public void sbbcreate() throws CreateException {} public void sbbexceptionthrown() {} public void sbbload() {} public void sbbpassivate() {} public void sbbpostcreate(){} public void sbbremove() {} public void sbbrolledback(){} public void sbbstore() {} public void setsbbcontext(){} public void unsetsbbcontext() {} Strona 63 /(101)