Specyfikacja interfejsu aplikacji
Specyfikacja interfejsu aplikacji ( AIS ) to zbiór otwartych specyfikacji definiujących interfejsy programowania aplikacji (API) dla aplikacji komputerowych o wysokiej dostępności. Jest rozwijany i publikowany przez Service Availability Forum (SA Forum) i udostępniany bezpłatnie. Poza zmniejszeniem złożoności aplikacji o wysokiej dostępności i skróceniem czasu opracowywania, specyfikacje miały na celu ułatwienie przenoszenia aplikacji między różnymi implementacjami oprogramowania pośredniego oraz umożliwienie zewnętrznym programistom dostępu do dziedziny, która w przeszłości była wysoce zastrzeżona.
Historia
AIS jest częścią Service Availability Interfaces (SAI) SA Forum. Oryginalne specyfikacje, opublikowane 14 kwietnia 2003 r., To Availability Management Framework (AMF), Cluster Membership Service (CLM) i cztery inne usługi użytkowe (Checkpoint, Event, Message, Lock).
Dodatkowe usługi zostały dodane w kolejnych wersjach.
- Wersja 3 (18 stycznia 2006) dodała pierwszy zestaw usług zarządzania: Log, Notification and Information Model Management (IMM).
- Wersja 4 (27 lutego 2007) rozszerzyła usługi narzędziowe o Timer i Naming.
- Wersja 5 (16 października 2007) rozszerzyła usługi zarządzania o Security i dodała Software Management Framework.
- Wersja 6 (21 października 2008) dodała usługę zarządzania platformą, aby wypełnić lukę między AIS i HPI ( interfejs platformy sprzętowej ).
AIS składa się z 12 usług i dwóch platform. Usługi są podzielone na trzy grupy funkcjonalne — usługi platformy AIS, podstawowe usługi zarządzania AIS i ogólne usługi narzędziowe AIS — oprócz ram AIS.
Początkowo interfejsy API były definiowane wyłącznie w języku programowania C , ale od lipca 2008 r. mapowanie Java różnych interfejsów API usług jest udostępniane stopniowo.
Zależności usługi
Różne usługi i ramy specyfikacji interfejsu zostały zaprojektowane tak, aby były modułowe i do pewnego stopnia niezależne od siebie. Pozwala to na istnienie systemu dostarczającego tylko AIS i żadnego HPI i vice versa.
Jedyną wymaganą zależnością architektoniczną jest zależność od usługi członkostwa w klastrze (CLM). Wszystkie usługi AIS, z wyjątkiem usługi zarządzania platformą (PLM) i usługi timera (TMR), zależą od CLM.
Oczekuje się, że wszystkie usługi AIS powinny korzystać z usług zarządzania AIS w celu udostępnienia swoich interfejsów administracyjnych, konfiguracji i informacji o zarządzaniu środowiskiem wykonawczym (rys. 2).
Usługi platformy
Usługa zarządzania platformą (PLM) zapewnia logiczny widok sprzętu i oprogramowania niskiego poziomu systemu. W tym sensie oprogramowanie niskiego poziomu obejmuje system operacyjny i warstwy wirtualizacji, które zapewniają środowiska wykonawcze dla wszelkiego rodzaju oprogramowania.
Główne jednostki logiczne zaimplementowane przez PLM to:
- Element sprzętowy (HE) — element sprzętowy jest jednostką logiczną reprezentującą dowolny rodzaj jednostki sprzętowej, którą może być na przykład obudowa, moduł procesora typu blade lub urządzenie we/wy. Zazwyczaj wszystkie jednostki wymienialne w terenie (FRU) są modelowane jako elementy sprzętowe.
- Środowisko wykonawcze (EE) — środowisko wykonawcze to jednostka logiczna reprezentująca środowisko zdolne do uruchamiania niektórych programów. Na przykład kaseta procesora lub SMP uruchamia pojedynczą instancję systemu operacyjnego modelowaną jako środowisko wykonawcze. Obsługiwane są różne architektury wirtualizacji (rys. 4).
PLM utrzymuje stan tych jednostek w modelu informacyjnym i zapewnia środki do ich kontrolowania i śledzenia wszelkich zmian stanu. Aby wykonać te zadania dla uczelni, usługa PLM zazwyczaj wykorzystuje HPI. W przypadku EE PLM odpowiada za pobieranie wszystkich niezbędnych informacji o kondycji systemu operacyjnego i każdej dostępnej warstwie wirtualizacji.
Cluster Membership Service (CLM) udostępnia aplikacjom informacje o członkostwie węzłów, które zostały skonfigurowane administracyjnie w konfiguracji klastra (te węzły są również nazywane węzłami klastra lub skonfigurowanymi węzłami) i stanowi rdzeń każdego systemu klastrowego. Klaster składa się z tego zestawu skonfigurowanych węzłów, z których każdy ma unikalną nazwę węzła.
Dwie jednostki logiczne zaimplementowane przez usługę członkostwa w klastrze to:
- Klaster — reprezentuje sam klaster i jest obiektem nadrzędnym obiektów węzła klastra.
- Węzeł klastra — reprezentuje skonfigurowany węzeł klastra.
Produkt CLM udostępnia interfejsy API umożliwiające pobieranie bieżących informacji o członkostwie w klastrze i śledzenie zmian w członkostwie (np. opuszczenie węzła, dołączenie do węzła). Wszystkie usługi AIS obejmujące cały klaster muszą używać interfejsu API śledzenia produktu CLM w celu określenia członkostwa.
Usługi zarządzania
Różne podmioty zaimplementowane przez usługi AIS (np. środowiska wykonawcze, punkty kontrolne, komponenty itp.) są reprezentowane jako obiekty zarządzane w SA Forum Information Model (IM), który można postrzegać jako bazę danych zarządzania konfiguracją . Obiekty zarządzane to instancje klas obiektów zdefiniowanych przez odpowiednią specyfikację usługi AIS, która definiuje atrybuty klas i operacje administracyjne. Operacje administracyjne określone dla klas obiektów reprezentują operacje, które można wykonać na jednostkach reprezentowanych przez obiekty, np. blokowanie jednostki usługowej lub eksportowanie zawartości komunikatora internetowego w formacie XML. Obiekty w IM są przechowywane w hierarchii drzewa, w której obiekt może mieć co najwyżej jeden obiekt nadrzędny i dowolną liczbę obiektów podrzędnych.
Jednostki logiczne reprezentowane przez obiekty w IM generalnie nie są implementowane przez samą usługę IMM; zamiast tego aplikacje użytkownika i usługi AIS, takie jak Checkpoint Service lub Availability Management Framework zapewniają ich implementację. Dlatego są one nazywane implementatorami obiektów (OI). Do celów zarządzania wszystkie usługi AIS udostępniają zaimplementowane jednostki jako obiekty zarządzane za pośrednictwem usługi IMM.
Istnieją dwie kategorie obiektów i atrybutów w IM: środowisko wykonawcze i konfiguracja.
Obiekty i atrybuty środowiska wykonawczego odzwierciedlają aktualny stan podmiotów, które reprezentują – mają charakter opisowy .
Z kolei obiekty i atrybuty konfiguracyjne mają charakter nakazowy , ponieważ w przypadku aplikacji do zarządzania — lub menedżerów obiektów (OM) — są one środkiem dostarczania danych wejściowych do osób wdrażających obiekty, które jednostki muszą zaimplementować.
Obiekty konfiguracyjne mogą zawierać zarówno atrybuty konfiguracyjne, jak i wykonawcze, podczas gdy obiekty wykonawcze mogą zawierać tylko atrybuty wykonawcze. Operacje administracyjne można definiować na obu kategoriach obiektów.
W związku z tym usługa IMM udostępnia interfejs „ południowy ” – IMM-OI API – dla implementatorów obiektów oraz interfejs „ północny ” – IMM-OM API – dla aplikacji zarządzających (rys. 5), np. agentów SNMP, i pośredniczy między te dwie partie. Jest również odpowiedzialny za przechowywanie trwałych obiektów i atrybutów.
Dziennik
Usługa dziennika jest przeznaczona do rejestrowania zdarzeń , czyli do zbierania obejmujących cały klaster, opartych na funkcjach (w przeciwieństwie do konkretnych implementacji) informacji o systemie, które są odpowiednie dla administratorów systemu lub zautomatyzowanych narzędzi.
Usługa dziennika umożliwia aplikacjom wyrażanie i zapisywanie rekordów dziennika za pośrednictwem strumieni dziennika, które prowadzą do określonych miejsc docelowych danych wyjściowych, takich jak nazwany plik. Po dotarciu do miejsca docelowego rekord dziennika podlega regułom formatowania danych wyjściowych, które są konfigurowalne i publiczne. Aplikacja rejestrująca nie musi znać żadnego z tych aspektów (np. lokalizacji pliku docelowego, rotacji lub formatowania pliku itp.), ponieważ Usługa dziennika obsługuje je na podstawie bieżących ustawień docelowego strumienia dziennika. Ponieważ format wyjściowy jest publiczny, narzędzia innych firm mogą odczytywać te pliki dziennika.
Określono cztery typy strumieni dziennika: alarm (zapisy dziennika oparte na ITU X.733 i ITU X.736), powiadomienia (zapisy dziennika oparte na ITU X.730 i ITU X.731), system i aplikacja . Typ aplikacji jest używany przez aplikacje do definiowania strumieni dziennika specyficznych dla aplikacji. W klastrze SA Forum istnieje dokładnie jeden predefiniowany strumień dziennika dla każdego typu strumienia dziennika alarmu, powiadomienia i dziennika systemowego. Aplikacje użytkownika mogą używać dowolnego z predefiniowanych strumieni lub tworzyć nowe strumienie dziennika specyficzne dla aplikacji.
Powiadomienie
Usługa powiadamiania jest - w dużym stopniu - oparta na modelu zarządzania awariami ITU-T (jak można znaleźć w serii dokumentów X.700), jak również na wielu innych pomocniczych zaleceniach.
Usługa powiadomień koncentruje się na koncepcji powiadomienia , które wyjaśnia incydent lub zmianę statusu. Termin „powiadomienie” jest używany zamiast „zdarzenia”, aby wyraźnie odróżnić je od „zdarzenia” zgodnie z definicją usługi AIS Event Service.
Usługa NTF jest oparta na paradygmacie publikowania-subskrybowania . Definiuje sześć typów powiadomień: alarm, alarm bezpieczeństwa, utworzenie/usunięcie obiektu, zmiana stanu, zmiana wartości atrybutu i różne. Powiadomienia są generowane/publikowane przez producentów za pomocą API producenta powiadomień. Odbiorcami powiadomień mogą być albo subskrybenci , którzy subskrybują powiadomienia i otrzymują je w miarę ich pojawiania się; lub czytelników , którzy pobierają powiadomienia z utrwalonych dzienników za pomocą interfejsu API konsumentów powiadomień. Konsumenci obu typów powiadomień mogą definiować filtry, które określają cechy powiadomień, którymi są zainteresowani otrzymywaniem lub czytaniem.
Powiadomienia mogą być generowane zarówno przez Usługi AIS, jak i przez aplikacje. Usługi AIS generujące powiadomienia mają sekcję w specyfikacji opisującą ich powiadomienia.
Bezpieczeństwo
Usługa bezpieczeństwa zapewnia mechanizmy, które mogą być wykorzystywane przez AIS Services do uwierzytelniania procesów klienckich usługi AIS (i potencjalnie innych) w ramach klastra oraz do autoryzacji ich do wykonywania określonych czynności. Mechanizmy te mogą służyć do zachowania integralności infrastruktury wysokiej dostępności i aplikacji SA Forum, w tym ich danych, poprzez ochronę przed nieautoryzowanym dostępem.
Egzekwowanie bezpieczeństwa jest delegowane do samych implementacji usługi AIS: usługi AIS z włączonymi zabezpieczeniami żądają autoryzacji od implementacji SEC w imieniu swoich procesów klienckich, gdy inicjują różne działania. SEC odpowiada na te prośby o autoryzację, wskazując przyznanie lub odmowę, a do usługi AIS należy odpowiednie zezwolenie lub odrzucenie operacji. SEC zapewnia te wskazania w oparciu o zestaw zasad bezpieczeństwa skonfigurowanych za pośrednictwem IMM. Informuje również swoich abonentów o zmianach polityki za pomocą odpowiednich wywołań zwrotnych.
Ramy
Struktura zarządzania dostępnością
Struktura zarządzania dostępnością zapewnia dostępność usług w systemach zgodnych z SA Forum. Koordynuje pracę poszczególnych kontrolowanych przez siebie podmiotów w zależności od ich stanu gotowości do świadczenia usług. W tym celu aplikacja musi zostać opisana zgodnie z modelem informacyjnym określonym dla AMF. Ten model opisuje, które zasoby należą do aplikacji w ramach klastra i jakie usługi zapewnia aplikacja.
Podstawową jednostką logiczną tego modelu informacyjnego jest komponent , który reprezentuje zestaw zasobów dla Availability Management Framework, które hermetyzują niektóre specyficzne funkcje aplikacji. Obciążenie generowane przez udostępnianie niektórych usług, które mogą być przypisane do komponentu przez AMF, jest reprezentowane jako wystąpienie usługi składnika (CSI) . Gdy komponent aktywnie świadczy usługę, przypisywany jest mu stan aktywny w imieniu CSI reprezentującego usługę.
Podstawową zasadą projektowania odpornego na błędy jest świadczenie usług przez zestaw redundantnych jednostek , dlatego też komponenty muszą działać jako rezerwowe w imieniu CSI. Komponenty rezerwowe utrzymują się w stanie umożliwiającym przejęcie realizacji usługi w przypadku awarii komponentu z aktywnym przydziałem. Rolą AMF jest przypisywanie aktywnych lub rezerwowych obciążeń do komponentów aplikacji w zależności od stanu komponentu i konfiguracji systemu.
W związku z tym interfejsy API udostępniane przez Availability Management Framework umożliwiają rejestrację komponentów, zarządzanie cyklem życia i przypisywanie obciążeń. Obejmują one funkcje raportowania błędów i monitorowania stanu. Umożliwiają również śledzenie przydziału instancji usługi komponentowej wśród zbioru komponentów chroniących CSI.
Konfiguracja struktury zarządzania dostępnością obejmuje zasady odzyskiwania i naprawy. Umożliwia ustalanie priorytetów zasobów i zapewnia różnorodne modele redundancji. Obejmują one od prostego modelu 2N (znanego również jako 1+1 lub aktywna rezerwa) do bardziej zaawansowanych, takich jak model redundancji N-drożnej, który pozwala na więcej niż jedno przypisanie rezerwy w imieniu tej samej instancji usługi składowej lub N-way-active, który umożliwia wiele aktywnych przypisań.
Aby uprościć administrację, AMF dodatkowo grupuje komponenty w jednostki usługowe i grupy usług, a instancje usług komponentów w instancje usług. Wszystko to składa się na aplikację. Za pośrednictwem IMM dostępny jest zestaw operacji administracyjnych na tych jednostkach logicznych.
Na potrzeby zarządzania oprogramowaniem podmioty korzystające z tego samego oprogramowania są pogrupowane w typy, co pozwala na jednopunktowy wpis do konfiguracji tych podmiotów.
Struktura zarządzania oprogramowaniem
System zgodny z SA Forum można scharakteryzować za pomocą konfiguracji wdrożenia, na którą składa się oprogramowanie wdrożone w systemie wraz ze wszystkimi skonfigurowanymi jednostkami oprogramowania. Konfiguracja wdrożenia stanowi istotną część modelu informacyjnego zarządzanego przez usługę IMM.
Struktura zarządzania oprogramowaniem (SMF) utrzymuje część modelu informacyjnego, która opisuje oprogramowanie dostępne dla klastra i wdrożone w nim. Ale głównym celem SMF jest umożliwienie ewolucji działającego systemu poprzez zorganizowanie migracji z jednej konfiguracji wdrożenia do innej. W terminologii SMF ten proces migracji nazywa się kampanią uaktualniającą .
Struktura zarządzania oprogramowaniem definiuje schemat XML, który ma być używany do określania kampanii aktualizacji. Implementacja SMF migruje system z jednej konfiguracji wdrożeniowej do nowej pożądanej na podstawie takiego pliku XML, który jest zasadniczo skryptem uporządkowanych działań i zmian konfiguracyjnych prowadzących do nowej konfiguracji.
Podczas tej migracji SMF
- utrzymuje model stanu kampanii,
- monitoruje potencjalne błędy spowodowane migracją oraz
- wdraża procedury odzyskiwania błędów zgodnie z wymaganiami.
Aby wykonać wszystkie te zadania, implementacja SMF współdziała co najmniej (1) z AMF w celu utrzymania dostępności, (2) z IMM w celu przeprowadzenia zmian w modelu informacji oraz (3) z NTF w celu otrzymywania powiadomień, które mogą wskazywać na błąd sytuacji spowodowanych trwającą kampanią.
Software Management Framework zapewnia również interfejs API dla procesów klienckich, który rejestruje ich zainteresowanie otrzymywaniem wywołań zwrotnych, gdy w klastrze rozpoczynana jest odpowiednia kampania aktualizacyjna i gdy przechodzi ona przez ważne kamienie milowe. Pozwala to na koordynację działań specyficznych dla aplikacji z aktualizacją. Może to obejmować proste blokowanie inicjacji kampanii aktualizacji, gdy aplikacja wykonuje jakieś krytyczne zadanie, do koordynowania akcji aktualizacji na poziomie aplikacji, takiej jak aktualizacja schematu bazy danych lub wdrażanie nowych protokołów.
Dla dostawców oprogramowania dostarczających aplikacje do wdrożenia w klastrze SA Forum, Software Management Framework definiuje również schemat XML dla pliku typów jednostek , który opisuje typy jednostek oprogramowania zaimplementowane przez aplikację. Te informacje są używane do tworzenia odpowiednich konfiguracji wdrożenia.
Usługi komunalne
Punkt kontrolny
Usługa punktu kontrolnego umożliwia procesom przyrostowe rejestrowanie danych punktu kontrolnego , co może służyć do ochrony aplikacji przed awariami. Kiedy proces wraca do zdrowia po awarii (z ponownym uruchomieniem lub przełączania awaryjnego ), usługa punktu kontrolnego może zostać wykorzystana do odzyskania danych z punktu kontrolnego i wznowienia wykonywania od zarejestrowanego stanu, minimalizując w ten sposób wpływ awarii.
Punkty kontrolne to jednostki obejmujące cały klaster. Kopia danych przechowywana w punkcie kontrolnym jest nazywana repliką punktu kontrolnego, która ze względu na wydajność jest zwykle przechowywana w pamięci głównej, a nie na dysku. Punkt kontrolny może mieć kilka replik punktów kontrolnych przechowywanych w różnych węzłach w klastrze, aby chronić go przed awariami węzłów. Proces tworzący punkt kontrolny może wybierać między synchronicznymi a asynchronicznymi zasadami aktualizacji replik. W przypadku replikacji asynchronicznej można również wybrać kolokację, aby zoptymalizować wydajność aktualizacji.
Wydarzenia
Usługa zdarzeń to mechanizm komunikacji między wieloma punktami do publikowania/subskrybowania oparty na koncepcji kanałów zdarzeń: co najmniej jeden wydawca komunikuje się asynchronicznie z co najmniej jednym anonimowym subskrybentem za pomocą zdarzeń w kanale zdarzeń. Kanały zdarzeń to nazwane jednostki w całym klastrze, które zapewniają najlepsze dostarczanie zdarzeń. Wydawcy mogą być również subskrybentami tego samego kanału wydarzeń.
Zdarzenia składają się ze standardowego nagłówka i zero lub więcej bajtów opublikowanych danych zdarzenia. Interfejs Event Service API nie narzuca określonego układu publikowanych danych zdarzeń.
Gdy proces zasubskrybuje kanał zdarzeń w celu otrzymywania opublikowanych zdarzeń, określa filtry, które mają zostać zastosowane do opublikowanych zdarzeń. Zdarzenia są dostarczane do procesu tylko wtedy, gdy spełniają podane filtry.
Zamki
Usługa blokowania to rozproszona usługa blokowania , która jest przeznaczona do użytku w klastrze, w którym procesy w różnych węzłach mogą konkurować ze sobą o dostęp do współdzielonego zasobu. Dla nich Usługa Blokady zapewnia podmioty zwane zasobami blokady, których z kolei procesy aplikacji używają do koordynowania dostępu do tych współdzielonych zasobów.
Usługa blokowania zapewnia prosty model blokady obsługujący jeden tryb blokowania dla dostępu wyłącznego i inny dla dostępu współdzielonego. Blokady zapewniane przez Usługę Blokowania są nierekurencyjne. Zatem zajęcie jednego zamka nie oznacza niejawnego załączenia innego zamka; raczej każdy zamek musi być zgłaszany indywidualnie.
Wiadomości
systemu komunikacji między procesami obejmującego cały klaster . Komunikacja jest oparta na kolejkach komunikatów identyfikowanych przez nazwę logiczną. Dowolna liczba procesów może wysyłać komunikaty do kolejki komunikatów, ale najwyżej jeden proces na raz może otworzyć ją do odbioru. Pojedyncza kolejka komunikatów obsługuje zatem punkt-punkt lub wiele punktów-punkt.
Procesy wysyłające komunikaty do kolejki komunikatów nie są świadome tożsamości procesu odbierającego; w związku z tym proces, który pierwotnie odbierał te komunikaty, mógł zostać zastąpiony innym procesem podczas przełączania awaryjnego lub przełączania.
Kolejki komunikatów można grupować, tworząc grupy kolejek komunikatów. Grupy kolejek komunikatów umożliwiają komunikację między wieloma punktami. Są one identyfikowane za pomocą nazw logicznych, dzięki czemu proces wysyłający nie jest świadomy liczby kolejek komunikatów ani lokalizacji kolejek komunikatów w klastrze, z którym się komunikuje. Grupy kolejek komunikatów mogą być używane do dystrybucji komunikatów między kolejkami komunikatów należącymi do grupy kolejek komunikatów. MSG definiuje trzy zasady dystrybucji emisji pojedynczej – równą dystrybucję obciążenia, lokalną równą dystrybucję obciążenia i lokalną najlepszą kolejkę – oraz politykę emisji ( multicast ).
Usługa komunikatów zapewnia na żądanie różne gwarancje doręczenia (np. potwierdzenie, trwałość komunikatu itp.) w kolejkach komunikatów iw grupach kolejek komunikatów emisji pojedynczej.
Nazewnictwo
Usługa nazewnictwa zapewnia mechanizm, za pomocą którego nazwy przyjazne dla człowieka są kojarzone z obiektami („powiązane z”), dzięki czemu obiekty te można wyszukiwać na podstawie ich nazw. Obiekty zazwyczaj reprezentują punkty dostępu do usług, punkty końcowe komunikacji i inne zasoby, które zapewniają jakiś rodzaj usługi.
Usługa nazewnictwa nie narzuca ani określonego układu, ani konwencji nazw ( zakłada się kodowanie UTF-8 ) ani obiektów, z którymi są powiązane. Pozwala użytkownikom serwisu wybrać i używać własnego schematu nazewnictwa bez zakładania określonej konfiguracji sprzętowej lub logicznej oprogramowania. Oczekuje się, że klienci usługi nazewnictwa będą rozumieć strukturę, układ i semantykę powiązań obiektów, które zamierzają przechowywać w usłudze i pobierać z usługi.
Timery
Usługa licznika czasu zapewnia mechanizm, za pomocą którego procesy klienta mogą ustawiać liczniki czasu i otrzymywać powiadomienia o wygaśnięciu licznika czasu. Licznik czasu to obiekt logiczny, który jest tworzony dynamicznie i reprezentuje czas wygaśnięcia jako czas bezwzględny lub czas trwania liczony od bieżącego czasu.
Usługa licznika czasu udostępnia dwa typy liczników czasu: liczniki pojedynczych zdarzeń i czasomierze okresowe. Pojedyncze liczniki zdarzeń wygasają raz i są usuwane po powiadomieniu. Okresowe liczniki czasu wygasają za każdym razem, gdy zostanie osiągnięty określony czas trwania, a proces jest powiadamiany o wygaśnięciu. Czasomierze okresowe muszą być jawnie usuwane przez wywołanie funkcji usuwania licznika czasu.
Model programowania
Wszystkie usługi AIS mają ten sam model programowania. W całej specyfikacji używane są te same konwencje nazewnictwa, standardowe predefiniowane typy i stałe, semantyka API, kontrola cyklu życia biblioteki itp.
SA Forum Application Interface występuje pomiędzy procesem a biblioteką, która implementuje ten interfejs. Interfejs jest przeznaczony do użytku zarówno przez wielowątkowe, jak i jednowątkowe procesy aplikacji. Termin „proces” można uznać za odpowiednik procesu zdefiniowanego przez standard POSIX; jednak AIS nie wymaga POSIX , ale raczej jakąkolwiek równoważną jednostkę, którą system zapewnia do zarządzania wykonywanym oprogramowaniem.
Serwer obszaru to abstrakcja reprezentująca serwer, który świadczy usługi dla obszaru specyfikacji (Availability Management Framework, Cluster Membership Service, Checkpoint Service itd.). Każdy obszar ma oddzielny serwer obszaru logicznego, chociaż osoba wdrażająca może utworzyć oddzielny moduł fizyczny dla każdego serwera obszaru lub połączyć jeden lub więcej serwerów obszaru w jeden moduł fizyczny.
Biblioteki implementacji obszaru mogą być zaimplementowane w jednej lub kilku bibliotekach fizycznych; jednakże do zainicjowania, zarejestrowania i uzyskania obiektu wyboru systemu operacyjnego wymagany jest proces oddzielnie dla biblioteki implementacji każdego obszaru. Dlatego z programistycznego punktu widzenia warto traktować je jako oddzielne biblioteki.
Model użytkowania jest typowy dla architektury sterowanej zdarzeniami, w której aplikacja przeprowadza konfigurację, a następnie odbiera wywołania zwrotne w przypadku wystąpienia zdarzeń (rys. 6).
Korzystanie z biblioteki Service Availability rozpoczyna się od wywołania inicjalizacji biblioteki, która potencjalnie ładuje dowolny kod dynamiczny i wiąże wywołania asynchroniczne realizowane przez proces. Gdy proces nie wymaga już korzystania z funkcji obszaru, wywołuje funkcję finalizacji obszaru, która odłącza proces od instancji implementacji obszaru interfejsu i odzyskuje wszelkie powiązane zasoby.
AIS wykorzystuje zarówno modele programowania synchronicznego, jak i asynchronicznego. Synchroniczne interfejsy API są zwykle używane w interfejsach zarządzania bibliotekami i stowarzyszeniami. Wiele usług AIS zapewnia możliwość śledzenia zmian w encjach, które wdrażają. Ścieżka API zazwyczaj składa się z trzech funkcji: wywołanej przez klienta inicjacji i zatrzymania śledzenia jednostki; oraz wywołanie zwrotne wywołane przez usługę w celu powiadomienia klienta o (oczekujących) zmianach śledzonej jednostki.
Kompatybilność wsteczna
Aby osiągnąć kompatybilność wsteczną podczas opracowywania specyfikacji AIS, należy przestrzegać kilku zasad:
- Definicja funkcji lub typu nigdy nie zmienia się dla określonej wersji SA Forum.
- Zmiany w definicji funkcji lub typu (dodanie nowego argumentu do funkcji, dodanie nowego pola do struktury danych) wymuszają zdefiniowanie nowej nazwy funkcji lub typu. Nowa nazwa funkcji lub typu jest tworzona na podstawie oryginalnej nazwy z poprzedniej wersji z sufiksem wskazującym wersję, w której funkcja/typ uległy zmianie (na przykład saAmfComponentRegister_3()).
- Jako wyjątek od poprzedniej reguły, nowe wartości wyliczeniowe, wartości flag lub pola unii mogą być dodawane do istniejącego typu wyliczenia, flagi lub unii bez zmiany nazwy typu, o ile rozmiar wyliczenia, flagi lub unii rodzaj się nie zmienia.
- Implementatorzy AIS muszą upewnić się, że przestrzegają numerów wersji dostarczonych przez aplikację podczas inicjowania biblioteki i nie ujawniają nowych wartości wyliczeniowych aplikacjom korzystającym ze starszych wersji.
- Osoby wdrażające AIS muszą również zapewnić przestrzeganie numerów wersji dostarczonych przez aplikację podczas inicjalizacji biblioteki w odniesieniu do nowych lub zmodyfikowanych kodów błędów i nie ujawniać aplikacjom kodów błędów, które dotyczą tylko funkcji w najnowszej wersji specyfikacji zapisane w starszej wersji specyfikacji.
Jako przykład rozważmy majorVersion Vx danej usługi, która zawiera funkcję f() i załóżmy, że f() musiało zostać zmodyfikowane w nowszej majorVersion Vy (Vy > Vx), co doprowadziło do wprowadzenia f_y( ) wariant, który teraz zastępuje f() w Vy.
Biorąc pod uwagę implementację AIS, która obsługuje obie wersje Vx i Vy, proces może zainicjować bibliotekę, określając Vx lub Vy:
- jeśli proces inicjalizuje uchwyt biblioteki za pomocą Vx, uchwyt ten nie zapewnia dostępu do funkcji, które zostały wprowadzone w wersjach nowszych niż Vx. W szczególności ten uchwyt nie umożliwi procesowi pomyślnego wywołania f_y()
- jeśli proces inicjalizuje uchwyt biblioteki za pomocą Vy, uchwyt ten nie zapewnia dostępu do funkcji wprowadzonej w wersjach starszych niż Vy, a następnie zastąpionej nowszym wariantem tej samej funkcji. W szczególności ten uchwyt nie umożliwi procesowi pomyślnego wywołania funkcji f().
Należy jednak zauważyć, że proces może wielokrotnie inicjować bibliotekę za każdym razem z wersją odpowiednią do funkcjonalności, którą zamierza uzyskać.
Dokument specyfikacji usługi AIS dla Vy zawiera tylko najnowszy wariant definicji funkcji lub typu obsługiwanej przez Vy.
Wersje specyfikacji są wersjonowane jako: . .
Kod wydania to wielka litera. Kompatybilność wsteczna jest utrzymywana tylko między wersjami tego samego kodu wydania. Wersja główna i wersja pomocnicza to numery przyrostowe. Wersje z dużymi zmianami numerów mogą wprowadzać nowe funkcje i zmieniać interfejs API w sposób zgodny z poprzednimi wersjami, jak opisano powyżej. Wersje z niewielką zmianą numeru nie powodują zmiany interfejsu API. Zapewniają poprawki błędów, zmiany redakcyjne i wyjaśnienia swojego poprzednika.
Rejestr wdrożeń
Rejestr implementacji SA Forum to proces, który umożliwia rejestrację i publiczne udostępnianie implementacji specyfikacji SA Forum. Członkostwo nie jest wymagane do rejestracji wdrożeń. Wdrożenia, które zostały pomyślnie zarejestrowane, mogą być określane jako „Zarejestrowane forum dostępności usług”.