O altă infrastructură de servicii Web de la Apache Software Foundation
Denis Sosnoski. Consultant, Sosnoski Software Solutions, Inc.
Dennis Sosnoski este fondatorul și specialistul principal al companiei de consultanță în tehnologie Java Sosnoski Software Solutions, Inc. specializată în predarea și consultarea problemelor privind serviciile XML și Web. Are mai mult de 30 de ani de experiență în designul de software profesional, specializat în tehnologiile XML și Java de la server. Denis este dezvoltatorul principal al sistemului integrat cu codul sursă JiBX XML Data Binding. pe baza tehnologiei claselor Java și a sistemului JibxSoap conectat la serviciile Web. precum și sistemele de servicii Web Apache Axis2. El a fost, de asemenea, unul dintre experții lor în dezvoltarea specificațiilor JAX-WS 2.0.
Bazele CXF
Interfața cu utilizatorul CXF are multe în comun cu interfețele stack Axis2 și Metro. Toate cele trei stive vă permit să creați un serviciu Web bazat pe codul Java ™ existent sau să generați cod Java bazat pe descrierea WSDL pentru utilizarea sau implementarea serviciului. Ca și alte stive, CXF modelează operațiunile cu serviciul ca apeluri metodice și porturile de servicii (portType) ca interfețe.
Despre această serie de articole
Similar cu Axa 2, dar în contrast cu Metro, CXF vă permite să alegeți între diferite tehnologii de legare a datelor. CXF acceptă date cu caracter obligatoriu JAXB 2.x par cu Metro și un pic mai bine decât Axis2, deoarece vă permite să configurați JAXB la generarea de cod din WSDL-descrierea serviciului (Axis2 nu permite acest lucru). CXF vă permite, de asemenea, să utilizați alte metode de legare a datelor, deși sprijinul lor nu este implementat, precum și în Axa2. De exemplu, puteți genera codul dintr-un fișier WSDL în CXF numai atunci când utilizați legături la date JAXB sau XMLBeans.
Metoda preferată de configurare a serviciului (care se numește frontend în terminologia CXF) este adnotările CXF JAX-WS 2.x, completate cu fișiere XML de configurare. Suport pentru adnotări JAX-WS din CXF este la egalitate cu Metro, ceea ce face ca această infrastructură este mult mai preferabil să se lucreze cu JAX-WS, decât Axis2 (suport pentru JAX-WS, care are unele limitări serioase, care au fost discutate în articolul „JAXB și JAX- WS în Axa2 "). Ca și alte implementări JAX-WS, CXF necesită o descriere WSDL pe partea clientului în timpul rulării.
Ca și în cazul altor stive, în CXF, procesarea cererilor și a răspunsurilor este efectuată de un set de componente configurabile. În CXF, aceste componente sunt numite interceptoare, mai degrabă decât manipulatoare, dar, în ciuda numelor diferite, acești termeni denotă aceleași componente. La fel ca Metro, CXF susține WS-Security și alte tehnologii avansate în sarcina de bază. Spre deosebire de Metro, arhivele CXF JAR sunt modulare. În funcție de tehnologiile utilizate, puteți selecta și include numai fișierele de care aveți nevoie în aplicația dvs. (în directorul CXF, fișierul / lib / WHICH_JARS descrie care fișiere JAR sunt necesare pentru diferite cazuri de utilizare tipice). Dezavantajul acestei modularități este că, în cele din urmă, este posibil să fiți nevoit să faceți o listă lungă de fișiere JAR necesare aplicației dvs., iar avantajul este că vă permite să reduceți dimensiunea aplicației care poate fi implementată.
La fel ca Metro, CXF necesită în mod obișnuit să se construiască un singur fișier WAR pentru serviciul Web, în loc să se folosească mai multe servicii din același server (abordarea utilizată în Axa 2). CXF oferă, de asemenea, un server HTTP integrat Jetty, potrivit pentru utilizarea într-un mediu de producție. Este o alternativă mai flexibilă și mai puternică pentru serverele simple HTTP integrate în Axis2 și Metro.
Exemple de aplicații
- getBook returnează informații detaliate despre carte. Cartea este identificată de numărul standard internațional ISBN (International Standard Book Number).
- getBooksByType returnează informații detaliate despre toate cărțile de un anumit tip.
- getTypes returnează tipurile de cărți disponibile.
- addBook adaugă o carte nouă în bibliotecă.
Utilizați pe partea clientului
Codul clientului pentru aplicația noastră pe CXF este identic cu utilizarea JAX-WS în Axis2 sau Metro. Pașii pentru construirea unui client sunt, de asemenea, foarte asemănători: utilizați utilitarul wsdl2java în CXF în locul programului wsimport dezvoltat pentru JAX-WS. Pentru informații detaliate despre lucrul cu codul clientului, consultați articolul "JAXB și JAX-WS în Axa2".
Utilizați serverul
Codul server al aplicației noastre pe CXF este, de asemenea, identic cu utilizarea JAX-WS în Axis2 sau Metro. Procesul de construire este, de asemenea, foarte similar cu Metro. În Axis2, suntem pregătiți pentru a implementa serviciul, crearea unui JAR-fișier cu clasele de serviciu și model de date și apoi desfășurat serviciul prin plasarea JAR-fișier în serverul directorul WEB-INF / servicejars Axis2. Metro și CXF în schimb au nevoie pentru a crea un război-fișier care conține clasele de modele de servicii și de date, biblioteca JAR-fișiere Metro sau CXF și un cuplu de fișiere de configurare (dintre care unul este numit în mod diferit în cele două stive). În fișierul WEB-INF / web.xml, acesta este configurat să proceseze cererile direct de servlet. Lista 1 arată versiunea acestui fișier utilizată în aplicația noastră:
Listarea 1. Fișierul web.xml din aplicația de probă
Fișierul WEB-INF / web.xml afișat în listare 1 este doar un fișier standard de configurare a servletului care îi spune serverului de aplicații Web (de exemplu Tomcat) cum să interacționeze cu servletul. Acest fișier este similar cu fișierul utilizat în exemplul Metro, deși pentru atributul CXF
Listing 2. Fișierul cxf-servlet.xml din aplicația de probă
Construirea și executarea codului
Constituie probleme
De la Java SE 6, implementările JAXB 2.x și JAX-WS 2.x (cu excepția extensiilor) au devenit parte a bibliotecilor standard Java Runtime Environment (JRE). Acest lucru a fost făcut pentru a încuraja utilizarea acestor tehnologii. Cu toate acestea, această bună intenție a dezvăluit o insulă neplăcută: acum, dacă doriți să utilizați cele mai recente versiuni ale acestor biblioteci, trebuie să schimbați JRE-ul deja instalat.
Fișierul build.xml utilizat în exemplul nostru de aplicații copiază fișierele CXF JAR necesare direct în fișierul WAR al serviciului. Acestea includ fișierele JAXB și JAX-WS JAR pentru construirea pe Java SE 5; dar când construiți Java SE 6, procedura de construire va utiliza versiunile JAXB și JAX-WS din instalarea JVM. Când descărcarea fișierelor conflicte cauza probleme în JAXB cod sau JAX-WS folosind Java SE 6 sau mai târziu, verificați pentru a vedea dacă distro dvs. CXF orice comentarii cu privire la compatibilitatea diferitelor versiuni ale JVM.
Înainte de a începe să lucrați cu aplicația de probă, trebuie să descărcați și să instalați versiunea curentă a CXF pe sistemul dvs. (consultați Resurse). Codul aplicației a fost testat cu versiunea 2.2.5. De asemenea, trebuie să editați fișierul build.properties localizat în directorul rădăcină. Găsiți atributul cxf-home în el și dați-i valoarea căii pe care este instalat CXF. Dacă testați o aplicație cu un server care rulează pe o altă mașină sau un alt port decât cel standard, trebuie să modificați atributele gazdă-nume și gazdă-port.
Pentru a construi o aplicație utilizând fișierul build.xml pentru Ant, deschideți consola din directorul rădăcină al codului aplicației și executați comanda ant. Această comandă lansează mai întâi programul wsdl2java (inclus în distribuția CXF), apoi compilează codul client și server și în final împachetează codul serverului în arhiva WAR. Apoi, puteți implementa fișierul cxf-library.war generat pe serverul de testare și tastați furnica în consola. lansați clientul aplicației. Clientul efectuează o serie de solicitări către server, imprimând informații sumare despre rezultatul fiecărei solicitări. După cum sa menționat deja în secțiunea Utilizare pe partea clientului. La asamblare, am configurat logarea CXF pentru a evita afișarea informațiilor detaliate când clientul pornește.
Primăvara în CXF
Rețineți că fișierul de configurare cxf-servlet.xml, listat în listare 2, configurează de fapt fasolea Spring Frame. După cum probabil știți, Spring este o infrastructură open source pentru dezvoltarea aplicațiilor. Acesta include multe componente și biblioteci pe care le puteți utiliza în aplicația dvs. Inițial, primăvara sa bazat pe containerul Inversion of Control (IoC). Acesta vă permite să asociați și să configurați componente JavaBean utilizând mecanismul de reflecție Java pentru a accesa proprietățile obiectelor de fasole în timpul execuției.
Containerul de primăvară IoC utilizează, de regulă, fișiere XML pentru a obține informații despre dependențe. Fișierul cxf-servlet.xml din listare 2 este un exemplu de fișier de configurare similar cu primavara. element
În fișierul cxf-servlet.xml, puteți specifica un număr de alți parametri care nu sunt utilizați în acest exemplu simplu, inclusiv configurația fluxului de mesaje de serviciu. Pentru informații detaliate despre configurația JAX-WS, consultați documentația CXF (în secțiunea Frontends / JAX-WS).
Cu excepția adnotărilor JAX-WS, primăvara este utilizată pentru întreaga configurare a stivei CXF, inclusiv pentru organizarea mesajelor interne CXF. În cele mai multe cazuri, toate detaliile setările sunt tratate automat de către configurația XML-fișiere incluse direct în CXF (în parametrul contextConfigLocation în fișierul web.xml în Listarea 1, puteți vedea exact cum sunt specificate aceste fișiere). Cu toate acestea, o configurație tipică poate fi redefinită sau extinsă utilizând propriile fișiere de configurare. Nu vom vorbi despre acest lucru în această serie de articole, pentru informații detaliate despre acest subiect, consultați documentația CXF.
Vom continua să ne cunoaștem cu CXF
Trimiteți-le prietenilor: