Wirtualne biurko na przykładzie Oracle9iAS Wireless

Piotr Listosz

Ile czasu pracownik spędza w pracy? Na ogół jest to osiem
godzin, czasem dziesięć, a w niektórych firmach nawet więcej (zwłaszcza w
tych, które – nastawione na zdobycie jak największej liczby klientów – nie
dbają o zdrowie własnych pracowników). Jednakże prawdą jest, że ilość
godzin, o których mowa widnieje jedynie w umowie o pracę, natomiast czas w
rzeczywistości spędzony za biurkiem jest o wiele krótszy. Nie chodzi tu nawet
o picie pięciu kaw dziennie i robienie kilkunastu przerw na papierosa (w
nowoczesnych firmach te zachowania są raczej marginalne i bliżej im w stronę
patologii niż normy), lecz o takie legalne i pożądane działania, jak wyjazdy
na konferencje, spotkania z kontrahentami i innego rodzaju podróże służbowe.
Na ogół czas, jaki pracownik spędza w podróży jest dla firmy czasem
straconym. Poza tym bywają spotkania i konferencje, na których po prostu
trzeba być (bo tego wymaga polityka firmy), jednak nie dzieje się na nich nic,
co mogłoby w jakikolwiek sposób zainteresować pracownika. Czy oglądanie
sufitu musi być w takich przypadkach jedynym sensownym zajęciem?

Odkąd Internet zaczął być jednym z elementów biznesu (w
Polsce było to około 11 lat temu; na świecie trochę wcześniej), pracodawcy
zaczęli zastanawiać się, jak efektywnie wykorzystać to nowe medium. Możliwość
przejrzenia interesujących stron WWW (interesujących z punktu widzenia
pracodawcy, nie pracownika), czy sprawdzenia poczty e- mail, to na pewno zajęcia
bardziej pożyteczne niż oglądanie sufitu, jednak nawet takie możliwości
nadal nie pozwalały w pełni wykorzystać pracownika, nie siedzącego przy własnym
biurku. Właśnie, biurko; idealna sytuacja miałaby miejsce wówczas, gdyby można
było wysłać pracownika w delegację wraz z jego biurkiem, a zatem z możliwością
dostępu do firmowego intranetu, aplikacji i baz danych wykorzystywanych w
przedsiębiorstwie. W takim przypadku nie miałoby znaczenia, czy znajduje się
on w pociągu, czy siedzi w pracy. Pracownik przebywający w dowolnym miejscu mógłby
być w pełni wykorzystany, co – siłą rzeczy – wpłynęłoby na
ograniczenie pośrednich kosztów działalności firmy. Wraz z upowszechnieniem
się urządzeń mobilnych (tj. telefonów komórkowych, palmtopów, laptopów,
itp., nie zaś żelazek na baterie) pojawiła się koncepcja stworzenia czegoś
w rodzaju „wirtualnego biurka” – urządzenia, przy pomocy którego
pracownik miałby dostęp do zasobów firmy, a które nie wiązałoby go z żadnym
określonym miejscem. Przy obecnym zaawansowaniu urządzeń bezprzewodowych,
koncepcja ta sprawia wrażenie prostej do realizacji, jednak – jak to
zwykle bywa – diabeł tkwi w szczegółach. Różnorodność aplikacji, które
należałoby udostępnić użytkownikom mobilnym (mówiąc o takim użytkowniku,
będziemy mieli na myśli osobę wyposażoną w urządzenie bezprzewodowe, przy
pomocy którego można uzyskać dostęp do zasobów informatycznych), mnogość
urządzeń bezprzewodowych, a także cały szereg protokołów i języków
znacznikowych, którymi mogą posługiwać się te urządzenia, sprawił, że
koncepcja wirtualnego biurka została sprowadzona do czegoś w rodzaju
„czarnej skrzynki”, która pełniłaby rolę pośrednika pomiędzy
aplikacjami, a urządzeniami mobilnymi wymagającymi dostępu do danych
generowanych przez te aplikacje. Ukoronowaniem pomysłu „czarnej
skrzynki” było powstanie platformy Oracle9iAS Wireless. Zanim jednak omówimy
tę technologię, spróbujmy bliżej przyjrzeć się problemom, z którymi
musieli sobie poradzić oracle’owi programiści.

Wyzwania technologii bezprzewodowej

Istnieją przynajmniej trzy powody, dla których
projektowanie aplikacji mobilnych stanowi nie lada wyzwanie. (Przez aplikację
mobilną będziemy rozumieć program, którego dane wyjściowe mają być
prezentowane na urządzeniu bezprzewodowym). Po pierwsze, urządzenia mobilne
wyposażane są zazwyczaj w niewielkie ekrany i dysponują ograniczonymi możliwościami
wprowadzania danych. Wskutek tego najlepiej nadają się one do przeprowadzania
ściśle określonego zestawu transakcji, nie zaś skomplikowanych operacji.
Ponadto wśród standardów obsługiwanych przez urządzenia bezprzewodowe
istnieje olbrzymia niejednorodność. Wreszcie mnogość protokołów z
wykorzystaniem których komunikują się urządzenia mobilne oraz cały szereg różnych,
rozumianych przez nie języków znacznikowych, to czynniki utrudniające
tworzenie aplikacji, które obsługiwałyby wszystkie (lub przynajmniej znakomitą
większość) dostępne urządzenia. Już na podstawie tych różnorodności
widać, że konieczna jest platforma software’owa, która radykalnie uprości
proces programowania, wdrażania oraz zarządzania aplikacjami mobilnymi.

