Non so quali sono i file di archivio AAR e come si differenziano dalla guerra. Ho letto che sono in qualche modo convertibili. Quando usare quale? Quali sono i pro, i contro e i limiti.Qual è la differenza tra aar e file di guerra?
Un .war è un archivio web che è possibile distribuire a qualsiasi application server Java EE.
A .aar è un artefatto di asse2 specifico che è possibile distribuire in un server applicazioni in cui è già installata l'applicazione Web standard Axis2.
È ancora possibile distribuire un'applicazione Axis2, compresi più servizi, in un'applicazione Web standard, utilizzando la modalità 'incorporata', come descritto qui: http://wso2.com/library/90. La conversione dalla modalità .ar in modalità incorporata consiste nell'estrarre tutti i file e nel metterli accuratamente nella giusta posizione per la modalità incorporata.
Pro per .aar è la distribuzione a caldo come risposta @ renat-gilmanov.
Pro per la .war (incorporati) è
Axis Archive (.aar)
Asse 2 servizi sono confezionati come Axis Archive (.aar). Questo è un file JAR (creato utilizzando le utilità jar o zip) con il file services.xml impacchettato nella directory META-INF dell'archivio.
Example, La StockQuoteService quando confezionato come StockQuoteService.aar avrà le seguenti strutture:
./stock/StockQuoteService.class
./META-INF/services.xml
distribuzione del servizio in Axis2 è abbastanza semplice; copia il file .aar nella directory axis2/WEB-INF/services nell'applicazione webnel tuo contenitore servlet. In caso di Tomcat, saranno $ TOMCAT_HOME/webapps/axis2/WEB-INF/services.
Razionale
servizio è piuttosto un piccolo pezzo di software. Si prega di pensare a quanto segue:
Ba Asse2 suggerisce di trattare * .aar come un'applicazione leggera. Condivide la stessa istanza di Axis2, può essere facilmente gestita e ridistribuita senza interrompere l'intera attività.
Immaginiamo di sviluppare un sistema complesso. Come un buon sviluppatore e architetto, hai deciso di costruire un sistema liberamente accoppiato usando i servizi come una piccola funzionalità. La decomposizione è andata bene, quindi hai ~ 100 servizi. Che è, tra l'altro, bene, perché si sarà in grado di:
La domanda è: preferirai sviluppare tutti questi servizi come applicazioni separate (guerre)? Spero che non lo farai. Sarà molto più facile ed efficiente usare un approccio così leggero come gli archivi di Axis.
Nota, Axis consente di gestire il ciclo di vita del servizio come fa Tomcat per l'applicazione.
Disponibilità è una grande preoccupazione quando si tratta di livello enterprise applicazioni. Anche un breve periodo di inattività può essere estremamente dannoso, quindi riavviare un server non è una buona opzione. È necessario aggiornare il sistema senza chiuderlo. Questo è dove caldo implementazione e aggiornamento a caldo sono disponibili in.
Hot distribuzione è la capacità di distribuzione di nuovi servizi, mentre il sistema è installato e funzionante. Ad esempio, supponiamo che siano disponibili due servizi - service1 e service2 - e che venga distribuito un nuovo servizio denominato service3 senza arrestare il sistema. La distribuzione del servizio3 è uno scenario di distribuzione molto caldo.
Aggiornamento a caldo è la possibilità di apportare modifiche a un servizio Web esistente senza arrestare il sistema. Questa è una caratteristica importante e richiesta in un ambiente di test.
The Axis2 Deployment model, Part 1: Six ways the Axis2 deployment model is more user friendly