Praktyka pokazała, że oba te podejścia są często łączone - dane szczególnie wrażliwe są izolowane fizycznie, a pozostałe umieszczone we wspólnej bazie.

Na dodawanie własnych kolumn (rozszerzanie schematu danych) także jest kilka sposobów. Pierwszy to predefiniowany zestaw kolumn, gdzie metadane danego podmiotu określają ich rolę w aplikacji. Jednak takie podejście po pierwsze marnuje miejsce (nie wszystkie pola będą zawsze wykorzystane), a po drugie ogranicza możliwości rozbudowy. Częściej stosowane są pary (klucz, wartość), które są wiązane z poszczególnymi rekordami w tabelach głównych. Można też stosować dokumenty XML pozwalające na umieszczenie w nich dowolnej struktury i wówczas z punktu widzenia aplikacji zmienia się tylko sposób zadawania zapytań - obok SQL pojawia się XQuery analizujący dodatkowe informacje.

Skalowalność usługi

W modelu SaaS skalowalność nabiera innego znaczenia niż np. "liczba transakcji na sekundę w systemie bazodanowym". Sposób realizacji procesu jest z punktu widzenia klienta nieistotny. Klient podpisuje umowę na określoną dostępność i wydajność biznesową systemu.

Technicznie realizacja takich wymagań nie jest skomplikowana. Jeżeli na przykład warstwa usługowa będzie dostępna za pośrednictwem WCF (Windows Communication Foundation), to projektant systemu niezależnie definiuje strukturę wymienianych informacji (kontrakt) i techniczne aspekty transmisji. Medium komunikacyjnym może być na przykład HTTP + SOAP (klasyczne usługi Web), albo szybki protokół binarny przesyłający informacje pomiędzy portami TCP.

Jednak zamiast tych mechanizmów można wykorzystać kolejkę komunikatów. Wtedy aplikacja kliencka wkłada dane do kolejki, a usługa kolejno je wyjmuje. Komunikat może mieć informacje o priorytecie, od czego będzie zależeć, jak często system będzie wykonywał polecenia pochodzące od danego podmiotu.

Ponieważ system SaaS wykorzystuje komunikację zgodną z modelem SOA - gdzie każda "przesyłana paczka" jest encją biznesową, to w naturalny sposób można przy definiowaniu skalowalności w ramach umowy SLA posługiwać się pojęciami biznesowymi. Czyli klient SaaS nie płaci za dodatkowy procesor, szybszą pamięć czy większą przepustowość łącza, tylko za to, że jego system będzie w stanie przyjąć 100, a nie 10 zamówień na minutę.

Trzeba podkreślić, że sugerowane wyżej rozwiązania nie są sposobami na pisanie "najbardziej wydajnych" aplikacji. Celem było przedstawienie takich mechanizmów, które z jednej strony pozwolą dostawcy SaaS skorzystać z efektu skali, a z drugiej sprawią, że zachowana będzie równowaga pomiędzy kosztem tworzenia rozwiązania a zyskiem.

SaaS czy S+S

Model SaaS zakłada, że klient ma zawsze dostęp do usługi (czyli zawsze jest podłączony do Internetu) i ufa dostawcy, że zawarta między nimi umowa SLA będzie spełniona. Jednak w wielu scenariuszach nie do końca jest to założenie prawdziwe i model SaaS przechodzi w S+S, czyli Software + Service. W zależności od typu rozwiązania i scenariusza biznesowego pewna funkcjonalność systemu informatycznego jest dostępna jako usługa, ale niezależnie od tego działa aplikacja kliencka offline, pozwalająca wykonać operacje bez konieczności podłączenia do sieci. Dodatkowo takie podejście pozwala zbudować wygodny interfejs użytkownika, bo nie jest on ograniczony przez możliwości przeglądarek internetowych. Obecnie technologie automatycznej aktualizacji sprawiają, że koszt wdrożenia i utrzymania takich systemów nie jest znacząco wyższy niż aplikacji WWW.

Najprostszym przykładem S+S są różnego rodzaju serwisy aktualizacyjne, gdzie np. pobierany jest nowy kod rozwiązania, aktualne przepisy, stawki oprocentowania itp., które służą głównej aplikacji zainstalowanej w komputerze. Innym przykładem są gry wieloosobowe - z jednej strony są instalowane lokalnie, ale dopiero po podłączeniu do serwera gracze mogą współzawodniczyć ze sobą. Rozwiązaniem S+S może być także mobilny system gromadzenia zamówień, który pracuje offline, ale aby ostatecznie potwierdzić zamówienie i zaalokować towar, musi synchronizować się z centralnym serwerem.

Tomasz Kopacz współpracuje z Computerworld od 1995 r. Prowadzi blog Digger pod adresem digger.computerworld.pl. Obecnie pracuje w Microsoft na stanowisku Senior Architect Evangelist.