Infrastruktura

Infrastruktura bezprzewodowa to łańcuch różnorodnych,
lecz współpracujących ze sobą komponentów. Typowe elementy takiej
infrastruktury to:

  • urządzenia mobilne i przeglądarki,
  • sieć bezprzewodowa,
  • serwery aplikacji i aplikacje.


Rys. 1. Elementy infrastruktury bezprzewodowej.

Urządzenia mobilne i przeglądarki

Zasadniczo każde urządzenie bezprzewodowe wyposażone jest
w miniprzeglądarkę, przy pomocy której może ono wyświetlać otrzymane
informacje (widać tu analogię do rozwiązania tradycyjnego, tj. do komputera
PC oraz standardowej przeglądarki internetowej). Ponadto urządzenia mobilne
montowane w samochodach, a także tradycyjne telefony, korzystają z technologii
przekazywania informacji drogą głosową. (Być może ta ostatnia uwaga wydaje
się trywialna, jednak – jak się za chwilę przekonamy – dostęp do
aplikacji „via głos” nie jest już taką oczywistą sprawą). Języki
znacznikowe, jakimi posługują się urządzenia bezprzewodowe (na przykład
VoiceXML, WML, HDML, itp.) są odpowiednikami języków HTML/XML, rozumianych
przez tradycyjne przeglądarki. Niestety, standardy w tej dziedzinie wciąż się
zmieniają, co oczywiście nie ułatwia życia programistom.

Sieć bezprzewodowa

Istotne cechy sieci bezprzewodowych to przepustowość i
rodzaj połączenia. Na przykład sieci 2.5G (GPRS) oraz 3G (UMTS) charakteryzują
się dużą przepustowością, dzięki czemu oferują szybki dostęp do zasobów.
Ponadto sieci takie pozwalają na dostęp w trybie „always-on”
(zawsze włączony), którego przewaga nad dostępem komutowanym jest oczywista.

Dostarczenie informacji do urządzenia mobilnego odbywa się
z udziałem protokołów transmisji, takich jak WAP (Wireless Access Protocol),
SMS (Short Messaging Service), czy nawet zwykły przekaz głosowy. Warto
zwrócić uwagę na fakt, że protokoły jakie funkcjonują w sieciach
bezprzewodowych, są w tych środowiskach bardziej wydajne, niż zwykły
internetowy protokół HTTP. Jest to jeden z głównych powodów, dla których
większość bezprzewodowych urządzeń klienckich nie korzysta z protokołu
HTTP (a szkoda, bo to z pewnością uprościłoby zadania stojące przed
programistami). Ten brak zgodności protokołów wymusza istnienie tzw. bramek
(ang. wireless gateway), które konwertują format żądań wymagany
przez „protokoły mobilne” na żądania rozumiane przez standardowy
protokół HTTP.

Serwery aplikacji i aplikacje

Zadaniem serwerów aplikacji jest zwiększenie wydajności
aplikacji, a także ułatwienie ich wdrażania i zarządzania nimi. Serwer o którym
mowa stanowi pomost łączący aplikację (źródło informacji) z bramką lub
urządzeniem mobilnym. Oczywiście połączenie to odbywa się z udziałem sieci
bezprzewodowej. Serwer aplikacji stanowi centralny i najważniejszy element
„wirtualnego biurka”. To właśnie on jest czarną skrzynką,
pobierającą informacje z aplikacji mobilnej, dostosowującą je do potrzeb
konkretnego użytkownika mobilnego (zgodnie z jego wytycznymi) i przekształcającą
na język znacznikowy, rozumiany przez urządzenie bezprzewodowe, którym posługuje
się ten użytkownik. Dzięki takiemu rozwiązaniu programista projektujący
aplikację, nie musi uwzględniać wszystkich istniejących protokołów
transmisji i języków znacznikowych. W rozwiązaniu proponowanym przez firmę
Oracle, wspomnianą wyżej rolę pełni platforma Oracle9iAS Wireless (która
de facto nie jest serwerem aplikacji, lecz jedynie komponentem tego serwera).
Posługując się pojęciem „serwer aplikacji”, będziemy mieli na
myśli tę właśnie platformę.

Dane generowane przez aplikacje mobilne, czy – mówiąc
bardziej obrazowo – treści przesyłane na urządzenia bezprzewodowe, mogą
przybierać rozmaite formy; mogą to być informacje pochodzące z baz danych,
dane personalizowane pod kątem określonego użytkownika, kierowane do niego
alerty, wiadomości e-mail, usługi lokalizacyjne, itp. Jak widać, ilość źródeł
informacji oraz ich różnorodność jest wcale niemała. Serwer aplikacji nie
ma prostego zadania, gdyż – przynajmniej w założeniu – każdą
informację powinno dać się przesłać do każdego urządzenia mobilnego, co
więcej, w formie zoptymalizowanej pod kątem tego urządzenia oraz dostosowanej
do wymagań jego użytkownika.

