Powiedzmy, że Twoja strona właśnie uruchomiła ogromną międzynarodową promocję. Trzeba utworzyć strony, przechowywać nowe zasoby, a klienci szturmują Twoją witrynę. A potem… Twoja strona się poddaje. To ostatnia rzecz, jakiej potrzebujesz.
Aby Twój system zarządzania stroną radził sobie płynnie niezależnie od obciążenia, potrzebuje architektury, która działa jak dobrze naoliwiona maszyna. Ale jeśli nie masz pewności, jak wygląda architektura Twojej strony, trudno ocenić jej odporność.
Funkcje AEM oferują architekturę zdolną do rozwoju wraz z Tobą i są doskonałym przykładem tej dobrze naoliwionej maszyny. Więc przyjrzyjmy się jej pod lupą i zobaczmy, co ją napędza!
Architektura AEM: Podstawowy przegląd
Patrząc szeroko na architekturę Adobe Experience Manager, platforma składa się z czterech podstawowych komponentów architektonicznych:
- Autor
- Publikator
- Dyspozytor
- Moduł równoważenia obciążenia
Komponenty te współpracują ze sobą, aby zapewnić płynne uruchamianie nowej zawartości strony oraz bezproblemowe i szybkie ładowanie dla użytkowników Twojej witryny.
Nie będziemy zagłębiać się w szczegóły techniczne, ale przyjrzyjmy się z wysokiego poziomu, za co odpowiada każdy z tych komponentów.
Autor
Warstwa autorska AEM to miejsce, w którym pracuje Twój zespół produkujący treści. Zasadniczo jest to środowisko, w którym wszystkie Twoje strony internetowe będą tworzone, organizowane i aktualizowane. To także tutaj będą przesyłane wszystkie media, których planujesz użyć na swojej stronie, takie jak obrazy, filmy itp.
Warstwa autorska nigdy nie jest widoczna dla użytkowników końcowych, co oznacza, że wszystko, nad czym tu pracujesz, jest niewidoczne, dopóki nie zdecydujesz się tego zatwierdzić i opublikować. Daje to twórcom treści swobodę w kształtowaniu i przekształcaniu, pisaniu i przepisywaniu, projektowaniu i przeprojektowywaniu, aż stworzą stronę, którą będą gotowi zaprezentować swoim klientom.
Publikacja
Jeśli szukasz tej części AEM, którą widzą odwiedzający Twoją witrynę, to jest właśnie to. Warstwa publikacji to miejsce, w którym znajduje się cała zatwierdzona i gotowa treść Twojej witryny, dostępna publicznie.
Po zatwierdzeniu czegoś do publikacji w warstwie autorskiej, przejdzie to do warstwy publikacji i będzie dostępne dla każdego.
Dyspozytor
Prawdopodobnie jedna z najważniejszych funkcji architektury AEM, dyspozytorzy są odpowiedzialni za kierowanie ruchu w Twojej witrynie ścieżkami, które zapewniają najszybsze działanie witryny.
Dyspozytorzy wykonują dwa główne zadania, które pomagają Twojej witrynie działać tak szybko, jak to możliwe: Buforowanie i równoważenie obciążenia.
Dyspozytor buforuje stronę po pierwszej wizycie użytkownika. Kolejni odwiedzający otrzymują wersję z bufora. Odbywa się to w celu przyspieszenia działania Twojej witryny i zmniejszenia bezpośredniego obciążenia serwerów.
Dodatkowo, dyspozytorzy równomiernie rozłożą ruch sieciowy kierowany do serwerów, aby żaden serwer nie został przeciążony żądaniami.
Równoważnik obciążenia
Oprócz zadań równoważenia obciążenia realizowanych przez dyspozytora, istnieje dodatkowy równoważnik obciążenia, który równomiernie rozprasza ruch twórców treści i użytkowników końcowych pomiędzy instancje autorskie, publikacyjne i dyspozytorów (gdy jest ich wiele).
Różnice w architekturze AEM as a Cloud Service
Architektura AEM Cloud Service ma podobieństwa do AEM 6.5 (lokalnie), ale ma również zauważalne różnice.
Te różnice można zaobserwować zarówno w architekturze środowiska uruchomieniowego AEM (wewnętrzne zachowanie oprogramowania z jego komponentami), jak i w architekturze wdrożeniowej (sposób zmiany kodu oprogramowania).
Przyjrzyjmy się szybko, jak architektury środowiska uruchomieniowego i wdrożeniowego są skonfigurowane konkretnie w AEM as a Cloud Service.
Architektura środowiska uruchomieniowego
W AEMaaCS istnieją “warstwy” autora, wydawcy i dyspozytora, tak jak w klasycznym AEM. W każdej warstwie może istnieć wiele instancji autora, wydawcy i dyspozytora. Zazwyczaj każda warstwa ma minimum dwie instancje.
Jedną z głównych różnic i zalet architektury AEM Cloud jest to, że te instancje autora, wydawcy i dyspozytora mogą nieskończenie skalować się wraz z zapotrzebowaniem wynikającym z ruchu na Twojej stronie.
Kolejną istotną różnicą w architekturze AEMaaCS jest włączenie dedykowanej “warstwy podglądu.” To tutaj cała zawartość, którą twórcy przygotowują w warstwie autora, może zostać wyświetlona w podglądzie przed ostateczną publikacją. Posiadanie oddzielnej warstwy dla tego procesu sprawia, że przeglądanie zmian na stronie i nowych stron jest łatwiejsze i szybsze.
Architektura wdrożeniowa
Architektura wdrożeniowa AEMaaCS działa bardzo odmiennie niż w klasycznym AEM. Ta całkowicie nowa funkcjonalność przyczynia się do jednej z największych zalet AEMaaCS: Brak przestojów.
Niezależnie od tego, czy wprowadzasz aktualizacje kodu swojej aplikacji AEMaaCS, czy to Adobe wdraża automatyczne aktualizacje, proces jest taki sam:
- Cloud Manager utworzy nową (nieopublikowaną) wersję Twojej aplikacji.
- Zmiany w kodzie zostaną wprowadzone do tej nowej wersji.
- Rygorystyczne testy będą uruchamiane automatycznie w tle, aby upewnić się, że wszystko działa poprawnie w zaktualizowanej wersji.
- Następnie Cloud Manager przełącza się na nową wersję.
Podczas przełączania na nową wersję aplikacji AEM, Cloud Manager wykorzystuje wzorzec stopniowej aktualizacji. Oznacza to, że jednocześnie aktualizuje tylko kilka części aplikacji, dzięki czemu większość pozostałych części pozostaje aktywna i funkcjonalna.
Jest to wyraźnie odmienne od AEM 6.5, gdzie aktualizacje kodu muszą być wykonywane ręcznie i często stanowią skomplikowane zadania dla zespołu technicznego. Ponadto, aktualizacje AEM 6.5 zazwyczaj wymagają pewnego okresu przestoju, aby mogły zostać wdrożone. Jak można sobie wyobrazić, utrudnia to zapewnienie, że zawsze korzystasz z najnowszej wersji.
Architektura wdrożeniowa AEMaaCS w szczególności zapewnia, że zawsze masz najnowszą wersję oprogramowania, ponieważ Cloud Manager może automatycznie instalować aktualizacje oprogramowania w tle bez żadnych przerw.
Stos technologiczny AEM
Każda wspaniała platforma jest wspierana przez solidny stos frameworków i narzędzi, które pomagają jej działać bezproblemowo, a AEM nie jest wyjątkiem.
AEM wymagał specyficznego zestawu wiodących technologii ciężko pracujących, aby zapewnić stałą szybkość witryny, jej niezawodność oraz płynne tworzenie i publikowanie treści.
Zatem, bez dalszych ceregieli, rzucimy światło na niektórych z głównych graczy działających za kulisami.
Framework Apache Sling
Główną odpowiedzialnością Apache Sling w ramach AEM jest zarządzanie sposobem dostarczania treści witryny publiczności. Składa się to z kilku kluczowych funkcji:
- Udostępnianie użytkownikom strony internetowej, do której próbują uzyskać dostęp.
- Dopasowywanie prawidłowego adresu URL do prawidłowej strony internetowej.
- Ładowanie właściwej treści (obrazów, tekstu itp.) na stronę, na której ma się znajdować.
- Wprowadzanie zmian w istniejącej treści (utworzonej przez Twój zespół).
- Ochrona stron przeznaczonych wyłącznie dla wybranych osób przed nieautoryzowanymi użytkownikami.
- Dodawanie niestandardowych funkcji do platformy AEM.
Bez Apache Sling, AEM nie byłoby w stanie wyświetlać poprawnych stron, treści ani dopasowanych adresów URL nikomu, kto odwiedza Twoją witrynę, co czyni go integralnym elementem ogólnej funkcjonalności AEM.
Struktura OSGi
Podczas gdy Apache Sling zajmuje się dostarczaniem Twojej treści, OSGi zajmuje się kodem i zasobami, które umożliwiają ogólne działanie aplikacji AEM.
Grupujekomponenty rdzenia AEM w mniejsze, łatwiejsze do zarządzania pakiety, które w tym kontekście są plikami archiwum JavaScript. Utrzymuje również organizację i porządek między tymi pakietami.
OSGi utrzymuje porządek w kodzie AEM poprzez:
- Izolowanie pakietów od siebie, tak aby zmiany w jednym nie zakłócały działania innych.
- Ułatwianie dodawania i usuwania pakietów podczas działania AEM, bez konieczności ponownego uruchamiania.
- Monitorowanie usług świadczonych przez poszczególne pakiety, aby AEM mógł łatwiej je znaleźć i wykorzystać do realizacji potrzebnych funkcji.
- Przechowywanie alternatywnych wersji tego samego pakietu, aby AEM zachował kompatybilność wsteczną.
- Nadzorowanie zależności między pakietami i zapewnienie, że pakiety współzależne są używane razem.
- Zarządzanie aktywacją i dezaktywacją pakietów w całym ich cyklu życia.
Granite UI
W AEM, Granite UI to technologia, za pomocą której Twój zespół będzie tworzył różne interfejsy użytkownika na Twojej stronie. Stanowi ona podstawę w warstwie autorskiej i odpowiada za takie rzeczy jak:
- Dostarczanie narzędzi potrzebnych autorom treści do tworzenia niestandardowych komponentów w AEM.
- Strukturyzowanie, definiowanie i interpretowanie danych wejściowych z formularzy wbudowanych w Twoją witrynę.
- Konfigurowanie i zarządzanie dialogami, które są komponentami wchodzącymi w interakcję z użytkownikami witryny lub żądającymi od nich danych.
- Umożliwianie szerokiej personalizacji interfejsu użytkownika, dla łatwego dostosowania do unikalnych projektów.
- Usprawnianie procesu tworzenia treści poprzez zapewnienie bardziej przyjaznego dla użytkownika interfejsu.
Repozytorium Treści Java
W ramach swoich stron internetowych większość dużych firm może spodziewać się niemal nieskończonej biblioteki zasobów. A kiedy przesyłasz te zasoby do AEM, wszystkie muszą gdzieś trafić.
Na szczęście, właśnie do tego służy Java Content Repository (JCR). Repozytorium Treści Java w Adobe Experience Manager funkcjonuje jako Twój główny system przechowywania i organizacji dla każdego rodzaju zasobów, których możesz potrzebować na swojej stronie. Obejmuje to obrazy, filmy, tekst, audio i wiele innych.
JCR jest siłą napędową stojącą za:
- Przechowywanie i katalogowanie wszystkich treści.
- Organizowanie treści w hierarchii.
- Śledzenie różnych wersji treści.
- Przypisywanie metadanych do treści.
- Rozbudowane możliwości wyszukiwania, które umożliwiają szybkie znajdowanie treści.
- Zapewnienie, że tylko użytkownicy z dostępem do treści mogą ją zobaczyć.
Apache Jackrabbit Oak
Działając w tandemie z JCR, Apache Jackrabbit Oak jest odpowiedzialny za prawidłową implementację JCR w AEM. Podczas gdy sam JCR jest jak nadrzędna lista wytycznych dla funkcjonalności repozytorium treści, Apache Jackrabbit Oak odpowiada za ich realizację.
Apache Jackrabbit Oak dodaje również pewne dodatkowe możliwości do repozytorium treści AEM.
Co najważniejsze, jest kluczowym motorem zwiększonej skalowalności w JCR i umożliwia jednoczesne przechowywanie, organizowanie i interpretowanie większych wolumenów treści.
Apache Jackrabbit Oak umożliwia również lepszą możliwość dostosowania JCR do unikalnych potrzeb zarządzania treścią.
Kontener Apache Felix OSGi
Kontener Apache Felix OSGi służy jako podstawowa struktura wspierająca modułową architekturę Adobe Experience Manager (AEM).
Umożliwia to AEM wysoką adaptacyjność, pozwalając programistom dodawać lub usuwać funkcjonalności, znane jako „pakiety” (bundles), bez konieczności restartowania całego systemu.
Ta elastyczność zapewnia, że AEM może ewoluować wraz z potrzebami Twojej organizacji, umożliwiając płynne aktualizacje i skalowalność bez zakłócania bieżących operacji.
Przetwarzanie żądań Sling
Przetwarzanie żądań Sling to komponent odpowiedzialny za zarządzanie przychodzącymi żądaniami z przeglądarek internetowych i kierowanie ich do odpowiedniej treści w AEM.
Wykorzystuje mechanizm mapowania do lokalizowania żądanej treści na podstawie adresów URL i tłumaczy te żądania na dynamiczne strony internetowe, korzystając z repozytorium treści AEM.
Dzięki dynamicznemu składaniu treści, Sling zapewnia użytkownikom spersonalizowane i responsywne doświadczenia webowe, dopasowane do ich konkretnych żądań i preferencji.
Sightly (HTL)
Sightly, znany również jako HTML Template Language (HTL), to język szablonów używany w AEM do tworzenia stron internetowych i komponentów.
Zapewnia ustrukturyzowane i bezpieczne podejście do tworzenia stron internetowych, wymuszając separację zagadnień między warstwami treści a prezentacji.
Programiści mogą pisać czysty i łatwy w utrzymaniu kod za pomocą Sightly, zmniejszając ryzyko luk bezpieczeństwa, takich jak Cross-Site Scripting (XSS), oraz zwiększając ogólną stabilność i wydajność stron internetowych opartych na AEM.
GraphQL
GraphQL to język zapytań i środowisko wykonawcze dla interfejsów API, które umożliwia klientom żądanie określonych danych z systemów backendowych AEM.
W przeciwieństwie do tradycyjnych interfejsów API RESTful, GraphQL umożliwia klientom definiowanie struktury danych, których potrzebują, zmniejszając nadmierne i niedostateczne pobieranie informacji.
Umożliwiając klientom żądanie wyłącznie niezbędnych danych, GraphQL optymalizuje wydajność sieci i poprawia responsywność aplikacji opartych na AEM, co zwiększa ogólne wrażenia użytkownika.
Moduły AEM (komponenty podstawowe)
Interfejs autorski AEM został zaprojektowany z myślą o łatwej użyteczności, solidnych możliwościach i elastyczności konfiguracji. Kiedy autorzy ciężko pracują nad tworzeniem lub edytowaniem stron internetowych w AEM, nie będą pracować na minimalistycznej, pustej platformie.
W interfejsie autorskim AEM znajduje się trzydzieści komponentów podstawowych, z których wszystkie są zaprojektowane z myślą o niezawodnym użytkowaniu i możliwościach dostosowania. Oto krótki przegląd największych korzyści płynących ze wszystkich komponentów:
- Możliwości chmurowe, które zapewniają niezawodne działanie komponentów.
- Wszechstronność, która pozwala autorom treści tworzyć nieograniczone układy stron.
- Przyjazność dla SEO, która wzmacnia strony poprzez semantyczne wyjście HTML.
- Możliwość wersjonowania, która chroni Twoją witrynę przed awariami podczas aktualizacji komponentów.
- Dostępność jako open-source, która otwiera drzwi deweloperom do ulepszania istniejących rozwiązań.
Jeśli to sprawia, że chcesz wypróbować interfejs autorski AEM, rozumiemy to. To potężne narzędzie, które przenosi tworzenie stron na wyższy poziom i sprawia, że AEM może być tak prosty lub tak złożony, jak tego potrzebujesz.
Podsumowanie
Do tej pory powinieneś mieć całościowy obraz każdego z czterech kluczowych elementów architektury AEM, a także stosu technologicznego, który składa się na podstawowe funkcje AEM.
Zwłaszcza, gdy firmy rosną, rozszerzają działalność na wiele oddziałów i poszerzają swoje horyzonty, AEM jest zbudowany tak, aby rozwijać się razem z nimi. Niezależnie od tego, czy masz wiele potrzeb związanych z tworzeniem treści naraz, wiele żądań stron, czy też skarby zasobów do przechowywania, rozwiązanie CMS oparte na Adobe Experience Cloud dostosowuje się bez wahania.
A w dzisiejszym skomplikowanym i szybko zmieniającym się krajobrazie internetowym, jest to to, czego najbardziej potrzebują zarówno marketerzy, jak i projektanci interfejsu użytkownika.
FAQ
W jakim języku jest napisany AEM?
AEM jest zbudowany w oparciu o Javę.
Jakie wzorce projektowe Java są używane w AEM?
Ze względu na modułowe możliwości OSGi, obsługiwane są liczne wzorce projektowe Java, w tym (ale nie tylko): Singleton, Whiteboard, Adapter, Resource Adapter, Decorator i Observer.
Czy AEM posiada API?
Tak, AEM wykorzystuje różnorodne interfejsy API, w tym (ale nie tylko): JCR API, Apache Sling API, RESTful API i Javascript API.
Czy AEM używa Springa?
AEM nie jest z natury oparty na frameworku Java Spring; jednak może być zintegrowany z niestandardowym kodem zbudowanym w Springu lub niestandardowymi rozszerzeniami.
Gdzie AEM przechowuje zawartość?
Zawartość jest przechowywana w repozytorium treści Java AEM, które wykorzystuje Apache Jackrabbit Oak.
