Modele tworzenia aplikacji mobilnych

Systemy mobilne to przyszłość telekomunikacji zintegrowanej z systemami IT. Szybkość ich rozwoju i popularyzacji zależy nie tylko od dostępności odpowiedniej infrastruktury, ale przede wszystkim usług i aplikacji. Tworzenie tych ostatnich wymaga zaś odpowiednich narzędzi i platform dla systemów mobilnych.

Systemy mobilne to przyszłość telekomunikacji zintegrowanej z systemami IT. Szybkość ich rozwoju i popularyzacji zależy nie tylko od dostępności odpowiedniej infrastruktury, ale przede wszystkim usług i aplikacji. Tworzenie tych ostatnich wymaga zaś odpowiednich narzędzi i platform dla systemów mobilnych.

Popularne sieci telefonii komórkowej ukształtowały się w rezultacie doświadczeń wynikających z rozwoju architektur i technologii sieci stacjonarnych. Zaproponowana przez Bellcore w latach 80. architektura SS7 (Systemy Sygnalizacji numer 7) i wdrożenie usług 0800 pozwoliły na odseparowanie logiki usług od logiki centrali oraz ich wyniesienie poza samą centralę. Jednym z tego efektów było wprowadzenie spójnej architektury danych na zewnętrznych serwerach. Nie byłoby to możliwe bez wprowadzenia asymetrycznego modelu połączenia (call model) oraz możliwości programowania sieci przy wykorzystaniu tzw. punktów trigerujących TDP (Trigger Detection Point).

Uniezależniona usługa

Rys. 1

Rys. 1

Te zmiany architektoniczne pozwoliły na odseparowanie dostawców usług od dostawców central, co spowodowało wzrost konkurencyjności. Dodatkowym impulsem, który przyczynił się do rozwoju otwartych platform i modeli oprogramowania, były decyzje prawne w wielu krajach wymuszające otwarcie sieci dla szerszej niż dotąd rzeszy dostawców. Ciągle jednak istotą programowania w telekomunikacji pozostały maszyny stanów, które realizują odpowiednią funkcjonalność. Ma to kapitalne znaczenie dla zrozumienia różnic oraz funkcji zarówno architektur, jak i modeli oprogramowania.

W wypadku oferty operatorów sieci mobilnych należy zwrócić uwagę na konieczność rozróżnienia co jest usługą, a co aplikacją. Usługi są historycznie pojęciem telekomunikacyjnym zdefiniowanym przez specyfikacje ITU-T [Q.1202], podczas gdy aplikacje to pojęcie informatyczne. Na rynku istnieje obecnie wiele platform i modeli tworzenia aplikacji mobilnych, ale w pewnym uproszczeniu można je podzielić na oprogramowanie telekomunikacyjne, biznesowe i modele mieszane. Można też wyróżnić modele zorientowane na zdarzenia, scentralizowane i rozproszone. Każdy z nich ma zalety i wady zależnie od zastosowań. Niżej przedstawiono niektóre z najpopularniejszych platform.

Rys. 2

Rys. 2

Warto dodać, że model oprogramowania wiąże się z rozgraniczeniem między specyfikacją a implementacją. Pierwsza opisuje, co musi się zdarzyć, a nie sposób, w jaki będzie to realizowane. Druga jest realizacją modelu na odpowiedniej platformie. Każdy model wykorzystuje konkretny język programowania. Pod tym względem w ciągu ostatnich 30 lat nastąpiła ewolucja - od języka maszynowego, przez zamknięte języki tworzone dla specyficznych platform, do powszechnie stosowanych języków programowania, jak C lub Java. Zapewne w dłuższej perspektywie tworzenie oprogramowania zostanie oparte na modelach skryptowo-graficznych.

Dodatkowym elementem, który wpłynął na architekturę oraz model tworzenia aplikacji mobilnych, jest rynek, na którym oferowane są aplikacje przeznaczone dla odbiorców indywidualnych i klientów biznesowych mających istotnie różne wymagania. Od późnych lat 80. dominującą technologią usługową na rynku mobilnym pozostaje SS7, w szczególności ISUP i INAP/CAMEL, ale dla firm kluczową rolę odgrywają technologie pakietowe (IP) i bazodanowe. Właśnie dlatego w ostatnich latach można zauważyć ogromny wpływ technologii informatycznych na kierunek rozwoju rynku telekomunikacyjnego.

Inteligent Network/CAMEL

Rys. 3

Rys. 3

Pierwszym modelem programowania i pierwszymi architekturami usługowymi w sieciach mobilnych były klasyczne rozwiązania SS7, które do realizacji usług wykorzystywały ISUP lub IN. Model ten dostarcza zestawu zaawansowanych funkcji do obsługi połączeń. Usługi realizowane w technologii SS7 mają najwyższą wydajność i niezawodność, jaką dotychczas udało się uzyskać w jakichkolwiek systemach. Klasycznym przykładem usługi opartej na technologiach IN jest system prepaid.