Żądania w sieci bezprzewodowej

Użytkownik korzystający z komputera PC i standardowej
przeglądarki internetowej, chcąc pobrać stronę WWW, wysyła do serwera
odpowiednie żądanie. Podobny proces ma miejsce w przypadku urządzeń
bezprzewodowych, żądających zasobów generowanych przez aplikacje mobilne.
Jednak ze względu na wspomnianą wcześniej różnorodność platform sprzętowych,
protokołów transmisji i języków znacznikowych, w proces wysyłania żądania
i odbierania danych musi zostać zaangażowany serwer aplikacji. Spróbujmy
scharakteryzować poszczególne etapy tego procesu i zaobserwować rolę, jaką
pełni w nim serwer aplikacji.


Rys. 2. Przesyłanie żądania w sieci bezprzewodowej

1. Wysłanie żądania

Użytkownik, chcąc skorzystać z usługi dostępnej dla urządzeń
bezprzewodowych, wybiera numer telefonu odpowiedniego dostawcy usług. Sieci
2.5G i 3G oferują dostęp typu „always-on”, w związku z czym, w
celu zapoczątkowania sesji nie jest wymagane łączenie się z usługodawcą.
Żądanie wysłane przez użytkownika kierowane jest do sieciowej stacji
bazowej. W proces wysyłania żądania może być zaangażowany jeden z wielu
protokołów (takich jak SMS, WAP, czy nawet zwykły przekaz głosowy), co jest
zależne od rodzaju urządzenia mobilnego. Warto zauważyć, że protokoły
oferujące pakietową transmisję danych, zoptymalizowane pod kątem
funkcjonowania w sieciach bezprzewodowych (charakteryzujących się ograniczoną
przepustowością i zawodną łącznością), są wydajniejsze niż standardowy
protokół HTTP, nie przystosowany do działania w takich warunkach.

2. Translacja żądania i przesłanie go do serwera aplikacji

Po nawiązaniu połączenia ze stacją bazową i prawidłowym
zakończeniu procesu uwierzytelnienia urządzenia mobilnego, dostawca usług
akceptuje połączenie, a żądanie wysyłane jest ze stacji bazowej do bramki
(ang. wireless gateway). W tym miejscu musi nastąpić konwersja żądania
przesyłanego z użyciem protokołu stosowanego w sieci bezprzewodowej, do
formatu wymaganego przez protokół HTTP (na przykład w przypadku stosu protokołów
WAP, następuje konwersja żądania przesyłanego z udziałem protokołu WTP (Wireless
Transport Protocol
), będącego protokołem warstwy transportowej stosu WAP,
na żądanie HTTP). Po przejściu (i konwersji) żądania przez bramkę,
przyjmuje ono postać typową dla protokołu HTTP, tj. staje się żądaniem
adresu URL określonego zasobu. Pod tym adresem znajduje się serwer aplikacji,
do którego kierowane jest żądanie (lub serwer WWW w przypadku żądania
strony sieci Web). Jak więc widać, bramka nie tylko wykonuje konwersję żądania,
ale także łączy sieć bezprzewodową z tradycyjną siecią przewodową.

3, 4. Przesłanie żądania do aplikacji i pobranie
rezultatów jej działania

W nagłówku żądania otrzymanego przez serwer aplikacji
(podobnie jak w nagłówku „tradycyjnego” żądania HTTP) znajdują
się informacje na temat tożsamości użytkownika, jego geograficznej
lokalizacji, typu urządzenia mobilnego oraz adresu żądanych zasobów. Dzięki
takim informacjom serwer aplikacji nie tylko odszuka i odeśle odpowiednie dane,
ale również dostosuje je do profilu określonego użytkownika i urządzenia
bezprzewodowego.

Serwer aplikacji – po odczytaniu informacji o użytkowniku
i urządzeniu – przystępuje do realizacji żądania. Ta operacja wykonywana
jest w dwóch etapach: najpierw pobierane są dane z żądanej aplikacji, a następnie
są one dostosowywane do profilu określonego użytkownika.

5,6. Dostosowanie informacji do potrzeb konkretnego urządzenia/sieci
i przesłanie ich do użytkownika mobilnego

Ze względu na fakt, iż użytkownicy korzystają z różnych
urządzeń mobilnych, które rozumieją różne języki znacznikowe, zadaniem
serwera aplikacji przesyłającego żądane dane do użytkownika (a konkretnie
do bramki łączącej sieć przewodową z bezprzewodową) jest przekształcenie
ich z formatu XML na język zrozumiały dla danego urządzenia mobilnego.

