Я обещал расширить этот ответ чем-то примерно "правильным". Вот прогресс на сегодняшний день, который я до сих пор не совсем уверен, на 100% правильно. Подробнее об этом позже.
Все это основано на стеке схем, которые Oasis публикует для определения стандартов XACML и SAML-P для XACML. XSD были собраны в модуль Commons-Schema (не показан), настроены для исправления нескольких ошибок Oasis и скомпилированы в классы Java с JAX-B. Эти классы являются основой для услуг, описанных ниже. Свойства schema.episode.path и schema.catalog.path указывают на файлы в этом модуле.
Я разделил каждый сервис (в данном случае PolicyService) на два модуля maven. PolicyService-Svc - это сервис, и его pom выглядит так:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<executions>
<execution>
<id>Generate WSDL</id>
<phase>generate-resources</phase>
<goals>
<goal>wsgen</goal>
</goals>
<configuration>
<sei>com.technica.pbac.ps.PolicyService</sei>
<genWsdl>true</genWsdl>
<keep>true</keep>
<verbose>true</verbose>
<extension>true</extension>
<catalog>${schema.catalog.path}</catalog>
<xjcArg>-episode</xjcArg>
<xjcArg>${schema.episode.path}</xjcArg>
<xjcArg>-catalog</xjcArg>
<xjcArg>${schema.catalog.path}</xjcArg>
</configuration>
</execution>
</executions>
</plugin>
PolicyService-Proxy - это общий прокси-код, который любой клиент или служба может использовать для вызова этой службы (подробнее о проблемах с этим ниже). Его пом выглядит так:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<executions>
<execution>
<!-- <phase>generate-sources</phase> -->
<goals>
<goal>wsimport</goal>
</goals>
<configuration>
<wsdlFiles>
<wsdlFile>localhost_8080/PolicyService-Svc/PolicyService.wsdl</wsdlFile>
</wsdlFiles>
<wsdlLocation>http://localhost:8080/PolicyService-Svc/PolicyService?WSDL</wsdlLocation>
<sourceDestDir>${project.build.directory}/generated-sources/jaxws</sourceDestDir>
<genWsdl>true</genWsdl>
<verbose>true</verbose>
<extension>true</extension>
<catalog>${schema.catalog.path}</catalog>
<xjcArg>-episode</xjcArg>
<xjcArg>${schema.episode.path}</xjcArg>
</configuration>
</execution>
</executions>
</plugin>
Теперь о проблемах, о которых я бы очень хотел посоветовать. Несмотря на то, что Commons-Schema предоставляет скомпилированные классы Java для всех схем, wsgen настаивает на создании wsdl с недавно сгенерированным xsds, которые немного отличаются друг от друга и слегка некорректны по-разному.
В качестве одного примера неверного и другого SAML определяет элемент Extensions, который конфликтует с тем же именем в другой схеме. Поэтому я отремонтировал его в базовой схеме Commons следующим образом:
<element name="Extensions" type="samlp:ExtensionsType">
<annotation>
<appinfo>
<jxb:class name="Extensions-SAML"/>
</appinfo>
</annotation>
</element>
Но wsgen / wsimport пропускает это исправление, поэтому конфликт снова возникает. Разъяренный и абсолютно смертельный для телосложения.
Другое исключение обязательных включает в себя, поэтому проверка затмения сообщает о них как об ошибках до ручной коррекции. Мой обходной путь - периодически копировать сгенерированные wsdl и xsds из целевой папки в src / main / webapp / WEB-Inf / wsdl, восстанавливать их вручную и настраивать poms, чтобы использовать эту папку вместо сгенерированной внутри целевой цели. Это работает для вызова услуг от не обслуживающих клиентов. Я копирую те же wsdls и xsds в аналогичную папку клиента и проверяю, что pom ссылается на них, а не на те, которые генерирует jaxws в этом модуле.
Проблема, которую я не могу решить, возникает, когда какой-либо службе необходимо вызвать другую службу через ее прокси. Jar-прокси вызывающей службы (с его немного отличающимися версиями важных базовых классов) теперь смешивается с jar-файлами вызывающей службы (на основе классов, сгенерированных JAXB Commons-Schema), что не вызывает никаких проблем.
Может кто-нибудь посоветовать, пожалуйста? Спасибо!