Office Web Apps

Office Web Apps to dawna nazwa przeglądarkowych wersji aplikacji biurowych, obecnie Office w sieci.

Architektura i ewolucja przeglądarkowych edytorów dokumentów firmy Microsoft

Office Web Apps to początkowa nazwa zestawu aplikacji biurowych Microsoft uruchamianych bezpośrednio w oknie przeglądarki internetowej, zaprezentowana po raz pierwszy równolegle z premierą pakietu Office 2010. Głównym celem tego projektu było uniezależnienie procesu edycji i przeglądania dokumentów w formatach Open XML (rozszerzenia DOCX, XLSX, PPTX) od oprogramowania klienckiego instalowanego na stacji roboczej. Historycznie usługa ta działała w oparciu o silnik renderujący zintegrowany z platformą SharePoint 2010 oraz konsumencką usługą Windows Live SkyDrive. W przeciwieństwie do wcześniejszych rozwiązań z obszaru Rich Internet Applications wykorzystujących wtyczki pokroju ActiveX czy Silverlight, inżynierowie Microsoft oparli środowisko Office Web Apps o uniwersalne standardy sieciowe, w tym HTML, CSS i JavaScript. Taka struktura zapewniła kompatybilność krzyżową z wieloma systemami operacyjnymi oraz silnikami renderującymi przeglądarek.

W kolejnych cyklach wydawniczych nastąpiła separacja warstwy logicznej. W środowiskach lokalnych (on-premises) wydzielono osobny, niezależny produkt serwerowy oznaczony jako Office Web Apps Server (OWAS), który w późniejszych latach przeszedł architektoniczną transformację, stając się usługą Office Online Server (OOS). System ten przejmuje zadania związane z przetwarzaniem plików dla farm SharePoint, serwerów Exchange oraz infrastruktury Skype for Business. Z upływem czasu oryginalna marka Office Web Apps została wygaszona na rzecz nazw „Office Online”, a ostatecznie „Office w sieci”. Ze względu na tę zmianę nomenklatury i standaryzację, zgłoszenia i zapytania operujące oryginalną nazwą należą obecnie do rzadkości. Kod źródłowy oraz paradygmaty działania stworzone dla pierwszej generacji stanowią jednak fundament dla aktualnych mechanizmów chmurowych zintegrowanych z platformą Microsoft 365.

Mechanizmy renderowania i różnice funkcjonalne względem wydań instalowanych lokalnie

Zrozumienie działania edytorów webowych wymaga analizy procesu ładowania plików w strukturach rozproszonych. Wersje instalowane bezpośrednio w systemie wczytują cały plik do pamięci operacyjnej urządzenia i wykorzystują natywne biblioteki do rysowania interfejsu graficznego i prezentacji zawartości. W przypadku architektury przeglądarkowej proces ten podzielono pomiędzy sprzęt klienta a maszynę obliczeniową w chmurze. Serwer otwiera strukturę archiwum ZIP, z jakiego składa się format Open XML, a następnie tłumaczy poszczególne właściwości na wartości zrozumiałe dla silnika przeglądarki. Do stacji roboczej transmitowane są wyłącznie mniejsze wycinki danych oraz odpowiednie węzły drzewa DOM (Document Object Model), które odpowiadają za widok tego fragmentu arkusza lub strony, na który w danej chwili patrzy operator.

Przeglądarkowe edytory implementują warstwę komunikacji opartą na stałych połączeniach WebSockets, co umożliwia współdzieloną edycję jednego dokumentu w czasie rzeczywistym. Każda modyfikacja znaków traktowana jest jako operacja wejścia, przesyłana na serwer i transmitowana do pozostałych klientów w celu bezkolizyjnego łączenia zmian. Rozwiązania bazujące na środowisku webowym (sandbox przeglądarki) posiadają konkretne ograniczenia wynikające z uwarunkowań technologicznych. Pakiet chmurowy nie pozwala na wykonywanie skryptów zapisanych w języku Visual Basic for Applications (VBA), pomija moduły dodatkowe bazujące na komponentach COM oraz nie obsługuje natywnie logiki wewnętrznej dla modelu Power Pivot w przypadku dużych zbiorów danych. Kompilacja bardzo złożonych form graficznych w edytorze Word, obejmująca zagęszczone obiekty wektorowe, wielokolumnowe układy marginesów czy osadzone czcionki, wywołuje z reguły spłaszczenie przestrzenne i uproszczenie wizualne na czas modyfikacji pliku, zachowując przy tym ścisłe wymiary podczas eksportu materiału końcowego do pliku PDF.