Tak w skrócie wygląda konwersacja pomiędzy użytkownikiem
mobilnym, a serwerem aplikacji, mająca na celu pobranie danych dostępnych w
zwykłej sieci przewodowej. Jak widać, realizacja tego procesu wymaga pokonania
wielu barier, z których podstawowa to wszechobecny brak kompatybilności. Dzięki
serwerowi aplikacji, „czarnej skrzynce” odpowiedzialnej za złączenie
rzeczywistości bezprzewodowej z tą tradycyjną, przewodową, problemy te
sprowadzają się do przestrzegania pewnych nieskomplikowanych zasad (na przykład
generowania danych w formacie XML). Serwer aplikacji ułatwia nie tylko obsługę
żądań pochodzących z urządzeń mobilnych, lecz również projektowanie
aplikacji będących celem tych żądań. Przyjrzyjmy się zatem jakie problemy
ominęły programistów, dzięki istnieniu serwera aplikacji.

Wyzwania w programowaniu aplikacji mobilnych

Już na pierwszy rzut oka da się zauważyć, że niemal
wszystkie urządzenia mobilne mają pewne wspólne cechy, które raczej nie
przydają im funkcjonalności. Cechy istotne z punktu widzenia programisty to:

  • Nieporęczny sposób wprowadzania danych;
  • Ograniczone możliwości prezentowania informacji;
  • Rozumienie różnych języków znacznikowych.

Klawiatura telefonu komórkowego z pewnością nie nadaje się
do przepisywania powieści (nawet jeśli mistrzowie świata w szybkości pisania
SMS-ów twierdzą inaczej). Mimo iż istnieją urządzenia mobilne z nieco
bardziej przyjaznym interfejsem, takie jak palmtopy, czy iPaq’i, to i tak
korzystanie z nich jest dużo bardziej kłopotliwe, niż posługiwanie się zwykłym
pecetem wyposażonym w klawiaturę i myszkę.

Rozmiary ekranu oraz możliwości wyświetlania, jakimi
dysponują urządzenia bezprzewodowe, mogą mocno się różnić. Trudno porównywać
kolorowe ekrany najnowszych palmtopów z wyświetlaczami przedpotopowych (czyt.
sprzed dwóch lat) Nokii, na których nawet gra w „wężyka” nie
dawała satysfakcji użytkownikowi. Zoptymalizowanie aplikacji w sposób uwzględniający
wszystkie urządzenia, z których może być ona dostępna, jest po prostu niemożliwe.
Jednakże z drugiej strony taka optymalizacja jest konieczna. Aplikacja powinna
działać efektywnie na każdym urządzeniu, optymalnie wykorzystując jego możliwości.
Ponadto powinno dać się dostosować jej funkcjonalność zarówno do potrzeb użytkownika,
jak i do możliwości urządzenia, a nawet do położenia geograficznego, w którym
w danym momencie znajduje się ów użytkownik (a więc do elementów
charakterystycznych wyłącznie dla technologii mobilnych).

Sytuację dodatkowo komplikuje cały szereg języków
znacznikowych, którymi mogą posługiwać się różne urządzenia mobilne, a
także niejednolite możliwości tych języków.

Co więcej, użytkownik mobilny nie może być ograniczony do
jednej aplikacji (lub do jednego rodzaju aplikacji). Powinien on mieć możliwość
pozyskiwania danych pochodzących z całego szeregu repozytoriów, takich jak
strony WWW, serwery pocztowe, czy bazy danych.


Rys. 3. Problemy stojące przed programistą aplikacji
mobilnych

Reasumując można stwierdzić, że przed programistą
aplikacji mobilnej stoi potężne wyzwanie, jakim jest obsługa całego
wachlarza urządzeń, protokołów i języków znacznikowych, a co za tym idzie,
tworzenie takich aplikacji, które bez dodatkowych przeróbek, nakładek i
wtyczek będą działały na każdym (lub niemal każdym) urządzeniu mobilnym.

Już na pierwszy rzut oka widać, że zadanie to jest niemal
niemożliwe do realizacji, bez istnienia dodatkowej platformy
software’owej, która wzięłaby na siebie translację i dostosowanie
danych generowanych przez aplikację, do wymagań urządzeń mobilnych i potrzeb
użytkownika. Co więcej, platforma taka powinna zapewnić skalowalność
aplikacji pod kątem obsługi dużej liczby użytkowników, wielu sesji równoległych
realizowanych przez danego użytkownika (jest to zadanie szczególnie trudne, ze
względu na ograniczoną przepustowość sieci bezprzewodowych oraz brak obsługi
cookies przez większość bramek), a także obsługiwać treści o dużych
rozmiarach (odpowiednio buforując je i dostarczając w zależności od parametrów
urządzenia mobilnego).

Platforma, o której mowa powinna uwzględnić potrzeby użytkowników
bezprzewodowego Internetu, którzy chcą przesyłać komunikaty, przeglądać
informacje, korzystać z usług, przeprowadzać transakcje online oraz mieć
dostęp do aplikacji biznesowych. (Większość bezprzewodowych platform
software’owych spełnia jedynie mały zakres tych wymagań, co wymusza wybór
różnych platform dla różnych usług). Powinna ona również uwzględniać
wciąż rozwijające się standardy bezprzewodowe, takie jak i-Mode, WAP, SMS,
GPRS, UMTS, a ponadto obsługiwać otwarte standardy programowania aplikacji,
takie jak XML, XHTML, Java Servlets, Java Server Pages. Platforma Oracle9iAS
Wireless spełnia te wymagania, tworząc rozwiązanie gotowe do wykorzystania w
biznesie.

