Jaka jest różnica między plikiem aar i wojennym?

Question

Nie wiem, czym są pliki archiwum AAR i czym różnią się od wojny. Czytałem, że są one w pewnym stopniu zamienne. Kiedy użyć którego? Jakie są plusy i minusy oraz ograniczenia.

Answer 1

.war jest archiwum stron internetowych, które można zainstalować na dowolnym serwerze aplikacji Java EE.

.aar to konkretny artefakt osi2, który można wdrożyć na serwerze aplikacji, na którym wdrożono już standardową aplikację internetową Axis2.

Nadal można wdrażać aplikację Axis2, w tym wiele usług, w standardowej aplikacji internetowej, używając trybu "osadzonego", jak opisano tutaj: http://wso2.com/library/90. Konwersja z trybu .aar do trybu wbudowanego polega na wyodrębnianiu wszystkich plików i ostrożnym umieszczaniu ich w odpowiednim miejscu dla trybu osadzonego.

Pro dla .aar jest gorącym rozmieszczeniem, ponieważ @ renat-gilmanov odpowiedział.

Pro za okres .war (wbudowanych) jest

1. łatwiejsze do wdrożenia i zarządzania w środowisku produkcyjnym: wystarczy wdrożyć jeden .war na dowolnym serwerze aplikacji zamiast śledzić skomplikowaną procedurę wdrażania.
2. można dodać więcej serwletów w tym samym pliku .war, np. aplikacja kliencka.

Answer 2

Axis Archive (.aar)

Oś 2 usługi są pakowane jako oś Archive (.aar). Jest to plik JAR (utworzony za pomocą narzędzi jar lub zip) z plikiem services.xml zapakowanym w katalog META-INF archiwum.

Example The StockQuoteService gdy opakowane StockQuoteService.aar będzie mieć następujące struktury:

./stock/StockQuoteService.class 
./META-INF/services.xml 

wdrożenia usługi w Axis2 jest bardzo prosta; po prostu skopiuj plik .aar do katalogu axis2/WEB-INF/services w aplikacji axis2 Web w kontenerze serwletu. W przypadku Tomcat będzie to $ TOMCAT_HOME/webapps/axis2/WEB-INF/services.

Uzasadnienie

Obsługa jest dość mały kawałek oprogramowania. Proszę pomyśleć o następującym:

• usług cyklu życia, ponieważ trzeba wdrożyć/przesunięcie/undeploy usługi lub usług, które rozwijają
• pojemnik narzutu związanego z każdej wdrożonej aplikacji
• napowietrznych spowodowane kilka przypadków oś2 rozmieszczone równolegle
• luźno architektury
• ...

Ba sic, Axis2 sugeruje traktowanie * .aar jako lekkiej aplikacji. Współużytkuje tę samą instancję Axis2, można ją łatwo zarządzać i przenosić bez zatrzymywania całej firmy.

Wyobraźmy sobie, że rozwijasz złożony system. Jako dobry programista i architekt zdecydowałeś się zbudować luźno sprzężony system, wykorzystując usługi jako najmniejszy element funkcjonalności. Dekompozycja poszła dobrze, więc masz ~ 100 usług. Co jest, nawiasem mówiąc, dobrze, bo będzie można do:

• uprościć opracowywanie
• rozwijać niektóre usługi w równoległym
• uprościć testowanie
• ...

Pytanie brzmi: czy wolisz rozwijać wszystkie te usługi jako oddzielne aplikacje (wojny)? Mam nadzieję, że nie. O wiele łatwiejsze i bardziej efektywne będzie stosowanie tak lekkiego podejścia, jak Archiwa osi.

Należy pamiętać, że Axis pozwala zarządzać cyklem życia serwisów tak jak Tomcat dla aplikacji.

Dostępność jest dużym problemem, jeśli chodzi o przedsiębiorstwa poziomie aplikacji. Nawet krótki czas przestoju może być bardzo szkodliwy, więc ponowne uruchomienie serwera nie jest dobrą opcją. Musisz zaktualizować system, nie wyłączając go. To gdzie gorący wdrażania i gorąco aktualizacja przyjść.

Hot rozmieszczenie jest możliwość wdrażania nowych usług, podczas gdy System jest uruchomiony. Na przykład załóżmy, że masz dwie usługi - usługi 1 i usługa 2 - uruchomione i wdrożysz nową usługę o nazwie service3 bez wyłączania systemu. Wdrażanie usługi service3 to scenariusz gorącej instalacji.

Aktualizacja na gorąco to możliwość wprowadzania zmian w istniejącym serwisie WWW bez wyłączania systemu. Jest to ważna cecha i wymagana jest w środowisku testowym.

The Axis2 Deployment model, Part 1: Six ways the Axis2 deployment model is more user friendly