apache cxf что это
Apache CXF™: An Open-Source Services Framework
Overview
Apache CXF™ is an open source services framework. CXF helps you build and develop services using frontend programming APIs, like JAX-WS and JAX-RS. These services can speak a variety of protocols such as SOAP, XML/HTTP, RESTful HTTP, or CORBA and work over a variety of transports such as HTTP, JMS or JBI.
The Apache CXF team is proud to announce the availability of our latest patch releases! Over 34 JIRA issues were fixed for 3.4.5, many back ported to 3.3.12.
Downloads are available here.
The Apache CXF team is proud to announce the availability of our latest patch releases! Over 26 JIRA issues were fixed for 3.4.4, many back ported to 3.3.11.
These releases contain a fix for a security issue, please see the security advisories page for more information:
Apache CXF Denial of service vulnerability in parsing JSON via JsonMapObjectReaderWriter (CVE-2021-30468)
Downloads are available here.
The Apache CXF team is proud to announce the availability of our latest patch releases! Over 22 JIRA issues were fixed for 3.4.3, many back ported to 3.3.10.
Downloads are available here.
Features
CXF includes a broad feature set, but it is primarily focused on the following areas:
CXF implements the JAX-WS APIs. CXF JAX-WS support includes some extensions to the standard that make it significantly easier to use, compared to the reference implementation: It will automatically generate code for request and response bean classes, and does not require a WSDL for simple cases.
It also includes a «simple frontend» which allows creation of clients and endpoints without annotations. CXF supports both contract first development with WSDL and code first development starting from Java.
For REST, CXF also supports a JAX-RS frontend.
To get started using CXF, check out the downloads, the user’s guide, or the mailing lists to get more information!
Goals
General
Support for Standards
JSR Support
WS-* and related Specifications Support
OpenAPI Specification (OAS) Support
Multiple Transports, Protocol Bindings, Data Bindings, and Formats
Flexible Deployment
Support for Multiple Programming Languages
Tooling
Getting Involved
Apache CXF is currently under heavy development. To get involved you can subscribe to the mailing lists. You can also grab the code from the Source Repository. You also need to read about Building CXF. For Eclipse users, you should read about Setting up Eclipse.
SOAP-сервер на Java при участии Apache CXF и Spring
0. Начальные условия
Вот так выглядит исходная WSDL-схема:
Сервис имеет весьма простую функциональность: возвращает текущее время в указанном часовом поясе. В случае, когда пояс не указан, сервис возвращает текущее время сервера.
Структура проекта
Определим структуру проекта. В папке build будем хранить скрипты для ant. В модуле ObjectLibrary будем держать исходную схему, а также сгенерированные по ней классы. Модуль CurrentTimeService будет основным, в нем будем держать реализацию сервиса, также по нему будем собирать war-файл.
В pom-файлах укажем необходимые модулям зависимости. Внешних зависимостей у нас будет не много: spring-web, log4j, cxf-rt-frontend-jaxws и cxf-rt-transports-http — все они доступны в http://repo1.maven.org/maven2.
1. Создание java-интерфейса на основе WSDL-схемы
Для автоматической генерации java-интерфейса на основе WSDL-схемы воспользуемся утилитой wsdl2java из пакета Apache CXF. Немного модифицируем исходный ant-скрипт для того, чтобы он предварительно очищал директорию, в которую будут складываться java-классы. Это может быть полезно в том случае, если в будущем исходная схема будет меняться. По-умолчанию директория не очищается, что может приводить к появлению «мусора» из классов, которые больше не используются. Такая проблема характерна для схем, имеющих в своем составе сложные составные типы.
Разместим этот скрипт в файле build/build.xml. Запустим таску regenerate.object.library, в результате работы которой в папке ObjectLibrary получим необходимый нам интерфейс.
2. Реализация веб-сервиса на основе полученного интерфейса
Реализацию интерфейса CurrentTimeService разместим в одноименном модуле. Код незамысловатый и в дополнительных комментариях не нуждается.
Теперь, в соответствии с примером, добавим в ресурсы файлы serviceContext.xml и web.xml. Также не забудем про log4j.xml. Найти эти файлы можно в архиве с исходными кодами, ссылка на него приведена в конце статьи. После этого реализацию сервиса можно считать законченной, осталось собрать приложение и проверить его работоспособносcть.
3. Сборка и проверка
Для сборки проекта выполним задачу maven «package». Полученный war-файл развернем на сервере Tomcat. Будем считать, что он доступен на порту 8080.
Для проверки воспользуемся программой soapUI. WSDL-схема сервиса доступна по ссылке http://localhost:8080/CurrentTimeService/service/currentTimeService?wsdl, с ее помощью мы можем создать новый проект soapUI.
Вместо заключения
Поставленная задача достигнута: веб-сервис корректно обрабатывает запросы. Также нам удалось избежать «жесткой» привязки к генерируемой реализации, что делает код более гибким и позволяет прикладывать меньше усилий для внесения изменений в дальнейшем.
Руководство по Apache CXF с весной
Быстрый учебник о том, как использовать Apache CXF с Spring Framework и как настроить его с помощью Java или XML.
1. Обзор
Этот учебник фокусируется на настройке и с помощью Apache CXF рамки вместе с весенними – либо с конфигурацией Java или XML.
Это второй в серии на Apache CXF; первый из них был посвящен основам CXF как реализации стандартных API JAX-WS.
2. Мейвен зависимостей
Как и в предыдущем учебнике, следующие две зависимости должны быть включены:
Кроме того, для поддержки Spring необходимы следующие зависимости:
Наконец, потому что мы будем программно настроить приложение с помощью JAVA Servlet 3.0 “API вместо традиционного веб.xml Дескриптор развертывания, нам понадобится артефакт ниже:
Этот где мы можем найти последнюю версию API Servlet.
3. Компоненты серверной стороны
Давайте теперь посмотрим на компоненты, которые должны присутствовать на стороне сервера для того, чтобы опубликовать конечную точку веб-службы.
3.1. Интерфейс WebApplicationInitilizer
WebApplicationИнициализатор интерфейс реализован для программной настройки СервлетКонтекст интерфейс для приложения. При присутствуют на classpath, его onStartup метод автоматически вызывается контейнером сервлета, а затем СервлетКонтекст мгновенно и инициализировано.
Вот как определяется класс для реализации WebApplicationИнициализатор интерфейс:
onStartup () метод реализуется с использованием фрагментов кода, показанных ниже.
Во-первых, создается и настраивается контекст приложения Spring для регистрации класса, содержащего метаданные конфигурации:
СервисКонфигурация класс аннотирован с @Configuration аннотация для предоставления определений фасоли. Этот класс обсуждается в следующем подразделе.
Следующий фрагмент показывает, как контекст приложения Spring добавляется в контекст сервлета:
CXF Сервлет класс, определяемый Apache CXF, генерируется и регистрируется для обработки входящих запросов:
Наконец, сервлет CXF отображается на относительном URL::
3.2. Старая добрая паутина.xml
Кроме того, если мы хотим использовать (несколько старомодный) дескриптор развертывания, а не WebApplicationИтилизатор интерфейс, соответствующий веб.xml файл должен содержать следующие определения сервлета:
3.3. Класс сервисной самоуверенции
Давайте теперь посмотрим на конфигурацию службы – сначала основной скелет, который прилагает определения фасоли для конечной точки веб-сервиса:
Первый необходимый боб является СпрингБус – который поставляет расширения для Apache CXF для работы с весенней рамочной:
БаелдунгИмпл класс используется для реализации интерфейса веб-службы. Его определение дается в следующем подразделе.
Кроме того, мы также можем объявить конечную точку сервера в файле конфигурации XML. В частности, cxf-сервлет.xml файл ниже работает с веб.xml Дескриптор развертывания, как было определено в подразделе 3.1 и описывает точно такую же конечную точку:
3.4. Определения типов
Этот класс обеспечивает реализацию для Баелдунг интерфейс конечной точки, который Apache CXF будет включать в опубликованные метаданные WSDL:
Интерфейс конечной точки, а также исполнителем использовать Студенческие класс, который определяется следующим образом:
4. Клиентская фасоль
Чтобы воспользоваться Весенней рамочной программой, мы объявляем фасоль в @Configuration аннотированный класс:
Фасоль с именем клиент определяется:
клиент фасоль представляет собой прокси для Баелдунг веб-сервис. Он создается призывом к создать метод на JaxWsProxyFactoryBean боб, фабрика по созданию прокси JAX-WS.
JaxWsProxyFactoryBean объект создается и настраивается следующим методом:
Завод сервисКласс свойство обозначает интерфейс веб-службы, в то время как адрес свойство указывает url-адрес для прокси для удаленных призывов.
Кроме того, для весенних бобов на стороне клиента можно вернуться к файлу конфигурации XML. Следующие элементы объявляют те же бобы, что и те, которые мы только что программно настроены выше:
5. Тестовые случаи
Во-первых, нам необходимо загрузить контекст приложения Spring из вышеупомянутого СервисКонфигурация класс конфигурации и кэшировать его в контекст поле:
Далее, прокси для интерфейса конечной точки службы объявляется и загружается из контекста приложения:
Этот Баелдунг прокси будет использоваться в тестовых случаях, описанных ниже.
В первом тестовом случае мы доказываем это, когда привет метод локально вызывается на прокси, ответ точно такой же, как то, что конечная точка исполнителем возвращается из удаленного веб-сервиса:
Во втором тестовом случае студенты регистрируются на курсы Baeldung, ссылаясь на регистрация метод на прокси, который, в свою очередь, называет веб-сервис. Затем эта удаленная служба вычислит номера студентов и вернет их вызывающему абоненту. Следующий фрагмент кода подтверждает то, что мы ожидаем:
6. Интеграционное тестирование
Для того, чтобы быть развернуты в качестве веб-приложения на сервере, фрагменты кода в этом учебнике должны быть упакованы в файл WAR в первую очередь. Этого можно достичь, объявив упаковочные свойство в файле POM:
Работа по упаковке осуществляется плагином Maven WAR:
Этот плагин упаковывает составленный исходный код в файл WAR. С тех пор, как мы настроили контекст сервлета с помощью Java-кода, веб.xml Дескриптор развертывания не должен быть существующим. В результате, failOnMissingWebXml имущество должно быть установлено на ложные чтобы избежать сбоя при выполнении плагина.
Мы можем следить за эта ссылка для последней версии плагина Maven WAR.
Для иллюстрации операций веб-сервиса мы создаем интеграционный тест. Этот тест сначала генерирует файл WAR и запускает встроенный сервер, затем заставляет клиентов вызывать веб-службу, проверяет последующие ответы и, наконец, останавливает сервер.
Вот плагин Maven Surefire:
профиль раздел с id интеграционные объявляется для облегчения интеграционного теста:
Плагин Maven Cargo включен в интеграционные профиль:
Обратите внимание, что cargo.hostname и cargo.servlet.port свойства конфигурации просто включены для ясности. Эти свойства конфигурации могут быть оставлены без какого-либо влияния на приложение, так как их значения такие же, как значения по умолчанию. Этот плагин запускает сервер, ждет подключения и, наконец, останавливает сервер для выпуска системных ресурсов.
Эта ссылка позволяет нам проверить последнюю версию плагина Maven Cargo.
Плагин Maven Surefire объявляется снова, в пределах интеграционные профиля, чтобы переопределить его конфигурацию в основной построить раздела и для выполнения тестовых случаев, описанных в предыдущем разделе:
7. Заключение
Этот учебник проиллюстрировал поддержку Apache CXF для весны. В частности, было показано, как веб-служба может быть опубликована с помощью файла конфигурации Spring, и как клиент может взаимодействовать с этой службой через прокси, созданный прокси-фабрикой Apache CXF, который был объявлен в другом файле конфигурации.
Frequently Asked Questions
General
Can CXF run with JDK/ Java 9+ (10, 11)?
Yes. CXF will support Java 9-11 with the next 3.3.x release.
Can CXF run with JDK 1.8/Java 8?
Yes. CXF supports Java 8. The latest 3.x version is built using JDK 1.8.
Can CXF run with JDK 1.7/Java 7?
Yes. CXF supports Java 7. Since Java 7 contains the 2.2.x versions of both JAXB and JAX-WS API jars, using CXF with Java 7 is much easier than with Java 6.
CXF 3.2 no longer supports Java 7 and requires Java 8 or newer. Users are strongly encouraged to start moving to Java 8.
Can CXF run with JDK 1.6?
JDK 1.6 incorporates the JAXB reference implementation. However, it incorporates an old version of the RI. CXF does not support this version. As of 1.6_04, this is easy to deal with: you must put the versions of JAXB RI (the ‘impl’ and ‘xjc’ jars) that we include with CXF in your classpath. As of this writing, these are version 2.2.10.
CXF 3.1 no longer supports Java 6 and requires Java 7 or newer.
Can CXF run with JDK 1.5?
Yes for CXF 2.6.x and older. Keep in mind though that Java 2 SE 5.0 with JDK 1.5 has reached end of life (EOL). CXF 2.7.x no longer supports Java 5. In order to upgrade to 2.7.x, you must be using Java 6 (or newer).
There are no more planned releases for the 2.6.x series of CXF that will support Java 5. Users are strongly encouraged to start moving to Java 7 and to start migrating to newer versions of CXF.
Can CXF run without the Sun reference SAAJ implementation?
In many cases, CXF can run without an SAAJ implementation. However, some features such as JAX-WS handlers and WS-Security do require an SAAJ implementation. By default, CXF ships with the Sun SAAJ implementation, but CXF also supports axis2-saaj version 1.4.1 as an alternative. When using a Java6 JRE, CXF can also use the SAAJ implementation built into Java.
Are there commercial offerings of CXF that provide services, support, and additional features?
Several companies provide services, training, documentation, support, etc. on top of CXF. Some of those companies also produce products that are either based on Apache CXF or include Apache CXF. See the Commercial CXF Offerings page for a list of companies and the services they provide.
Is there an Apache CXF certification program?
No, but Oracle’s SCDJWS certification covers the web services stack and related areas. Note, that the popular SCJP certification is a prerequisite to the SCDJWS. Also, check out the SCDJWS Forum at the Java Ranch for healthy discussions in regards to the certification. Study notes can be found at SCDJWS 5.0 Study Guide, WikiBooks and Ivan A. Krizsan Study Notes. Java Ranch also provides and information page in regards to the certification.
JAX-WS Related
Official answer: The JAX-WS spec (specifically section 3.6.1) mandates that it be generated this way. To customize the name, you have to use an @WebParam(name = «blah») annotation to specify better names. (You can use @WebResult for the return value, but you’ll only see the results if you look at the XML.)
Reason: One of the mysteries of java is that abstract methods (and thus interface methods) do NOT get their parameter names compiled into them even with debug info. Thus, when the service model is built from an interface, there is no way to determine the names that were using in the original code.
How can I add soap headers to the request/response?
There are several ways to do this depending on how your project is written (code first or wsdl first) and requirements such as portability.
Введение в Apache CXF
Введение в Apache CXF
1. обзор
Помимо функций, определенных стандартами JAX-WS, Apache CXF обеспечивает возможность преобразования между классами WSDL и Java, API-интерфейсы, используемые для управления необработанными сообщениями XML, поддержку JAX-RS, интеграцию с Spring Framework и т. Д.
Это руководство является первым из серии, посвященной Apache CXF, в которой представлены основные характеристики платформы. Он использует только стандартные API-интерфейсы JAX-WS в исходном коде, но в то же время использует Apache CXF за кулисами, например, автоматически генерируемые метаданные WSDL и конфигурацию по умолчанию CXF.
2. Maven Зависимости
Ключевая зависимость, необходимая для использования Apache CXF:org.apache.cxf:[.s1] cxf – rt – frontend – jaxws. This provides a JAX-WS implementation to replace the built-in JDK one:
Notice that this artifact contains a file named javax.xml.ws.spi.Provider inside the META-INF/services directory. Java VM looks at the first line of this file to determine the JAX-WS implementation to make use of. In this case, content of the line is o rg.apache.cxf.jaxws.spi.ProviderImpl, ссылаясь на реализацию, предоставленную Apache CXF.
В этом руководстве мы не используем контейнер сервлета для публикации службы, поэтому для предоставления необходимых определений типов Java требуется другая зависимость:
Последние версии этих зависимостей можно найти вcxf-rt-frontend-jaxws иcxf-rt-transports-http-jetty в центральном репозитории Maven.
3. Конечная точка веб-службы
Начнем с класса реализации, используемого для настройки конечной точки службы:
Все сигнатуры методов, объявленные в интерфейсе конечной точки, должны быть реализованы, но это не обязательно для реализации интерфейса.
Здесь класс реализацииexampleImpl по-прежнему реализует следующий интерфейс конечной точки, чтобы было ясно, что все объявленные методы интерфейса были реализованы, но делать это необязательно:
По умолчанию Apache CXF использует JAXB в качестве архитектуры привязки данных. Однако, поскольку JAXB не поддерживает напрямую привязкуMap, которая возвращается из методаgetStudents,we need an adapter to convert the Map to a Java class that JAXB can use.
Кроме того, чтобы отделить элементы контракта от их реализации, мы определяемStudent как интерфейс, а JAXB также не поддерживает интерфейсы напрямую, поэтому нам нужен еще один адаптер, чтобы справиться с этим. Фактически, для удобства мы можем объявитьStudent как класс. Использование этого типа в качестве интерфейса является еще одной демонстрацией использования классов адаптации.
Адаптеры показаны в разделе справа ниже.
4. Пользовательские адаптеры
В этом разделе показан способ использования классов адаптации для поддержки привязки интерфейса Java иMap с помощью JAXB.
4.1. Интерфейсный адаптер
Вот как определяется интерфейсStudent:
В этом интерфейсе объявляется только один метод, возвращающийString, и указываетсяStudentAdapter как класс адаптации для сопоставления себя с типом, который может применять привязку JAXB, и обратно.
КлассStudentAdapter определяется следующим образом:
Класс адаптации должен реализовывать интерфейсXmlAdapter и обеспечивать реализацию для методовmarshal иunmarshal. Методmarshal преобразует связанный тип (Student, интерфейс, который JAXB не может обрабатывать напрямую) в тип значения (StudentImpl, конкретный класс, который может обрабатываться JAXB). Методunmarshal делает все наоборот.
Вот определение классаStudentImpl:
4.2. Map Адаптер
МетодgetStudents интерфейса конечной точкиexample возвращаетMap и указывает класс адаптации для преобразованияMap в тип, который может обрабатываться JAXB. Подобно классуStudentAdapter, этот класс адаптации должен реализовывать методыmarshal иunmarshal интерфейсаXmlAdapter:
КлассStudentMapAdapter отображаетMap в тип значенияStudentMap и обратно со следующим определением:
5. развертывание
5.1. Server Определение
Для развертывания описанного выше веб-сервиса мы будем использовать стандартные API-интерфейсы JAX-WS. Поскольку мы используем Apache CXF, фреймворк выполняет дополнительную работу, например, создание и публикация схемы WSDL. Вот как определяется сервисный сервер:
После того, как сервер активен некоторое время, чтобы облегчить тестирование, он должен быть выключен для освобождения системных ресурсов. Вы можете указать любую продолжительность работы сервера в зависимости от ваших потребностей, передав аргументlong методуThread.sleep.
5.2. РазвертываниеServer
КонфигурацияmainClass относится к классуServer, в котором публикуется конечная точка веб-службы. После выполнения целиjava этого плагина мы can check out the WSDL schema automatically generated by Apache CXF by accessing the URL http://localhost:8080/example?wsdl.
6. Тестовые случаи
В этом разделе описываются шаги для написания тестовых случаев, используемых для проверки веб-службы, которую мы создали ранее.
Обратите внимание, что нам нужно выполнить цельexec:java для запуска сервера веб-службы перед запуском любого теста.
6.1. подготовка
Первым шагом является объявление нескольких полей для тестового класса:
Следующий блок инициализатора используется для инициализации поляservice типаjavax.xml.ws.Service перед запуском любого теста:
После добавления зависимости JUnit к файлу POM мы можем использовать аннотацию@Before, как в фрагменте кода ниже. Этот метод запускается перед каждым тестом для повторного создания экземпляров полейexample:
6.2. Тестовая реализация
Ясно, что метод удаленной конечной точки возвращает тот же ответ, что и локальный метод, что означает, что веб-служба работает, как и ожидалось.
Следующий тестовый пример демонстрирует использование методаhelloStudent:
В этом случае клиент отправляет объектStudent в конечную точку и получает взамен сообщение, содержащее имя студента. Как и в предыдущем тесте, ответы от удаленных и локальных вызовов одинаковы.
Последний тестовый пример, который мы покажем здесь, более сложный. Как определено классом реализации конечной точки службы, каждый раз, когда клиент вызывает методhelloStudent на конечной точке, отправленный объектStudent будет сохранен в кэше. Этот кеш можно получить, вызвав методgetStudents на конечной точке. Следующий тестовый пример подтверждает, что содержимое кешаstudents представляет собой то, что клиент отправил веб-службе:
7. Заключение
В этом руководстве был представлен Apache CXF, мощная среда для работы с веб-сервисами в Java. В нем основное внимание уделялось применению инфраструктуры как стандартной реализации JAX-WS, но при этом использовались определенные возможности платформы во время выполнения.
Реализацию всех этих примеров и фрагментов кода можно найти вa GitHub project.