Platforma Oracle9iAS Wireless

Oracle9iAS Wireless to – odpowiedzialny za obsługę klientów
mobilnych – komponent serwera aplikacji Oracle9i. (Serwer ten został
doskonale scharakteryzowany w cyklu artykułów Ewy Palarczyk, jakie ukazały się
w numerach 18, 19 i 20 miesięcznika Oracle’owe PLOUG’tki). Podobnie
jak cały serwer Oracle9iAS, tak i platforma Wireless ma budowę modułową.
Jej podstawowym elementem jest wielomodalne jądro, działające jak usługa pośrednicząca
(proxy), funkcjonująca pomiędzy aplikacją a dowolnym urządzeniem
mobilnym. Oprócz wspomnianego jądra, platforma składa się z szeregu modułów,
które pokrótce zostaną scharakteryzowane w dalszej części tego artykułu.


Rys. 4. Architektura platformy Oracle9
iAS Wireless

Wielomodalne jądro

Jądro platformy Oracle9iAS Wireless jest strukturą
uniezależniającą programistę aplikacji od istniejących sieci, protokołów,
urządzeń, bramek i innych komplikacji, jakie może on spotkać na drodze pomiędzy
aplikacją a urządzeniem bezprzewodowym. Wszystkie problemy, z jakimi
potencjalnie mógłby zetknąć się programista, zostały sprowadzone do
jednego protokołu (HTTP) oraz jednego języka znacznikowego (XML). Dane
generowane w tym języku przesyłane są do platformy Wireless z udziałem
wspomnianego protokołu i… to już wszystko o co musi zadbać programista; cała
reszta to zadanie omawianej platformy. To tu odbywa się dekodowanie danych
pobranych z aplikacji oraz ich transformacja i optymalizacja, uwzględniająca
możliwości konkretnego urządzenia mobilnego oraz wymagania jego użytkownika
(aktualnie obsługiwanych jest ponad 100 urządzeń mobilnych, jednak Oracle
dysponuje sprawdzonym systemem aktualizacji tej listy urządzeń). System
Oracle9iAS Wireless korzysta z bazy danych Oracle9i, w której
przechowywane są obiekty trwałe (na przykład informacje o urządzeniach i użytkownikach).
Przy pomocy dostarczanego wraz z systemem API, programista może manipulować
tymi obiektami, a także mieć wpływ na zachowanie samej platformy Wireless (na
przykład zmienić sposób uwierzytelniania użytkownika mobilnego lub
zmodyfikować mechanizm identyfikacji urządzenia bezprzewodowego).

Zarządzanie transakcjami, użytkownikami i urządzeniami
mobilnymi odbywa się przez przeglądarkę WWW. Z poziomu dostępnej tu
aplikacji można manipulować uprawnieniami użytkowników, sposobem w jaki mogą
oni oglądać dane oraz sterować procesami i wydajnością.

Dostęp do aplikacji drogą głosową

Mimo iż zakrawa to na opowieść z gatunku science-fiction,
to faktem jest, że dostęp do aplikacji mobilnej można uzyskać z…
dowolnego telefonu. Co więcej, na pewno już nieraz zetknęliśmy się z usługą
tego typu. Często dzwoniąc do różnego rodzaju biur obsługi klienta, jesteśmy
proszeni o wybranie numeru lub podanie informacji głosowej. W zależności od
rodzaju informacji, jesteśmy kierowani do wybranego operatora lub odtwarzane
jest odpowiednie nagranie głosowe. Zastanówmy się jak działa ten system w
oparciu o platformę Wireless Oracle’a. W celu udostępnienia aplikacji
„via głos” wymagane są cztery komponenty: bramka głosowa, serwer
aplikacji (w naszym przypadku Oracle9iAS Wireless), aplikacja generująca
żądane dane oraz oczywiście użytkownik wyposażony w telefon. Oracle
wykorzystuje tu jeszcze bazę danych, w której przechowywane są profile użytkowników
(także „wzorce” ich wypowiedzi), wskutek czego system nie musi za
każdym razem uczyć się mowy abonenta. Bramka głosowa to swego rodzaju
konwerter, przekształcający strony w formacie VoiceXML (generowane przez
serwer aplikacji) na nagrania audio, a wypowiedzi abonenta na żądania HTTP.
Strona VoiceXML przypomina zwyczajną stronę w formacie XML, z tym że zamiast
tekstów wyświetlanych na standardowym urządzeniu wyjściowym, zawiera ona
nagrania audio zwane „monitami”, które mogą prosić dzwoniącego o
podanie polecenia głosowego. W celu zrozumienia tego polecenia bramka głosowa
używa oprogramowania rozpoznającego mowę, w efekcie czego generuje żądanie
HTTP i wysyła je do serwera aplikacji. Na podstawie tego żądania aplikacja
zwraca dane w formacie XML, które serwer Wireless przekształca na stronę w
formacie VoiceXML i kieruje ją do bramki głosowej. Serwer Oracle9iAS
Wireless nie jest dostarczany wraz z bramką głosową, jednakże potrafi współpracować
z dowolną bramką, zgodną ze standardem VoiceXML, taką jak NMS, Verascape,
Comverse, IBM, czy Voice Genie.