Wyzwania eksploatacyjne w środowisku przeglądarki internetowej

Przetwarzanie dokumentów z setkami tysięcy komórek lub obszernych slajdów graficznych obciąża lokalny procesor w sposób niemal zbieżny z obciążeniami generowanymi przez starsze aplikacje instalowalne. Głównym zadaniem realizowanym po stronie urządzenia końcowego jest interpretacja kilkudziesięciu megabajtów kodu JavaScript, który steruje renderowaniem poszczególnych pikseli okna i zarządza buforem wprowadzanych znaków. Błędy eksploatacyjne w pracy webowej wynikają na ogół z nakładających się restrykcji konfiguracji samego środowiska stacji roboczej. Rozszerzenia przeglądarkowe, w tym narzędzia modyfikujące strukturę nagłówków HTTP, skrypty ingerujące w ładowanie obiektów zewnętrznych lub mechanizmy egzekwujące wyłączenie tzw. ciasteczek stron trzecich (third-party cookies), nierzadko przerywają poświadczenia autoryzacyjne. W rezultacie użytkownik otrzymuje błąd połączenia serwerowego i brak możliwości weryfikacji zapisu wygenerowanych zmian.

Częstym uchybieniem technicznym są także desynchronizacje stanu pracy wywołane zmianami parametrów transmisji. Transfer poleceń w narzędziach webowych bazuje na stałym potwierdzaniu odebranych porcji informacji. Gubienie pakietów w połączeniach sieciowych lub wyraźne skoki opóźnień powodują rozejście się logiki między stacją końcową a środowiskiem chmurowym. Platforma reaguje na taki stan powiadomieniem wymuszającym pełne przeładowanie strony internetowej i zrzut części niezapisanej pamięci wprowadzania tekstowego. Dodatkowym czynnikiem destabilizującym są przepełnione tablice danych w pamięci podręcznej samej przeglądarki, skutkujące zapętleniami mechanizmów logowania, zrywanymi sesjami oraz błędami generowania zawartości z racji uciętych nagłówków przekraczających dopuszczalne wielkości bufora po stronie serwerów HTTP (błąd 400).

Hardware a płynność działania aplikacji webowych – obszar interwencji technicznej

Pomimo faktu, że środowisko Office Web Apps nie wymaga dedykowanego instalatora, jego czas reakcji pozostaje nierozerwalnie związany z parametrami sprzętowymi, na których jest uruchamiany. Silniki kompilujące JavaScript zawarte w oprogramowaniu do przeglądania sieci zmuszają układy logiczne procesora do obróbki setek tysięcy instrukcji w krótkim odstępie czasu. Jeśli laptop posiada uszkodzony lub niedrożny z powodu zalegających zanieczyszczeń układ chłodzenia połączony z wyschniętą pastą termoprzewodzącą na rdzeniu krzemowym, wbudowane termometry uaktywniają mechanizmy bezpieczeństwa w postaci sprzętowego zbijania mnożnika taktowania. Skutkiem obniżonej częstotliwości pracy procesora są opóźnienia, tak zwany input lag między wciśnięciem klawisza a wyświetleniem glifu na ekranie, oraz skokowe przesuwanie ekranu z towarzyszącym mu głośnym szumem wentylatorów systemowych.

Kolejnym obszarem determinującym wydajność edycji jest pojemność pamięci oraz wydajność samego składowania danych operacyjnych. Posiadanie otwartych kilku kart w tle obok uruchomionego edytora tekstowego absorbuje średnio od 1,5 do 3 gigabajtów pojemności RAM. Przy maszynach wyposażonych w 4 GB pamięci fizycznej, zarządzanie systemem sprowadza się do wymuszenia zrzutu bloków danych operacyjnych na pamięć masową dysku (stronicowanie). W sytuacji bazowania na klasycznym dysku talerzowym HDD, całkowity czas operacji wymiany stron powoduje blokady interfejsu systemowego i brak odpowiedzi oprogramowania na komendy wskaźnika. Warszawskie Pogotowie Komputerowe reaguje na te utrudnienia sprzętowe. Nasz serwis komputerowy przeprowadza wymiany nośników talerzowych na dyski SSD oparte o kości NAND flash, podwaja fizyczną pojemność zainstalowanych modułów RAM i rekonstruuje układy chłodzenia, przywracając starszym płytom głównym sprawność pozwalającą na szybkie i bezproblemowe użytkowanie przeglądarkowych wersji programów biurowych.