W modelu IN logika usługi jest wyniesiona poza centrale, a jej środowiskiem wykonawczym jest serwer SCP, który jest informowany o zdarzeniach dotyczących połączenia realizowanego w sieci przez centralę przy użyciu protokołu IN. Usługa subskrybuje się na zdarzenia, które są definiowane przez standard IN i przesyłane przez centralę w chwili, gdy maszyna stanów znajduje się w stanie, do którego ktoś się subskrybuje. Podstawą realizacji tej operacji jest tzw. call half model. Rozwiązanie to jest podobne do modelu klient-serwer, gdzie protokół IN jest usługowym API wykorzystywanym przez ich dostawców. Usługa jest realizowana w środowisku dostawcy, które musi zostać zintegrowane z protokołem IN. Do tego celu stosuje się najczęściej język C/C++. Przykładami dostawców usług opartych na IN są Ericsson i Siemens.

Java Telephony API

JTAPI (patrz rys. 1) jest pierwszym modelem programowania, który miał na celu kontrolę sprzętu telekomunikacyjnego, w szczególności central PBX i systemów call centers, przy użyciu języka Java. Jego podstawowym celem było dostarczenie prostego i łatwego w obsłudze modelu obiektowego, który pozwoliłby na integrację połączenia telefonicznego z aplikacją uruchomioną na komputerze odbierającego telefon agenta. Przykładem usługi realizowanej za pomocą JTAPI jest prezentacja danych osoby dzwoniącej już w momencie, gdy dzwoni telefon.

Drugim ważnym celem JTAPI jest integracja systemu z istniejącymi architekturami CTI. Model ten wymaga dostępności środowiska wykonawczego, gdzie osadzona jest logika usługi. Choć nie dostarcza on zbyt wielu zaawansowanych funkcji, to istotnie przyczynił się do rozwoju nowocześniejszych modeli, takich jak Parlay czy JAIN. Oprócz tego zintegrowane systemy JTAP/CTI mają niezawodność i wydajność klasy telekomunikacyjnej. Przykładami dostawców usług JTAPI są firmy Genesis i Avaya.

Java API for Integrated Networks

Rys. 4

Rys. 4

Model JAIN (patrz rys. 2) został stworzony w celu dostarczenia abstrakcji sieci i API, które pozwoliłoby na tworzenie aplikacji, mogących równocześnie obsługiwać abonentów sieci stacjonarnych, komórkowych i szerokopasmowych. Standard ten z założenia spełnia wszystkie wymagania stawiane systemom telekomunikacyjnym i architektonicznie jest równoważny modelowi IN lub SIP. W początkowym okresie podjęto prace nad wieloma modelami, np. JAIN, JCC/JAIN, SIP/JAIN, SLEE/etc.

Modele JCC są odpowiedzialne za obsługę przychodzących rozmów i realizację takich funkcjonalności, jak inicjacja połączenia, obsługa zdarzeń oraz dostęp do danych połączenia. JCC API zostało tak zaprojektowane, aby za jego pomocą można było zrealizować większość usług dodanych, oferowanych przez operatorów. Z biegiem czasu okazało się, że rynek najbardziej docenił specyfikację JAIN SLEE (JSLEE), która opisuje środowisko wykonania (Service Logic Execution Environment) i architekturę integracji. Sytuacja ta odzwierciedla fakt, że samo API nie ma wartości dla operatora, ponieważ opisuje tylko możliwość realizacji usług, do której wymagane jest środowisko wykonania i najczęściej wiąże się to z dodatkowymi kosztami zakupu serwera aplikacyjnego obsługującego dane API.

Zasadniczo architektura JSLEE składa się ze środowiska wykonawczego (kontenera SLEE) i adaptera protokołu RA (Resorce Adapter). Resorce jest interfejsem do danej sieci (np. SS7 lub SIP). Pomiędzy RA oraz SLEE wykorzystana jest architektura oparta na zdarzeniach, natomiast same usługi są budowane przez łączenie komponentów zwanych SBB. Komunikaty z sieci są przekazywane przez RA jako zdarzenia do kontenera SLEE, który następnie przekazuje je do SBB, gdzie umiejscowiona jest logika usługi. Przykładami dostawców JSLEE są firmy OpenCloud i Alcatel.

SIP servlet

Rys. 5

Rys. 5

SIP servlet (patrz rys. 3) jest modelem programowania usług, które wykorzystują protokół SIP (Session Initiation Protocol). Jako technologia SIP servlet jest wzorowana na HTTP. Jest to model sesyjny, który był projektowany do zastosowań na rynku biznesowym, ale obecnie stał się modelem dla sieci IMS integrowanym z nią przez interfejs ISC. Na rysunku pokazano jak w IMS jest wykorzystany SIP servlet.

Model SIP wymaga środowiska wykonawczego, jakim jest serwer aplikacyjny, w którym najczęściej istnieje SIP servlet kontener, zajmujący się parsowaniem komunikatów SIP i przekazywaniem ich do aplikacji, która ma zadaną logikę biznesową. Przykładowa architektura kontenera obsługującego SIP servlet jest pokazana na rysunku. Przykładami dostawców SIP servlet są firmy BEA i Ubiquity.


TOP 200