Asynchroniczna komunikacja dwukierunkowa

Wbudowany w oprogramowanie Oracle9iAS Wireless moduł
serwera asynchronicznego, pozwala korzystać z aplikacji mobilnych (a także z
Internetu) przez dowolne urządzenie obsługujące komunikację asynchroniczną,
jak na przykład telefon komórkowy wyposażony jedynie w możliwość wysyłania
i odbierania SMS-ów, e-mail, czy dwukierunkowy pager (dostęp do bazy danych
przez pager to rzeczywiście nie lada gratka). Użytkownik po prostu wysyła krótki
komunikat z żądaniem określonych danych lub usługi, po czym otrzymuje
odpowiedź również w postaci komunikatu. Odpowiedzi dostosowane są do możliwości
technicznych urządzenia, na przykład dzielone na mniejsze fragmenty. Co
ciekawsze, przez urządzenia asynchroniczne można „uruchamiać” te
same aplikacje co przez urządzenia synchroniczne (na przykład telefony WAP,
PDA lub przeglądarki internetowe). Oracle’owa platforma Wireless umożliwia
łączenie poleceń, dzięki czemu redukuje się ilość komunikatów przesyłanych
pomiędzy urządzeniem a aplikacją (to dobra wiadomość dla tych, którzy nie
lubią pisać SMS-ów). Takie łączone komunikaty obsługiwane są
sekwencyjnie.

Oczywiście nie istnieje platforma, która byłaby w stanie
obsłużyć wszystkie możliwe urządzenia (zwłaszcza te, które dopiero
powstaną), jednak firma Oracle udostępnia doskonale udokumentowane API, dzięki
któremu programiści znający język Java mogą pisać nowe sterowniki dla
nowych urządzeń asynchronicznych.

Dostarczanie komunikatów

Za dostarczanie komunikatów do urządzeń mobilnych
odpowiedzialna jest usługa Push Service, będąca jednym z modułów
oracle’owej platformy bezprzewodowej. Komunikaty mogą być dostarczane różnymi
drogami, wśród których najbardziej popularne to SMS, e-mail oraz przekaz głosowy.
Oczywiście samo dostarczanie komunikatów nie jest niczym nadzwyczajnym, jednak
Oracle pozwala również na zarządzanie komunikatami oraz śledzenie ich
(kontrolowanie trasy komunikatu). Możliwe jest też tworzenie list
dystrybucyjnych i grup odbiorców komunikatów. Tu Oracle również udostępnia
API, które pozwala na pisanie sterowników do nowych urządzeń. Tak więc
– jak widać – architektura serwera Wireless jest w pełni
rozszerzalna. Wzbogacenie aplikacji w możliwość generowania i rozsyłania
komunikatów wydaje się bardzo ciekawą możliwością, zwłaszcza że nie
wymaga się tu od programisty niczego nowego. W tym celu może on korzystać z języka
XML oraz z Javy (a konkretnie z Push Java Beans).

Dostosowanie do umiejętności użytkownika

Wydajność aplikacji mobilnych rośnie wraz ze stopniem
dostosowania ich do potrzeb i umiejętności użytkowników. Platforma Oracle9iAS
Wireless udostępnia mechanizm Customization & Alert, pozwalający na
przystosowanie aplikacji do wymogów jej użytkownika.

Mechanizm ten opiera się na modelu publikacja/subskrypcja
(na podobnej zasadzie działają internetowe listy wysyłkowe), dzięki któremu
użytkownik ma możliwość „zaprenumerowania” interesujących go
alertów (komunikatów generowanych przez aplikację, wskutek zajścia określonego
zdarzenia). Rodzaj i tematyka alertów może być dostosowana do potrzeb ich
odbiorców. Co więcej, ci ostatni mogą zapisać swoje ustawienia i posługiwać
się nimi podczas kolejnych odwołań do serwera aplikacji. Ustawieniami takimi
można zarządzać z poziomu dowolnego urządzenia bezprzewodowego lub komputera
PC, wyposażonego w przeglądarkę WWW.

Korzystanie z istniejących aplikacji internetowych

Kolejna usługa oferowana przez platformę Oracle9iAS
Wireless, to Transcoding Service. Dzięki niej możliwe jest
przystosowanie istniejących, często przestarzałych aplikacji internetowych,
do wymagań urządzeń mobilnych. Informacje generowane przez takie aplikacje są
po prostu konwertowane do formatu XML, ten zaś może być przekształcony przez
platformę Wireless na język znacznikowy, rozumiany przez określone urządzenie
mobilne (a nawet na przekaz głosowy). Możliwość konwersji dotyczy nie tylko
starszych aplikacji, czy na przykład statycznych stron HTML, lecz również
nowych technologii, nie obsługiwanych przez starsze urządzenia mobilne. Na
przykład strony generowane w języku WML przeznaczone są dla urządzeń obsługujących
protokół WAP. Żeby można było korzystać z serwisu WAP przy pomocy urządzeń
nierozumiejących języka WML, jego zawartość przekształcana jest do formatu
XML, a następnie do formatu rozumianego przez dane urządzenie.

