Ще одна інфраструктура Web-сервісів від Apache Software Foundation
Денис Сосноскі. консультант, Sosnoski Software Solutions, Inc.
Денис Сосноскі (Dennis Sosnoski) - засновник і провідний фахівець консалтингової компанії за технологіями Java - Sosnoski Software Solutions, Inc. що спеціалізується в навчанні і консультуванні з проблем XML і Web-сервісів. Він має більш ніж 30-річний досвід роботи в професійному проектуванні ПО, спеціалізуючись на серверних XML і Java-технологіях. Денис є основним розробником інтегрованої системи з відкритим програмним кодом JiBX XML Data Binding. побудованої на базі технології класів Java і пов'язаної системи Web-сервісів JibxSoap. також як і системи Web-сервісів Apache Axis2. Він також був одним їх експертів при розробці специфікацій JAX-WS 2.0.
основи CXF
Інтерфейс CXF має багато спільного з інтерфейсами стеків Axis2 і Metro. Всі три стека дозволяють створити Web-сервіс на основі існуючого коду Java ™ або ж згенерувати код Java на основі WSDL-опису для використання або реалізації сервісу. Як і інші стеки, CXF моделює операції з сервісом у вигляді викликів методів, а порти сервісу (portType) - у вигляді інтерфейсів.
Про це циклі статей
Аналогічно Axis2, але на противагу Metro, CXF дозволяє вибирати між різними технологіями зв'язування з даними. CXF підтримує зв'язування з даними JAXB 2.x нарівні з Metro і дещо краще, ніж Axis2, тому що він дозволяє налаштовувати JAXB при генерації коду з WSDL-опису сервісу (Axis2 цього не дозволяє). CXF також дозволяє використовувати інші методи зв'язування з даними, хоча їх підтримка реалізована не так добре, як в Axis2. Наприклад, генерувати код з WSDL-файлу в CXF можна тільки при використанні зв'язування з даними JAXB або XMLBeans.
Кращим методом конфігурації сервісу (який в термінології CXF називається frontend) в CXF є анотації JAX-WS 2.x, що доповнюються конфігураційними XML-файлами. Підтримка анотацій JAX-WS в CXF знаходиться на одному рівні з Metro, що робить цю інфраструктуру набагато краще для роботи з JAX-WS, ніж Axis2 (підтримка JAX-WS в якому має кілька серйозних обмежень, які обговорювалися в статті "JAXB і JAX- WS в Axis2 "). Як і інші реалізації JAX-WS, CXF вимагає наявності WSDL-опису на стороні клієнта під час виконання.
Як і в інших стеках, в CXF обробка запитів і відповідей здійснюється набором конфігурованих компонентів. У CXF ці компоненти називаються перехоплювачами (intercepters), а не обработчиками (handlers), але, незважаючи на різні назви, ці терміни позначають одні й ті ж компоненти. Як і Metro, CXF в базовій завантаженні підтримує WS-Security і інші додаткові технології. На відміну від Metro, JAR-архіви CXF є модульними. Залежно від використовуваних технологій ви можете вибрати і включити в свій додаток лише потрібні вам файли (в директорії CXF в файлі / lib / WHICH_JARS описується, які JAR-файли потрібні при різних типових варіантах використання). Недоліком такої модульності є те, що в підсумку, можливо, доведеться мати справу з довгим списком JAR-файлів, потрібних вашому додатку, а гідністю - то, що вона дозволяє скоротити розмір його розгортає додатки.
Як і Metro, CXF зазвичай вимагає зібрати для Web-сервісу один WAR-файл замість розгортання потенційно кількох сервісів всередині одного сервера (підхід, який застосовується в Axis2). CXF також надає вбудований HTTP-сервер Jetty, придатний для використання в робочому середовищі. Він є більш гнучкою і потужною альтернативою простим серверів HTTP, інтегрованим в Axis2 і Metro.
приклад програми
- getBook повертає детальну інформацію по книзі. Книга ідентифікується з міжнародного стандартного номеру ISBN (International Standard Book Number).
- getBooksByType повертає докладну інформацію про всі книгах певного типу.
- getTypes повертає наявні типи книг.
- addBook додає в бібліотеку нову книгу.
Використання на клієнтській стороні
Клієнтський код для нашого застосування на CXF ідентичний використання JAX-WS в Axis2 або Metro. Кроки по збірці клієнта також дуже схожі: використовуйте входить в CXF утиліту wsdl2java замість розробленої для JAX-WS програми wsimport. За детальною інформацією про роботу з клієнтським кодом звертайтеся до статті "JAXB і JAX-WS в Axis2".
Використання на серверній стороні
Серверний код нашого застосування на CXF також ідентичний використання JAX-WS в Axis2 або Metro. Процес складання також дуже схожий на Metro. У Axis2, ми готували сервіс до розгортання, створюючи JAR-файл з класами сервісу та моделі даних, а потім розгортали сервіс, поміщаючи цей JAR-файл в директорію WEB-INF / servicejars сервера Axis2. В Metro і CXF замість цього потрібно створити WAR-файл, який містить класи сервісу та моделі даних, бібліотечні JAR-файли Metro або CXF і пару конфігураційних файлів (один з яких називається по різному в цих двох стеках). У файлі WEB-INF / web.xml конфигурируется безпосередньо обробка запитів сервлетом. У лістингу 1 показана версія цього файлу, яка використовується в нашому додатку:
Лістинг 1. Файл web.xml в прикладі додатка
Наведений у лістингу 1 файл WEB-INF / web.xml є всього лише стандартним конфігураційним файлом сервлету, повідомляють сервера Web-додатків (наприклад Tomcat), як взаємодіяти з сервлетом. Даний файл схожий на файл, використаний в прикладі для Metro, хоча для CXF атрибут
Лістинг 2. Файл cxf-servlet.xml в прикладі додатка
Збірка і запуск коду
проблеми збирання
Починаючи з Java SE 6, реалізації JAXB 2.x і JAX-WS 2.x (за винятком розширень) стали частиною стандартних бібліотек Java Runtime Environment (JRE). Це було зроблено для заохочення використання цих технологій. Однак у цього доброго наміру виявилася неприємна оборотна сторона: тепер при необхідності використовувати свіжі версії даних бібліотек необхідно змінювати вже встановлену JRE.
Файл build.xml, який використовується в нашому прикладі додатка, копіює необхідні CXF JAR-файли безпосередньо в WAR-файл сервісу. В їх число входять JAR-файли JAXB і JAX-WS для збірки на Java SE 5; але коли ви робите збірку на Java SE 6, процедура складання буде використовувати версії JAXB і JAX-WS з установки JVM. Якщо конфлікти завантаження файлів викликають проблеми в коді JAXB або JAX-WS при використанні Java SE 6 або більш нової версії, перевірте, чи є до вашого дистрибутива CXF якісь зауваження про сумісність з різними версіями JVM.
Перед початком роботи з прикладом програми, вам потрібно завантажити і встановити собі на систему поточну версію CXF (див. Ресурси). Код додатка тестувався з версією 2.2.5. Також потрібно відредагувати файл build.properties, що знаходиться в кореневому каталозі. Знайдіть в ньому атрибут cxf-home і задайте йому значення шляху, по якому встановлено CXF. Якщо ви будете тестувати програму із сервером, що працює на іншій машині, або порту, відмінному від стандартного, вам слід змінити атрибути host-name і host-port.
Щоб зібрати програму за допомогою файлу build.xml для Ant, відкрийте консоль в кореневій директорії коду програми і виконайте команду ant. Ця команда спочатку запускає програму wsdl2java (включену в дистрибутив CXF), потім скомпілює код клієнта і сервера, і, нарешті, упакує код сервера в WAR-архів. Потім можна розгорнути згенерований файл cxf-library.war на тестовому сервері, і, набравши в консолі ant run. запустити клієнт додатки. Клієнт виконує серію запитів до сервера, друкуючи коротку інформацію про результат кожного запиту. Як уже згадувалося в розділі Використання на клієнтській стороні. при складанні ми сконфигурировали журнал CXF так, щоб уникнути виведення детальної інформації при запуску клієнта.
Spring в CXF
Зверніть увагу, що в файлі конфігурації cxf-servlet.xml, зазначеному в лістингу 2. фактично конфигурируется bean-компонент Spring Framework. Як ви, можливо, знаєте, Spring - це інфраструктура з відкритим вихідним кодом для розробки додатків. Вона включає в себе безліч компонентів і бібліотек, які можна використовувати в своєму додатку. Спочатку в основі Spring лежав контейнер Inversion of Control (IoC). Він дозволяє пов'язувати і конфігурувати JavaBean - компоненти, використовуючи механізм відображення Java для доступу до властивостей bean-об'єктів під час виконання.
Контейнер Spring IoC, як правило, використовує для отримання інформації про залежності XML-файли. Наведений у лістингу 2 файл cxf-servlet.xml є прикладом подібного конфігураційного файлу Spring. елемент
У файлі cxf-servlet.xml можна вказати безліч інших параметрів, які не використовуються в цьому простому прикладі, в тому числі конфігурацію потоку повідомлень сервісу. З детальною інформацією про конфігурацію JAX-WS можна ознайомитися в документації CXF (в розділі Frontends / JAX-WS).
За винятком анотацій JAX-WS, Spring використовується для всієї конфігурації стека CXF, в тому числі для організації роботи внутрішніх повідомлень CXF. У більшості випадків всі деталі настройки обробляються автоматично, за допомогою конфігураційних XML-файлів, включених безпосередньо в CXF (в параметрі contextConfigLocation в файлі web.xml з лістингу 1. можна побачити, як саме ці файли вказуються). Однак типову конфігурацію можна перевизначити або розширити, використовуючи свої власні конфігураційні файли. Ми не будемо розповідати про це в даному циклі статей, за детальною інформацією на цю тему звертайтеся до документації CXF.