Dostęp w trybie offline

Nie ma wątpliwości co do tego, że łączność
bezprzewodowa jest zawodna (zawodzi zwłaszcza w Nowy Rok). Oracle przygotował
się na tę ewentualność, oferując dostęp do aplikacji w trybie offline.
Taki dostęp ograniczony jest jedynie do tych urządzeń mobilnych, na których
można zainstalować oprogramowanie Oracle9i Lite, a więc na wszelkiego
rodzaju palmtopach, laptopach, notebookach, wyposażonych w takie systemy
operacyjne jak Palm OS, Symbian EPOC, Microsoft Windows CE, Microsoft Windows
95/98/NT/2000.

Oracle9i Lite to zestaw technologii, pozwalających na
projektowanie, wdrażanie i zarządzanie aplikacjami mobilnymi, pracującymi w
trybie offline. Jedną z ważniejszych funkcji tego systemu jest mechanizm
automatycznej synchronizacji danych pomiędzy jednostką mobilną, a centralną
(synchronizacja ta odbywa się w obu kierunkach). Dzięki takiej funkcji
pracownicy działów IT nie muszą martwić się tym, jak rozprowadzić nowe
wersje aplikacji mobilnej na tysiące urządzeń. Po prostu oprogramowanie samo
się zsynchronizuje, po połączeniu się urządzenia mobilnego z siecią.
Synchronizacja danych i oprogramowania możliwa jest dzięki istnieniu serwera
mobilnego
(moduł Mobile Server), będącego komponentem systemu Oracle9i
Lite, zainstalowanym na platformie Oracle9iAS Wireless. Drugi komponent
tego systemu to serwer WWW mobilnego klienta, pracujący na urządzeniu
bezprzewodowym.

Podstawowym elementem platformy Oracle9i Lite jest
wydajna, choć nieskomplikowana relacyjna baza danych (w wersji Lite). Dzięki
prostocie tego systemu, a jednocześnie sporych możliwościach, aplikacje mogą
działać w warunkach ograniczonych przez niewielką pamięć i wydajność urządzeń
mobilnych, a także zawodność sieci bezprzewodowych.

Więcej informacji na temat systemu Oracle9i Lite można
znaleźć w materiałach z prelekcji, jaką pp. Janusz Jezierski i Robert
Wrembel wygłosili podczas VIII Konferencji PLOUG w październiku 2002 roku
(materiały te dostępne są pod adresem: http://www.ploug.org.pl/konf_02/materialy/pdfy/Jezierski.pdf).

Świadomość lokalizacji

Każdy, kto znajdzie się w obcym mieście, chciałby wiedzieć
jak trafić na pocztę, do banku, czy urzędu skarbowego. Możliwość taką
zapewniają aplikacje „świadome” miejsca, w jakim aktualnie
przebywa użytkownik. Usługi lokalizacyjne udostępniane przez platformę
Oracle9iAS Wireless mocno udoskonalają aplikacje mobilne. Dzięki nim użytkownik
może skoncentrować się wyłącznie na informacjach istotnych dla niego w
danej chwili (analiza map, kierunków jazdy, raportów o ruchu ulicznym, a także
lokalizowanie obiektów). Sama platforma Wireless również oferuje szereg modułów
lokalizacyjnych (prezentacja map, podawanie położeń geograficznych,
wyznaczanie tras, interfejsy do usług Yellow Pages), które są przygotowane do
rozbudowywania i dołączania do własnych programów. Automatyczne odczytywanie
położenia urządzenia mobilnego możliwe jest dzięki współpracy firmy
Oracle z producentami tych urządzeń (m.in. z firmami CellPoint, Ericsson,
Nokia, Signalsoft). Takie usługi lokalizacyjne mogą okazać się bezcenne na
przykład dla właścicieli firm spedycyjnych, którzy dzięki nim są w stanie
w dowolnej chwili dowiedzieć się, gdzie znajdują się ich samochody i
pracownicy.

Usługi pocztowe i zarządzanie informacjami osobistymi

Dostęp do poczty elektronicznej z palmtopa wydaje się czymś
oczywistym. Nieco mniej oczywisty jest dostęp z poziomu zwykłego telefonu komórkowego,
natomiast możliwość sprawdzenia poczty przez tradycyjny telefon, oferujący
wyłącznie przekaz głosowy, zakrawa na fantazję. Jednakże platforma Oracle9iAS
Wireless udostępnia takie możliwości. Dzięki modułom Mobile PIM oraz
Email, użytkownik korzystający z dowolnego urządzenia mobilnego, może
skomunikować się z serwerem POP3 lub IMAP4 (obsługiwane platformy pocztowe to
między innymi Microsoft Exchange oraz Lotus Domino). Moduł Mobile PIM (Personal
Information Management
) składa się z szeregu komponentów, dzięki którym
użytkownik może tworzyć harmonogramy, zarządzać planem dnia, uzyskiwać
dostęp do serwerów usług katalogowych LDAP, zarządzać książką adresową,
czy wymieniać komunikaty przesyłane w popularnych sieciach typu instant
messages
(na przykład ICQ).

Proste i bezpieczne usługi m-Commerce

m-Commerce to „komórkowa” odmiana technologii
e-Commerce, pozwalającej na przeprowadzanie transakcji online. Moduł mCommerce
Service
platformy Oracle9iAS Wireless udostępnia takie usługi, w
formie zoptymalizowanej do niezbyt poręcznych w użytkowaniu urządzeń
mobilnych. Moduł ten korzysta z przechowywanych w bazie danych informacji o użytkowniku,
którymi w sposób automatyczny wypełnia wszelkiego rodzaju formularze,
wymagane przez sklepy elektroniczne i systemy płatności online. Bezpieczeństwo
transakcji chronione jest trzyczęściowym kluczem, na który składa się klucz
systemowy, klucz użytkownika (pozwalający na uwierzytelnienie użytkownika w
systemie) oraz jego hasło.

Ukłon w stronę programistów

Jednym z elementów platformy Oracle9iAS Wireless jest
Mobile Studio, środowisko programisty, pozwalające na koordynację działań
różnych grup projektantów pracujących nad aplikacją, a także upraszczające
proces jej testowania w środowisku, w którym będzie ostatecznie pracowała.
Otwarta architektura, w oparciu o którą powstał moduł Mobile Studio (J2EE/XML),
umożliwia dostosowywanie jego wyglądu oraz sposobu działania do wymagań
programistów. Intuicyjny interfejs administracyjny tego środowiska pozwala na
szybkie wykreowanie wydajnego portalu deweloperskiego. Działający egzemplarz
Mobile Studio można obejrzeć pod adresem http://studio.oraclemobile.com

Bezpieczeństwo technologii mobilnej

Bezpieczny dostęp do zasobów bankowych, danych przedsiębiorstw,
usług m-Commerce lub dowolnych innych źródeł niejawnych informacji, to
podstawowy wymóg oczekiwany przez użytkowników systemów bezprzewodowych.
Platforma Oracle9iAS Wireless udostępnia podobne środki bezpieczeństwa,
jakie wykorzystywane są w tradycyjnych środowiskach. System kluczy prywatnych
i publicznych, gwarantujący poufność informacji, podpisy elektroniczne,
zapewniające jej nienaruszalność oraz cyfrowe certyfikaty, potwierdzające tożsamość
stron biorących udział w transakcji, to podstawowe elementy systemu bezpieczeństwa.
Samo przesyłanie informacji po sieciach bezprzewodowych i przewodowych jest także
bezpieczne, gdyż może odbywać się z udziałem protokołów WTSL (Wireless
Transport Layer Security
) i SSL (Secure Socket Layer). Ponadto
przechowywane w bazie danych informacje o użytkowniku są również kodowane, a
implementacja skomplikowanych list ACL (Access Control List) gwarantuje
dostarczanie właściwych danych odpowiednim użytkownikom.

Mimo iż zapewnienie bezpieczeństwa w sieciach
heterogenicznych (przy ogromnej ilości różnych urządzeń bezprzewodowych i różnorodności
protokołów) to rzecz naprawdę trudna, Oracle poradził sobie z tym problemem
znakomicie.

Nowe możliwości

Trudno wyobrazić sobie, jak będą wyglądać przyszłe
aplikacje, jednak przynajmniej jedna rzecz jest niemal pewna – nie będą one
przywiązywać pracowników do biurek. Już dziś niemal każdy z nich wyposażony
jest w taki czy inny telefon komórkowy, a możliwość porozmawiania z inną
osobą staje się tylko jedną z wielu funkcji takiego urządzenia. Często też
użytkownicy korzystają z aplikacji mobilnych dostępnych przez WAP (na przykład
usługi lokalizacyjne), lub SMS (na przykład informacja o stanie konta
bankowego).

Trudno zatem nie dostrzec przewagi jaką daje firmom Internet
bezprzewodowy. Dzięki takiej technologii mogą oni mieć stały kontakt z
klientami, partnerami, dostawcami, czy wreszcie z pracownikami. Jednakże – jak
zostało to podkreślone w niniejszym tekście – tworzenie aplikacji, które
musiałyby uwzględniać ogromną heterogeniczność technologii mobilnej jest
niezwykle trudne. Na szczęście istnieją platformy, które rozwiązują większość
tych problemów, a tym samym pozwalają programistom skupić się wyłącznie na
merytorycznych aspektach aplikacji. Jedną z takich platform jest Oracle9iAS
Wireless. Na pewno warto wypróbować jej możliwości, przybliżające ideę
„wirtualnego biurka”.

Bibliografia

  1. Oracle9iAS Wireless: Creating a Mobilized
    Business, Kalle Radage, An Oracle White Paper, marzec 2002
  2. Mobile E-Business – Cut Cost and Drive New Revenue,
    Harald Collet, An Oracle White Paper, grudzień 2001
  3. Oracle9i Lite: rozwiązanie dla mobilnych baz danych?,
    Juliusz Jezierski, Robert Wrembel, materiały z VIII Konferencji PLOUG,
    październik 2002
  4. Serwer aplikacji Oracle9i, Ewa Palarczyk, Oracle’owe
    PLOUG’tki n-ry 18, 19, 20
    , sierpień, grudzień 2001, marzec 2002