Author: alessio.soldano(a)jboss.com
Date: 2010-11-02 14:00:03 -0400 (Tue, 02 Nov 2010)
New Revision: 13200
Added:
stack/cxf/trunk/src/main/doc/
stack/cxf/trunk/src/main/doc/Author_Group.xml
stack/cxf/trunk/src/main/doc/Book_Info.xml
stack/cxf/trunk/src/main/doc/JBossWS-Articlesandspecs.xml
stack/cxf/trunk/src/main/doc/JBossWS-Authentication.xml
stack/cxf/trunk/src/main/doc/JBossWS-CXF.xml
stack/cxf/trunk/src/main/doc/JBossWS-CXFJMStransporttutorial.xml
stack/cxf/trunk/src/main/doc/JBossWS-CXFWS-Addressingtutorial.xml
stack/cxf/trunk/src/main/doc/JBossWS-CXFWS-ReliableMessagingtutorial.xml
stack/cxf/trunk/src/main/doc/JBossWS-Endpointmanagement.xml
stack/cxf/trunk/src/main/doc/JBossWS-JAX-WSAnnotations.xml
stack/cxf/trunk/src/main/doc/JBossWS-JAX-WSTools.xml
stack/cxf/trunk/src/main/doc/JBossWS-QuickStart.xml
stack/cxf/trunk/src/main/doc/JBossWS-Recordsmanagement.xml
stack/cxf/trunk/src/main/doc/JBossWS-Securetransport.xml
stack/cxf/trunk/src/main/doc/JBossWS-StackCXFUserGuide.xml
stack/cxf/trunk/src/main/doc/JBossWS-UserGuide.xml
stack/cxf/trunk/src/main/doc/JBossWS-wsconsume.xml
stack/cxf/trunk/src/main/doc/JBossWS-wsprovide.xml
stack/cxf/trunk/src/main/doc/JBossWS-wsrunclient.xml
Modified:
stack/cxf/trunk/pom.xml
stack/cxf/trunk/src/main/scripts/assembly-bin-dist.xml
Log:
[JBWS-2215] Adding docbook sources and generating documentation during binary distro
creation
Modified: stack/cxf/trunk/pom.xml
===================================================================
--- stack/cxf/trunk/pom.xml 2010-11-02 14:28:01 UTC (rev 13199)
+++ stack/cxf/trunk/pom.xml 2010-11-02 18:00:03 UTC (rev 13200)
@@ -1197,6 +1197,25 @@
</dependency>
</dependencies>
</plugin>
+ <plugin>
+ <groupId>org.jboss.maven.plugins</groupId>
+ <artifactId>maven-jdocbook-plugin</artifactId>
+ <version>2.1.2</version>
+ <extensions>true</extensions>
+ <dependencies>
+ <dependency>
+ <groupId>org.jboss</groupId>
+ <artifactId>jbossorg-docbook-xslt</artifactId>
+ <version>1.1.0</version>
+ </dependency>
+ <dependency>
+ <groupId>org.jboss</groupId>
+ <artifactId>jbossorg-jdocbook-style</artifactId>
+ <version>1.0.0</version>
+ <type>jdocbook-style</type>
+ </dependency>
+ </dependencies>
+ </plugin>
</plugins>
</pluginManagement>
@@ -1279,6 +1298,49 @@
</descriptors>
</configuration>
</plugin>
+ <plugin>
+ <groupId>org.jboss.maven.plugins</groupId>
+ <artifactId>maven-jdocbook-plugin</artifactId>
+ <executions>
+ <execution>
+ <goals>
+ <goal>resources</goal>
+ <goal>generate</goal>
+ </goals>
+ <phase>package</phase>
+ </execution>
+ </executions>
+ <configuration>
+ <sourceDocumentName>JBossWS-CXF.xml</sourceDocumentName>
+ <sourceDirectory>src/main/doc</sourceDirectory>
+ <imageResource>
+ <directory>src/main/doc</directory>
+ <includes>
+ <include>images/*</include>
+ </includes>
+ </imageResource>
+ <formats>
+ <!--format>
+ <formatName>pdf</formatName>
+
<stylesheetResource>classpath:/xslt/org/jboss/pdf.xsl</stylesheetResource>
+ <finalName>JBossWS-CXF_Guide.pdf</finalName>
+ </format-->
+ <format>
+ <formatName>html</formatName>
+
<stylesheetResource>classpath:/xslt/org/jboss/xhtml.xsl</stylesheetResource>
+ <finalName>index.html</finalName>
+ </format>
+ <format>
+ <formatName>html_single</formatName>
+
<stylesheetResource>classpath:/xslt/org/jboss/xhtml-single.xsl</stylesheetResource>
+ <finalName>index.html</finalName>
+ </format>
+ </formats>
+ <options>
+ <xincludeSupported>true</xincludeSupported>
+ </options>
+ </configuration>
+ </plugin>
</plugins>
</build>
</profile>
Added: stack/cxf/trunk/src/main/doc/Author_Group.xml
===================================================================
--- stack/cxf/trunk/src/main/doc/Author_Group.xml (rev 0)
+++ stack/cxf/trunk/src/main/doc/Author_Group.xml 2010-11-02 18:00:03 UTC (rev 13200)
@@ -0,0 +1,17 @@
+<?xml version='1.0'?>
+<!DOCTYPE authorgroup PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+ ]>
+<authorgroup>
+ <author>
+ <firstname>Alessio</firstname>
+ <surname>Soldano</surname>
+ </author>
+ <author>
+ <firstname>Richard</firstname>
+ <surname>Opalka</surname>
+ </author>
+ <author>
+ <firstname>Jim</firstname>
+ <surname>Ma</surname>
+ </author>
+</authorgroup>
Added: stack/cxf/trunk/src/main/doc/Book_Info.xml
===================================================================
--- stack/cxf/trunk/src/main/doc/Book_Info.xml (rev 0)
+++ stack/cxf/trunk/src/main/doc/Book_Info.xml 2010-11-02 18:00:03 UTC (rev 13200)
@@ -0,0 +1,14 @@
+<?xml version="1.0" standalone="no"?>
+<!DOCTYPE bookinfo PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [ ]>
+
+<bookinfo>
+<title>JBossWS-CXF Guide</title>
+ <subtitle>JBoss Web Services with Apache CXF based stack</subtitle>
+ <productname>JBossWS-CXF</productname>
+ <!-- <pubdate>Nov 2010</pubdate> -->
+ <abstract>
+ <para>This book is the guide to JBoss Web Services with Apache CXF based stack.
It covers information, details and usage of JBossWS-CXF stack, as well as some tutorials /
examples.</para>
+ </abstract>
+ <!-- <subtitle>Authors</subtitle>-->
+ <xi:include href="Author_Group.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+</bookinfo>
Added: stack/cxf/trunk/src/main/doc/JBossWS-Articlesandspecs.xml
===================================================================
--- stack/cxf/trunk/src/main/doc/JBossWS-Articlesandspecs.xml (rev
0)
+++ stack/cxf/trunk/src/main/doc/JBossWS-Articlesandspecs.xml 2010-11-02 18:00:03 UTC (rev
13200)
@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?><chapter
id="chap_JBossWS-Articlesandspecs"><title>JBossWS-Articlesandspecs</title><section><title>J2EE-5.0
Web Services Specifications</title><itemizedlist><listitem><para>
<ulink
url="http://www.jcp.org/en/jsr/detail?id=244">J2EE-5.0 - Java2
Enterprise Edition Specification (JSR244)</ulink>
</para></listitem><listitem><para> <ulink
url="http://www.jcp.org/en/jsr/detail?id=921">WS4EE-1.1 - Enterprise Web
Services (JSR921)</ulink> </para></listitem><listitem><para>
<ulink
url="http://www.jcp.org/en/jsr/detail?id=220">EJB-3.0 - Enterprise
Java Beans (JSR220)</ulink>
</para></listitem><listitem><para> <ulink
url="http://www.jcp.org/en/jsr/detail?id=224">JAXWS-2.0 - Java API for
XML-Based Web Services (JSR224)</ulink>
</para></listitem><listitem><para> <ulink
url="http://www.jcp.org/en/jsr/detail?id=222">JAXB-2.0 - Java Architecture
for XML Binding (JSR222)</ulink>
</para></listitem><listitem><para> <ulink
url="http://www.w3.org/TR/soap12-!
part1">SOAP-1.2 - SOAP Messaging Framework</ulink>
</para></listitem><listitem><para> <ulink
url="http://www.w3.org/TR/soap12-part0">SOAP-1.2 Primer</ulink>
</para></listitem><listitem><para> <ulink
url="http://schemas.xmlsoap.org/wsdl/soap12">WSDL 1.1 Binding Extension for
SOAP 1.2</ulink> </para></listitem><listitem><para>
<ulink
url="http://www.w3.org/TR/wsdl20">WSDL-2.0 - Part 1: Core
Language</ulink> </para></listitem><listitem><para>
<ulink
url="http://www.w3.org/TR/wsdl20-extensions">WSDL-2.0 - Part 2:
Predefined Extensions</ulink>
</para></listitem><listitem><para> <ulink
url="http://www.w3.org/TR/wsdl20-bindings">WSDL-2.0 - Part 3:
Bindings</ulink> </para></listitem><listitem><para>
<ulink
url="http://www.w3.org/2002/ws/desc/wsdl20-primer">WSDL-2.0
Primer</ulink> </para></listitem><listitem><para> <ulink
url="http://www.ws-i.org/Profiles/BasicProfile-1.1.html">BP-1.1 - Basic
Profile</ulink> </para></listitem><listitem><para> <ulink
url="http://www.jcp.org/en/jsr/de!
tail?id=181">JSR181 - Web Services Metadata</ulink> </para></l!
istitem>
<listitem><para> <ulink
url="http://www.ws-i.org/Profiles/AttachmentsProfile-1.0.html"&...
Attachments Profile 1.0</ulink>
</para></listitem><listitem><para> <ulink
url="http://www.w3.org/TR/soap12-mtom/">SOAP Message Transmission
Optimization Mechanism (MTOM)</ulink>
</para></listitem><listitem><para> <ulink
url="http://www.w3.org/TR/xop10/">XML-binary Optimized Packaging
(XOP)</ulink></para></listitem></itemizedlist></section>
+<section><title>J2EE-1.4 Web Services
Specifications</title><itemizedlist><listitem><para> <ulink
url="http://java.sun.com/j2ee/1.4/index.jsp">J2EE-1.4 - Java 2 Platform,
Enterprise Edition (J2EE) 1.4</ulink>
</para></listitem><listitem><para> <ulink
url="http://www.jcp.org/en/jsr/detail?id=921">WS4EE-1.1 - Enterprise Web
Services</ulink> </para></listitem><listitem><para>
<ulink
url="http://www.jcp.org/en/jsr/detail?id=153">EJB-2.1 - Enterprise
Java Beans</ulink> </para></listitem><listitem><para>
<ulink
url="http://www.jcp.org/en/jsr/detail?id=101">JAXRPC-1.1 - Java API
for XML-based RPC</ulink> </para></listitem><listitem><para>
<ulink
url="http://www.jcp.org/en/jsr/detail?id=67">SAAJ-1.2 - SOAP with
Attachments</ulink> </para></listitem><listitem><para>
<ulink
url="http://www.jcp.org/en/jsr/detail?id=93">JAXR-1.0 - Java API
for XML Registries</ulink>
</para></listitem><listitem><para> <ulink
url="http://www.w3.org/TR/2000/NOTE-SOAP-20000508">SOAP-1.1 - Simple Object
Acc!
ess Protocol</ulink> </para></listitem><listitem><para>
<ulink
url="http://www.w3.org/TR/wsdl">WSDL-1.1 - Web Services Description
Language</ulink> </para></listitem><listitem><para>
<ulink
url="http://www.w3.org/TR/REC-xml/">XML-1.0 - Extensible Markup
Language</ulink> </para></listitem><listitem><para>
<ulink
url="http://www.w3.org/TR/xmlschema-1/">XMLSchema -
Structures</ulink> </para></listitem><listitem><para>
<ulink
url="http://www.w3.org/TR/xmlschema-2/">XMLSchema - Data
Types</ulink> </para></listitem><listitem><para> <ulink
url="http://www.w3.org/TR/xmlschema-0">XMLSchema Primer</ulink>
</para></listitem><listitem><para> <ulink
url="http://www.w3.org/TR/REC-xml-names">XMLNS - Namespaces in
XML</ulink> </para></listitem><listitem><para> <ulink
url="http://www.ws-i.org/Profiles/BasicProfile-1.0.html">BP-1.0 - Basic
Profile</ulink></para></listitem></itemizedlist></section>
+<section><title>Optional advanced Web Services
specifications</title><itemizedlist><listitem><para> <ulink
url="http://msdn.microsoft.com/library/default.asp?url=/library/en-u...
Web Services Specifications Index Page</ulink>
</para></listitem><listitem><para> <ulink
url="http://jira.jboss.com/jira/browse/JBWS-330">WS-Distributed
Managment</ulink> </para></listitem><listitem><para>
<ulink
url="http://jira.jboss.com/jira/browse/JBWS-326">WS-Notifica...
</para></listitem><listitem><para> <ulink
url="http://jira.jboss.com/jira/browse/JBWS-76">WS-ReliableM...
</para></listitem><listitem><para> <ulink
url="http://jira.jboss.com/jira/browse/JBWS-329">WS-Resource...
</para></listitem><listitem><para> <ulink
url="http://jira.jboss.com/jira/browse/JBWS-36">WS-Transacti...
</para></listitem><listitem><para> <ulink
url="http://jira.jboss.org/jira/browse/JBWS-447">WS-BPEL<...!
ablelist/><para>Please provide feedback on your needs of these optional WS
specifications as this will influence what we will put on the <ulink
url="http://jira.jboss.org/jira/browse/JBWS?report=com.atlassian.jir...
roadmap</ulink>.</para></section>
+</chapter>
\ No newline at end of file
Added: stack/cxf/trunk/src/main/doc/JBossWS-Authentication.xml
===================================================================
--- stack/cxf/trunk/src/main/doc/JBossWS-Authentication.xml (rev
0)
+++ stack/cxf/trunk/src/main/doc/JBossWS-Authentication.xml 2010-11-02 18:00:03 UTC (rev
13200)
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="UTF-8"?><chapter
id="chap_JBossWS-Authentication"><title>JBossWS-Authentication</title><para>This
page explains the simplest way to authenticate a web service user with
JBossWS.</para><para>First we secure the access to the SLSB as we would do for
normal (non web service) invocations: this can be easily done through the @RolesAllowed,
@PermitAll, @DenyAll annotation. The allowed user roles can be set with these annotations
both on the bean class and on any of its business methods.</para><screen
xml:space="preserve">@Stateless
+@RolesAllowed("friend")
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> EndpointEJB <emphasis
role="bold">implements</emphasis> EndpointInterface
+{
+ ...
+}
+</screen><para>Similarly POJO endpoints are secured the same way as we do for
normal web applications in web.xml:</para><screen
xml:space="preserve"> <security-constraint>
+ <web-resource-collection>
+ <web-resource-name>All resources</web-resource-name>
+ <url-pattern>/*</url-pattern>
+ </web-resource-collection>
+ <auth-constraint>
+ <role-name>friend</role-name>
+ </auth-constraint>
+ </security-constraint>
+
+ <security-role>
+ <role-name>friend</role-name>
+ </security-role></screen><section><title>Define the
security domain</title><para>Next, define the security domain for this
deployment. This is performed using the <ulink
url="http://community.jboss.org/docs/DOC-13972#SecurityDomain"&...
annotation for EJB3 endpoints</para><screen
xml:space="preserve">@Stateless
+@SecurityDomain("JBossWS")
+@RolesAllowed("friend")
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> EndpointEJB <emphasis
role="bold">implements</emphasis> EndpointInterface
+{
+ ...
+}
+</screen><para>or modifying the jboss-web.xml for POJO
endpoints</para><screen
xml:space="preserve"><jboss-web>
+ <security-domain>java:/jaas/JBossWS</security-domain>
+</jboss-web>
+</screen><para>The JBossWS security context is configured in login-config.xml
and uses the <ulink
url="http://wiki.jboss.org/wiki/Wiki.jsp?page=UsersRolesLoginModule&...;.
As a matter of fact login-config.xml, that lives in the server config dir, contains this
security domain definition:</para><screen xml:space="preserve">
<!--
+ A template configuration for the JBossWS security domain.
+ This defaults to the UsersRolesLoginModule the same as other and should be
+ changed to a stronger authentication mechanism as required.
+ -->
+ <application-policy name="JBossWS">
+ <authentication>
+ <login-module
code="org.jboss.security.auth.spi.UsersRolesLoginModule"
+ flag="required">
+ <module-option
name="usersProperties">props/jbossws-users.properties</module-option>
+ <module-option
name="rolesProperties">props/jbossws-roles.properties</module-option>
+ <module-option
name="unauthenticatedIdentity">anonymous</module-option>
+ </login-module>
+ </authentication>
+ </application-policy>
+</screen><para>Of course you can define and use your own security domain as
well as your login module (in order to check for users' identity querying a database
for example).</para></section>
+<section><title>Use BindingProvider to set
principal/credential</title><para>A web service client may use the
javax.xml.ws.BindingProvider interface to set the username/password
combination</para><screen xml:space="preserve">URL wsdlURL =
<emphasis role="bold">new</emphasis>
File("resources/jaxws/samples/context/WEB-INF/wsdl/TestEndpoint.wsdl").toURL();
+QName qname = <emphasis role="bold">new</emphasis>
QName("http://org.jboss.ws/jaxws/context", "TestEndpointService");
+Service service = Service.create(wsdlURL, qname);
+port = (TestEndpoint)service.getPort(TestEndpoint.class);
+
+BindingProvider bp = (BindingProvider)port;
+bp.getRequestContext().put(BindingProvider.USERNAME_PROPERTY, "kermit");
+bp.getRequestContext().put(BindingProvider.PASSWORD_PROPERTY, "thefrog");
+</screen></section>
+<section><title>Using HTTP Basic Auth for
security</title><para>To enable HTTP Basic authentication you use the
<ulink
url="http://community.jboss.org/docs/DOC-13972#WebContext">@...
annotation on the bean class</para><screen
xml:space="preserve">@Stateless
+@SecurityDomain("JBossWS")
+@RolesAllowed("friend")
+@WebContext(contextRoot="/my-cxt", urlPattern="/*",
authMethod="BASIC", transportGuarantee="NONE",
secureWSDLAccess=<emphasis role="bold">false</emphasis>)
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> EndpointEJB <emphasis
role="bold">implements</emphasis> EndpointInterface
+{
+ ...
+}
+</screen><para>For POJO endpoints, we modify the web.xml adding the
auth-method element:</para><screen xml:space="preserve">
<login-config>
+ <auth-method>BASIC</auth-method>
+ <realm-name>Test Realm</realm-name>
+ </login-config>
+</screen></section>
+</chapter>
\ No newline at end of file
Added: stack/cxf/trunk/src/main/doc/JBossWS-CXF.xml
===================================================================
--- stack/cxf/trunk/src/main/doc/JBossWS-CXF.xml (rev 0)
+++ stack/cxf/trunk/src/main/doc/JBossWS-CXF.xml 2010-11-02 18:00:03 UTC (rev 13200)
@@ -0,0 +1,62 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
+<book>
+
+<xi:include href="Book_Info.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+
+<part id="Main documentation">
+ <title>Main Documentation</title>
+ <partintro>
+ <para>
+ JBossWS-CXF is basically the JBoss Web Service integration with Apache CXF stack.
This way additional JBoss features and customizations are added on top of already
+ existing Apache CXF functionalities. In particular the integration provides
technologies for allowing the JBoss Application Server to support JavaEE requirements
+ in terms of Web Services functionalities.
+ </para>
+ <para>
+ Below you find the essential documentation on the current JBossWS-CXF release.
That covers a quick start, a full user guide and tooling. You can read more on
+ JBoss Web Service Framework on the JBossWS Wiki at <ulink
url="http://community.jboss.org/wiki/JBossWS">http://communi...;.
+ </para>
+ <para>
+ Please note, the wiki also offers a <ulink
url="http://www.jboss.org/community/docs/DOC-13531">Guided Tour</ulink>
along the JBossWS documentation, for those who
+ don't know where to start from when dealing with webservices in general.
+ </para>
+ </partintro>
+ <xi:include href="JBossWS-QuickStart.xml" encoding="UTF-8"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="JBossWS-UserGuide.xml" encoding="UTF-8"
xmlns:xi="http://www.w3.org/2001/XInclude" /> <!-- remove WSF stuff from
generated page -->
+ <xi:include href="JBossWS-StackCXFUserGuide.xml"
encoding="UTF-8"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="JBossWS-JAX-WSTools.xml" encoding="UTF-8"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="JBossWS-wsconsume.xml" encoding="UTF-8"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="JBossWS-wsprovide.xml" encoding="UTF-8"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="JBossWS-wsrunclient.xml" encoding="UTF-8"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+</part>
+
+
+<part id="Additional documentation">
+ <title>Additional documentation</title>
+ <partintro>
+ <para>
+ This section of the book provides documentation on common additional user
requirements, like enabling authentication, securing the transport, etc.
+ </para>
+ </partintro>
+ <xi:include href="JBossWS-Authentication.xml" encoding="UTF-8"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="JBossWS-Securetransport.xml" encoding="UTF-8"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="JBossWS-Endpointmanagement.xml"
encoding="UTF-8"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="JBossWS-Recordsmanagement.xml"
encoding="UTF-8"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+</part>
+
+
+<part id="Samples, Tutorials, references">
+ <title>Samples & Tutorials</title>
+ <partintro>
+ <para>
+ Below you find few tutorials on WS-* technologies usage as well as a brief list
of reference links and the list of supported JAX-WS annotations.
+ </para>
+ </partintro>
+ <xi:include href="JBossWS-CXFWS-Addressingtutorial.xml"
encoding="UTF-8"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="JBossWS-CXFWS-ReliableMessagingtutorial.xml"
encoding="UTF-8"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="JBossWS-CXFJMStransporttutorial.xml"
encoding="UTF-8"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="JBossWS-Articlesandspecs.xml"
encoding="UTF-8"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="JBossWS-JAX-WSAnnotations.xml"
encoding="UTF-8"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+</part>
+
+</book>
Added: stack/cxf/trunk/src/main/doc/JBossWS-CXFJMStransporttutorial.xml
===================================================================
--- stack/cxf/trunk/src/main/doc/JBossWS-CXFJMStransporttutorial.xml
(rev 0)
+++ stack/cxf/trunk/src/main/doc/JBossWS-CXFJMStransporttutorial.xml 2010-11-02 18:00:03
UTC (rev 13200)
@@ -0,0 +1,160 @@
+<?xml version="1.0" encoding="UTF-8"?><chapter
id="chap_JBossWS-CXFJMStransporttutorial"><title>JBossWS-CXFJMStransporttutorial</title><para>JBossWS-CXF
supports JMS Transport to transfer SOAP messages. There is a testcase in the codebase to
demonstrate this ability, available <ulink
url="http://anonsvn.jboss.org/repos/jbossws/stack/cxf/tags/jbossws-c...;.
In this tutorial, we will use a wsdl first web service example to show you how to enable
this feature in JBossWS.</para><para> </para><para/><section
id="JBossWS-CXFJMStransporttutorial_WSDL"><title>WSDL</title><screen
xml:space="preserve">
+<wsdl:definitions name="OrganizationJMSEndpointService"
targetNamespace="<ulink
url="http://org.jboss.ws/samples/jmstransport">http://org.jboss.ws/samples/jmstransport</ulink>"
xmlns:jms="<ulink
url="http://cxf.apache.org/transports/jms">http://cxf.apache...
xmlns:ns1="<ulink
url="http://schemas.xmlsoap.org/wsdl/soap/http">http://schem...
xmlns:soap="<ulink
url="http://schemas.xmlsoap.org/wsdl/soap/">http://schemas.x...
xmlns:tns="<ulink
url="http://org.jboss.ws/samples/jmstransport">http://org.jboss.ws/samples/jmstransport</ulink>"
xmlns:wsdl="<ulink
url="http://schemas.xmlsoap.org/wsdl/">http://schemas.xmlsoa...
xmlns:xsd="<ulink
url="http://www.w3.org/2001/XMLSchema">http://www.w3.org/200...
+ <wsdl:message name="getContactInfoResponse">
+ <wsdl:part name="return" type="xsd:string">
+ </wsdl:part>
+ </wsdl:message>
+ <wsdl:message name="getContactInfo">
+ <wsdl:part name="arg0" type="xsd:string">
+ </wsdl:part>
+ </wsdl:message>
+ <wsdl:portType name="Organization">
+ <wsdl:operation name="getContactInfo">
+ <wsdl:input message="tns:getContactInfo"
name="getContactInfo">
+ </wsdl:input>
+ <wsdl:output message="tns:getContactInfoResponse"
name="getContactInfoResponse">
+ </wsdl:output>
+ </wsdl:operation>
+ </wsdl:portType>
+ <wsdl:binding name="HTTPSoapBinding"
type="tns:Organization">
+ <soap:binding style="rpc" transport="<ulink
url="http://schemas.xmlsoap.org/soap/http">http://schemas.xm...
+ <wsdl:operation name="getContactInfo">
+ <soap:operation soapAction="" style="rpc"/>
+ <wsdl:input name="getContactInfo">
+ <soap:body namespace="<ulink
url="http://org.jboss.ws/samples/jmstransport">http://org.jboss.ws/samples/jmstransport</ulink>"
use="literal"/>
+ </wsdl:input>
+ <wsdl:output name="getContactInfoResponse">
+ <soap:body namespace="<ulink
url="http://org.jboss.ws/samples/jmstransport">http://org.jboss.ws/samples/jmstransport</ulink>"
use="literal"/>
+ </wsdl:output>
+ </wsdl:operation>
+ </wsdl:binding>
+
+ <wsdl:binding name="JMSSoapBinding"
type="tns:Organization">
+ <soap:binding style="rpc" transport="<ulink
url="http://cxf.apache.org/transports/jms">http://cxf.apache...
+ <wsdl:operation name="getContactInfo">
+ <soap:operation soapAction="" style="rpc"/>
+ <wsdl:input name="getContactInfo">
+ <soap:body namespace="<ulink
url="http://org.jboss.ws/samples/jmstransport">http://org.jboss.ws/samples/jmstransport</ulink>"
use="literal"/>
+ </wsdl:input>
+ <wsdl:output name="getContactInfoResponse">
+ <soap:body namespace="<ulink
url="http://org.jboss.ws/samples/jmstransport">http://org.jboss.ws/samples/jmstransport</ulink>"
use="literal"/>
+ </wsdl:output>
+ </wsdl:operation>
+ </wsdl:binding>
+
+
+ <wsdl:service name="OrganizationService">
+ <wsdl:port binding='tns:HTTPSoapBinding'
name='HttpEndpointPort'>
+ <soap:address location='<ulink
url="http://@jboss.bind.address@:8080/jaxws-samples-jmstransport'/">http://@jboss.bind.address@:8080/jaxws-samples-jmstransport'/</ulink>>
+ </wsdl:port>
+ <wsdl:port binding="tns:JMSSoapBinding"
name="JmsEndpointPort">
+ <jms:address
+ destinationStyle="queue"
+ jndiConnectionFactoryName="ConnectionFactory"
+ jndiDestinationName="queue/RequestQueue"
+ jndiReplyDestinationName="queue/ResponseQueue">
+ >
+ </jms:address>
+ </wsdl:port>
+ </wsdl:service>
+</wsdl:definitions></screen><para> </para><para>Apache
CXF defines the jms wsdl extension, so the jms queue name or other information about jms
in wsdl port can be parsed to send or receive jms message. Check this wiki page to see
what jms attributes you can defined in WSDL. In this wsdl, we define two queues to send
and receive the soap message. CXF uses JNDI to look up the jms ConnectionFactory, so we
may also need to provide the JNDI properties as the following example
:</para><para> </para><screen
xml:space="preserve"><jms:address
+ destinationStyle="queue"
+ jndiConnectionFactoryName="ConnectionFactory"
+ jndiDestinationName="queue/RequestQueue"
+ jndiReplyDestinationName="queue/ResponseQueue"
+ >
+ <jms:JMSNamingProperty name="java.naming.factory.initial"
+
value="org.jnp.interfaces.NamingContextFactory"/>
+ <jms:JMSNamingProperty name="java.naming.provider.url"
+ value="jnp://localhost:1099"/>
+</jms:address></screen><para> </para></section>
+<section
id="JBossWS-CXFJMStransporttutorial_Service_Implementation"><title>Service
Implementation</title><para> </para><para>After generated code
from this wsdl , we wrote two class to implement this interface for this two ports . We
annotate the portName in annotation to tell web service stack which transport this service
uses :</para><para> </para><screen
xml:space="preserve">@WebService
(serviceName="OrganizationService",
portName="HttpEndpointPort",wsdlLocation =
"WEB-INF/wsdl/jmstransport.wsdl",targetNamespace =
"http://org.jboss.ws/samples/jmstransport",
endpointInterface="org.jboss.test.ws.jaxws.samples.jmstransport.Organization")
+@SOAPBinding(style = SOAPBinding.Style.RPC)
+
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> OrganizationHttpEndpoint <emphasis
role="bold">implements</emphasis> Organization
+{
+ @WebMethod
+ <emphasis role="bold">public</emphasis> String
getContactInfo(String organization)
+ {
+ <emphasis role="bold">return</emphasis> "The '"
+ organization + "' boss is currently out of office, please call again.";
+ }
+}
+
+
+
+
+</screen><para> </para><para> </para><para> </para><screen
xml:space="preserve">@WebService
(serviceName="OrganizationService",portName="JmsEndpointPort",
wsdlLocation = "WEB-INF/wsdl/jmstransport.wsdl", targetNamespace =
"http://org.jboss.ws/samples/jmstransport",
endpointInterface="org.jboss.test.ws.jaxws.samples.jmstransport.Organization")
+@SOAPBinding(style = SOAPBinding.Style.RPC)
+
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> OrganizationJmsEndpoint <emphasis
role="bold">implements</emphasis> Organization
+{
+ @WebMethod
+ <emphasis role="bold">public</emphasis> String
getContactInfo(String organization)
+ {
+ <emphasis role="bold">return</emphasis> "The '"
+ organization + "' boss is currently out of office, please call again.";
+ }
+}
+
+
+
+
+</screen><para> </para></section>
+<section
id="JBossWS-CXFJMStransporttutorial_webxml"><title>web.xml</title><para> </para><screen
xml:space="preserve"><web-app xmlns="<ulink
url="http://java.sun.com/xml/ns/j2ee">http://java.sun.com/xm...
+ xmlns:xsi="<ulink
url="http://www.w3.org/2001/XMLSchema-instance">http://www.w...
+ xsi:schemaLocation="<ulink
url="http://java.sun.com/xml/ns/j2ee">http://java.sun.com/xm...
<ulink
url="http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">http:/...
+ version="2.4">
+
+ <servlet>
+ <servlet-name>OrganizationService</servlet-name>
+
<servlet-class>org.jboss.test.ws.jaxws.samples.jmstransport.OrganizationHttpEndpoint</servlet-class>
+ <load-on-startup>1</load-on-startup>
+ </servlet>
+
+ <servlet-mapping>
+ <servlet-name>OrganizationService</servlet-name>
+ <url-pattern>/*</url-pattern>
+
</servlet-mapping></web-app></screen><para> </para><para>It
is almost the same as the usual web.xml to deploy a web service except the
<load-on-startup> servlet initializeparameter. This is for jms service start
ready when deployment, no need to wait until the first servlet request to start the jms
endpoint.</para><para> </para></section>
+<section
id="JBossWS-CXFJMStransporttutorial_jbosswscxfxml"><title>jbossws-cxf.xml</title><para>In
addition to web.xml, the jbossws-cxf.xml is needed to actually pass in cxf to start this
two port.</para><para> </para><screen
xml:space="preserve"><beans xmlns='<ulink
url="http://www.springframework.org/schema/beans">http://www...
+ xmlns:xsi='<ulink
url="http://www.w3.org/2001/XMLSchema-instance">http://www.w...
xmlns:beans='<ulink
url="http://www.springframework.org/schema/beans">http://www...
+ xmlns:jms="<ulink
url="http://cxf.apache.org/transports/jms">http://cxf.apache...
+ xmlns:jaxws='<ulink
url="http://cxf.apache.org/jaxws">http://cxf.apache.org/jaxw...
+ xsi:schemaLocation='<ulink
url="http://www.springframework.org/schema/beans">http://www...
<ulink
url="http://www.springframework.org/schema/beans/spring-beans-2.0.xs...
+ <ulink
url="http://www.w3.org/2006/07/ws-policy">http://www.w3.org/...
<ulink
url="http://www.w3.org/2006/07/ws-policy.xsd">http://www.w3....
+ <ulink
url="http://cxf.apache.org/jaxws">http://cxf.apache.org/jaxw...
<ulink
url="http://cxf.apache.org/schemas/jaxws.xsd">http://cxf.apa...
+ <ulink
url="http://cxf.apache.org/transports/jms">http://cxf.apache...
<ulink
url="http://cxf.apache.org/schemas/configuration/jms.xsd">ht...
+
+ <import
resource="classpath:META-INF/cxf/cxf-extension-jms.xml"/>
+ <jaxws:endpoint id='SOAPQueryService'
+
implementor='org.jboss.test.ws.jaxws.samples.jmstransport.OrganizationHttpEndpoint'
+ >
+ <jaxws:invoker>
+ <bean class='org.jboss.wsf.stack.cxf.InvokerJSE'/>
+ </jaxws:invoker>
+ </jaxws:endpoint>
+
+ <jaxws:endpoint id='JMSQueryService'
+
implementor='org.jboss.test.ws.jaxws.samples.jmstransport.OrganizationJmsEndpoint'
+ transportId="<ulink
url="http://cxf.apache.org/transports/jms">http://cxf.apache...
+ </jaxws:endpoint>
+</beans></screen><para> </para><para><emphasis
role="bold">Note: </emphasis>the import resource is the
JmsTransportFactory configuration . It is required to jms transport enablement
.</para><para> </para><para>Below gives the war file directory
structure to make it more clear what inside :</para><screen
xml:space="preserve">
+|-- jmstransport-sample.war
+`-- WEB-INF
+ |-- classes
+ | `-- org
+ | `-- jboss
+ | `-- test
+ | `-- ws
+ | `-- jaxws
+ | `-- samples
+ | `-- jmstransport
+ | |-- JMSTransportTestCase$ResponseListener.class
+ | |-- JMSTransportTestCase.class
+ | |-- Organization.class
+ | |-- OrganizationHttpEndpoint.class
+ | `-- OrganizationJmsEndpoint.class
+ |-- jboss-web.xml
+ |-- jbossws-cxf.xml
+ |-- web.xml
+ `-- wsdl
+ `-- jmstransport.wsdl</screen></section>
+</chapter>
\ No newline at end of file
Added: stack/cxf/trunk/src/main/doc/JBossWS-CXFWS-Addressingtutorial.xml
===================================================================
--- stack/cxf/trunk/src/main/doc/JBossWS-CXFWS-Addressingtutorial.xml
(rev 0)
+++ stack/cxf/trunk/src/main/doc/JBossWS-CXFWS-Addressingtutorial.xml 2010-11-02 18:00:03
UTC (rev 13200)
@@ -0,0 +1,170 @@
+<?xml version="1.0" encoding="UTF-8"?><chapter
id="chap_JBossWS-CXFWS-Addressingtutorial"><title>JBossWS-CXFWS-Addressingtutorial</title><para><ulink
url="http://incubator.apache.org/cxf/">Apache CXF</ulink> comes with
support for <ulink
url="http://www.w3.org/TR/ws-addr-core/">WS-Addressing
1.0</ulink>. In this sample we will show how to create client and endpoint
communicating each other using this feature.</para><para>Creating
WS-Addressing based service and client is very simple. User needs to create regular JAX-WS
service and client first. The last step is to configure the addressing on both
sides.</para><para> </para><para/><para> </para><section
id="JBossWS-CXFWS-Addressingtutorial_The_Service"><title>The
Service</title><para>We will start with the following endpoint implementation
(bottom-up approach):</para><para> </para><screen
xml:space="preserve">@WebService
+(
+ portName = "AddressingServicePort",
+ serviceName = "AddressingService",
+ targetNamespace =
"http://www.jboss.org/jbossws/ws-extensions/wsaddressing",
+ endpointInterface = "org.jboss.test.ws.jaxws.samples.wsa.ServiceIface"
+)
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> ServiceImpl <emphasis
role="bold">implements</emphasis> ServiceIface
+{
+ <emphasis role="bold">public</emphasis> String sayHello()
+ {
+ <emphasis role="bold">return</emphasis> "Hello
World!";
+ }
+}
+</screen><para>The endpoint implements the following endpoint
interface:</para><screen xml:space="preserve"><emphasis
role="bold">package</emphasis> org.jboss.test.ws.jaxws.samples.wsa;
+
+<emphasis role="bold">import</emphasis> javax.jws.WebMethod;
+<emphasis role="bold">import</emphasis> javax.jws.WebService;
+
+@WebService
+(
+ targetNamespace = "http://www.jboss.org/jbossws/ws-extensions/wsaddressing"
+)
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">interface</emphasis> ServiceIface
+{
+ @WebMethod
+ String sayHello();
+}
+</screen><para>Let's say that compiled endpoint and interface classes are
located in directory <emphasis
role="bold">/home/username/wsa/cxf/classes</emphasis>. Our next step is
to generate JAX-WS artifacts and WSDL that will be part of endpoint
archive.</para><para> </para></section>
+<section
id="JBossWS-CXFWS-Addressingtutorial_Generating_WSDL_and_JAXWS_Endpoint_Artifacts"><title>Generating
WSDL and JAX-WS Endpoint Artifacts</title><para>We will use <emphasis
role="bold">wsprovide</emphasis> commandline tool to generate WSDL and
JAX-WS artifacts. Here's the command:</para><screen
xml:space="preserve">cd JBOSS_HOME/bin
+
+./wsprovide.sh --keep --wsdl \
+ --classpath=/home/username/wsa/cxf/classes \
+ --output=/home/username/wsa/cxf/wsprovide/generated/classes \
+ --resource=/home/username/wsa/cxf/wsprovide/generated/wsdl \
+ --source=/home/username/wsa/cxf/wsprovide/generated/src \
+ org.jboss.test.ws.jaxws.samples.wsa.ServiceImpl
+</screen><para>The above command generates the following
artifacts:</para><screen xml:space="preserve"># compiled classes
+ls
/home/username/wsa/cxf/wsprovide/generated/classes/org/jboss/test/ws/jaxws/samples/wsa/jaxws
+SayHello.class SayHelloResponse.class
+
+# java sources
+ls
/home/username/wsa/cxf/wsprovide/generated/src/org/jboss/test/ws/jaxws/samples/wsa/jaxws
+SayHello.java SayHelloResponse.java
+
+# contract artifacts
+ls /home/username/wsa/cxf/wsprovide/generated/wsdl/
+AddressingService.wsdl</screen><para>All aforementioned generated artifacts
will be part of endpoint archive. But before we will create the endpoint archive we need
to reference generated WSDL from endpoint. To achieve that we will use <emphasis
role="bold">wsdlLocation</emphasis> annotation attribute. Here's
the updated endpoint implementation before packaging it to the war
file:</para><screen xml:space="preserve"><emphasis
role="bold">package</emphasis> org.jboss.test.ws.jaxws.samples.wsa;
+
+<emphasis role="bold">import</emphasis> javax.jws.WebService;
+
+@WebService
+(
+ portName = "AddressingServicePort",
+ serviceName = "AddressingService",
+ wsdlLocation = "WEB-INF/wsdl/AddressingService.wsdl",
+ targetNamespace =
"http://www.jboss.org/jbossws/ws-extensions/wsaddressing",
+ endpointInterface = "org.jboss.test.ws.jaxws.samples.wsa.ServiceIface"
+)
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> ServiceImpl <emphasis
role="bold">implements</emphasis> ServiceIface
+{
+ <emphasis role="bold">public</emphasis> String sayHello()
+ {
+ <emphasis role="bold">return</emphasis> "Hello
World!";
+ }
+}
+</screen><para> </para><para>Created endpoint war archive
consists of the following entries:</para><para> </para><screen
xml:space="preserve">jar -tvf jaxws-samples-wsa.war
+ 0 Mon Apr 21 20:39:30 CEST 2008 META-INF/
+ 106 Mon Apr 21 20:39:28 CEST 2008 META-INF/MANIFEST.MF
+ 0 Mon Apr 21 20:39:30 CEST 2008 WEB-INF/
+ 593 Mon Apr 21 20:39:28 CEST 2008 WEB-INF/web.xml
+ 0 Mon Apr 21 20:39:30 CEST 2008 WEB-INF/classes/
+ 0 Mon Apr 21 20:39:26 CEST 2008 WEB-INF/classes/org/
+ 0 Mon Apr 21 20:39:26 CEST 2008 WEB-INF/classes/org/jboss/
+ 0 Mon Apr 21 20:39:26 CEST 2008 WEB-INF/classes/org/jboss/test/
+ 0 Mon Apr 21 20:39:26 CEST 2008 WEB-INF/classes/org/jboss/test/ws/
+ 0 Mon Apr 21 20:39:26 CEST 2008 WEB-INF/classes/org/jboss/test/ws/jaxws/
+ 0 Mon Apr 21 20:39:26 CEST 2008 WEB-INF/classes/org/jboss/test/ws/jaxws/samples/
+ 0 Mon Apr 21 20:39:26 CEST 2008
WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsa/
+ 374 Mon Apr 21 20:39:26 CEST 2008
WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsa/ServiceIface.class
+ 954 Mon Apr 21 20:39:26 CEST 2008
WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsa/ServiceImpl.class
+ 0 Mon Apr 21 20:39:26 CEST 2008
WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsa/jaxws/
+ 703 Mon Apr 21 20:39:26 CEST 2008
WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsa/jaxws/SayHello.class
+ 1074 Mon Apr 21 20:39:26 CEST 2008
WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsa/jaxws/SayHelloResponse.class
+ 0 Mon Apr 21 20:39:30 CEST 2008 WEB-INF/wsdl/
+ 2378 Mon Apr 21 20:39:28 CEST 2008 WEB-INF/wsdl/AddressingService.wsdl
+</screen><para>The content of web.xml file is:</para><screen
xml:space="preserve"><?xml version="1.0"
encoding="UTF-8"?><web-app
+ version="2.5" xmlns="<ulink
url="http://java.sun.com/xml/ns/javaee">http://java.sun.com/...
+ xmlns:xsi="<ulink
url="http://www.w3.org/2001/XMLSchema-instance">http://www.w...
+ xsi:schemaLocation="<ulink
url="http://java.sun.com/xml/ns/javaee">http://java.sun.com/...
<ulink
url="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">http...
+ <servlet>
+ <servlet-name>AddressingService</servlet-name>
+
<servlet-class>org.jboss.test.ws.jaxws.samples.wsa.ServiceImpl</servlet-class>
+ </servlet>
+ <servlet-mapping>
+ <servlet-name>AddressingService</servlet-name>
+ <url-pattern>/*</url-pattern>
+ </servlet-mapping>
+</web-app>
+</screen></section>
+<section
id="JBossWS-CXFWS-Addressingtutorial_Writing_Regular_JAXWS_Client"><title>Writing
Regular JAX-WS Client</title><para>The following is the regular JAX-WS client
using endpoint interface to lookup the
webservice:</para><para> </para><para>package
org.jboss.test.ws.jaxws.samples.wsa;</para><screen
xml:space="preserve">import java.net.URL;import
javax.xml.namespace.QName;import javax.xml.ws.Service;public final class
SimpleServiceTestCase{ private final String serviceURL = "http://" +
getServerHost() + ":8080/jaxws-samples-wsa/AddressingService"; public
static void main(String[] args) throws Exception { // create service QName
serviceName = new
QName("http://www.jboss.org/jbossws/ws-extensions/wsaddressing",
"AddressingService"); URL wsdlURL = new URL(serviceURL +
"?wsdl"); Service service = Service.create(wsdlURL, serviceName);
ServiceIface proxy = (ServiceIface)service.getPort(ServiceIface.class); �!
� // invoke method proxy.sayHello(); } }</screen><para>Now
we have both endpoint and client implementation but without WS-Addressing in place. Our
next goal is to turn on the WS-Addressing feature.</para></section>
+<section
id="JBossWS-CXFWS-Addressingtutorial_Turning_on_WSAddressing_10"><title>Turning
on WS-Addressing 1.0</title><para>In order to turn on WS-Addressing in
JBossWS-CXF integration the last two steps are
remaining:</para><itemizedlist><listitem><para>annotate service
endpoint with @Addressing
annotation</para></listitem><listitem><para>modify client to
configure WS-Addressing using JAX-WS webservice
feature</para></listitem></itemizedlist><para> </para><section
id="JBossWS-CXFWS-Addressingtutorial_Updating_Endpoint_Code_to_Configure_WSAddressing"><title>Updating
Endpoint Code to Configure WS-Addressing</title><para>Now we need to update
endpoint implementation to configure WS-Addressing. Here's the updated endpoint
code:</para><screen xml:space="preserve"><emphasis
role="bold">package</emphasis> org.jboss.test.ws.jaxws.samples.wsa;
+
+<emphasis role="bold">import</emphasis> javax.jws.WebService;
+<emphasis role="bold">import</emphasis>
javax.xml.ws.soap.Addressing;
+
+@WebService
+(
+ portName = "AddressingServicePort",
+ serviceName = "AddressingService",
+ wsdlLocation = "WEB-INF/wsdl/AddressingService.wsdl",
+ targetNamespace =
"http://www.jboss.org/jbossws/ws-extensions/wsaddressing",
+ endpointInterface = "org.jboss.test.ws.jaxws.samples.wsa.ServiceIface"
+)
+@Addressing(enabled=true, required=<emphasis
role="bold">true</emphasis>)
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> ServiceImpl <emphasis
role="bold">implements</emphasis> ServiceIface
+{
+ <emphasis role="bold">public</emphasis> String sayHello()
+ {
+ <emphasis role="bold">return</emphasis> "Hello
World!";
+ }
+}
+</screen><para>As users can see we added JAX-WS 2.1 <emphasis
role="bold">Addressing</emphasis> annotation to configure
WS-Addressing. The next step is to repackage the endpoint archive to apply this
change.</para><para> </para></section>
+<section
id="JBossWS-CXFWS-Addressingtutorial_Updating_Client_Code_to_Configure_WSAddressing"><title>Updating
Client Code to Configure WS-Addressing</title><para>Now we need to update
client implementation as well to configure WS-Addressing. Here's the updated client
code:</para><screen xml:space="preserve"><emphasis
role="bold">package</emphasis> org.jboss.test.ws.jaxws.samples.wsa;
+
+<emphasis role="bold">import</emphasis> java.net.URL;
+<emphasis role="bold">import</emphasis> javax.xml.namespace.QName;
+<emphasis role="bold">import</emphasis> javax.xml.ws.Service;
+<emphasis role="bold">import</emphasis>
javax.xml.ws.soap.AddressingFeature;
+
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">final</emphasis> <emphasis
role="bold">class</emphasis> AddressingTestCase
+{
+ <emphasis role="bold">private</emphasis> <emphasis
role="bold">final</emphasis> String serviceURL = "http://" +
getServerHost() + ":8080/jaxws-samples-wsa/AddressingService";
+
+ <emphasis role="bold">public</emphasis> <emphasis
role="bold">static</emphasis> <emphasis
role="bold">void</emphasis> main(String[] args) <emphasis
role="bold">throws</emphasis> Exception
+ {
+ // construct proxy
+ QName serviceName = <emphasis role="bold">new</emphasis>
QName("http://www.jboss.org/jbossws/ws-extensions/wsaddressing",
"AddressingService");
+ URL wsdlURL = <emphasis role="bold">new</emphasis>
URL(serviceURL + "?wsdl");
+ Service service = Service.create(wsdlURL, serviceName);
+ ServiceIface proxy = (ServiceIface)service.getPort(ServiceIface.class,
<emphasis role="bold">new</emphasis> AddressingFeature());
+ // invoke method
+ assertEquals("Hello World!", proxy.sayHello());
+ }
+
+}
+</screen><para>And that's all. Now we have both JAX-WS client and
endpoint communicating each other using WS-Addressing
feature.</para><para> </para><para> </para></section>
+<section
id="JBossWS-CXFWS-Addressingtutorial_Leveraging_WSAddressing_Policy"><title>Leveraging
WS-Addressing Policy</title><para>An option you can also evaluate to simplify
both client and server deployment, is to let the server engine generate and publish the
wsdl contract instead of using the one mentioned above: (please note the removal of
wsdlLocation attribute in the @WebService
annotation)</para><para> </para><screen
xml:space="preserve">@WebService
+(
+ portName = "AddressingServicePort",
+ serviceName = "AddressingService",
+ targetNamespace =
"http://www.jboss.org/jbossws/ws-extensions/wsaddressing",
+ endpointInterface = "org.jboss.test.ws.jaxws.samples.wsa.ServiceIface"
+)
+@Addressing(enabled=true, required=<emphasis
role="bold">true</emphasis>)
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> ServiceImpl <emphasis
role="bold">implements</emphasis> ServiceIface
+{
+ ...
+}
+</screen><para> </para><para>This way the endpoint is published
with a contract containing a WS-Addressing Policy that tells clients addressing needs to
be on.</para><para> </para><screen
xml:space="preserve"><wsp:Policy
wsu:Id="AddressingServiceSoapBinding_WSAM_Addressing_Policy">
+ <wsam:Addressing>
+ <wsp:Policy/>
+ </wsam:Addressing>
+</wsp:Policy></screen><para> </para><para>The
client can then simply do as follows:</para><para> </para><screen
xml:space="preserve">Service service = Service.create(wsdlURL, serviceName);
+ServiceIface proxy = (ServiceIface)service.getPort(ServiceIface.class);
+// invoke method
+</screen><para> </para><para>No need for setting the
AddressingFeature, the policy engine takes care of enabling WS-Addressing to match the
policy advertised by the server.</para><para> </para></section>
+</section>
+<section
id="JBossWS-CXFWS-Addressingtutorial_Sample_Sources"><title>Sample
Sources</title><para>All sources from this tutorial are part of JBossWS-CXF
testsuite.</para></section>
+</chapter>
\ No newline at end of file
Added: stack/cxf/trunk/src/main/doc/JBossWS-CXFWS-ReliableMessagingtutorial.xml
===================================================================
--- stack/cxf/trunk/src/main/doc/JBossWS-CXFWS-ReliableMessagingtutorial.xml
(rev 0)
+++ stack/cxf/trunk/src/main/doc/JBossWS-CXFWS-ReliableMessagingtutorial.xml 2010-11-02
18:00:03 UTC (rev 13200)
@@ -0,0 +1,319 @@
+<?xml version="1.0" encoding="UTF-8"?><chapter
id="chap_JBossWS-CXFWS-ReliableMessagingtutorial"><title>JBossWS-CXFWS-ReliableMessagingtutorial</title><para><ulink
url="http://incubator.apache.org/cxf/">Apache CXF</ulink> comes with
support for <ulink
url="http://specs.xmlsoap.org/ws/2005/02/rm/ws-reliablemessaging.pdf...
1.0</ulink>. In this sample we will show how to create client and endpoint
communicating each other using WS-RM 1.0. The sample uses <ulink
url="http://www.w3.org/2006/07/ws-policy/">WS-Policy</uli...
specification to configure WS-RM.</para><para>Creating the WS-RM based service
and client is very simple. User needs to create regular JAX-WS service and client first.
The last step is to configure WSRM.</para><para/><section
id="JBossWS-CXFWS-ReliableMessagingtutorial_The_service"><title>The
service</title><para>We will start with the following endpoint implementation
(bottom-up approach):</para><screen
xml:space="preserve"><emphasis role="bold">package<!
/emphasis> org.jboss.test.ws.jaxws.samples.wsrm.service;
+
+<emphasis role="bold">import</emphasis> javax.jws.Oneway;
+<emphasis role="bold">import</emphasis> javax.jws.WebMethod;
+<emphasis role="bold">import</emphasis> javax.jws.WebService;
+
+@WebService
+(
+ name = "SimpleService",
+ serviceName = "SimpleService",
+ targetNamespace = "http://www.jboss.org/jbossws/ws-extensions/wsrm"
+)
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> SimpleServiceImpl
+{
+ @Oneway
+ @WebMethod
+ <emphasis role="bold">public</emphasis> <emphasis
role="bold">void</emphasis> ping()
+ {
+ System.out.println("ping()");
+ }
+
+ @WebMethod
+ <emphasis role="bold">public</emphasis> String echo(String s)
+ {
+ System.out.println("echo(" + s + ")");
+ <emphasis role="bold">return</emphasis> s;
+ }
+}
+</screen><para>Let's say that compiled endpoint class is in directory
<emphasis role="bold">/home/username/wsrm/cxf/classes</emphasis>.
Our next step is to generate JAX-WS artifacts and
WSDL.</para><para> </para></section>
+<section
id="JBossWS-CXFWS-ReliableMessagingtutorial_Generating_WSDL_and_JAXWS_Endpoint_Artifacts"><title>Generating
WSDL and JAX-WS Endpoint Artifacts</title><para>We will use <emphasis
role="bold">wsprovide</emphasis> commandline tool to generate WSDL and
JAX-WS artifacts. Here's the command:</para><screen
xml:space="preserve">cd $JBOSS_HOME/bin
+
+./wsprovide.sh --keep --wsdl \
+ --classpath=/home/username/wsrm/cxf/classes \
+ --output=/home/username/wsrm/cxf/wsprovide/generated/classes \
+ --resource=/home/username/wsrm/cxf/wsprovide/generated/wsdl \
+ --source=/home/username/wsrm/cxf/wsprovide/generated/src \
+ org.jboss.test.ws.jaxws.samples.wsrm.service.SimpleServiceImpl
+</screen><para>The above command generates the following
artifacts:</para><screen xml:space="preserve"># compiled classes
+ls
/home/username/wsrm/cxf/wsprovide/generated/classes/org/jboss/test/ws/jaxws/samples/wsrm/service/jaxws/
+Echo.class EchoResponse.class Ping.class
+
+# java sources
+ls
/home/username/wsrm/cxf/wsprovide/generated/src/org/jboss/test/ws/jaxws/samples/wsrm/service/jaxws/
+Echo.java EchoResponse.java Ping.java
+
+# contract artifacts
+ls /home/username/wsrm/cxf/wsprovide/generated/wsdl/
+SimpleService.wsdl
+</screen><para>All aforementioned generated artifacts will be part of
endpoint archive. But before we will create the endpoint archive we need to reference
generated WSDL from endpoint. To achieve that we will use <emphasis
role="bold">wsdlLocation</emphasis> annotation attribute. Here's
the updated endpoint implementation before packaging it to the war
file:</para><screen xml:space="preserve"><emphasis
role="bold">package</emphasis>
org.jboss.test.ws.jaxws.samples.wsrm.service;
+
+<emphasis role="bold">import</emphasis> javax.jws.Oneway;
+<emphasis role="bold">import</emphasis> javax.jws.WebMethod;
+<emphasis role="bold">import</emphasis> javax.jws.WebService;
+
+@WebService
+(
+ name = "SimpleService",
+ serviceName = "SimpleService",
+ wsdlLocation = "WEB-INF/wsdl/SimpleService.wsdl",
+ targetNamespace = "http://www.jboss.org/jbossws/ws-extensions/wsrm"
+)
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> SimpleServiceImpl
+{
+ @Oneway
+ @WebMethod
+ <emphasis role="bold">public</emphasis> <emphasis
role="bold">void</emphasis> ping()
+ {
+ System.out.println("ping()");
+ }
+
+ @WebMethod
+ <emphasis role="bold">public</emphasis> String echo(String s)
+ {
+ System.out.println("echo(" + s + ")");
+ <emphasis role="bold">return</emphasis> s;
+ }
+}
+</screen><para>Created endpoint war archive consists of the following
entries:</para><screen xml:space="preserve">jar -tvf
jaxws-samples-wsrm.war
+ 0 Wed Apr 16 14:39:22 CEST 2008 META-INF/
+ 106 Wed Apr 16 14:39:20 CEST 2008 META-INF/MANIFEST.MF
+ 0 Wed Apr 16 14:39:22 CEST 2008 WEB-INF/
+ 591 Wed Apr 16 14:39:20 CEST 2008 WEB-INF/web.xml
+ 0 Wed Apr 16 14:39:22 CEST 2008 WEB-INF/classes/
+ 0 Wed Apr 16 14:39:18 CEST 2008 WEB-INF/classes/org/
+ 0 Wed Apr 16 14:39:18 CEST 2008 WEB-INF/classes/org/jboss/
+ 0 Wed Apr 16 14:39:18 CEST 2008 WEB-INF/classes/org/jboss/test/
+ 0 Wed Apr 16 14:39:18 CEST 2008 WEB-INF/classes/org/jboss/test/ws/
+ 0 Wed Apr 16 14:39:20 CEST 2008 WEB-INF/classes/org/jboss/test/ws/jaxws/
+ 0 Wed Apr 16 14:39:20 CEST 2008 WEB-INF/classes/org/jboss/test/ws/jaxws/samples/
+ 0 Wed Apr 16 14:39:18 CEST 2008
WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsrm/
+ 0 Wed Apr 16 14:39:18 CEST 2008
WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsrm/service/
+ 0 Wed Apr 16 14:39:18 CEST 2008
WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsrm/service/jaxws/
+ 1235 Wed Apr 16 14:39:18 CEST 2008
WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsrm/service/SimpleServiceImpl.class
+ 997 Wed Apr 16 14:39:18 CEST 2008
WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsrm/service/jaxws/Echo.class
+ 1050 Wed Apr 16 14:39:18 CEST 2008
WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsrm/service/jaxws/EchoResponse.class
+ 679 Wed Apr 16 14:39:18 CEST 2008
WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsrm/service/jaxws/Ping.class
+ 0 Wed Apr 16 14:39:22 CEST 2008 WEB-INF/wsdl/
+ 2799 Wed Apr 16 14:39:20 CEST 2008 WEB-INF/wsdl/SimpleService.wsdl
+</screen><para>The content of web.xml file is:</para><screen
xml:space="preserve"><?xml version="1.0"
encoding="UTF-8"?>
+
+<web-app
+ version="2.5"
xmlns="http://java.sun.com/xml/ns/javaee"
+
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
+ <servlet>
+ <servlet-name>SimpleService</servlet-name>
+
<servlet-class>org.jboss.test.ws.jaxws.samples.wsrm.service.SimpleServiceImpl</servlet-class>
+ </servlet>
+ <servlet-mapping>
+ <servlet-name>SimpleService</servlet-name>
+ <url-pattern>/*</url-pattern>
+ </servlet-mapping>
+</web-app></screen></section>
+<section
id="JBossWS-CXFWS-ReliableMessagingtutorial_Generating_JAXWS_Client_Artifacts"><title>Generating
JAX-WS Client Artifacts</title><para>Before we will write regular JAX-WS
client we need to generate client artifacts from WSDL. Here's the command to achieve
that:</para><screen xml:space="preserve">cd $JBOSS_HOME/bin
+
+./wsconsume.sh --keep \
+ --package=org.jboss.test.ws.jaxws.samples.wsrm.generated \
+ --output=/home/username/wsrm/cxf/wsconsume/generated/classes \
+ --source=/home/username/wsrm/cxf/wsconsume/generated/src \
+ /home/username/wsrm/cxf/wsprovide/generated/wsdl/SimpleService.wsdl
+</screen><para>The above command generates the following
artifacts:</para><screen xml:space="preserve"># compiled classes
+ls
/home/username/wsrm/cxf/wsconsume/generated/classes/org/jboss/test/ws/jaxws/samples/wsrm/generated/
+Echo.class ObjectFactory.class Ping.class
SimpleService_Service.class
+EchoResponse.class package-info.class SimpleService.class
SimpleService_SimpleServicePort_Client.class
+
+# java sources
+ls
/home/username/wsrm/cxf/wsconsume/generated/src/org/jboss/test/ws/jaxws/samples/wsrm/generated/
+Echo.java ObjectFactory.java Ping.java SimpleService_Service.java
+EchoResponse.java package-info.java SimpleService.java
SimpleService_SimpleServicePort_Client.java
+</screen><para>Now the last step is to write the regular JAX-WS client using
generated artifacts.</para><para> </para></section>
+<section
id="JBossWS-CXFWS-ReliableMessagingtutorial_Writing_Regular_JAXWS_Client"><title>Writing
Regular JAX-WS Client</title><para>The following is the regular JAX-WS client
using generated artifacts:</para><screen
xml:space="preserve">package org.jboss.test.ws.jaxws.samples.wsrm.client;
+
+import java.net.URL;
+import javax.xml.namespace.QName;
+import javax.xml.ws.Service;
+import org.jboss.test.ws.jaxws.samples.wsrm.generated.SimpleService;
+
+public final class SimpleServiceTestCase
+{
+
+ private static final String serviceURL =
"http://localhost:8080/jaxws-samples-wsrm/SimpleService";
+
+ public static void main(String[] args) throws Exception
+ {
+ // create service
+ QName serviceName = new
QName("http://www.jboss.org/jbossws/ws-extensions/wsrm",
"SimpleService");
+ URL wsdlURL = new URL(serviceURL + "?wsdl");
+ Service service = Service.create(wsdlURL, serviceName);
+ SimpleService proxy = (SimpleService)service.getPort(SimpleService.class);
+
+ // invoke methods
+ proxy.ping(); // one way call
+ proxy.echo("Hello World!"); // request responce call
+ }
+
+}
+</screen><para>Now we have both endpoint and client implementation but
without WSRM in place. Our next goal is to turn on the WS-RM
feature.</para><para> </para></section>
+<section
id="JBossWS-CXFWS-ReliableMessagingtutorial_Turning_on_WSRM_10"><title>Turning
on WS-RM 1.0</title><section
id="JBossWS-CXFWS-ReliableMessagingtutorial_Extending_WSDL_Using_WSPolicy"><title>Extending
WSDL Using WS-Policy</title><para>To activate WSRM on server side we need to
extend the WSDL with WSRM and addressing policies. Here is how it looks
like:</para><screen xml:space="preserve"><?xml
version="1.0" encoding="UTF-8"?>
+<wsdl:definitions name="SimpleService" targetNamespace="<ulink
url="http://www.jboss.org/jbossws/ws-extensions/wsrm">http:/...
xmlns:tns="<ulink
url="http://www.jboss.org/jbossws/ws-extensions/wsrm">http:/...
xmlns:xsd="<ulink
url="http://www.w3.org/2001/XMLSchema">http://www.w3.org/200...
xmlns:soap="<ulink
url="http://schemas.xmlsoap.org/wsdl/soap/">http://schemas.x...
xmlns:wsdl="<ulink
url="http://schemas.xmlsoap.org/wsdl/">http://schemas.xmlsoa...
xmlns:wsp="<ulink
url="http://www.w3.org/2006/07/ws-policy">http://www.w3.org/...
+<wsdl:types>
+<xsd:schema xmlns:xsd="<ulink
url="http://www.w3.org/2001/XMLSchema">http://www.w3.org/200...
xmlns:tns="<ulink
url="http://www.jboss.org/jbossws/ws-extensions/wsrm">http:/...
attributeFormDefault="unqualified" elementFormDefault="unqualified"
targetNamespace="<ulink
url="http://www.jboss.org/jbossws/ws-extensions/wsrm">http:/...
+<xsd:element name="ping" type="tns:ping"/>
+<xsd:complexType name="ping">
+<xsd:sequence/>
+</xsd:complexType>
+<xsd:element name="echo" type="tns:echo"/>
+<xsd:complexType name="echo">
+<xsd:sequence>
+<xsd:element minOccurs="0" name="arg0"
type="xsd:string"/>
+</xsd:sequence>
+</xsd:complexType>
+<xsd:element name="echoResponse"
type="tns:echoResponse"/>
+<xsd:complexType name="echoResponse">
+<xsd:sequence>
+<xsd:element minOccurs="0" name="return"
type="xsd:string"/>
+</xsd:sequence>
+</xsd:complexType>
+</xsd:schema>
+ </wsdl:types>
+ <wsdl:message name="echoResponse">
+ <wsdl:part name="parameters"
element="tns:echoResponse">
+ </wsdl:part>
+ </wsdl:message>
+ <wsdl:message name="echo">
+ <wsdl:part name="parameters" element="tns:echo">
+ </wsdl:part>
+ </wsdl:message>
+ <wsdl:message name="ping">
+ <wsdl:part name="parameters" element="tns:ping">
+ </wsdl:part>
+ </wsdl:message>
+ <wsdl:portType name="SimpleService">
+ <wsdl:operation name="ping">
+ <wsdl:input name="ping" message="tns:ping">
+ </wsdl:input>
+ </wsdl:operation>
+ <wsdl:operation name="echo">
+ <wsdl:input name="echo" message="tns:echo">
+ </wsdl:input>
+ <wsdl:output name="echoResponse"
message="tns:echoResponse">
+ </wsdl:output>
+ </wsdl:operation>
+ </wsdl:portType>
+ <wsdl:binding name="SimpleServiceSoapBinding"
type="tns:SimpleService">
+
+ <!-- - - - - - - - - - - - - - - - - - - - - - - - - - -->
+ <!-- Created WS-Policy with WSRM addressing assertions -->
+ <!-- - - - - - - - - - - - - - - - - - - - - - - - - -
--><wsp:Policy>
+ <wswa:UsingAddressing xmlns:wswa="<ulink
url="http://www.w3.org/2006/05/addressing/wsdl">http://www.w...
+ <wsrmp:RMAssertion xmlns:wsrmp="<ulink
url="http://schemas.xmlsoap.org/ws/2005/02/rm/policy">http:/...
+ </wsp:Policy>
+
+ <soap:binding style="document" transport="<ulink
url="http://schemas.xmlsoap.org/soap/http">http://schemas.xm...
+ <wsdl:operation name="ping">
+ <soap:operation soapAction="" style="document"/>
+ <wsdl:input name="ping">
+ <soap:body use="literal"/>
+ </wsdl:input>
+ </wsdl:operation>
+ <wsdl:operation name="echo">
+ <soap:operation soapAction="" style="document"/>
+ <wsdl:input name="echo">
+ <soap:body use="literal"/>
+ </wsdl:input>
+ <wsdl:output name="echoResponse">
+ <soap:body use="literal"/>
+ </wsdl:output>
+ </wsdl:operation>
+ </wsdl:binding>
+ <wsdl:service name="SimpleService">
+ <wsdl:port name="SimpleServicePort"
binding="tns:SimpleServiceSoapBinding">
+ <soap:address location="<ulink
url="http://localhost:9090/hello">http://localhost:9090/hello</ulink>"/>
+ </wsdl:port>
+ </wsdl:service>
+</wsdl:definitions>
+</screen><para> </para><para> </para></section>
+<section
id="JBossWS-CXFWS-ReliableMessagingtutorial_Basic_WSRM_configuration"><title>Basic
WS-RM configuration</title><para>Once the endpoint wsdl is properly updated
with the policies elements, the JBossWS-CXF stack is
<emphasis>automatically</emphasis> able to detect the need for the WS-Policy
engine to be used, both on client and server side, for enabling WS-Reliable
Messaging.</para><para>The endpoint advertises RM capabilities through the
published wsdl and the client is required to also enable WS-RM for successfully exchanging
messages with the server.</para><para>The regular jaxws client above is enough
if the user does not need to tune any specific detail of the RM subsystem (acknowledgment
/ retransmission intervals, thresholds,
...)</para><para> </para></section>
+<section
id="JBossWS-CXFWS-ReliableMessagingtutorial_Advanced_WSRM_configuration"><title>Advanced
WS-RM configuration</title><para>When users want to have full control over the
way WS-RM communication is established, the current CXF Bus needs to be properly
configured. This can be done through a CXF Spring configuration.</para><section
id="JBossWS-CXFWS-ReliableMessagingtutorial_Providing_Client_CXF_Configuration"><title>Providing
Client CXF Configuration</title><para>Next step is to create the client CXF
configuration file that will be used by client. The following file was copied/pasted from
CXF 2.0.5 ws_rm sample. It simply activates the WSRM protocol for CXF client. We will name
this file <emphasis role="bold">cxf.xml</emphasis> in our sample.
Here's the content of this file:</para><screen
xml:space="preserve"><beans
+ xmlns="<ulink
url="http://www.springframework.org/schema/beans">http://www...
+ xmlns:xsi="<ulink
url="http://www.w3.org/2001/XMLSchema-instance">http://www.w...
+ xmlns:cxf="<ulink
url="http://cxf.apache.org/core">http://cxf.apache.org/core&...
+ xmlns:wsa="<ulink
url="http://cxf.apache.org/ws/addressing">http://cxf.apache....
+ xmlns:http="<ulink
url="http://cxf.apache.org/transports/http/configuration">ht...
+ xmlns:wsrm-policy="<ulink
url="http://schemas.xmlsoap.org/ws/2005/02/rm/policy">http:/...
+ xmlns:wsrm-mgr="<ulink
url="http://cxf.apache.org/ws/rm/manager">http://cxf.apache....
+ xsi:schemaLocation="
+ <ulink
url="http://cxf.apache.org/core">http://cxf.apache.org/core&...
+ <ulink
url="http://cxf.apache.org/schemas/core.xsd">http://cxf.apac...
+ <ulink
url="http://cxf.apache.org/transports/http/configuration">ht...
+ <ulink
url="http://cxf.apache.org/schemas/configuration/http-conf.xsd"...
+ <ulink
url="http://schemas.xmlsoap.org/ws/2005/02/rm/policy">http:/...
+ <ulink
url="http://schemas.xmlsoap.org/ws/2005/02/rm/wsrm-policy.xsd"&...
+ <ulink
url="http://cxf.apache.org/ws/rm/manager">http://cxf.apache....
+ <ulink
url="http://cxf.apache.org/schemas/configuration/wsrm-manager.xsd&qu...
+ <ulink
url="http://www.springframework.org/schema/beans">http://www...
+ <ulink
url="http://www.springframework.org/schema/beans/spring-beans.xsd&qu...
+
+ <cxf:bus>
+ <cxf:features>
+ <cxf:logging/>
+ <wsa:addressing/>
+ <wsrm-mgr:reliableMessaging>
+ <wsrm-policy:RMAssertion>
+ <wsrm-policy:BaseRetransmissionInterval
Milliseconds="4000"/>
+ <wsrm-policy:AcknowledgementInterval
Milliseconds="2000"/>
+ </wsrm-policy:RMAssertion>
+ <wsrm-mgr:destinationPolicy>
+ <wsrm-mgr:acksPolicy intraMessageThreshold="0" />
+ </wsrm-mgr:destinationPolicy>
+ </wsrm-mgr:reliableMessaging>
+ </cxf:features>
+ </cxf:bus>
+
+</beans>
+</screen><para>And that's almost all. The client configuration needs to
picked up by the client classloader; in order to achieve that the cxf.xml file has to be
put in the META-INF directory of client jar. That jar should then be provided when setting
the class loader.</para><para>Alternatively the bus configuration can also be
read programmatically as follows:</para><para> </para></section>
+<section
id="JBossWS-CXFWS-ReliableMessagingtutorial_Updating_Client_Code_to_Read_Bus_Configuration_File"><title>Updating
Client Code to Read Bus Configuration File</title><para>And here's the
last piece the updated CXF client:</para><screen
xml:space="preserve"><emphasis
role="bold">package</emphasis>
org.jboss.test.ws.jaxws.samples.wsrm.client;
+
+<emphasis role="bold">import</emphasis> java.net.URL;
+<emphasis role="bold">import</emphasis> java.io.File;
+<emphasis role="bold">import</emphasis> javax.xml.namespace.QName;
+<emphasis role="bold">import</emphasis> javax.xml.ws.Service;
+<emphasis role="bold">import</emphasis> org.apache.cxf.Bus;
+<emphasis role="bold">import</emphasis> org.apache.cxf.BusFactory;
+<emphasis role="bold">import</emphasis>
org.apache.cxf.bus.spring.SpringBusFactory;
+<emphasis role="bold">import</emphasis>
org.jboss.test.ws.jaxws.samples.wsrm.generated.SimpleService;
+
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">final</emphasis> <emphasis
role="bold">class</emphasis> SimpleServiceTestCase
+{
+
+ <emphasis role="bold">private</emphasis> <emphasis
role="bold">static</emphasis> <emphasis
role="bold">final</emphasis> String serviceURL =
"http://localhost:8080/jaxws-samples-wsrm/SimpleService";
+
+ <emphasis role="bold">public</emphasis> <emphasis
role="bold">static</emphasis> <emphasis
role="bold">void</emphasis> main(String[] args) <emphasis
role="bold">throws</emphasis> Exception
+ {
+ // create bus
+ SpringBusFactory busFactory = <emphasis
role="bold">new</emphasis> SpringBusFactory();
+ URL cxfConfig = <emphasis role="bold">new</emphasis>
File("resources/jaxws/samples/wsrm/cxf.xml").toURL();
+ Bus bus = busFactory.createBus(cxfConfig);
+ busFactory.setDefaultBus(bus);
+
+ // create service
+ QName serviceName = <emphasis role="bold">new</emphasis>
QName("http://www.jboss.org/jbossws/ws-extensions/wsrm",
"SimpleService");
+ URL wsdlURL = <emphasis role="bold">new</emphasis>
URL(serviceURL + "?wsdl");
+ Service service = Service.create(wsdlURL, serviceName);
+ SimpleService proxy = (SimpleService)service.getPort(SimpleService.class);
+
+ // invoke methods
+ proxy.ping(); // one way call
+ proxy.echo("Hello World!"); // request responce call
+
+ // shutdown bus
+ bus.shutdown(<emphasis role="bold">true</emphasis>);
+ }
+
+}
+</screen></section>
+</section>
+</section>
+<section
id="JBossWS-CXFWS-ReliableMessagingtutorial_Sample_Sources"><title>Sample
Sources</title><para>All sources from this tutorial are part of JBossWS-CXF
distribution.</para></section>
+</chapter>
\ No newline at end of file
Added: stack/cxf/trunk/src/main/doc/JBossWS-Endpointmanagement.xml
===================================================================
--- stack/cxf/trunk/src/main/doc/JBossWS-Endpointmanagement.xml
(rev 0)
+++ stack/cxf/trunk/src/main/doc/JBossWS-Endpointmanagement.xml 2010-11-02 18:00:03 UTC
(rev 13200)
@@ -0,0 +1,18 @@
+<?xml version="1.0" encoding="UTF-8"?><chapter
id="chap_JBossWS-Endpointmanagement"><title>JBossWS-Endpointmanagement</title><para>JBossWS
registers MBeans that users can leverage to manage every webservice endpoint. Apart from
the obvious start/stop functionalities, they provide valuable information and statistics
about messages processed by the
endpoints.</para><para/><para> </para><section
id="JBossWS-Endpointmanagement_Getting_the_information"><title>Getting
the information</title><para>JBoss ships with a JMX-Console with all the
application server MBeans. It is usually available at URL <ulink
url="http://localhost:8080/jmx-console">http://localhost:8080/jmx-console</ulink>.
For endpoint management you might be interested in the MBeans belonging to the jboss.ws
domain.</para><para>The application server also has an applet based
web-console which basically has the same data as the JMX-Console plus some advanced
features including snapshot graphics.</para><para>Of course!
you can access an MBean programmatically too. Please refer to the <ulink
url="http://wiki.jboss.org/wiki/Wiki.jsp?page=FAQJBossJMX">J... JMX
faq</ulink> for further details; here is a brief code snippet you might want to
start from in order to access a ManagedEndpointMBean from the same virtual
machine:</para><screen xml:space="preserve"><emphasis
role="bold">try</emphasis>
+{
+ MBeanServer server = MBeanServerLocator.locate();
+ ManagedEndpointMBean mep = (ManagedEndpointMBean)MBeanProxyExt.create(
+ ManagedEndpointMBean.class,
+ "jboss.ws:context=my-ctx,endpoint=MyEndpoit",
+ server);
+ ...
+}
+<emphasis role="bold">catch</emphasis> (Exception e)
+{
+ e.printStackTrace();
+}
+</screen></section>
+<section
id="JBossWS-Endpointmanagement_Metrics"><title>Metrics</title><para>For
each deployed endpoint you'll find an
<emphasis>org.jboss.wsf.framework.management.ManagedEndpoint</emphasis> MBean
providing basic start/stop functionalities and metrics. Calling a stopped endpoint will
always result in a SOAP fault message.</para><para>The metrics available for
each managed endpoint are:</para><itemizedlist><listitem><para>
Min, max, average and total processing time: processing includes both the WS stack plus
application server work and the user business logic
</para></listitem><listitem><para> Last start and stop time
</para></listitem><listitem><para> Request, response and fault
count</para></listitem></itemizedlist></section>
+<section
id="JBossWS-Endpointmanagement_Records"><title>Records</title><para>JBossWS
features a highly configurable records' collection and management system. Each record
is basically composed of a message plus additional information (for example the caller
address and the called endpoint operation).</para><para>Endpoints can be
configured with record processors that are invoked whenever a message flow is detected and
records are thus created.</para><para>Every deployed endpoint is configured
with default record processors. However custom processors as well as record filters can be
easily plugged in and managed at any time through JMX. This gives users the chance of
performing advanced analysis of the webservice traffic according to their business
requirements.</para><para>Please refer to the <ulink
url="http://jbossws.jboss.org/mediawiki/index.php?title=Records_mana...
management page</ulink> for further details.</para></section>
+<section
id="JBossWS-Endpointmanagement_Snapshots_and_threshold_monitors"><title>Snapshots
and threshold monitors</title><para>As previously said, the <ulink
url="http://wiki.jboss.org/wiki/Wiki.jsp?page=WebConsole">JBoss Web
Console</ulink> has interesting features including <ulink
url="http://wiki.jboss.org/wiki/Wiki.jsp?page=WebConsoleSnapshots&qu...
and <ulink
url="http://wiki.jboss.org/wiki/Wiki.jsp?page=WebConsoleMonitoring&q...
monitors</ulink>.</para><para>Snapshots allow users to record changes of
a given MBean attribute within a defined time interval. Data are sampled at a given rate
and may be plotted to graphs with a few clicks. Snapshots are listed in the Web console
and can be created simply browsing to <ulink
url="http://localhost:8080/web-console/createSnapshot.jsp">http://localhost:8080/web-console/createSnapshot.jsp</ulink>
.</para><para>Threshold monitors allow users to be notified whenever a given
MBean attribute exceed a certain range!
of values. The threshold monitor's creation and management processes are similar to
those mentioned above for the snapshots. Simply browse to <ulink
url="http://localhost:8080/web-console/createThresholdMonitor.jsp">http://localhost:8080/web-console/createThresholdMonitor.jsp</ulink>
.</para><para>Speaking of WS availability and SLA, this all becomes
interesting because users can monitor and take snapshots of critical attributes like the
average/max processing time of a managed endpoint. Moreover, advanced analysis can be
performed leveraging ad-hoc attributes of custom <ulink
url="http://jbossws.jboss.org/mediawiki/index.php?title=Endpoint_man...
processors</ulink>.</para></section>
+</chapter>
\ No newline at end of file
Added: stack/cxf/trunk/src/main/doc/JBossWS-JAX-WSAnnotations.xml
===================================================================
--- stack/cxf/trunk/src/main/doc/JBossWS-JAX-WSAnnotations.xml
(rev 0)
+++ stack/cxf/trunk/src/main/doc/JBossWS-JAX-WSAnnotations.xml 2010-11-02 18:00:03 UTC
(rev 13200)
@@ -0,0 +1,20 @@
+<?xml version="1.0" encoding="UTF-8"?><chapter
id="chap_JBossWS-JAX-WSAnnotations"><title>JBossWS-JAX-WSAnnotations</title><para/><section
id="JBossWS-JAX-WSAnnotations_JAXWS_Annotations"><title>JAX-WS
Annotations</title><para>For details, see <ulink
url="http://www.jcp.org/en/jsr/detail?id=224">JSR-224 - Java API for
XML-Based Web Services (JAX-WS)
2.0</ulink></para><para> </para><section
id="JBossWS-JAX-WSAnnotations_javaxxmlwsServiceMode"><title>javax.xml.ws.ServiceMode</title><para>The
ServiceMode annotation is used to specify the mode for a provider class, i.e. whether a
provider wants to have access to protocol message payloads (e.g. a SOAP body) or the
entire protocol messages (e.g. a SOAP
envelope).</para><para> </para></section>
+<section
id="JBossWS-JAX-WSAnnotations_javaxxmlwsWebFault"><title>javax.xml.ws.WebFault</title><para>The
WebFault annotation is used when mapping WSDL faults to Java exceptions, see section 2.5.
It is used to capture the name of the fault element used when marshalling the JAXB type
generated from the global element referenced by the WSDL fault message. It can also be
used to customize the mapping of service specific exceptions to WSDL
faults.</para><para> </para></section>
+<section
id="JBossWS-JAX-WSAnnotations_javaxxmlwsRequestWrapper"><title>javax.xml.ws.RequestWrapper</title><para>The
RequestWrapper annotation is applied to the methods of an SEI. It is used to capture the
JAXB generated request wrapper bean and the element name and namespace for marshalling /
unmarshalling the bean. The default value of localName element is the operationName as
defined in WebMethod annotation and the default value for the targetNamespace element is
the target namespace of the SEI.When starting from Java, this annotation is used to
resolve overloading conflicts in document literal mode. Only the className element is
required in this case.</para><para> </para></section>
+<section
id="JBossWS-JAX-WSAnnotations_javaxxmlwsResponseWrapper"><title>javax.xml.ws.ResponseWrapper</title><para>The
ResponseWrapper annotation is applied to the methods of an SEI. It is used to capture the
JAXB generated response wrapper bean and the element name and namespace for marshalling /
unmarshalling the bean. The default value of the localName element is the operationName as
defined in the WebMethod appended with ”Response” and the default value of the
targetNamespace element is the target namespace of the SEI. When starting from Java, this
annotation is used to resolve overloading conflicts in document literal mode. Only the
className element is required in this
case.</para><para> </para></section>
+<section
id="JBossWS-JAX-WSAnnotations_javaxxmlwsWebServiceClient"><title>javax.xml.ws.WebServiceClient</title><para>The
WebServiceClient annotation is specified on a generated service class (see 2.7). It is
used to associate a class with a specific Web service, identify by a URL to a WSDL
document and the qualified name of a wsdl:service
element.</para><para> </para></section>
+<section
id="JBossWS-JAX-WSAnnotations_javaxxmlwsWebEndpoint"><title>javax.xml.ws.WebEndpoint</title><para>The
WebEndpoint annotation is specified on the getPortName() methods of a generated service
class (see 2.7). It is used to associate a get method with a specific wsdl:port,
identified by its local name (a
NCName).</para><para> </para></section>
+<section
id="JBossWS-JAX-WSAnnotations_javaxxmlwsWebServiceProvider"><title>javax.xml.ws.WebServiceProvider</title><para>The
WebServiceProvider annotation is specified on classes that implement a strongly typed
javax- .xml.ws.Provider. It is used to declare that a class that satisfies the
requirements for a provider (see 5.1) does indeed define a Web service endpoint, much like
the WebService annotation does for SEI-based endpoints.</para><para>The
WebServiceProvider and WebService annotations are mutually
exclusive.</para><para> </para></section>
+<section
id="JBossWS-JAX-WSAnnotations_javaxxmlwsBindingType"><title>javax.xml.ws.BindingType</title><para>The
BindingType annotation is applied to an endpoint implementation class. It specifies the
binding to use when publishing an endpoint of this type.</para><para>The
default binding for an endpoint is the SOAP 1.1/HTTP
one</para><para> </para></section>
+<section
id="JBossWS-JAX-WSAnnotations_javaxxmlwsWebServiceRef"><title>javax.xml.ws.WebServiceRef</title><para>The
WebServiceRef annotation is used to declare a reference to a Web service. It follows the
resource pattern exemplified by the javax.annotation.Resource annotation in JSR-250 [32].
The WebServiceRef annotation is required to be honored when running on the Java EE 5
platform, where it is subject to the common resource injection rules described by the
platform specification [33].</para><para> </para></section>
+<section
id="JBossWS-JAX-WSAnnotations_javaxxmlwsWebServiceRefs"><title>javax.xml.ws.WebServiceRefs</title><para>The
WebServiceRefs annotation is used to declare multiple references to Web services on a
single class. It is necessary to work around the limition against specifying repeated
annotations of the same type on any given class, which prevents listing multiple
javax.ws.WebServiceRef annotations one after the other. This annotation follows the
resource pattern exemplified by the javax.annotation.Resources annotation in
JSR-250.</para><para>Since no name and type can be inferred in this case, each
WebServiceRef annotation inside a WebServiceRefs MUST contain name and type elements with
non-default values. The WebServiceRef annotation is required to be honored when running on
the Java EE 5 platform, where it is subject to the common resource injection rules
described by the platform
specification.</para><para> </para></section>
+<section
id="JBossWS-JAX-WSAnnotations_javaxxmlwsAction"><title>javax.xml.ws.Action</title><para>The
Action annotation is applied to the methods of a SEI. It used to generate the wsa:Action
on wsdl:input and wsdl:output of each wsdl:operation mapped from the annotated
methods.</para><para> </para></section>
+<section
id="JBossWS-JAX-WSAnnotations_javaxxmlwsFaultAction"><title>javax.xml.ws.FaultAction</title><para>The
FaultAction annotation is used within the Action annotation to generate the wsa:Action
element on the wsdl:fault element of each wsdl:operation mapped from the annotated
methods.</para><para> </para></section>
+<section
id="JBossWS-JAX-WSAnnotations_Annotations_Defined_by_JSR181"><title>Annotations
Defined by JSR-181</title><para>JSR-181 defines the syntax and semantics of
Java Web Service (JWS) metadata and default values.</para><para>For details,
see <ulink
url="http://jcp.org/en/jsr/detail?id=181">JSR 181 - Web
Services Metadata for the Java
Platform</ulink></para><para> </para><section
id="JBossWS-JAX-WSAnnotations_javaxjwsWebService"><title>javax.jws.WebService</title><para>Marks
a Java class as implementing a Web Service, or a Java interface as defining a Web Service
interface.</para><para> </para></section>
+<section
id="JBossWS-JAX-WSAnnotations_javaxjwsWebMethod"><title>javax.jws.WebMethod</title><para>Customizes
a method that is exposed as a Web Service
operation.</para><para> </para></section>
+<section
id="JBossWS-JAX-WSAnnotations_javaxjwsOneWay"><title>javax.jws.OneWay</title><para>Indicates
that the given web method has only an input message and no output. Typically, a oneway
method returns the thread of control to the calling application prior to executing the
actual business method. A JSR-181 processor is REQUIRED to report an error if an operation
marked @Oneway has a return value, declares any checked exceptions or has any INOUT or OUT
parameters.</para><para> </para></section>
+<section
id="JBossWS-JAX-WSAnnotations_javaxjwsWebParam"><title>javax.jws.WebParam</title><para>Customizes
the mapping of an individual parameter to a Web Service message part and XML
element.</para><para> </para></section>
+<section
id="JBossWS-JAX-WSAnnotations_javaxjwsWebResult"><title>javax.jws.WebResult</title><para>Customizes
the mapping of the return value to a WSDL part and XML
element.</para><para> </para></section>
+<section
id="JBossWS-JAX-WSAnnotations_javaxjwsSOAPBinding"><title>javax.jws.SOAPBinding</title><para>Specifies
the mapping of the Web Service onto the SOAP message protocol.</para><para>The
SOAPBinding annotation has a target of TYPE and METHOD. The annotation may be placed on a
method if and only if the SOAPBinding.style is DOCUMENT. Implementations MUST report an
error if the SOAPBinding annotation is placed on a method with a SOAPBinding.style of RPC.
Methods that do not have a SOAPBinding annotation accept the SOAPBinding behavior defined
on the type.</para><para> </para></section>
+<section
id="JBossWS-JAX-WSAnnotations_javaxjwsHandlerChain"><title>javax.jws.HandlerChain</title><para>The
@HandlerChain annotation associates the Web Service with an externally defined handler
chain.</para><para>It is an error to combine this annotation with the
@SOAPMessageHandlers annotation.</para><para>The @HandlerChain annotation MAY
be present on the endpoint interface and service implementation bean. The service
implementation bean's @HandlerChain is used if @HandlerChain is present on
both.</para><para>The @HandlerChain annotation MAY be specified on the type
only. The annotation target includes METHOD and FIELD for use by
JAX-WS-2.0.</para></section>
+</section></section></chapter>
\ No newline at end of file
Added: stack/cxf/trunk/src/main/doc/JBossWS-JAX-WSTools.xml
===================================================================
--- stack/cxf/trunk/src/main/doc/JBossWS-JAX-WSTools.xml (rev 0)
+++ stack/cxf/trunk/src/main/doc/JBossWS-JAX-WSTools.xml 2010-11-02 18:00:03 UTC (rev
13200)
@@ -0,0 +1,171 @@
+<?xml version="1.0" encoding="UTF-8"?><chapter
id="chap_JBossWS-JAX-WSTools"><title>JBossWS-JAX-WSTools</title><para>The
JAX-WS tools provided by JBossWS can be used in a variety of ways. First we will look at
server-side development strategies, and then proceed to the
client.</para><para/><section
id="JBossWS-JAX-WSTools_Server_side"><title>Server
side</title><para>When developing a Web Service Endpoint (the server-side) you
have the option of starting from Java (bottom-up development), or from the abstact
contract (WSDL) that defines your service (top-down development). If this is a new service
(no existing contract), the bottom-up approach is the fastest route; you only need to add
a few annotations to your classes to get a service up and running. However, if you are
developing a service with an already defined contract, it is far simpler to use the
top-down approach, since the provided tool will generate the annotated code for
you.</para><para>Bottom-up use cases:</para!
<itemizedlist><listitem><para> Exposing an already
existing EJB3 bean as a Web Service
</para></listitem><listitem><para> Providing a new service, and
you want the contract to be generated for you
</para></listitem></itemizedlist><para>Top-down use
cases:</para><itemizedlist><listitem><para> Replacing the
implementation of an existing Web Service, and you can't break compatibility with
older clients </para></listitem><listitem><para> Exposing a
service that conforms to a contract specified by a third party (e.g. a vender that calls
you back using an already defined protocol).
</para></listitem><listitem><para> Creating a service that adheres
to the XML Schema and WSDL you developed by hand up front
</para></listitem></itemizedlist><para>The following JAX-WS
command line tools are included in JBossWS:</para><informaltable><tgroup
cols="2"><colspec colnum="1"
colname="col1"/><colspec colnum="2"
colname="col2"/><thead><row><entry> Command
</entry><entry> Description </entry><!
/row></thead><tbody><row><entry><para><link
linkend="chap_JBos!
sWS-wspr
ovide">JBossWS -
wsprovide</link></para></entry><entry>Generates JAX-WS portable
artifacts, and provides the abstract contract. Used for bottom-up
development.</entry></row><row><entry><para><link
linkend="chap_JBossWS-wsconsume">JBossWS -
wsconsume</link></para></entry><entry>Consumes the abstract
contract (WSDL and Schema files), and produces artifacts for both a server and client.
Used for top-down and client
development</entry></row><row><entry><para><link
linkend="chap_JBossWS-wsrunclient">JBossWS -
wsrunclient</link></para></entry><entry>Executes a Java client
(has a main method) using the JBossWS
classpath.</entry></row></tbody></tgroup></informaltable><section
id="JBossWS-JAX-WSTools_BottomUp_Using_wsprovide"><title>Bottom-Up
(Using wsprovide)</title><para>The bottom-up strategy involves developing the
Java code for your service, and then annotating it using JAX-WS annotations. These
annotations can be used to customize the contract that is generated for your service!
. For example, you can change the operation name to map to anything you like. However,
all of the annotations have sensible defaults, so only the @WebService annotation is
required.</para><para>This can be as simple as creating a single
class:</para><screen xml:space="preserve"><emphasis
role="bold">package</emphasis> echo;
+
+(a)javax.jws.WebService
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> Echo
+{
+ <emphasis role="bold">public</emphasis> String echo(String
input)
+ {
+ <emphasis role="bold">return</emphasis> input;
+ }
+}
+</screen><para>A JSE or EJB3 deployment can be built using this class, and it
is the only Java code needed to deploy on JBossWS. The WSDL, and all other Java artifacts
called "wrapper classes" will be generated for you at deploy time. This actually
goes beyond the JAX-WS specification, which requires that wrapper classes be generated
using an offline tool. The reason for this requirement is purely a vender implementation
problem, and since we do not believe in burdening a developer with a bunch of additional
steps, we generate these as well. However, if you want your deployment to be portable to
other application servers, you will unfortunately need to use a tool and add the generated
classes to your deployment.</para><para>This is the primary purpose of the
<link linkend="chap_JBossWS-wsprovide">JBossWS -
wsprovide</link>tool, to generate portable JAX-WS artifacts. Additionally, it can be
used to "provide" the abstract contract (WSDL file) for your service. This can
be obt!
ained by invoking <link linkend="chap_JBossWS-wsprovide">JBossWS -
wsprovide</link> using the "-w" option:</para><screen
xml:space="preserve">$ javac -d . -classpath jboss-jaxws.jar Echo.java
+$ wsprovide -w echo.Echo
+Generating WSDL:
+EchoService.wsdl
+Writing Classes:
+echo/jaxws/Echo.class
+echo/jaxws/EchoResponse.class
+</screen><para>Inspecting the WSDL reveals a service called
EchoService:</para><screen xml:space="preserve"><service
name='EchoService'><port binding='tns:EchoBinding'
name='EchoPort'>
+ <soap:address
location='REPLACE_WITH_ACTUAL_URL'/></port>
+</service>
+</screen><para>As expected, this service defines one operation,
"echo":</para><screen
xml:space="preserve"><portType
name='Echo'><operation name='echo'
parameterOrder='echo'>
+ <input message='tns:Echo_echo'/>
+ <output
message='tns:Echo_echoResponse'/></operation>
+</portType>
+</screen><note><para><para><emphasis><emphasis
role="bold">Note</emphasis></emphasis></para><para><emphasis>Remember
that <emphasis role="bold">when deploying on JBossWS you do not need to
run this tool.</emphasis> You only need it for generating portable artifacts and/or
the abstract contract for your
service.</emphasis></para></para></note><para>Let's
create a POJO endpoint for deployment on JBoss AS. A simple web.xml needs to be
created:</para><screen xml:space="preserve"><web-app
xmlns="<ulink
url="http://java.sun.com/xml/ns/j2ee">http://java.sun.com/xm...
+ xmlns:xsi="<ulink
url="http://www.w3.org/2001/XMLSchema-instance">http://www.w...
+ xsi:schemaLocation="<ulink
url="http://java.sun.com/xml/ns/j2ee">http://java.sun.com/xm...
<ulink
url="http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">http:/...
+ version="2.4">
+
+ <servlet>
+ <servlet-name>Echo</servlet-name>
+ <servlet-class>echo.Echo</servlet-class>
+ </servlet>
+
+ <servlet-mapping>
+ <servlet-name>Echo</servlet-name>
+ <url-pattern>/Echo</url-pattern>
+ </servlet-mapping>
+</web-app>
+</screen><para>The web.xml and the single class can now be used to create a
war:</para><screen xml:space="preserve">$ mkdir -p WEB-INF/classes
+$ cp -rp echo WEB-INF/classes/
+$ cp web.xml WEB-INF
+$ jar cvf echo.war WEB-INF
+added manifest
+adding: WEB-INF/(in = 0) (out= 0)(stored 0%)
+adding: WEB-INF/classes/(in = 0) (out= 0)(stored 0%)
+adding: WEB-INF/classes/echo/(in = 0) (out= 0)(stored 0%)
+adding: WEB-INF/classes/echo/Echo.class(in = 340) (out= 247)(deflated 27%)
+adding: WEB-INF/web.xml(in = 576) (out= 271)(deflated 52%)
+</screen><para>The war can then be deployed:</para><screen
xml:space="preserve">cp echo.war
/usr/local/jboss-4.2.0.GA-ejb3/server/default/deploy
+</screen><para>This will internally invoke <link
linkend="chap_JBossWS-wsprovide">JBossWS - wsprovide</link>, which will
generate the WSDL. If deployment was successful, and you are using the default settings,
it should be available here: <ulink
url="http://localhost:8080/echo/Echo?wsdl">http://localhost:8080/echo/Echo?wsdl</ulink></para><para>For
a portable JAX-WS deployment, the wrapper classes generated earlier could be added to the
deployment.</para></section>
+<section
id="JBossWS-JAX-WSTools_TopDown_Using_wsconsume"><title>Top-Down (Using
wsconsume)</title><para>The top-down development strategy begins with the
abstract contract for the service, which includes the WSDL file and zero or more schema
files. The <link linkend="chap_JBossWS-wsconsume">JBossWS -
wsconsume</link> tool is then used to consume this contract, and produce annotated
Java classes (and optionally sources) that define
it.</para><note><para><para><emphasis
role="bold">Note</emphasis></para><para>wsconsume seems to
have a problem with symlinks on unix
systems</para></para></note><para>Using the WSDL file from the
bottom-up example, a new Java implementation that adheres to this service can be
generated. The "-k" option is passed to <link
linkend="chap_JBossWS-wsconsume">JBossWS - wsconsume</link> to preserve
the Java source files that are generated, instead of providing just
classes:</para><screen xml:space="preserve">
+$ wsconsume -k EchoService.wsdl
+echo/Echo.java
+echo/EchoResponse.java
+echo/EchoService.java
+echo/Echo_Type.java
+echo/ObjectFactory.java
+echo/package-info.java
+echo/Echo.java
+echo/EchoResponse.java
+echo/EchoService.java
+echo/Echo_Type.java
+echo/ObjectFactory.java
+echo/package-info.java
+</screen><para>The following table shows the purpose of each generated
file:</para><informaltable><tgroup cols="2"><colspec
colnum="1" colname="col1"/><colspec colnum="2"
colname="col2"/><thead><row><entry> File
</entry><entry> Purpose
</entry></row></thead><tbody><row><entry>Echo.java</entry><entry>Service
Endpoint
Interface</entry></row><row><entry>Echo_Type.java</entry><entry>Wrapper
bean for request
message</entry></row><row><entry>EchoResponse.java</entry><entry>Wrapper
bean for response
message</entry></row><row><entry>ObjectFactory.java</entry><entry>JAXB
XML
Registry</entry></row><row><entry>package-info.java</entry><entry>Holder
for JAXB package
annotations</entry></row><row><entry>EchoService.java</entry><entry>Used
only by JAX-WS
clients</entry></row></tbody></tgroup></informaltable><para>Examining
the Service Endpoint Interface reveals annotations that are more explicit than in the
class written by hand in the bottom-up example, however, these evaluate to the sa!
me contract:</para><screen xml:space="preserve">@WebService(name =
"Echo", targetNamespace = "http://echo/")
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">interface</emphasis> Echo {
+ @WebMethod
+ @WebResult(targetNamespace = "")
+ @RequestWrapper(localName = "echo", targetNamespace =
"http://echo/", className = "echo.Echo_Type")
+ @ResponseWrapper(localName = "echoResponse", targetNamespace =
"http://echo/", className = "echo.EchoResponse")
+ <emphasis role="bold">public</emphasis> String echo(
+ @WebParam(name = "arg0", targetNamespace = "")
+ String arg0);
+
+}
+</screen><para>The only missing piece (besides the packaging) is the
implementation class, which can now be written, using the above
interface.</para><screen xml:space="preserve"><emphasis
role="bold">package</emphasis> echo;
+
+(a)javax.jws.WebService(endpointInterface="echo.Echo")
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> EchoImpl <emphasis
role="bold">implements</emphasis> Echo
+{
+ <emphasis role="bold">public</emphasis> String echo(String
arg0)
+ {
+ <emphasis role="bold">return</emphasis> arg0;
+ }
+}
+</screen></section>
+</section>
+<section id="JBossWS-JAX-WSTools_Client_Side"><title>Client
Side</title><para>Before going to detail on the client-side it is important to
understand the decoupling concept that is central to Web Services. Web Services are not
the best fit for internal RPC, even though they can be used in this way. There are much
better technologies for this (CORBA, and RMI for example). Web Services were designed
specifically for interoperable coarse-grained correspondence. There is no expectation or
guarantee that any party participating in a Web Service interaction will be at any
particular location, running on any particular OS, or written in any particular
programming language. So because of this, it is important to clearly separate client and
server implementations. The only thing they should have in common is the abstract contract
definition. If, for whatever reason, your software does not adhere to this principal, then
you should not be using Web Services. For the above reasons, the!
<emphasis><emphasis role="bold">recommended methodology for
developing a client is</emphasis></emphasis> to follow
<emphasis><emphasis role="bold">the top-down
approach</emphasis></emphasis>, even if the client is running on the same
server.</para><para>Let's repeat the process of the top-down section,
although using the deployed WSDL, instead of the one generated offline by <link
linkend="chap_JBossWS-wsprovide">JBossWS - wsprovide</link>. The reason
why we do this is just to get the right value for soap:address. This value must be
computed at deploy time, since it is based on container configuration specifics. You could
of course edit the WSDL file yourself, although you need to ensure that the path is
correct.</para><para>Offline version:</para><screen
xml:space="preserve"><service name='EchoService'>
+ <port binding='tns:EchoBinding' name='EchoPort'>
+ <soap:address location='REPLACE_WITH_ACTUAL_URL'/>
+ </port></service>
+</screen><para>Online version:</para><screen
xml:space="preserve"><service name="EchoService">
+ <port binding="tns:EchoBinding" name="EchoPort">
+ <soap:address location="<ulink
url="http://localhost.localdomain:8080/echo/Echo">http://localhost.localdomain:8080/echo/Echo</ulink>"/>
+ </port>
+</service>
+</screen><para>Using the online deployed version with <link
linkend="chap_JBossWS-wsconsume">JBossWS -
wsconsume</link>:</para><screen xml:space="preserve">$
wsconsume -k
http://localhost:8080/echo/Echo?wsdl
+echo/Echo.java
+echo/EchoResponse.java
+echo/EchoService.java
+echo/Echo_Type.java
+echo/ObjectFactory.java
+echo/package-info.java
+echo/Echo.java
+echo/EchoResponse.java
+echo/EchoService.java
+echo/Echo_Type.java
+echo/ObjectFactory.java
+echo/package-info.java
+</screen><para>The one class that was not examined in the top-down section,
was EchoService.java. Notice how it stores the location the WSDL was obtained
from.</para><screen xml:space="preserve">@WebServiceClient(name =
"EchoService", targetNamespace = "http://echo/", wsdlLocation =
"http://localhost:8080/echo/Echo?wsdl")
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> EchoService <emphasis
role="bold">extends</emphasis> Service
+{
+ <emphasis role="bold">private</emphasis> <emphasis
role="bold">final</emphasis> <emphasis
role="bold">static</emphasis> URL ECHOSERVICE_WSDL_LOCATION;
+
+ <emphasis role="bold">static</emphasis> {
+ URL url = <emphasis role="bold">null</emphasis>;
+ <emphasis role="bold">try</emphasis> {
+ url = <emphasis role="bold">new</emphasis>
URL("http://localhost:8080/echo/Echo?wsdl");
+ } <emphasis role="bold">catch</emphasis>
(MalformedURLException e) {
+ e.printStackTrace();
+ }
+ ECHOSERVICE_WSDL_LOCATION = url;
+ }
+
+ <emphasis role="bold">public</emphasis> EchoService(URL
wsdlLocation, QName serviceName) {
+ <emphasis role="bold">super</emphasis>(wsdlLocation,
serviceName);
+ }
+
+ <emphasis role="bold">public</emphasis> EchoService() {
+ <emphasis
role="bold">super</emphasis>(ECHOSERVICE_WSDL_LOCATION, <emphasis
role="bold">new</emphasis> QName("http://echo/",
"EchoService"));
+ }
+
+ @WebEndpoint(name = "EchoPort")
+ <emphasis role="bold">public</emphasis> Echo getEchoPort() {
+ <emphasis role="bold">return</emphasis>
(Echo)super.getPort(<emphasis role="bold">new</emphasis>
QName("http://echo/", "EchoPort"), Echo.class);
+ }
+}
+</screen><para>As you can see, this generated class extends the main client
entry point in JAX-WS, javax.xml.ws.Service. While you can use Service directly, this is
far simpler since it provides the configuration info for you. The only method we really
care about is the getEchoPort() method, which returns an instance of our Service Endpoint
Interface. Any WS operation can then be called by just invoking a method on the returned
interface.</para><note><para><para><emphasis><emphasis
role="bold">Note</emphasis></emphasis></para><para><emphasis>It's
not recommended to refer to a remote WSDL URL in a production application. This causes
network I/O every time you instantiate the Service Object. Instead, use the tool on a
saved local copy, or use the URL version of the constructor to provide a new WSDL
location.</emphasis></para></para></note><para>All that is
left to do, is write and compile the client:</para><screen
xml:space="preserve"><emphasis
role="bold">import</emphasis> e!
cho.*;
+
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> EchoClient
+{
+ <emphasis role="bold">public</emphasis> <emphasis
role="bold">static</emphasis> <emphasis
role="bold">void</emphasis> main(String args[])
+ {
+ <emphasis role="bold">if</emphasis> (args.length != 1)
+ {
+ System.err.println("usage: EchoClient <message>");
+ System.exit(1);
+ }
+
+ EchoService service = <emphasis role="bold">new</emphasis>
EchoService();
+ Echo echo = service.getEchoPort();
+ System.out.println("Server said: " + echo.echo(args[0]));
+ }}
+</screen><para>It can then be easily executed using the <link
linkend="chap_JBossWS-wsrunclient">JBossWS - wsrunclient</link> tool.
This is just a convenience tool that invokes java with the needed
classpath:</para><screen xml:space="preserve">$ wsrunclient
EchoClient 'Hello World!'
+Server said: Hello World!
+</screen><para>It is easy to change the endpoint address of your operation at
runtime, setting the ENDPOINT_ADDRESS_PROPERTY as shown below:</para><screen
xml:space="preserve">...
+ EchoService service = <emphasis role="bold">new</emphasis>
EchoService();
+ Echo echo = service.getEchoPort();
+
+ /* Set NEW Endpoint Location */
+ String endpointURL = "http://NEW_ENDPOINT_URL";
+ BindingProvider bp = (BindingProvider)echo;
+ bp.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
endpointURL);
+
+ System.out.println("Server said: " + echo.echo(args[0]));
+...
+</screen></section>
+<section
id="JBossWS-JAX-WSTools_Commandline_Maven_Plugin_and_Ant_Task_Reference"><title>Command-line,
Maven Plugin and Ant Task
Reference</title><itemizedlist><listitem><para> <link
linkend="chap_JBossWS-wsconsume">JBossWS - wsconsume</link> reference
page </para></listitem><listitem><para> <link
linkend="chap_JBossWS-wsprovide">JBossWS - wsprovide</link> reference
page </para></listitem><listitem><para> <link
linkend="chap_JBossWS-wsrunclient">JBossWS - wsrunclient</link>
reference page</para></listitem></itemizedlist></section>
+<section
id="JBossWS-JAX-WSTools_JAXWS_binding_customization"><title>JAX-WS
binding customization</title><para>An introduction to binding
customizations:</para><itemizedlist><listitem><para> <ulink
url="http://java.sun.com/webservices/docs/2.0/jaxws/customizations.h...
</para></listitem><listitem><para> <ulink
url="https://jax-ws.dev.java.net/source/browse/jax-ws/guide/docs/wsd...
schema</ulink> </para></listitem><listitem><para> <ulink
url="https://jax-ws.dev.java.net/nonav/guide/customizations/"&g...
</para></listitem></itemizedlist><para>The schema for the binding
customization files can be found
here:</para><itemizedlist><listitem><para> <ulink
url="https://jax-ws.dev.java.net/source/browse/jax-ws/guide/docs/wsd...!
2&view=log</ulink>
</para></listitem></itemizedlist></section>
+</chapter>
\ No newline at end of file
Added: stack/cxf/trunk/src/main/doc/JBossWS-QuickStart.xml
===================================================================
--- stack/cxf/trunk/src/main/doc/JBossWS-QuickStart.xml (rev 0)
+++ stack/cxf/trunk/src/main/doc/JBossWS-QuickStart.xml 2010-11-02 18:00:03 UTC (rev
13200)
@@ -0,0 +1,193 @@
+<?xml version="1.0" encoding="UTF-8"?><chapter
id="chap_JBossWS-QuickStart"><title>JBossWS-QuickStart</title><para/><para> </para><section
id="JBossWS-QuickStart_Right_on"><title>Right
on'</title><para>JBossWS uses the JBoss application server as its target
container. The following examples focus on web service deployments that leverage EJB3
service implementations and the JAX-WS programming models. For further information on POJO
service implementations and advanced topics you need consult the user
guide.</para><para>In the following sections we will explore the samples that
ship with the JBossWS distribution. They provide a build structure based on Ant to get you
started quickly.</para></section>
+<section
id="JBossWS-QuickStart_Developing_web_service_implementations"><title>Developing
web service implementations</title><para>JAX-WS does leverage <ulink
url="http://java.sun.com/j2se/1.5.0/docs/guide/language/annotations....
5 annotations</ulink> in order to express web service meta data on Java components
and to describe the mapping between Java data types and XML. When developing web service
implementations you need to decide whether you are going start with an abstract contract
(<ulink
url="http://www.w3.org/TR/wsdl">WSDL</ulink>) or a Java
component.</para><para>If you are in charge to provide the service
implementation, then you are probably going to start with the implementation and derive
the abstract contract from it. You are probably not even getting in touch with the WSDL
unless you hand it to 3rd party clients. For this reason we are going to look at a service
implementation that leverages <ulink
url="http://jcp.org/en/jsr/detail?id=181">JSR-181 annot!
ations</ulink>.</para><note><para><para><emphasis
role="bold">Note</emphasis></para><para>Even though
detailed knowledge of web service meta data is not required, it will definitely help if
you make yourself familiar with it. For further information
see</para><itemizedlist><listitem><para> <ulink
url="http://jcp.org/en/jsr/detail?id=181">Web service meta data
(JSR-181)</ulink> </para></listitem><listitem><para>
<ulink
url="http://java.sun.com/webservices/jaxb/">Java API for XML
binding
(JAXB)</ulink></para></listitem></itemizedlist></para></note><para>When
starting from Java you must provide the service implementation. A valid endpoint
implementation class must meet the following
requirements:</para><itemizedlist><listitem><para> It
<emphasis>must</emphasis> carry a
<computeroutput>javax.jws.WebService</computeroutput> annotation (see JSR 181)
</para></listitem><listitem><para> All method parameters and
return types <emphasis>must</emphasis> be compatible with the JAXB !
2.0 </para></listitem></itemizedlist><para>Let's look at a
sam!
ple EJB3
component that is going to be exposed as a web service. (This is based on the Retail
example).</para><para>Don't be confused with the EJB3 annotation
<computeroutput>@Stateless</computeroutput>. We concentrate on the
<computeroutput>@WebService</computeroutput> annotation for
now.</para><para><emphasis role="bold">The service
implementation class</emphasis></para><screen
xml:space="preserve"><emphasis
role="bold">package</emphasis>
org.jboss.test.ws.jaxws.samples.retail.profile;
+
+<emphasis role="bold">import</emphasis> javax.ejb.Stateless;
+<emphasis role="bold">import</emphasis> javax.jws.WebService;
+<emphasis role="bold">import</emphasis> javax.jws.WebMethod;
+<emphasis role="bold">import</emphasis>
javax.jws.soap.SOAPBinding;
+
+@Stateless (1)
+@WebService( (2)
+ name="ProfileMgmt",
+ targetNamespace = "http://org.jboss.ws/samples/retail/profile",
+ serviceName = "ProfileMgmtService")
+@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE) (3)
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> ProfileMgmtBean {
+
+ @WebMethod (4)
+ <emphasis role="bold">public</emphasis> DiscountResponse
getCustomerDiscount(DiscountRequest request) {
+ <emphasis role="bold">return</emphasis> <emphasis
role="bold">new</emphasis> DiscountResponse(request.getCustomer(),
10.00);
+ }
+}
+
+</screen><orderedlist><listitem><para> We are using a stateless
session bean implementation </para></listitem><listitem><para>
Exposed a web service with an explicit namespace
</para></listitem><listitem><para> It's a doc/lit bare
endpoint </para></listitem><listitem><para> And offers an
'getCustomerDiscount' operation
</para></listitem></orderedlist><para> <emphasis
role="bold"> What about the payload?
</emphasis></para><para>The method parameters and return values are
going to represent our XML payload and thus require being compatible with <ulink
url="http://java.sun.com/webservices/jaxb/">JAXB2</ulink>. Actually you
wouldn't need any JAXB annotations for this particular example, because JAXB relies on
meaningful defaults. For the sake of documentation we put the more important ones
here.</para><para>Take a look at the request parameter:</para><screen
xml:space="preserve"><emphasis
role="bold">package</emphasis>
org.jboss.test.ws.jaxws.samples.retail.profile;
+
+<emphasis role="bold">import</emphasis>
javax.xml.bind.annotation.XmlAccessType;
+<emphasis role="bold">import</emphasis>
javax.xml.bind.annotation.XmlAccessorType;
+<emphasis role="bold">import</emphasis>
javax.xml.bind.annotation.XmlType;
+
+<emphasis role="bold">import</emphasis>
org.jboss.test.ws.jaxws.samples.retail.Customer;
+
+(a)XmlAccessorType(XmlAccessType.field)
+@XmlType( (1)
+ name = "discountRequest",
+ namespace="http://org.jboss.ws/samples/retail/profile",
+ propOrder = { "customer" }
+)
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> DiscountRequest {
+
+ <emphasis role="bold">protected</emphasis> Customer customer;
+
+ <emphasis role="bold">public</emphasis> DiscountRequest() {
+ }
+
+ <emphasis role="bold">public</emphasis> DiscountRequest(Customer
customer) {
+ this.customer = customer;
+ }
+
+ <emphasis role="bold">public</emphasis> Customer getCustomer()
{
+ <emphasis role="bold">return</emphasis> customer;
+ }
+
+ <emphasis role="bold">public</emphasis> <emphasis
role="bold">void</emphasis> setCustomer(Customer value) {
+ this.customer = value;
+ }
+
+}
+
+</screen><orderedlist><listitem><para>In this case we use
<computeroutput>@XmlType</computeroutput> to specify an XML complex type name
and override the namespace.
</para></listitem></orderedlist><para> </para><variablelist/><section
id="JBossWS-QuickStart_Deploying_service_implementations"><title>Deploying
service implementations</title><para>Service deployment basically depends on
the implementation type. As you may already know web services can be implemented as EJB3
components or plain old Java objects. This quick start leverages EJB3 components in all
examples, thats why we are going to look at this case in the next
sections.</para><para> </para><para><emphasis
role="bold"> EJB3 services </emphasis></para><para>Simply
wrap up the service implementation class, the endpoint interface and any custom data types
in a JAR and drop them in the <computeroutput>deploy</computeroutput>
directory. No additional deployment descriptors required. Any meta data required for the
dep!
loyment of the actual web service is taken from the annotations provided on the
implementation class and the service endpoint interface. JBossWS will intercept that EJB3
deployment (the bean will also be there) and create an HTTP endpoint at
deploy-time:</para><para> </para><para><emphasis
role="bold">The JAR package structure</emphasis></para><screen
xml:space="preserve">jar -tf jaxws-samples-retail.jar
+
+org/jboss/test/ws/jaxws/samples/retail/profile/DiscountRequest.class
+org/jboss/test/ws/jaxws/samples/retail/profile/DiscountResponse.class
+org/jboss/test/ws/jaxws/samples/retail/profile/ObjectFactory.class
+org/jboss/test/ws/jaxws/samples/retail/profile/ProfileMgmt.class
+org/jboss/test/ws/jaxws/samples/retail/profile/ProfileMgmtBean.class
+org/jboss/test/ws/jaxws/samples/retail/profile/ProfileMgmtService.class
+org/jboss/test/ws/jaxws/samples/retail/profile/package-info.class
+</screen><note><para><para><emphasis><emphasis
role="bold">Note</emphasis></emphasis></para><para><emphasis>If
the deployment was successful you should be able to see your endpoint at <ulink
url="http://localhost:8080/jbossws/services">http://localhost:8080/jbossws/services</ulink></emphasis></para><para> </para></para></note></section>
+</section>
+<section
id="JBossWS-QuickStart_Consuming_web_services"><title>Consuming web
services</title><para>When creating web service clients you would usually
start from the WSDL. JBossWS ships with a set of tools to generate the required JAX-WS
artefacts to build client implementations. In the following section we will look at the
most basic usage patterns. For a more detailed introductoin to web service client please
consult the <ulink
url="http://community.jboss.org/docs/DOC-13972">user
guide</ulink>.</para><para> </para><para> </para><para><emphasis
role="bold">Using wsconsume
</emphasis></para><para> </para><para>The <link
linkend="chap_JBossWS-wsconsume">wsconsume tool</link> is used to
consume the abstract contract (WSDL) and produce annotated Java classes (and optionally
sources) that define it. We are going to start with the WSDL from our retail example
(<link
linkend="JBossWS-QuickStart_Profile_MgmtService">ProfileMgmtService.wsdl</link>).
For a detailed tool reference!
you need to consult the user guide.</para><screen
xml:space="preserve">wsconsume is a command line tool that generates
+portable JAX-WS artifacts from a WSDL file.
+
+usage: org.jboss.ws.tools.jaxws.command.wsconsume [options] <wsdl-url>
+
+options:
+ -h, --help Show this help message
+ -b, --binding=<file> One or more JAX-WS or JAXB binding files
+ -k, --keep Keep/Generate Java source
+ -c --catalog=<file> Oasis XML Catalog file for entity
resolution
+ -p --package=<name> The target package for generated source
+ -w --wsdlLocation=<loc> Value to use for @WebService.wsdlLocation
+ -o, --output=<directory> The directory to put generated artifacts
+ -s, --source=<directory> The directory to put Java source
+ -q, --quiet Be somewhat more quiet
+ -t, --show-traces Show full exception stack traces
+</screen><para>Let's try it on our retail sample:</para><screen
xml:space="preserve">~./wsconsume.sh -k
+-p org.jboss.test.ws.jaxws.samples.retail.profile ProfileMgmtService.wsdl (1)
+
+org/jboss/test/ws/jaxws/samples/retail/profile/Customer.java
+org/jboss/test/ws/jaxws/samples/retail/profile/DiscountRequest.java
+org/jboss/test/ws/jaxws/samples/retail/profile/DiscountResponse.java
+org/jboss/test/ws/jaxws/samples/retail/profile/ObjectFactory.java
+org/jboss/test/ws/jaxws/samples/retail/profile/ProfileMgmt.java
+org/jboss/test/ws/jaxws/samples/retail/profile/ProfileMgmtService.java
+org/jboss/test/ws/jaxws/samples/retail/profile/package-info.java
+
+</screen><orderedlist><listitem><para> As you can see we did use
the <computeroutput>-p</computeroutput> switch to specify the package name of
the generated sources.
</para></listitem></orderedlist><para> </para><para><emphasis
role="bold"> The generated artifacts explained
</emphasis></para><informaltable><tgroup
cols="2"><colspec colnum="1"
colname="col1"/><colspec colnum="2"
colname="col2"/><thead><row><entry> File
</entry><entry> Purpose
</entry></row></thead><tbody><row><entry>ProfileMgmt.java</entry><entry>Service
Endpoint
Interface</entry></row><row><entry>Customer.java</entry><entry>Custom
data
type</entry></row><row><entry>Discount*.java</entry><entry>Custom
data
type</entry></row><row><entry>ObjectFactory.java</entry><entry>JAXB
XML
Registry</entry></row><row><entry>package-info.java</entry><entry>Holder
for JAXB package
annotations</entry></row><row><entry>ProfileMgmtService.java</entry><entry>Service
factory</entry></row></tbody></tgroup></informaltable><para>B!
asically <computeroutput>wsconsume</computeroutput> generates all custom data
types (JAXB annotated classes), the service endpoint interface and a service factory
class. We will look at how these artifacts can be used the build web service client
implementations in the next section.</para><para> </para><bridgehead
id="Constructing_a_service_stub">Constructing a service
stub</bridgehead><para>Web service clients make use of a service stubs that
hide the details of a remote web service invocation. To a client application a WS
invocation just looks like an invocation of any other business component. In this case the
service endpoint interface acts as the business interface. JAX-WS does use a service
factory class to construct this as particular service stub:</para><screen
xml:space="preserve"><emphasis
role="bold">import</emphasis> javax.xml.ws.Service;
+
+Service service = Service.create( (1)
+ <emphasis role="bold">new</emphasis>
URL("http://example.org/service?wsdl"),
+ <emphasis role="bold">new</emphasis>
QName("MyService")
+);
+ProfileMgmt profileMgmt = service.getPort(ProfileMgmt.class); (2)
+
+// do something with the service stub here... (3)
+</screen><orderedlist><listitem><para> Create a service factory
using the WSDL location and the service name
</para></listitem><listitem><para> Use the tool created service
endpoint interface to build the service stub
</para></listitem><listitem><para> Use the stub like any other
business interface
</para></listitem></orderedlist><para> </para><para> </para><para><emphasis><emphasis
role="bold">Note</emphasis></emphasis></para><note><para><para><emphasis>The
creation of the service stub is quite costly. You should take care that it gets reused by
your application code (However <emphasis role="bold">it's not thread
safe</emphasis>). Within a EE5 environment you might want to investigate the
<computeroutput>@WebServiceRef</computeroutput>
functionality.</emphasis></para><para> </para></para></note></section>
+<section
id="JBossWS-QuickStart_Appendix"><title>Appendix</title><section
id="JBossWS-QuickStart_Profile_MgmtService"><title>ProfileMgmtService.wsdl</title><screen
xml:space="preserve"><definitions
+ name='ProfileMgmtService'
+ targetNamespace='<ulink
url="http://org.jboss.ws/samples/retail/profile">http://org.jboss.ws/samples/retail/profile</ulink>'
+ xmlns='<ulink
url="http://schemas.xmlsoap.org/wsdl/">http://schemas.xmlsoa...
+ xmlns:ns1='<ulink
url="http://org.jboss.ws/samples/retail">http://org.jboss.ws/samples/retail</ulink>'
+ xmlns:soap='<ulink
url="http://schemas.xmlsoap.org/wsdl/soap/">http://schemas.x...
+ xmlns:tns='<ulink
url="http://org.jboss.ws/samples/retail/profile">http://org.jboss.ws/samples/retail/profile</ulink>'
+ xmlns:xsd='<ulink
url="http://www.w3.org/2001/XMLSchema">http://www.w3.org/200...
+
+ <types>
+
+ <xs:schema targetNamespace='<ulink
url="http://org.jboss.ws/samples/retail">http://org.jboss.ws/samples/retail</ulink>'
+ version='1.0' xmlns:xs='<ulink
url="http://www.w3.org/2001/XMLSchema">http://www.w3.org/200...
+ <xs:complexType name='customer'>
+ <xs:sequence>
+ <xs:element minOccurs='0' name='creditCardDetails'
type='xs:string'/>
+ <xs:element minOccurs='0' name='firstName'
type='xs:string'/>
+ <xs:element minOccurs='0' name='lastName'
type='xs:string'/>
+ </xs:sequence>
+ </xs:complexType>
+ </xs:schema>
+
+ <xs:schema
+ targetNamespace='<ulink
url="http://org.jboss.ws/samples/retail/profile">http://org.jboss.ws/samples/retail/profile</ulink>'
+ version='1.0'
+ xmlns:ns1='<ulink
url="http://org.jboss.ws/samples/retail">http://org.jboss.ws/samples/retail</ulink>'
+ xmlns:tns='<ulink
url="http://org.jboss.ws/samples/retail/profile">http://org.jboss.ws/samples/retail/profile</ulink>'
+ xmlns:xs='<ulink
url="http://www.w3.org/2001/XMLSchema">http://www.w3.org/200...
+
+ <xs:import namespace='<ulink
url="http://org.jboss.ws/samples/retail'/">http://org.jboss.ws/samples/retail'/</ulink>>
+ <xs:element name='getCustomerDiscount'
+ nillable='true' type='tns:discountRequest'/>
+ <xs:element name='getCustomerDiscountResponse'
+ nillable='true'
type='tns:discountResponse'/>
+ <xs:complexType name='discountRequest'>
+ <xs:sequence>
+ <xs:element minOccurs='0' name='customer'
type='ns1:customer'/>
+
+ </xs:sequence>
+ </xs:complexType>
+ <xs:complexType name='discountResponse'>
+ <xs:sequence>
+ <xs:element minOccurs='0' name='customer'
type='ns1:customer'/>
+ <xs:element name='discount'
type='xs:double'/>
+ </xs:sequence>
+ </xs:complexType>
+ </xs:schema>
+
+ </types>
+
+ <message name='ProfileMgmt_getCustomerDiscount'>
+ <part element='tns:getCustomerDiscount'
name='getCustomerDiscount'/>
+ </message>
+ <message name='ProfileMgmt_getCustomerDiscountResponse'>
+ <part element='tns:getCustomerDiscountResponse'
+ name='getCustomerDiscountResponse'/>
+ </message>
+ <portType name='ProfileMgmt'>
+ <operation name='getCustomerDiscount'
+ parameterOrder='getCustomerDiscount'>
+
+ <input message='tns:ProfileMgmt_getCustomerDiscount'/>
+ <output
message='tns:ProfileMgmt_getCustomerDiscountResponse'/>
+ </operation>
+ </portType>
+ <binding name='ProfileMgmtBinding'
type='tns:ProfileMgmt'>
+ <soap:binding style='document'
+ transport='<ulink
url="http://schemas.xmlsoap.org/soap/http'/">http://sche...
+ <operation name='getCustomerDiscount'>
+ <soap:operation soapAction=''/>
+ <input>
+
+ <soap:body use='literal'/>
+ </input>
+ <output>
+ <soap:body use='literal'/>
+ </output>
+ </operation>
+ </binding>
+ <service name='ProfileMgmtService'>
+ <port binding='tns:ProfileMgmtBinding'
name='ProfileMgmtPort'>
+
+ <soap:address
+ location='<ulink
url="http://">http://</ulink><HOST>:<PORT>/jaxws-samples-retail/ProfileMgmtBean'/>
+ </port>
+ </service>
+</definitions></screen><para> </para> </section>
+</section></chapter>
\ No newline at end of file
Added: stack/cxf/trunk/src/main/doc/JBossWS-Recordsmanagement.xml
===================================================================
--- stack/cxf/trunk/src/main/doc/JBossWS-Recordsmanagement.xml
(rev 0)
+++ stack/cxf/trunk/src/main/doc/JBossWS-Recordsmanagement.xml 2010-11-02 18:00:03 UTC
(rev 13200)
@@ -0,0 +1,33 @@
+<?xml version="1.0" encoding="UTF-8"?><chapter
id="chap_JBossWS-Recordsmanagement"><title>JBossWS-Recordsmanagement</title><para>JBossWS
records' collection and management system gives administrators a means of performing
custom analysis of their webservice traffic as well as exporting communication
logs.</para><para/><para> </para><section
id="JBossWS-Recordsmanagement_What_is_recorded"><title>What is
recorded</title><para>Each record is basically composed of a message plus
additional information; here are the current record
attributes:</para><itemizedlist><listitem><para> Creation date
</para></listitem><listitem><para> Source host
</para></listitem><listitem><para> Destination host
</para></listitem><listitem><para> Message type (in/out)
</para></listitem><listitem><para> Invoked endpoint operation
</para></listitem><listitem><para> Message envelope (including
both soap:header and soap:body for SOAP messages)
</para></listitem><listitem><para> Http headers
</para></list!
item><listitem><para> Record group ID (allowing records belonging to the
same message flow to be linked together)
</para></listitem></itemizedlist><para>Of course records may also
have meaningful values for a subset of the afore mentioned record
attributes.</para><para> </para></section>
+<section id="JBossWS-Recordsmanagement_Use_cases"><title>Use
cases</title><para>What are records useful for? In spite of <link
linkend="chap_JBossWS-Endpointmanagement">endpoint metrics</link> that
provide response time information and counts of invocations, records provide users with
rich data about the content of the exchanged messages and their sender/receiver. The
record system allows fine grained management and is customizable according to the users
need; some of the use cases supported by the default configuration
are:</para><itemizedlist><listitem><para> Logging request and
response messages: being able to record messages received from and sent to a given service
consumer without stopping the provider may be really useful. You just need to set the
<emphasis>recording</emphasis> attribute of their endpoint's LogRecorder
to true. The added value of this logging solution comes from the use of filters through
which messages coming from a given address and related to a gi!
ven wsdl operation only can be logged.
</para></listitem><listitem><para> Accountability: service
providers may want to know which consumers are actually hitting a given service. This can
be done for example using the <emphasis>getClientHosts</emphasis>
functionality of the MemoryBufferRecorder once it has been switched to recording state.
</para></listitem><listitem><para> Getting statistics, filtering
records: service administrators might want to see the last records related to a given
endpoint or operation, the last records related to messages coming from a given customer
and the response the system gave them, etc. These information can be obtained using the
<emphasis>getRecordsByOperation</emphasis>,
<emphasis>getRecordsByClientHost</emphasis> or the more general
<emphasis>getMatchingRecords</emphasis> functionality of the
MemoryBufferRecorder.</para></listitem></itemizedlist><para> </para></section>
+<section
id="JBossWS-Recordsmanagement_How_it_works_and_how_to_use_it"><title>How
it works and how to use it</title><para>The recording system is composed
of</para><itemizedlist><listitem><para> JAX-WS handlers
intercepting inbound and outbound communication
</para></listitem><listitem><para> Record processors plugged into
deployed endpoints; handlers collect records and send them to every processors through the
current endpoint. Processors may store records, convert them, log them, ...
</para></listitem><listitem><para> MBean views of processors that
can be used to configure and fine tune recording at runtime
</para></listitem><listitem><para> Record filters allowing
selection of information to be recorded as well as providing means of performing custom
queries on the saved
records.</para></listitem></itemizedlist><para> </para><section
id="JBossWS-Recordsmanagement_Server_side"><title>Server
side</title><para>On server side records are collected by JAX-WS handlers and
pa!
ssed to the configured processors. JBossWS comes with two default record processors that
are plugged into every endpoint during the
deployment:</para><itemizedlist><listitem><para> LogRecorder: a
simple record processor that writes records to the configured log.
</para></listitem><listitem><para> MemoryBufferRecorder: a record
processor that keeps the last received records in memory and allows user to search / get
statistics on them. </para></listitem></itemizedlist><para>Every
processors can be fine tuned to process some record attributes only according to the user
and/or performance requirements. Default processors are not in recording mode upon
creation, thus you need to switch them to recording mode through their MBean interfaces
(see the <emphasis>Recording</emphasis> flag in the
jmx-console).</para><para>Common processor properties and their respective
defaults values are:</para><itemizedlist><listitem><para>
processDestinationHost (true) </para></listitem><listitem><!
para> processSourceHost (true) </para></listitem><listitem><pa!
ra> proc
essHeaders (true) </para></listitem><listitem><para>
processEnvelope (true) </para></listitem><listitem><para>
processMessageType (true) </para></listitem><listitem><para>
processOperation (true) </para></listitem><listitem><para>
processDate (true) </para></listitem><listitem><para> recording
(false) </para></listitem></itemizedlist><para>The recorders can
be configured in the stacks bean configuration</para><screen
xml:space="preserve"> <!-- Installed Record Processors-->
+ <bean name="WSMemoryBufferRecorder"
class="org.jboss.wsf.framework.management.recording.MemoryBufferRecorder">
+ <property name="recording">false</property>
+ </bean>
+ <bean name="WSLogRecorder"
class="org.jboss.wsf.framework.management.recording.LogRecorder">
+ <property name="recording">false</property>
+ </bean>
+</screen><para>The recording system is available for all the JBossWS
supported stacks. However slightly different procedure is required to enable it depending
on the used
stack.</para><variablelist><varlistentry><term><emphasis
role="bold">Native stack</emphasis>
</term><listitem/></varlistentry></variablelist><para>Native
stack comes with <ulink
url="http://community.jboss.org/docs/DOC-13512">JBossWS - JAX-WS Endpoint
Configuration</ulink>. The default standard endpoint already has the server side
recording handler:</para><screen xml:space="preserve">
<endpoint-config>
+ <config-name>Standard Endpoint</config-name>
+ <pre-handler-chains>
+ <javaee:handler-chain>
+
<javaee:protocol-bindings>##SOAP11_HTTP</javaee:protocol-bindings>
+ <javaee:handler>
+ <javaee:handler-name>Recording
Handler</javaee:handler-name>
+
<javaee:handler-class>org.jboss.wsf.framework.invocation.RecordingServerHandler</javaee:handler-class>
+ </javaee:handler>
+ </javaee:handler-chain>
+ </pre-handler-chains>
+ </endpoint-config>
+</screen><para>thus nothing is required to use it since it is automatically
installed in the pre-handler-chain. Of course you might want to add it to other endpoint
configurations you're
using.</para><variablelist><varlistentry><term><emphasis
role="bold">Metro and CXF stacks
</emphasis></term><listitem/></varlistentry></variablelist><para>Other
stacks require users to manually add the
<emphasis>org.jboss.wsf.framework.invocation.RecordingServerHandler</emphasis>
to their endpoint handler chain. This can be done <link
linkend="chap_JBossWS-UserGuide">the same way common user handlers are
added</link>.</para><para>Once the handler is properly added to the
chain, log recording configuration is agnostic to the used stack. Users just need to tune
the processors parameters though their MBean
interfaces.</para><para> </para></section>
+<section id="JBossWS-Recordsmanagement_Client_side"><title>Client
side</title><para>JMX management of processors is of course available on
server side only. However users might also be interested in collecting and processing
records on client side. Since handlers can be set on client side too, customer handlers
could be configured to capture messages almost like the
<emphasis>RecordingServerHandler</emphasis> does. This is left to the users
since it is directly linked to their custom needs. For instance a common use could be to
pass client side collected records to the
LogRecorder.</para><para> </para></section>
+</section>
+<section
id="JBossWS-Recordsmanagement_Advanced_hints"><title>Advanced
hints</title><section
id="JBossWS-Recordsmanagement_Adding_custom_recorders"><title>Adding
custom recorders</title><para>As previously said, the recording system is
extensible: JBossWS users can write their own processors and plug them at runtime into
their deployed endpoints through the <emphasis>addRecordProcessor</emphasis>
functionality of the ManagedEndpoint MBean. Every processor needs to implement the
<emphasis>org.jboss.wsf.spi.management.recording.RecordProcessor</emphasis>
interface. Then you can choose one of the two following
options:</para><itemizedlist><listitem><para> Give you record
processor an MBean interface declaring the manageable attributes: the recording system
will plug your processor to the endpoint and register a management MBean for it using your
interface. This allows you to create highly configurable custom processors. For an example
of this development option, take a look at!
the
<emphasis>org.jboss.wsf.framework.management.recording.MemoryBufferRecorder</emphasis>.
</para></listitem><listitem><para> Add your record processor to
the managed endpoint as is: the recording system will plug it to the endpoint and register
a standard management MBean for its basic processing configuration. The
<emphasis>org.jboss.wsf.framework.management.recording.LogRecorder</emphasis>
is an example of this development option.
</para></listitem></itemizedlist><para>A code snippet showing how
to get the MBeanProxy instance which you can invoke MBean with can be found <link
linkend="chap_JBossWS-Endpointmanagement">here</link>.</para></section>
+<section
id="JBossWS-Recordsmanagement_Handlers_position"><title>Handler's
position</title><para>Of course the recording handler's position in the
handler chain influences the collected records. As a matter of fact some information may
or may not be available at a given point of the handler chain execution. The standard
endpoint configuration declares the RecordingServerHandler into the pre-handler-chain.
Speaking of the native stack, this means for example that you'll get the invoked
operation data and that decrypted messages will be recorded if using WS-Security, since
the WS-Security handler runs in the post-handler-chain. Users might want to change the
recording handler's position in the chain according to their
requirements.</para></section>
+<section
id="JBossWS-Recordsmanagement_Multiple_handlers"><title>Multiple
handlers</title><para>Records attributes include a record group ID that is
meant to link records whose messages belong to the same message flow (a request-response
for example). In order to set the right group ID to the records, the current ID is
associated to the thread that is processing the endpoint invocation. This means that
multiple related records can be linked together and extracted together from a
processor.</para><para>For this reason, you might want to install multiple
recording handlers into different points of the handler chain. For instance, it could make
sense to record messages both before and after encryption/decryption when using
WS-Security.</para></section>
+</section>
+<section
id="JBossWS-Recordsmanagement_Future_extensions"><title>Future
extensions</title><para>This paragraph covers eventual future extensions
and/or idea JBossWS users may want to leverage for their own
business.</para><section
id="JBossWS-Recordsmanagement_Database_recorder"><title>Database
recorder</title><para>The MemoryBufferRecorder provides interesting
functionalities to query the collected records set. For obvious reasons, records are
discarded once a given size of the buffer is reached.</para><para>A DB based
recorder could be developed; it should work the same way the MemoryBufferRecorder does,
except for records that should be saved through a given datasource. This will provide
persistence of data even in case of application server reboot and webservice application
redeploy. It will also allow records coming from different node of a cluster to be stored
together. Finally this would allow administrators to directly query the database, which
might be far more eff!
icient.</para></section>
+<section
id="JBossWS-Recordsmanagement_Custom_log_writer"><title>Custom log
writer</title><para>The idea of getting statistics from collected records
could be further exploited getting custom logs from the records. These logs could be
outputted by a custom processor in standard or proprietary formats allowing them to be
imported into eventual third-party log processing tools which might offer complex/funky
graphic or statistic functionalities and so on.</para></section>
+</section>
+<section
id="JBossWS-Recordsmanagement_References"><title>References</title><para>You
might want to take a look at the
<emphasis>org.jboss.wsf.framework.management.recording</emphasis> and
<emphasis>org.jboss.wsf.spi.management.recording</emphasis> packages in the
source code to better understand how all this works and can be
used.</para></section>
+</chapter>
\ No newline at end of file
Added: stack/cxf/trunk/src/main/doc/JBossWS-Securetransport.xml
===================================================================
--- stack/cxf/trunk/src/main/doc/JBossWS-Securetransport.xml (rev
0)
+++ stack/cxf/trunk/src/main/doc/JBossWS-Securetransport.xml 2010-11-02 18:00:03 UTC (rev
13200)
@@ -0,0 +1,54 @@
+<?xml version="1.0" encoding="UTF-8"?><chapter
id="chap_JBossWS-Securetransport"><title>JBossWS-Securetransport</title><para/><para>JBossWS
allows you to require that requests to a given endpoint use SSL by specifying the
<emphasis>transportGuarantee</emphasis> attribute in the <ulink
url="http://community.jboss.org/docs/DOC-13972#WebContext">@...
annotation.</para><para>Here is an example using a SLSB
endpoint:</para><screen xml:space="preserve">@Stateless
+@SecurityDomain("JBossWS")
+@RolesAllowed("friend")
+@WebContext
+(
+ contextRoot="/my-cxt",
+ urlPattern="/*",
+ authMethod="BASIC",
+ transportGuarantee="CONFIDENTIAL",
+ secureWSDLAccess=<emphasis role="bold">false</emphasis>
+)
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> EndpointEJB <emphasis
role="bold">implements</emphasis> EndpointInterface
+{
+ ...
+}
+</screen><para>Similarly to enforce the same requirement on POJO endpoints,
you need to edit web.xml and add a user-data-constraint element to your
security-constraint element:</para><screen xml:space="preserve">
<security-constraint>
+ <web-resource-collection>
+ <web-resource-name>All resources</web-resource-name>
+ <url-pattern>/*</url-pattern>
+ </web-resource-collection>
+ <auth-constraint>
+ <role-name>friend</role-name>
+ </auth-constraint>
+ <user-data-constraint>
+
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
+ </user-data-constraint>
+ </security-constraint>
+
+ <security-role>
+ <role-name>friend</role-name>
+ </security-role>
+</screen><para>If you're manually creating your service contract, make
sure that the endpoint address in your WSDL file uses a secure protocol. The easiest way
is to add "<ulink url="https://">https://</ulink>" to the
SOAP Address entry:</para><screen xml:space="preserve">
<service name="MyService">
+ <port name="BasicSecuredPort"
binding="tns:MyBinding">
+ <soap:address location="<ulink
url="https://localhost:8443/my-ctx/SecureEndpoint">https://localhost:8443/my-ctx/SecureEndpoint</ulink>"/>
+ </port>
+ </service>
+</screen><para>For this to work the Tomcat+SSL connector must be
enabled:</para><screen xml:space="preserve"> <Connector
port="8443" address="${jboss.bind.address}"
+ maxThreads="100" minSpareThreads="5"
maxSpareThreads="15"
+ scheme="https" secure="true" clientAuth="want"
+ keystoreFile="${jboss.server.home.dir}/conf/keystores/wsse.keystore"
+ keystorePass="jbossws"
+ truststoreFile="${jboss.server.home.dir}/conf/keystores/wsse.keystore"
+ truststorePass="jbossws"
+ sslProtocol = "TLS" />
+</screen><para>Please refer the <ulink
url="http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html">... SSL
Configuration HOWTO</ulink> for further
details.</para><para> </para><section
id="JBossWS-Securetransport_Client_side"><title>Client
side</title><para>On the client side the truststore must be
installed:</para><screen xml:space="preserve">
<sysproperty key="javax.net.ssl.keyStore"
value="${test.resources.dir}/wsse/wsse.keystore"/>
+ <sysproperty key="javax.net.ssl.trustStore"
value="${test.resources.dir}/wsse/wsse.truststore"/>
+ <sysproperty key="javax.net.ssl.keyStorePassword"
value="jbossws"/>
+ <sysproperty key="javax.net.ssl.trustStorePassword"
value="jbossws"/>
+ <sysproperty key="javax.net.ssl.keyStoreType"
value="jks"/>
+ <sysproperty key="javax.net.ssl.trustStoreType"
value="jks"/></screen><para>As you can see, this requires you
to setup the environment specifying both the location and type of your
truststore.</para><para>Finally, in case you see the following
exception:</para><screen xml:space="preserve"> java.io.IOException:
HTTPS hostname wrong: should be <localhost>
+ at sun.net.www.protocol.https.HttpsClient.checkURLSpoofing(HttpsClient.java:493)
+ at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:418)
+</screen><para>you should disable URL checking on the client
side:</para><screen xml:space="preserve"> <sysproperty
key="org.jboss.security.ignoreHttpsHost"
value="true"/></screen></section>
+</chapter>
\ No newline at end of file
Added: stack/cxf/trunk/src/main/doc/JBossWS-StackCXFUserGuide.xml
===================================================================
--- stack/cxf/trunk/src/main/doc/JBossWS-StackCXFUserGuide.xml
(rev 0)
+++ stack/cxf/trunk/src/main/doc/JBossWS-StackCXFUserGuide.xml 2010-11-02 18:00:03 UTC
(rev 13200)
@@ -0,0 +1,382 @@
+<?xml version="1.0" encoding="UTF-8"?><chapter
id="chap_JBossWS-StackCXFUserGuide"><title>JBossWS-StackCXFUserGuide</title><note><para><para>This
page covers features available in <emphasis role="bold">JBossWS CXF stack
only</emphasis>. <link linkend="chap_JBossWS-UserGuide">Please refer
to the common user guide</link> for a basic introduction to JAX-WS programming as
well as documentation on all features, tools, etc. the JBossWS Web Service Framework
provides for every supported stack (including CXF
stack).</para><para> </para> <para>Also please note this page does
not go through the documentation of every feature, option, etc. provided by Apache CXF; on
the countrary the only topics covered here are specific issues regarding integration with
JBoss and stack specific features provided by JBossWS Web Service Framework for the CXF
stack. A few tutorials are also provided for show how to leverage some WS
technologies.</para> <para>The <emphasis>official Apache CXF
documentat!
ion</emphasis> is available <ulink
url="http://cxf.apache.org">here</ulink>.</para></para></note><para/><para> </para><section
id="JBossWS-StackCXFUserGuide_JBossWS_CXF_Integration"><title>JBossWS
CXF Integration</title><section
id="JBossWS-StackCXFUserGuide_Creating_a_Bus_instance"><title>Creating
a Bus instance</title><para>Most of the Apache CXF features are configurable
using the <emphasis>org.apache.cxf.Bus</emphasis> class. New Bus instances are
produced by the currently configured
<emphasis>org.apache.cxf.BusFactory</emphasis> implementation the following
way:</para><screen xml:space="preserve">Bus bus =
BusFactory.newInstance().createBus();
+</screen><para>The algorithm for selecting the actual implementation of
BusFactory to be used leverages the Service API, basically looking for optional
configurations in META-INF/services/... location using the current classloader.
JBossWS-CXF integration comes with his own implementation of BusFactory,
<emphasis>org.jboss.wsf.stack.cxf.client.configuration.JBossWSBusFactory</emphasis>,
that allows for automatic detection of Spring availability as well as seamless setup of
JBossWS customizations on top of Apache CXF. JBossWSBusFactory is
<emphasis>automatically</emphasis> retrieved by the BusFactory.newInstance()
call above.</para><para> </para><para>JBossWS users willing to
explicitely use functionalities of
<emphasis>org.apache.cxf.bus.spring.SpringBusFactory</emphasis> or
<emphasis>org.apache.cxf.bus.CXFBusFactory,</emphasis> get the same API with
JBossWS additions through JBossWSBusFactory:</para><screen
xml:space="preserve">String myConfigFile = ...
+Bus bus = <emphasis role="bold">new</emphasis>
JBossWSBusFactory().createBus(myConfigFile);
+</screen><para> </para><screen
xml:space="preserve">Map<Class, Object> myExtensions =
<emphasis role="bold">new</emphasis> HashMap<Class,
Object>();
+myExtensions.put(...);
+Bus bus = <emphasis role="bold">new</emphasis>
JBossWSBusFactory().createBus(myExtensions);
+</screen></section>
+<section
id="JBossWS-StackCXFUserGuide_Server_Side_Integration_Customization"><title>Server
Side Integration Customization</title><para>It is possible to customize the
JBossWS and CXF integration by incorporating the CXF configuration file to the endpoint
deployment archive. In order for that to be possible, JBossWS-CXF requires Spring to be
installed in the application server. The Spring Framework libraries installation can be
perfomed using the <ulink
url="http://community.jboss.org/docs/DOC-13545">JBossWS-CXF
installation</ulink>.</para><para>The convention is the
following:</para><itemizedlist><listitem><para> file name must be
<emphasis role="bold">jbossws-cxf.xml</emphasis>
</para></listitem><listitem><para> for POJO deployments it is
located in <emphasis role="bold">WEB-INF</emphasis> directory
</para></listitem><listitem><para> for EJB3 deployments it is
located in <emphasis role="bold">META-INF</emphasis> directory
</para></listitem></itemizedlist><para>If user do !
not provide its own CXF configuration file, a default one is automatically generated
during the deployment.</para><para>For POJO deployments the generated
<emphasis role="bold">jbossws-cxf.xml</emphasis> has the following
content:</para><screen xml:space="preserve"><beans
+ xmlns='<ulink
url="http://www.springframework.org/schema/beans">http://www...
+ xmlns:xsi='<ulink
url="http://www.w3.org/2001/XMLSchema-instance">http://www.w...
+ xmlns:beans='<ulink
url="http://www.springframework.org/schema/beans">http://www...
+ xmlns:jaxws='<ulink
url="http://cxf.apache.org/jaxws">http://cxf.apache.org/jaxw...
+ xsi:schemaLocation='<ulink
url="http://www.springframework.org/schema/beans">http://www...
+ <ulink
url="http://www.springframework.org/schema/beans/spring-beans.xsd&qu...
+ <ulink
url="http://cxf.apache.org/jaxws">http://cxf.apache.org/jaxw...
+ <ulink
url="http://cxf.apache.org/schemas/jaxws.xsd">http://cxf.apa...
+
+ <!-- one or more jaxws:endpoint POJO declarations -->
+ <jaxws:endpoint
+ id='POJOEndpoint'
+ address='<ulink
url="http://localhost:8080/pojo_endpoint_archive_name">http://localhost:8080/pojo_endpoint_archive_name</ulink>'
+ implementor='my.package.POJOEndpointImpl'>
+ <jaxws:invoker>
+ <bean class='org.jboss.wsf.stack.cxf.InvokerJSE'/>
+ </jaxws:invoker>
+ </jaxws:endpoint></beans>
+</screen><para>For EJB3 deployments the generated <emphasis
role="bold">jbossws-cxf.xml</emphasis> has the following
content:</para><screen xml:space="preserve"><beans
+ xmlns='<ulink
url="http://www.springframework.org/schema/beans">http://www...
+ xmlns:xsi='<ulink
url="http://www.w3.org/2001/XMLSchema-instance">http://www.w...
+ xmlns:beans='<ulink
url="http://www.springframework.org/schema/beans">http://www...
+ xmlns:jaxws='<ulink
url="http://cxf.apache.org/jaxws">http://cxf.apache.org/jaxw...
+ xsi:schemaLocation='<ulink
url="http://www.springframework.org/schema/beans">http://www...
+ <ulink
url="http://www.springframework.org/schema/beans/spring-beans.xsd&qu...
+ <ulink
url="http://cxf.apache.org/jaxws">http://cxf.apache.org/jaxw...
+ <ulink
url="http://cxf.apache.org/schemas/jaxws.xsd">http://cxf.apa...
+
+ <!-- one or more jaxws:endpoint EJB3 declarations -->
+ <jaxws:endpoint
+ id='EJB3Endpoint'
+ address='<ulink
url="http://localhost:8080/ejb3_endpoint_archive_name">http://localhost:8080/ejb3_endpoint_archive_name</ulink>'
+ implementor='my.package.EJB3EndpointImpl'>
+ <jaxws:invoker>
+ <bean class='org.jboss.wsf.stack.cxf.InvokerEJB3'/>
+ </jaxws:invoker>
+ </jaxws:endpoint></beans>
+</screen><para>Providing custom CXF configuration to the endpoint deployment
is useful in cases when users want to use features that are not part of standard JAX-WS
specification but CXF implements them. For example see <link
linkend="chap_JBossWS-CXFWS-ReliableMessagingtutorial">CXF WS-RM
tutorial</link> customization file. We are providing custom CXF endpoint
configuration there to turn on WS-RM feature for
endpoint.</para><note><para><para><emphasis><emphasis
role="bold">Note</emphasis></emphasis></para><para><emphasis>When
user incorporates its own CXF configuration to the endpoint archive he must reference
either <emphasis
role="bold">org.jboss.wsf.stack.cxf.InvokerJSE</emphasis> or
<emphasis role="bold">org.jboss.wsf.stack.cxf.InvokerEJB3</emphasis>
jaxws invoker bean there for each jaxws
endpoint.</emphasis></para><para> </para></para></note></section>
+</section>
+<section
id="JBossWS-StackCXFUserGuide_Extended_Features"><title>Extended
Features</title><para><ulink
url="http://cwiki.apache.org/CXF20DOC/ws-support.html">Here&... is
the CXF documentation about supported WS-*
specifications.</para><para> </para><section
id="JBossWS-StackCXFUserGuide_WSAddressing"><title>WS-Addressing</title><para>Apache
CXF has a thorough support for WS-Addressing; details are available at the following
pages:</para><para><ulink
url="http://cwiki.apache.org/CXF20DOC/ws-addressing.html">CXF WS-Addressing
documentation</ulink> <ulink
url="http://cwiki.apache.org/CXF20DOC/wsaconfiguration.html">...
WS-Addressing
configuration</ulink></para><para> </para><para>Given the
JAXWS specification currently covers WS-Addressing basic fuctionalities, users simply
needing to enable it can make use of the @Addressing annotation and AddressingFeature, as
shown in the following JBossWS-CXF tutorial:</para><para><link
linkend="chap_JBossWS-CXFWS-Addressingtutorial"!
JBossWS-CXF WS-Addressing
Tutorial</link></para><para> </para></section>
+<section
id="JBossWS-StackCXFUserGuide_WSReliableMessaging"><title>WS-ReliableMessaging</title><para>The
Apache CXF technical documentation on WS-RealiableMessaging is available as a reference at
the following pages:</para><para><ulink
url="http://cwiki.apache.org/CXF20DOC/ws-reliablemessaging.html"...
WS-ReliableMessaging documentation</ulink> <ulink
url="http://cwiki.apache.org/CXF20DOC/wsrmconfiguration.html"&g...
WS-ReliableMessaging
configuration</ulink></para><para> </para><para>For a
complete tutorial on how to enable WS-ReliableMessaging in a user client-server
application, please take a look at:</para><para><link
linkend="chap_JBossWS-CXFWS-ReliableMessagingtutorial">JBossWS-CXF
WS-ReliableMessaging
Tutorial</link></para><para> </para></section>
+<section
id="JBossWS-StackCXFUserGuide_WSPolicy"><title>WS-Policy</title><para>Apache
CXF technical documentation on the WS-Policy engine and its configuration is available
at:</para><para><ulink
url="http://cwiki.apache.org/CXF20DOC/ws-policy.html">CXF WS-Policy
documentation</ulink> <ulink
url="http://cwiki.apache.org/CXF20DOC/wspconfiguration.html">... WS-Policy
configuration</ulink></para><para> </para><para>For a
complete sample of WS-Policy usage, please take a look at the JBossWS-CXF
WS-ReliableMessaging tutorial below, as WS-RM is implemented leveraging policies
there:</para><para><link
linkend="chap_JBossWS-CXFWS-ReliableMessagingtutorial">JBossWS-CXF WS-Policy
& WS-ReliableMessaging
Tutorial</link></para><para> </para><section
id="JBossWS-StackCXFUserGuide_Note_on_PolicyEngine_setup"><title>Note
on PolicyEngine setup</title><para>When building up the Bus without Spring
libraries available on the classpath, JBossWSBusFactory still makes sure the PolicyEngine
!
(as well as the RMManager) is properly setup. This allows users to leverage basic
WS-Policy functionalities the same way they'd do with a full Spring-enabled
Bus.</para><para> </para></section>
+</section>
+<section
id="JBossWS-StackCXFUserGuide_WSSecurity"><title>WS-Security</title><para><ulink
url="http://cxf.apache.org/">Apache CXF</ulink> leverages <ulink
url="http://ws.apache.org/wss4j/">WSS4J</ulink> to provide WS-Security
functionalities. This means that thanks to the JBossWS-CXF integration, users can create
web service applications using CXF - WSS4J implementation of WS-Security and deploy them
on JBoss Application Server.</para><para> </para><section
id="JBossWS-StackCXFUserGuide_WSS4J_security_on_JBoss"><title>WSS4J
security on JBoss</title><para>The Apache CXF documentation features an brief
chapter on <ulink
url="http://cwiki.apache.org/CXF20DOC/ws-security.html">how to use WSS4J
security in CXF</ulink>. Here below instead you'll find some explanations on how
to create a simple application and what you need to do to leverage WSS4J security on
JBoss.</para><para> </para><variablelist><varlistentry><term><emphasis
role="bold">Creating the web service endpoint </em!
phasis></term><listitem/></varlistentry></variablelist><para>First
of all you need to create the web service endpoint / client using JAX-WS. This can be
achieved in many ways, for instance you might want
to:</para><orderedlist><listitem><para> write your endpoint
implementation, then run the <emphasis
role="bold"><emphasis>wsprovide</emphasis></emphasis> JBoss
commandline tool which generates the service contract (bottom-up approach);
</para></listitem><listitem><para> run the <emphasis
role="bold"><emphasis>wsconsume</emphasis></emphasis> JBoss
commandline tool to get the client artifacts from the service contract (top-down
approach); </para></listitem><listitem><para> write your client
implementation.
</para></listitem></orderedlist><para> </para><variablelist><varlistentry><term><emphasis
role="bold">Turn on WS-Security
</emphasis></term><listitem/></varlistentry></variablelist><para>WSS4J
security is triggered through interceptors that are added to the service and/or c!
lient. These interceptors allows you to perform the most commo!
n WS-Sec
urity related process:</para><itemizedlist><listitem><para> pass
authentication tokens between services;
</para></listitem><listitem><para> encrypt messages or parts of
messages; </para></listitem><listitem><para> sign messages;
</para></listitem><listitem><para> timestamp messages.
</para></listitem></itemizedlist><para>Interceptors can be added
either programmatically or through the Spring xml configuration of
endpoints.</para><para>For instance, on server side, you can configure
signature and encryption in the <emphasis>jboss-cxf.xml</emphasis> file this
way:</para><screen xml:space="preserve"><beans
+ xmlns='<ulink
url="http://www.springframework.org/schema/beans">http://www...
+ xmlns:xsi='<ulink
url="http://www.w3.org/2001/XMLSchema-instance">http://www.w...
+ xmlns:beans='<ulink
url="http://www.springframework.org/schema/beans">http://www...
+ xmlns:jaxws='<ulink
url="http://cxf.apache.org/jaxws">http://cxf.apache.org/jaxw...
+ xsi:schemaLocation='<ulink
url="http://cxf.apache.org/core">http://cxf.apache.org/core&...
+ <ulink
url="http://cxf.apache.org/schemas/core.xsd">http://cxf.apac...
+ <ulink
url="http://www.springframework.org/schema/beans">http://www...
+ <ulink
url="http://www.springframework.org/schema/beans/spring-beans-2.0.xs...
+ <ulink
url="http://cxf.apache.org/jaxws">http://cxf.apache.org/jaxw...
+ <ulink
url="http://cxf.apache.org/schemas/jaxws.xsd">http://cxf.apa...
+
+ <bean id="Sign_Request"
class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor">
+ <constructor-arg>
+ <map>
+ <entry key="action" value="Timestamp Signature
Encrypt"/>
+ <entry key="signaturePropFile"
value="bob.properties"/>
+ <entry key="decryptionPropFile"
value="bob.properties"/>
+ <entry key="passwordCallbackClass"
value="org.jboss.test.ws.jaxws.samples.wsse.KeystorePasswordCallback"/>
+ </map>
+ </constructor-arg>
+ </bean>
+
+ <bean id="Sign_Response"
class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor">
+ <constructor-arg>
+ <map>
+ <entry key="action" value="Timestamp Signature
Encrypt"/>
+ <entry key="user" value="bob"/>
+ <entry key="signaturePropFile"
value="bob.properties"/>
+ <entry key="encryptionPropFile"
value="bob.properties"/>
+ <entry key="encryptionUser" value="Alice"/>
+ <entry key="signatureKeyIdentifier"
value="DirectReference"/>
+ <entry key="passwordCallbackClass"
value="org.jboss.test.ws.jaxws.samples.wsse.KeystorePasswordCallback"/>
+ <entry key="signatureParts" value="{Element}{<ulink
url="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecur...
url="http://schemas.xmlsoap.org/soap/envelope/">http://schem...
+ <entry key="encryptionParts" value="{Element}{<ulink
url="http://www.w3.org/2000/09/xmldsig#">http://www.w3.org/2...
url="http://schemas.xmlsoap.org/soap/envelope/">http://schem...
+ <entry key="encryptionKeyTransportAlgorithm"
value="<ulink
url="http://www.w3.org/2001/04/xmlenc#rsa-1_5">http://www.w3...
+ <entry key="encryptionSymAlgorithm" value="<ulink
url="http://www.w3.org/2001/04/xmlenc#tripledes-cbc">http://...
+ </map>
+ </constructor-arg>
+ </bean>
+
+ <jaxws:endpoint
+ id='ServiceImpl'
+ address='<ulink
url="http://@jboss.bind.address@:8080/jaxws-samples-wsse-sign-encrypt">http://@jboss.bind.address@:8080/jaxws-samples-wsse-sign-encrypt</ulink>'
+ implementor='org.jboss.test.ws.jaxws.samples.wsse.ServiceImpl'>
+ <jaxws:invoker>
+ <bean class='org.jboss.wsf.stack.cxf.InvokerJSE'/>
+ </jaxws:invoker>
+ <jaxws:outInterceptors>
+ <bean
class="org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor"/>
+ <ref bean="Sign_Response"/>
+ </jaxws:outInterceptors>
+ <jaxws:inInterceptors>
+ <ref bean="Sign_Request"/>
+ <bean
class="org.apache.cxf.binding.soap.saaj.SAAJInInterceptor"/>
+ </jaxws:inInterceptors>
+ </jaxws:endpoint>
+</beans>
+</screen><para>This specifies the whole security configuration (including
algorithms and elements to be signed/encrypted); moreover it references a properties file
(<emphasis>bob.properties</emphasis>) providing the keystore-related
information:</para><screen
xml:space="preserve">org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
+org.apache.ws.security.crypto.merlin.keystore.type=jks
+org.apache.ws.security.crypto.merlin.keystore.password=password
+org.apache.ws.security.crypto.merlin.keystore.alias=bob
+org.apache.ws.security.crypto.merlin.file=bob.jks
+</screen><para>As you can see in the
<emphasis>jbossws-cxf.xml</emphasis> file above, a keystore password callback
handler is also configured; while the properties file has the password for the keystore,
this callback handler is used to set password for each key (it has to match the one used
when each key was imported in the store). Here's a trivial
example:</para><screen xml:space="preserve"><emphasis
role="bold">package</emphasis> org.jboss.test.ws.jaxws.samples.wsse;
+
+<emphasis role="bold">import</emphasis> java.io.IOException;
+<emphasis role="bold">import</emphasis> java.util.HashMap;
+<emphasis role="bold">import</emphasis> java.util.Map;
+
+<emphasis role="bold">import</emphasis>
javax.security.auth.callback.Callback;
+<emphasis role="bold">import</emphasis>
javax.security.auth.callback.CallbackHandler;
+<emphasis role="bold">import</emphasis>
javax.security.auth.callback.UnsupportedCallbackException;
+<emphasis role="bold">import</emphasis>
org.apache.ws.security.WSPasswordCallback;
+
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> KeystorePasswordCallback <emphasis
role="bold">implements</emphasis> CallbackHandler
+{
+ <emphasis role="bold">private</emphasis> Map<String,
String> passwords = <emphasis role="bold">new</emphasis>
HashMap<String, String>();
+
+ <emphasis role="bold">public</emphasis>
KeystorePasswordCallback()
+ {
+ passwords.put("alice", "password");
+ passwords.put("bob", "password");
+ }
+
+ <emphasis role="bold">public</emphasis> <emphasis
role="bold">void</emphasis> handle(Callback[] callbacks) <emphasis
role="bold">throws</emphasis> IOException,
UnsupportedCallbackException
+ {
+ <emphasis role="bold">for</emphasis> (<emphasis
role="bold">int</emphasis> i = 0; i < callbacks.length; i++)
+ {
+ WSPasswordCallback pc = (WSPasswordCallback)callbacks[i];
+ String pass = passwords.get(pc.getIdentifer());
+ <emphasis role="bold">if</emphasis> (pass != <emphasis
role="bold">null</emphasis>)
+ {
+ pc.setPassword(pass);
+ <emphasis role="bold">return</emphasis>;
+ }
+ }
+ }
+
+ <emphasis role="bold">public</emphasis> <emphasis
role="bold">void</emphasis> setAliasPassword(String alias, String
password)
+ {
+ passwords.put(alias, password);
+ }
+}
+</screen><para>On client side, you can similarly setup the interceptors
programmatically; here is an excerpt of the client for the above described endpoint (of
course you can also leverage a proper Spring configuration for loading an already
configured CXF Bus instance):</para><screen
xml:space="preserve">Endpoint cxfEndpoint = client.getEndpoint();
+Map<String,Object> outProps = <emphasis
role="bold">new</emphasis> HashMap<String,Object>();
+outProps.put("action", "Timestamp Signature Encrypt");
+outProps.put("user", "alice");
+outProps.put("signaturePropFile", "META-INF/alice.properties");
+outProps.put("signatureKeyIdentifier", "DirectReference");
+outProps.put("passwordCallbackClass",
"org.jboss.test.ws.jaxws.samples.wsse.KeystorePasswordCallback");
+outProps.put("signatureParts",
"{Element}{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp;{Element}{http://schemas.xmlsoap.org/soap/envelope/}Body");
+outProps.put("encryptionPropFile", "META-INF/alice.properties");
+outProps.put("encryptionUser", "Bob");
+outProps.put("encryptionParts",
"{Element}{http://www.w3.org/2000/09/xmldsig#}Signature;{Content}{http://schemas.xmlsoap.org/soap/envelope/}Body");
+outProps.put("encryptionSymAlgorithm",
"http://www.w3.org/2001/04/xmlenc#tripledes-cbc");
+outProps.put("encryptionKeyTransportAlgorithm",
"http://www.w3.org/2001/04/xmlenc#rsa-1_5");
+WSS4JOutInterceptor wssOut = <emphasis role="bold">new</emphasis>
WSS4JOutInterceptor(outProps); //request
+cxfEndpoint.getOutInterceptors().add(wssOut);
+cxfEndpoint.getOutInterceptors().add(<emphasis
role="bold">new</emphasis> SAAJOutInterceptor());
+
+Map<String,Object> inProps= <emphasis
role="bold">new</emphasis> HashMap<String,Object>();
+inProps.put("action", "Timestamp Signature Encrypt");
+inProps.put("signaturePropFile", "META-INF/alice.properties");
+inProps.put("passwordCallbackClass",
"org.jboss.test.ws.jaxws.samples.wsse.KeystorePasswordCallback");
+inProps.put("decryptionPropFile", "META-INF/alice.properties");
+WSS4JInInterceptor wssIn = <emphasis role="bold">new</emphasis>
WSS4JInInterceptor(inProps); //response
+cxfEndpoint.getInInterceptors().add(wssIn);
+cxfEndpoint.getInInterceptors().add(<emphasis
role="bold">new</emphasis> SAAJInInterceptor());
+</screen><variablelist><varlistentry><term/><listitem/></varlistentry><varlistentry><term><emphasis
role="bold">Package and deploy
</emphasis></term><listitem/></varlistentry></variablelist><para>To
deploy your web service endpoint, you need to package the following files along with your
service implementation and wsdl
contract:</para><itemizedlist><listitem><para> the jbossws-cxf.xml
descriptor </para></listitem><listitem><para> the properties file
</para></listitem><listitem><para> the keystore file (if required
for signature/encryption) </para></listitem><listitem><para> the
keystore password callback handler class
</para></listitem></itemizedlist><para>For instance, here are the
archive contents for the afore mentioned signature & encryption sample (POJO
endpoint):</para><screen xml:space="preserve">[alessio@localhost
cxf-tests]$ jar -tvf target/test-libs/jaxws-samples-wsse-sign-encrypt.war
+ 0 Tue Jun 03 19:41:26 CEST 2008 META-INF/
+ 106 Tue Jun 03 19:41:24 CEST 2008 META-INF/MANIFEST.MF
+ 0 Tue Jun 03 19:41:26 CEST 2008 WEB-INF/
+ 0 Tue Jun 03 19:41:26 CEST 2008 WEB-INF/classes/
+ 0 Tue Jun 03 19:41:24 CEST 2008 WEB-INF/classes/org/
+ 0 Tue Jun 03 19:41:24 CEST 2008 WEB-INF/classes/org/jboss/
+ 0 Tue Jun 03 19:41:24 CEST 2008 WEB-INF/classes/org/jboss/test/
+ 0 Tue Jun 03 19:41:24 CEST 2008 WEB-INF/classes/org/jboss/test/ws/
+ 0 Tue Jun 03 19:41:24 CEST 2008 WEB-INF/classes/org/jboss/test/ws/jaxws/
+ 0 Tue Jun 03 19:41:24 CEST 2008 WEB-INF/classes/org/jboss/test/ws/jaxws/samples/
+ 0 Tue Jun 03 19:41:24 CEST 2008 WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsse/
+1628 Tue Jun 03 19:41:24 CEST 2008
WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsse/KeystorePasswordCallback.class
+ 364 Tue Jun 03 19:41:24 CEST 2008
WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsse/ServiceIface.class
+ 859 Tue Jun 03 19:41:24 CEST 2008
WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsse/ServiceImpl.class
+ 0 Tue Jun 03 19:41:24 CEST 2008
WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsse/jaxws/
+ 685 Tue Jun 03 19:41:24 CEST 2008
WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsse/jaxws/SayHello.class
+1049 Tue Jun 03 19:41:24 CEST 2008
WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsse/jaxws/SayHelloResponse.class
+2847 Tue Jun 03 19:41:24 CEST 2008 WEB-INF/jbossws-cxf.xml
+ 0 Tue Jun 03 19:41:24 CEST 2008 WEB-INF/wsdl/
+1575 Tue Jun 03 19:41:24 CEST 2008 WEB-INF/wsdl/SecurityService.wsdl
+ 641 Tue Jun 03 19:41:24 CEST 2008 WEB-INF/wsdl/SecurityService_schema1.xsd
+1820 Tue Jun 03 19:41:24 CEST 2008 WEB-INF/classes/bob.jks
+ 311 Tue Jun 03 19:41:24 CEST 2008 WEB-INF/classes/bob.properties
+ 573 Tue Jun 03 19:41:24 CEST 2008 WEB-INF/web.xml
+</screen><para>On client side, instead, you only need the properties and
keystore files (assuming you setup the interceptors
programmatically).</para><para>Check that JBossWS-CXF is installed on your
current JBoss Application Server, deploy and test your WS-Security-enabled
application.</para><para> </para></section>
+<section
id="JBossWS-StackCXFUserGuide_WSSecurity_Policies"><title>WS-Security
Policies</title><para> </para><para>Starting from JBossWS-CXF
3.1.1, WS-Security Policy implementation is available and can be used to configure
WS-Security more easily.</para><para>Please refer to the <ulink
url="http://cwiki.apache.org/CXF20DOC/ws-securitypolicy.html"&g... CXF
documentation</ulink>; basically instead of manually configuring interceptors in the
client or through jbossws-cxf.xml descriptor, you simply provide the right policies in the
WSDL contract.</para><screen xml:space="preserve"> ...
+ <binding name="SecurityServicePortBinding"
type="tns:ServiceIface">
+ <wsp:PolicyReference URI="#SecurityServiceSignPolicy"/>
+ ...
+ <wsp:Policy wsu:Id="SecurityServiceSignPolicy"
+ xmlns:sp="<ulink
url="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">h...
+ <wsp:ExactlyOne>
+ <wsp:All>
+ <sp:AsymmetricBinding xmlns:sp='<ulink
url="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">h...
+ <wsp:Policy>
+ <sp:InitiatorToken>
+ <wsp:Policy>
+ <sp:X509Token sp:IncludeToken='<ulink
url="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeTok...
+ <wsp:Policy>
+ <sp:WssX509V3Token10 />
+ </wsp:Policy>
+ </sp:X509Token>
+ </wsp:Policy>
+ </sp:InitiatorToken>
+ <sp:RecipientToken>
+ <wsp:Policy>
+ <sp:X509Token sp:IncludeToken='<ulink
url="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeTok...
+ <wsp:Policy>
+ <sp:WssX509V3Token10 />
+ </wsp:Policy>
+ </sp:X509Token>
+ </wsp:Policy>
+ </sp:RecipientToken>
+ <sp:AlgorithmSuite>
+ <wsp:Policy>
+ <sp:Basic256 />
+ </wsp:Policy>
+ </sp:AlgorithmSuite>
+ <sp:Layout>
+ <wsp:Policy>
+ <sp:Strict />
+ </wsp:Policy>
+ </sp:Layout>
+ <sp:OnlySignEntireHeadersAndBody />
+ </wsp:Policy>
+ </sp:AsymmetricBinding>
+ <sp:Wss10 xmlns:sp='<ulink
url="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">h...
+ <wsp:Policy>
+ <sp:MustSupportRefEmbeddedToken />
+ </wsp:Policy>
+ </sp:Wss10>
+ <sp:SignedParts xmlns:sp='<ulink
url="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">h...
+ <sp:Body />
+ </sp:SignedParts>
+ </wsp:All>
+ </wsp:ExactlyOne>
+ </wsp:Policy>
+ ...
+</screen><para>Just few properties are also required to be set either in the
message context or in the jbossws-cxf.xml descriptor.</para><screen
xml:space="preserve">((BindingProvider)proxy).getRequestContext().put(SecurityConstants.CALLBACK_HANDLER,
<emphasis role="bold">new</emphasis> KeystorePasswordCallback());
+((BindingProvider)proxy).getRequestContext().put(SecurityConstants.SIGNATURE_PROPERTIES,
Thread.currentThread().getContextClassLoader().getResource("META-INF/alice.properties"));
+((BindingProvider)proxy).getRequestContext().put(SecurityConstants.ENCRYPT_PROPERTIES,
Thread.currentThread().getContextClassLoader().getResource("META-INF/alice.properties"));
+</screen><screen xml:space="preserve"><beans
+ xmlns='<ulink
url="http://www.springframework.org/schema/beans">http://www...
+ xmlns:xsi='<ulink
url="http://www.w3.org/2001/XMLSchema-instance">http://www.w...
+ xmlns:beans='<ulink
url="http://www.springframework.org/schema/beans">http://www...
+ xmlns:jaxws='<ulink
url="http://cxf.apache.org/jaxws">http://cxf.apache.org/jaxw...
+ xsi:schemaLocation='<ulink
url="http://cxf.apache.org/core">http://cxf.apache.org/core&...
+ <ulink
url="http://cxf.apache.org/schemas/core.xsd">http://cxf.apac...
+ <ulink
url="http://www.springframework.org/schema/beans">http://www...
+ <ulink
url="http://www.springframework.org/schema/beans/spring-beans-2.0.xs...
+ <ulink
url="http://cxf.apache.org/jaxws">http://cxf.apache.org/jaxw...
+ <ulink
url="http://cxf.apache.org/schemas/jaxws.xsd">http://cxf.apa...
+
+ <jaxws:endpoint
+ id='ServiceImpl'
+ address='<ulink
url="http://@jboss.bind.address@:8080/jaxws-samples-wssePolicy-sign">http://@jboss.bind.address@:8080/jaxws-samples-wssePolicy-sign</ulink>'
+ implementor='org.jboss.test.ws.jaxws.samples.wssePolicy.ServiceImpl'>
+
+ <jaxws:properties>
+ <entry key="ws-security.signature.properties"
value="bob.properties"/>
+ <entry key="ws-security.encryption.properties"
value="bob.properties"/>
+ <entry key="ws-security.callback-handler"
value="org.jboss.test.ws.jaxws.samples.wssePolicy.KeystorePasswordCallback"/>
+ </jaxws:properties>
+ </jaxws:endpoint>
+</beans>
+</screen><para> </para></section>
+<section
id="JBossWS-StackCXFUserGuide_Authentication_and_authorization"><title>Authentication
and authorization</title><para> </para><para>The Username Token
Profile can of course be used to provide client's credentials to the target endpoint.
Starting from JBossWS-CXF 3.3.0 (which includes Apache CXF 2.2.8), the username token
information can be used for authentication and authorization on JBoss AS (JAAS
integration).</para><para>On server side, you need to specify what follows
(for instance using a <emphasis>jbossws-cxf.xml</emphasis>
descriptor):</para><itemizedlist><listitem><para>an interceptor
for performing authentication and populating a valid SecurityContext; the provided
interceptor should extend
org.apache.cxf.ws.security.wss4j.AbstractUsernameTokenAuthenticatingInterceptor, in
particular JBossWS integration comes with
<emphasis>org.jboss.wsf.stack.cxf.security.authentication.SubjectCreatingInterceptor</emphasis>
for this;</para></listitem><listitem><para>an in!
terceptor for performing authorization; CXF requires that to extend
org.apache.cxf.interceptor.security.AbstractAuthorizingInInterceptor, for instance the
<emphasis>SimpleAuthorizingInterceptor</emphasis> can be used for simply
mapping endpoint operations to allowed
roles.</para></listitem></itemizedlist><screen
xml:space="preserve"><beans
+ xmlns='<ulink
url="http://www.springframework.org/schema/beans">http://www...
+ xmlns:xsi='<ulink
url="http://www.w3.org/2001/XMLSchema-instance">http://www.w...
+ xmlns:beans='<ulink
url="http://www.springframework.org/schema/beans">http://www...
+ xmlns:jaxws='<ulink
url="http://cxf.apache.org/jaxws">http://cxf.apache.org/jaxw...
+ xmlns:util='<ulink
url="http://www.springframework.org/schema/util">http://www....
+ xsi:schemaLocation='<ulink
url="http://cxf.apache.org/core">http://cxf.apache.org/core&...
+ <ulink
url="http://cxf.apache.org/schemas/core.xsd">http://cxf.apac...
+ <ulink
url="http://www.springframework.org/schema/util">http://www....
+ <ulink
url="http://www.springframework.org/schema/util/spring-util-2.0.xsd&...
+ <ulink
url="http://www.springframework.org/schema/beans">http://www...
+ <ulink
url="http://www.springframework.org/schema/beans/spring-beans-2.0.xs...
+ <ulink
url="http://cxf.apache.org/jaxws">http://cxf.apache.org/jaxw...
+ <ulink
url="http://cxf.apache.org/schemas/jaxws.xsd">http://cxf.apa...
+
+ <bean id="SecurityContextIn"
+
class="org.jboss.wsf.stack.cxf.security.authentication.SubjectCreatingInterceptor">
+ <constructor-arg>
+ <map>
+ <entry key="action" value="UsernameToken"/>
+ </map>
+ </constructor-arg>
+ </bean>
+
+ <util:map id="methodPermissions">
+ <entry key="sayHello" value="friend"/>
+ <entry key="greetMe" value="snoopies"/>
+ </util:map>
+
+ <bean id="AuthorizeIn"
+
class="org.apache.cxf.interceptor.security.SimpleAuthorizingInterceptor">
+ <property name="methodRolesMap"
ref="methodPermissions"/>
+ </bean>
+
+ <jaxws:endpoint
+ id='ServiceImpl'
+ address='<ulink
url="http://@jboss.bind.address@:8080/jaxws-samples-wsse-username-authorize">http://@jboss.bind.address@:8080/jaxws-samples-wsse-username-authorize</ulink>'
+ implementor='org.jboss.test.ws.jaxws.samples.wsse.ServiceImpl'>
+ <jaxws:inInterceptors>
+ <ref bean="SecurityContextIn"/>
+ <ref bean="AuthorizeIn"/>
+ <bean
class="org.apache.cxf.binding.soap.saaj.SAAJInInterceptor"/>
+ </jaxws:inInterceptors>
+ </jaxws:endpoint>
+</beans></screen><para> </para><para>Authentication
and authorization will simply be delegated to the security domain configured for the
endpoint. Of course you can specify the login module you prefer for that security domain
(refer the application server / security documentation for
that).</para><para> </para><para>On client side, the username is
provided through API (or a custom Spring configuration used to load the
Bus):</para><para> </para><screen
xml:space="preserve">Endpoint cxfEndpoint = client.getEndpoint();
+Map<String, Object> outProps = <emphasis
role="bold">new</emphasis> HashMap<String, Object>();
+outProps.put("action", "UsernameToken");
+outProps.put("user", username);
+outProps.put("passwordType", "PasswordText");
+outProps.put("passwordCallbackClass",
"org.jboss.test.ws.jaxws.samples.wsse.UsernamePasswordCallback");
+WSS4JOutInterceptor wssOut = <emphasis role="bold">new</emphasis>
WSS4JOutInterceptor(outProps); //request
+cxfEndpoint.getOutInterceptors().add(wssOut);
+cxfEndpoint.getOutInterceptors().add(<emphasis
role="bold">new</emphasis> SAAJOutInterceptor());
+</screen><para> </para><para>The password instead is provided
through a password callback handler that needs to implement
<emphasis>javax.security.auth.callback.CallbackHandler</emphasis>, similarly
to the keystore's password callback
handler.</para><para> </para><para>If you're running an older
JBossWS-CXF version, or you're not interested in the the application server auth
integration, you can use a password callback handler on server side too, configured
through a WSS4JInInterceptor:</para><para> </para><screen
xml:space="preserve"><bean
id="UsernameToken_Request">
+ <constructor-arg>
+ <map>
+ <entry key="action" value="UsernameToken"/>
+ <entry key="passwordCallbackClass"
value="org.jboss.test.ws.jaxws.samples.wsse.ServerUsernamePasswordCallback"/>
+ </map>
+ </constructor-arg>
+</bean>
+</screen><para> </para><screen
xml:space="preserve"><emphasis
role="bold">package</emphasis> org.jboss.test.ws.jaxws.samples.wsse;
+
+<emphasis role="bold">import</emphasis> java.io.IOException;
+<emphasis role="bold">import</emphasis>
javax.security.auth.callback.CallbackHandler;
+<emphasis role="bold">import</emphasis>
javax.security.auth.callback.UnsupportedCallbackException;
+<emphasis role="bold">import</emphasis>
org.apache.ws.security.WSPasswordCallback;
+
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> ServerUsernamePasswordCallback
<emphasis role="bold">implements</emphasis> CallbackHandler
+{
+ <emphasis role="bold">public</emphasis> <emphasis
role="bold">void</emphasis> handle(Callback[] callbacks) <emphasis
role="bold">throws</emphasis> IOException,
UnsupportedCallbackException
+ {
+ WSPasswordCallback pc = (WSPasswordCallback)callbacks[0];
+ <emphasis role="bold">if</emphasis>
(!("kermit".equals(pc.getIdentifier()) &&
"thefrog".equals(pc.getPassword())))
+ <emphasis role="bold">throw</emphasis> <emphasis
role="bold">new</emphasis> SecurityException("User '" +
pc.getIdentifier() + "' with password '" + pc.getPassword() +
"' not allowed.");
+ }
+}
+</screen></section>
+<section
id="JBossWS-StackCXFUserGuide_Further_information"><title>Further
information</title><variablelist><varlistentry><term><emphasis
role="bold">Samples
</emphasis></term><listitem/></varlistentry></variablelist><para>The
JBossWS-CXF source distribution comes with some samples using X.509 certificate signature
and encryption as well as Username Token Profile. You can find them in package
<emphasis>org.jboss.test.ws.jaxws.samples.wsse</emphasis>
.</para><variablelist><varlistentry><term><emphasis
role="bold">Crypto algorithms
</emphasis></term><listitem/></varlistentry></variablelist><para>When
requiring encryption, you might need to install an additional JCE provider supporting the
crypto algorithms Apache CXF uses. This usually means the Bouncy Castle provider need to
be configured in your JRE. Please refer the <ulink
url="http://community.jboss.org/docs/DOC-13532">Native stack
user</ulink> guide for further information about
this.</para><para> </para></section>
+</section>
+<section id="JBossWS-StackCXFUserGuide_JMS_transport"><title>JMS
transport</title><para><link
linkend="chap_JBossWS-CXFJMStransporttutorial">Here</link> is a
tutorial on how to deploy and invoke a JMS endpoint using
JBossWS-CXF.</para><para> </para></section>
+</section>
+<section
id="JBossWS-StackCXFUserGuide_HTTP_server_transport_setup"><title>HTTP
server transport setup</title><para>Apache CXF comes with pluggable transport
layers, allowing different transport modules to be
used.</para><para> </para><para>The JBossWS-CXF integration
leverages CXF servlet transport for the deployment of endpoints on top of the running
JBoss Application Server.</para><para> </para><para>However, when
users directly leverage the JAXWS <ulink
url="http://download.oracle.com/javase/6/docs/api/javax/xml/ws/Endpo...
s)</ulink> API, endpoints are expected to be deployed on a standalone http server
started just for serving the specified endpoint. Apache CXF currently defaults to using
the <ulink
url="http://jetty.codehaus.org/jetty/">Jetty</ulink>
based http transport. Starting <emphasis>from release 3.4.0</emphasis>, the
JBossWS-CXF integration instead uses a different http transport module based on th!
e <ulink
url="http://download.oracle.com/javase/6/docs/jre/api/net/httpserver...
server</ulink> embedded in JDK6 distributions. Thanks to Apache CXF transport
pluggability, users can still change the transport they want to use in this case by simply
replacing the <emphasis>jbossws-cxf-transports-httpserver.jar</emphasis>
library with another http transport one, for instance the
<emphasis>cxf-rt-transports-http-jetty.jar</emphasis>.</para><para> </para></section>
+<section
id="JBossWS-StackCXFUserGuide_SOAP_Message_Logging"><title>SOAP Message
Logging</title><para>In the jbossws-cxf-client.jar[*] file you will find
META-INF/cxf/cxf-extension-jbossws.xml, which contains the JBossWS extensions to the
Apache CXF stack. In that file you need to enable</para><screen
xml:space="preserve"> <cxf:bus>
+ <cxf:inInterceptors>
+ <ref bean="logInbound"/>
+ </cxf:inInterceptors>
+ <cxf:outInterceptors>
+ <ref bean="logOutbound"/>
+ </cxf:outInterceptors>
+ <cxf:inFaultInterceptors>
+ <ref bean="logOutbound"/>
+ </cxf:inFaultInterceptors>
+ </cxf:bus>
+</screen><para> </para><para>Once you've uncommented the
cxf-extension-jbossws.xml contents, you need to re-pack the
jar/zip.</para><para> </para><para>[*] The
cxf-extension-jbossws.xml is available from version 3.2.2; if you don't have that
file, you can manually add it and link it in cxf.extensions
file.</para><para> </para><para>Finally, please note that logging
can be enabled in many ways with Apache CXF, see the following documentation pages for
instance:</para><itemizedlist><listitem><para><ulink
url="http://cxf.apache.org/docs/configuration.html">http://c...
url="http://cxf.apache.org/docs/debugging-and-logging.html">...
+</chapter>
\ No newline at end of file
Added: stack/cxf/trunk/src/main/doc/JBossWS-UserGuide.xml
===================================================================
--- stack/cxf/trunk/src/main/doc/JBossWS-UserGuide.xml (rev 0)
+++ stack/cxf/trunk/src/main/doc/JBossWS-UserGuide.xml 2010-11-02 18:00:03 UTC (rev
13200)
@@ -0,0 +1,475 @@
+<?xml version="1.0" encoding="UTF-8"?><chapter
id="chap_JBossWS-UserGuide"><title>JBossWS-UserGuide</title><para/>
+<section id="JBossWS-UserGuide_Common_User_Guide"><title>Common
User Guide</title><para> </para><para>Here below is the
documentation that applies to every supported stacks. This includes basic JAX-WS usage as
well as references to common additional functionalities the JBossWS Web Service Framework
provides on top of the supported stacks.</para><section
id="JBossWS-UserGuide_Web_Service_Concepts"><title>Web Service
Concepts</title><section
id="JBossWS-UserGuide_DocumentLiteral"><title>Document/Literal</title><para>With
document style web services two business partners agree on the exchange of complex
business documents that are well defined in XML schema. For example, one party sends a
document describing a purchase order, the other responds (immediately or later) with a
document that describes the status of the purchase order. No need to agree on such low
level details as operation names and their associated
parameters.</para><para>The payload of the SOAP message is an XM!
L document that can be validated against XML schema.</para><para>Document is
defined by the style attribute on the SOAP binding.</para><screen
xml:space="preserve"> <binding name='EndpointInterfaceBinding'
type='tns:EndpointInterface'>
+ <soap:binding style='document' transport='<ulink
url="http://schemas.xmlsoap.org/soap/http'/">http://sche...
+ <operation name='concat'>
+ <soap:operation soapAction=''/>
+ <input>
+ <soap:body use='literal'/>
+ </input>
+ <output>
+ <soap:body use='literal'/>
+ </output>
+ </operation></binding>
+</screen><para>With document style web services the payload of every message
is defined by a complex type in XML schema.</para><screen
xml:space="preserve"> <complexType
name='concatType'>
+ <sequence>
+ <element name='String_1' nillable='true'
type='string'/>
+ <element name='long_1' type='long'/>
+ </sequence>
+ </complexType>
+ <element name='concat' type='tns:concatType'/>
+</screen><para>Therefore, message parts <emphasis
role="bold">must</emphasis> refer to an <emphasis
role="bold">element</emphasis> from the schema.</para><screen
xml:space="preserve"> <message
name='EndpointInterface_concat'>
+ <part name='parameters'
element='tns:concat'/></message>
+</screen><para>The following message definition <emphasis
role="bold">is invalid</emphasis>.</para><screen
xml:space="preserve"> <message
name='EndpointInterface_concat'>
+ <part name='parameters'
type='tns:concatType'/></message></screen><section
id="JBossWS-UserGuide_DocumentLiteral_Bare"><title>Document/Literal
(Bare)</title><para>Bare is an implementation detail from the Java domain.
Neither in the abstract contract (i.e. wsdl+schema) nor at the SOAP message level is a
bare endpoint recognizable.</para><para>A bare endpoint or client uses a Java
bean that represents the entire document payload.</para><screen
xml:space="preserve">@WebService
+@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> DocBareServiceImpl
+{
+ @WebMethod
+ <emphasis role="bold">public</emphasis> SubmitBareResponse
submitPO(SubmitBareRequest poRequest)
+ {
+ ...
+ }
+}
+</screen><para>The trick is that the Java beans representing the payload
contain JAXB annotations that define how the payload is represented on the
wire.</para><screen
xml:space="preserve">@XmlAccessorType(XmlAccessType.FIELD)
+@XmlType(name = "SubmitBareRequest", namespace="<ulink
url="http://soapbinding.samples.jaxws.ws.test.jboss.org/">ht...;,
propOrder = { "product" })
+@XmlRootElement(namespace="<ulink
url="http://soapbinding.samples.jaxws.ws.test.jboss.org/">ht...;,
name = "SubmitPO")
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> SubmitBareRequest
+{
+ @XmlElement(namespace="<ulink
url="http://soapbinding.samples.jaxws.ws.test.jboss.org/">ht...
required = <emphasis role="bold">true</emphasis>)
+ <emphasis role="bold">private</emphasis> String product;
+
+ ...
+}
+</screen></section>
+<section
id="JBossWS-UserGuide_DocumentLiteral_Wrapped"><title>Document/Literal
(Wrapped)</title><para>Wrapped is an implementation detail from the Java
domain. Neither in the abstract contract (i.e. wsdl+schema) nor at the SOAP message level
is a wrapped endpoint recognizable.</para><para>A wrapped endpoint or client
uses the individual document payload properties. Wrapped is the default and does not have
to be declared explicitly.</para><screen
xml:space="preserve">@WebService
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> DocWrappedServiceImpl
+{
+ @WebMethod
+ @RequestWrapper (className="org.somepackage.SubmitPO")
+ @ResponseWrapper (className="org.somepackage.SubmitPOResponse")
+ <emphasis role="bold">public</emphasis> String submitPO(String
product, <emphasis role="bold">int</emphasis> quantity)
+ {
+ ...
+ }
+}
+</screen><para>Note, that with JBossWS the request/response wrapper
annotations are <emphasis role="bold">not required</emphasis>, they
will be generated on demand using sensible
defaults.</para><para> </para></section>
+</section>
+<section
id="JBossWS-UserGuide_RPCLiteral"><title>RPC/Literal</title><para>With
RPC there is a wrapper element that names the endpoint operation. Child elements of the
RPC parent are the individual parameters.</para><para>The SOAP body is
constructed based on some simple
rules:</para><itemizedlist><listitem><para> The port type
operation name defines the endpoint method name
</para></listitem><listitem><para> Message parts are endpoint
method parameters </para></listitem></itemizedlist><para>RPC is
defined by the style attribute on the SOAP binding.</para><screen
xml:space="preserve"> <binding name='EndpointInterfaceBinding'
type='tns:EndpointInterface'>
+ <soap:binding style='rpc' transport='<ulink
url="http://schemas.xmlsoap.org/soap/http'/">http://sche...
+ <operation name='echo'>
+ <soap:operation soapAction=''/>
+ <input>
+ <soap:body namespace='<ulink
url="http://org.jboss.ws/samples/jsr181pojo">http://org.jboss.ws/samples/jsr181pojo</ulink>'
use='literal'/>
+ </input>
+ <output>
+ <soap:body namespace='<ulink
url="http://org.jboss.ws/samples/jsr181pojo">http://org.jboss.ws/samples/jsr181pojo</ulink>'
use='literal'/>
+ </output>
+ </operation></binding>
+</screen><para>With rpc style web services the portType names the operation
(i.e. the java method on the endpoint)</para><screen
xml:space="preserve"> <portType
name='EndpointInterface'>
+ <operation name='echo' parameterOrder='String_1'>
+ <input message='tns:EndpointInterface_echo'/>
+ <output message='tns:EndpointInterface_echoResponse'/>
+ </operation></portType>
+</screen><para>Operation parameters are defined by individual message
parts.</para><screen xml:space="preserve"> <message
name='EndpointInterface_echo'>
+ <part name='String_1'
type='xsd:string'/></message><message
name='EndpointInterface_echoResponse'>
+ <part name='result'
type='xsd:string'/></message>
+</screen><para>Note, there is no complex type in XML schema that could
validate the entire SOAP message payload.</para><screen
xml:space="preserve">@WebService
+@SOAPBinding(style = SOAPBinding.Style.RPC)
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> JSEBean01
+{
+ @WebMethod
+ @WebResult(name="result")
+ <emphasis role="bold">public</emphasis> String
echo(@WebParam(name="String_1") String input)
+ {
+ ...
+ }
+}
+</screen><para>The element names of RPC parameters/return values may be
defined using the JAX-WS <link
linkend="chap_JBossWS-JAX-WSAnnotations">WebParam</link> and <link
linkend="chap_JBossWS-JAX-WSAnnotations">WebResult</link> annotations
respectively.</para></section>
+<section
id="JBossWS-UserGuide_RPCEncoded"><title>RPC/Encoded</title><para>SOAP
encodeding style is defined by the infamous <ulink
url="http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383512&quo...
5</ulink> of the <ulink
url="http://www.w3.org/TR/2000/NOTE-SOAP-20000508">SOAP-1.1&...
specification. <emphasis role="bold">It has inherent interoperability
issues</emphasis> that cannot be fixed. The <ulink
url="http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html&q...
Profile-1.0</ulink> prohibits this encoding style in <ulink
url="http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html#r...
SOAP encodingStyle Attribute</ulink>.</para><para> JBossWS doesn't
support rpc/encoded anymore.</para><para> </para></section>
+</section>
+<section id="JBossWS-UserGuide_Web_Service_Endpoints"><title>Web
Service Endpoints</title><para>JAX-WS simplifies the development model for a
web service endpoint a great deal. In short, an endpoint implementation bean is annotated
with JAX-WS annotations and deployed to the server. The server automatically generates and
publishes the abstract contract (i.e. wsdl+schema) for client consumption. All
marshalling/unmarshalling is delegated to
JAXB.</para><para> </para><section
id="JBossWS-UserGuide_Plain_old_Java_Object_POJO"><title>Plain old Java
Object (POJO)</title><para>Let's take a look at simple POJO endpoint
implementation. All endpoint associated metadata is provided via JSR-181
annotations</para><screen xml:space="preserve"> @WebService
+ @SOAPBinding(style = SOAPBinding.Style.RPC)
+ <emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> JSEBean01
+ {
+ @WebMethod
+ <emphasis role="bold">public</emphasis> String echo(String
input)
+ {
+ ...
+ }
+ }
+</screen><para><emphasis role="bold">The endpoint as a web
application</emphasis></para><para>A JAX-WS java service endpoint (JSE)
is deployed as a web application.</para><screen
xml:space="preserve"> <web-app ...>
+ <servlet>
+ <servlet-name>TestService</servlet-name>
+
<servlet-class>org.jboss.test.ws.jaxws.samples.jsr181pojo.JSEBean01</servlet-class>
+ </servlet>
+ <servlet-mapping>
+ <servlet-name>TestService</servlet-name>
+ <url-pattern>/*</url-pattern>
+ </servlet-mapping>
+ </web-app>
+</screen><para><emphasis role="bold">Packaging the
endpoint</emphasis></para><para>A JSR-181 java service endpoint (JSE) is
packaged as a web application in a *.war file.</para><screen
xml:space="preserve"> <war
warfile="${build.dir}/libs/jbossws-samples-jsr181pojo.war"
webxml="${build.resources.dir}/samples/jsr181pojo/WEB-INF/web.xml">
+ <classes dir="${build.dir}/classes">
+ <include
name="org/jboss/test/ws/samples/jsr181pojo/JSEBean01.class"/>
+ </classes>
+ </war>
+</screen><para>Note, only the endpoint implementation bean and web.xml are
required.</para><para><emphasis role="bold">Accessing the
generated WSDL</emphasis></para><para>A successfully deployed service
endpoint will show up in the service endpoint manager. This is also where you find the
links to the generated wsdl.</para><screen xml:space="preserve">
http://yourhost:8080/jbossws/services
+</screen><para>Note, it is also possible to generate the abstract contract
off line using jbossw tools. For details of that please see <link
linkend="chap_JBossWS-JAX-WSTools">Bottom-Up (Java to
WSDL)</link></para><para> </para></section>
+<section
id="JBossWS-UserGuide_EJB3_Stateless_Session_Bean_SLSB"><title>EJB3
Stateless Session Bean (SLSB)</title><para>The JAX-WS programming model
support the same set of annotations on EJB3 stateless session beans as on <link
linkend="JBossWS-UserGuide_Plain_old_Java_Object_POJO">Plain old Java Object
(POJO)</link> endpoints. EJB-2.1 endpoints are supported using the JAX-RPC
progamming model (with JBossWS-Native only).</para><screen
xml:space="preserve"> @Stateless
+ @Remote(EJB3RemoteInterface.class)
+ @RemoteBinding(jndiBinding = "/ejb3/EJB3EndpointInterface")
+
+ @WebService
+ @SOAPBinding(style = SOAPBinding.Style.RPC)
+ <emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> EJB3Bean01 <emphasis
role="bold">implements</emphasis> EJB3RemoteInterface
+ {
+ @WebMethod
+ <emphasis role="bold">public</emphasis> String echo(String
input)
+ {
+ ...
+ }
+ }
+</screen><para>Above you see an EJB-3.0 stateless session bean that exposes
one method both on the remote interface and on and as an endpoint
operation.</para><para><emphasis role="bold">Packaging the
endpoint</emphasis></para><para>A JSR-181 EJB service endpoint is
packaged as an ordinary ejb deployment.</para><screen
xml:space="preserve"> <jar
jarfile="${build.dir}/libs/jbossws-samples-jsr181ejb.jar">
+ <fileset dir="${build.dir}/classes">
+ <include
name="org/jboss/test/ws/samples/jsr181ejb/EJB3Bean01.class"/>
+ <include
name="org/jboss/test/ws/samples/jsr181ejb/EJB3RemoteInterface.class"/>
+ </fileset>
+ </jar>
+</screen><para><emphasis role="bold">Accessing the generated
WSDL</emphasis></para><para>A successfully deployed service endpoint
will show up in the service endpoint manager. This is also where you find the links to the
generated wsdl.</para><screen xml:space="preserve">
http://yourhost:8080/jbossws/services
+</screen><para>Note, it is also possible to generate the abstract contract
off line using jbossw tools. For details of that please see <link
linkend="chap_JBossWS-JAX-WSTools">Bottom-Up (Java to
WSDL)</link></para><para> </para></section>
+<section id="JBossWS-UserGuide_Endpoint_Provider"><title>Endpoint
Provider</title><para>JAX-WS services typically implement a native Java
service endpoint interface (SEI), perhaps mapped from a WSDL port type, either directly or
via the use of annotations.</para><para>Java SEIs provide a high level
Java-centric abstraction that hides the details of converting between Java objects and
their XML representations for use in XML-based messages. However, in some cases it is
desirable for services to be able to operate at the XML message level. The Provider
interface offers an alternative to SEIs and may be implemented by services wishing to work
at the XML message level.</para><para>A Provider based service instances
invoke method is called for each message received for the service.</para><screen
xml:space="preserve"> @WebServiceProvider(wsdlLocation =
"WEB-INF/wsdl/Provider.wsdl")
+ @ServiceMode(value = Service.Mode.PAYLOAD)
+ <emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> ProviderBeanPayload <emphasis
role="bold">implements</emphasis> Provider<Source>
+ {
+ <emphasis role="bold">public</emphasis> Source invoke(Source
req)
+ {
+ // Access the entire request PAYLOAD and return the response PAYLOAD
+ }
+ }
+</screen><para>Note, Service.Mode.PAYLOAD is the default and does not have to
be declared explicitly. You can also use Service.Mode.MESSAGE to access the entire SOAP
message (i.e. with MESSAGE the Provider can also see SOAP
Headers)</para><para>The abstract contract for a provider endpoint cannot be
derived/generated automatically. Therefore it is necessary to specify the wsdlLocation
with the @WebServiceProvider
annotation.</para><para> </para></section>
+<section
id="JBossWS-UserGuide_WebServiceContext"><title>WebServiceContext</title><para>The
WebServiceContext is treated as an injectable resource that can be set at the time an
endpoint is initialized. The WebServiceContext object will then use thread-local
information to return the correct information regardless of how many threads are
concurrently being used to serve requests addressed to the same endpoint
object.</para><screen xml:space="preserve"> @WebService
+ <emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> EndpointJSE
+ {
+ @Resource
+ WebServiceContext wsCtx;
+
+ @WebMethod
+ <emphasis role="bold">public</emphasis> String
testGetMessageContext()
+ {
+ SOAPMessageContext jaxwsContext =
(SOAPMessageContext)wsCtx.getMessageContext();
+ <emphasis role="bold">return</emphasis> jaxwsContext !=
<emphasis role="bold">null</emphasis> ? "pass" :
"fail";
+ }
+
+ @WebMethod
+ <emphasis role="bold">public</emphasis> String
testGetUserPrincipal()
+ {
+ Principal principal = wsCtx.getUserPrincipal();
+ <emphasis role="bold">return</emphasis>
principal.getName();
+ }
+
+ @WebMethod
+ <emphasis role="bold">public</emphasis> <emphasis
role="bold">boolean</emphasis> testIsUserInRole(String role)
+ {
+ <emphasis role="bold">return</emphasis>
wsCtx.isUserInRole(role);
+ }
+ }
+</screen><para> </para><para> </para><para> </para></section>
+</section>
+<section id="JBossWS-UserGuide_Web_Service_Clients"><title>Web
Service Clients</title><section
id="JBossWS-UserGuide_Service"><title>Service</title><para><computeroutput>Service</computeroutput>
is an abstraction that represents a WSDL service. A WSDL service is a collection of
related ports, each of which consists of a port type bound to a particular protocol and
available at a particular endpoint address.</para><para>For most clients, you
will start with a set of stubs generated from the WSDL. One of these will be the service,
and you will create objects of that class in order to work with the service (see
"static case" below).</para><section
id="JBossWS-UserGuide_Service_Usage"><title>Service
Usage</title><para><emphasis role="bold">Static
case</emphasis></para><para>Most clients will start with a WSDL file,
and generate some stubs using jbossws tools like
<emphasis>wsconsume</emphasis>. This usually gives a mass of files, one of
which is the top of the tree. This is!
the service implementation class.</para><para>The generated implementation
class can be recognised as it will have two public constructors, one with no arguments and
one with two arguments, representing the wsdl location (a java.net.URL) and the service
name (a javax.xml.namespace.QName) respectively.</para><para>Usually you will
use the no-argument constructor. In this case the WSDL location and service name are those
found in the WSDL. These are set implicitly from the WebServiceClient annotation that
decorates the generated class.</para><para>The following code snippet shows
the generated constructors from the generated class:</para><screen
xml:space="preserve">// Generated Service Class
+
+@WebServiceClient(name="StockQuoteService", targetNamespace="<ulink
url="http://example.com/stocks">http://example.com/stocks<...;,
wsdlLocation="<ulink
url="http://example.com/stocks.wsdl">http://example.com/stoc...)
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> StockQuoteService <emphasis
role="bold">extends</emphasis> javax.xml.ws.Service
+{
+ <emphasis role="bold">public</emphasis> StockQuoteService()
+ {
+ <emphasis role="bold">super</emphasis>(<emphasis
role="bold">new</emphasis> URL("<ulink
url="http://example.com/stocks.wsdl">http://example.com/stoc...),
<emphasis role="bold">new</emphasis> QName("<ulink
url="http://example.com/stocks">http://example.com/stocks<...;,
"StockQuoteService"));
+ }
+
+ <emphasis role="bold">public</emphasis> StockQuoteService(String
wsdlLocation, QName serviceName)
+ {
+ <emphasis role="bold">super</emphasis>(wsdlLocation,
serviceName);
+ }
+
+ ...
+}
+</screen><para>Section <link
linkend="JBossWS-UserGuide_Dynamic_Proxy">Dynamic Proxy</link> explains
how to obtain a port from the service and how to invoke an operation on the port. If you
need to work with the XML payload directly or with the XML representation of the entire
SOAP message, have a look at <link
linkend="JBossWS-UserGuide_Dispatch">Dispatch</link>.</para><para><emphasis
role="bold">Dynamic case</emphasis></para><para>In the
dynamic case, when nothing is generated, a web service client uses
<computeroutput>Service.create</computeroutput> to create Service instances,
the following code illustrates this process.</para><screen
xml:space="preserve"> URL wsdlLocation = <emphasis
role="bold">new</emphasis> URL("<ulink
url="http://example.org/my.wsdl">http://example.org/my.wsdl&...);
+ QName serviceName = <emphasis role="bold">new</emphasis>
QName("<ulink
url="http://example.org/sample">http://example.org/sample<...;,
"MyService");
+ Service service = Service.create(wsdlLocation, serviceName);
+</screen><para> </para><para> </para></section>
+<section id="JBossWS-UserGuide_Handler_Resolver"><title>Handler
Resolver</title><para>JAX-WS provides a flexible plug-in framework for message
processing modules, known as handlers, that may be used to extend the capabilities of a
JAX-WS runtime system. <link
linkend="JBossWS-UserGuide_Handler_Framework">Handler Framework</link>
describes the handler framework in detail. A Service instance provides access to a
HandlerResolver via a pair of getHandlerResolver/setHandlerResolver methods that may be
used to configure a set of handlers on a per-service, per-port or per-protocol binding
basis.</para><para>When a Service instance is used to create a proxy or a
Dispatch instance then the handler resolver currently registered with the service is used
to create the required handler chain. Subsequent changes to the handler resolver
configured for a Service instance do not affect the handlers on previously created
proxies, or Dispatch instances.</para></section>
+<section
id="JBossWS-UserGuide_Executor"><title>Executor</title><para>Service
instances can be configured with a java.util.concurrent.Executor. The executor will then
be used to invoke any asynchronous callbacks requested by the application. The setExecutor
and getExecutor methods of Service can be used to modify and retrieve the executor
configured for a service.</para></section>
+</section>
+<section id="JBossWS-UserGuide_Dynamic_Proxy"><title>Dynamic
Proxy</title><para>You can create an instance of a client proxy using one of
getPort methods on the <link
linkend="JBossWS-UserGuide_Service">Service</link>.</para><screen
xml:space="preserve"> /**
+ * The getPort method returns a proxy. A service client
+ * uses this proxy to invoke operations on the target
+ * service endpoint. The
<code>serviceEndpointInterface</code>
+ * specifies the service endpoint interface that is supported by
+ * the created dynamic proxy instance.
+ **/
+ <emphasis role="bold">public</emphasis> <T> T
getPort(QName portName, Class<T> serviceEndpointInterface)
+ {
+ ...
+ }
+
+ /**
+ * The getPort method returns a proxy. The parameter
+ * <code>serviceEndpointInterface</code> specifies the
service
+ * endpoint interface that is supported by the returned proxy.
+ * In the implementation of this method, the JAX-WS
+ * runtime system takes the responsibility of selecting a protocol
+ * binding (and a port) and configuring the proxy accordingly.
+ * The returned proxy should not be reconfigured by the client.
+ *
+ **/
+ <emphasis role="bold">public</emphasis> <T> T
getPort(Class<T> serviceEndpointInterface)
+ {
+ ...
+ }
+</screen><para>The service endpoint interface (SEI) is usually generated
using tools. For details see <link linkend="chap_JBossWS-JAX-WSTools">Top
Down (WSDL to Java)</link></para><para>A generated static <ulink
url="http://community.jboss.org/Service">Service</ulink> usually also
offers typed methods to get ports. These methods also return dynamic proxies that
implement the SEI.</para><screen
xml:space="preserve">@WebServiceClient(name =
"TestEndpointService", targetNamespace = "<ulink
url="http://org.jboss.ws/wsref">http://org.jboss.ws/wsref</ulink>",
+ wsdlLocation = "<ulink
url="http://localhost.localdomain:8080/jaxws-samples-webserviceref?wsdl">http://localhost.localdomain:8080/jaxws-samples-webserviceref?wsdl</ulink>")
+
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> TestEndpointService <emphasis
role="bold">extends</emphasis> Service
+{
+ ...
+
+ <emphasis role="bold">public</emphasis> TestEndpointService(URL
wsdlLocation, QName serviceName) {
+ <emphasis role="bold">super</emphasis>(wsdlLocation,
serviceName);
+ }
+
+ @WebEndpoint(name = "TestEndpointPort")
+ <emphasis role="bold">public</emphasis> TestEndpoint
getTestEndpointPort()
+ {
+ <emphasis role="bold">return</emphasis>
(TestEndpoint)super.getPort(TESTENDPOINTPORT, TestEndpoint.class);
+ }
+}
+</screen><para> </para></section>
+<section
id="JBossWS-UserGuide_WebServiceRef"><title>WebServiceRef</title><para>The
WebServiceRef annotation is used to declare a reference to a Web service. It follows the
resource pattern exemplified by the javax.annotation.Resource annotation in
JSR-250.</para><para>There are two uses to the WebServiceRef
annotation:</para><orderedlist><listitem><para> To define a
reference whose type is a generated service class. In this case, the type and value
element will both refer to the generated service class type. Moreover, if the reference
type can be inferred by the field/method declaration the annotation is applied to, the
type and value elements MAY have the default value (Object.class, that is). If the type
cannot be inferred, then at least the type element MUST be present with a non-default
value. </para></listitem><listitem><para> To define a reference
whose type is a SEI. In this case, the type element MAY be present with its default value
if the type of the reference ca!
n be inferred from the annotated field/method declaration, but the value element MUST
always be present and refer to a generated service class type (a subtype of
javax.xml.ws.Service). The wsdlLocation element, if present, overrides theWSDL location
information specified in the WebService annotation of the referenced generated service
class. </para></listitem></orderedlist><screen
xml:space="preserve"><emphasis
role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> EJB3Client <emphasis
role="bold">implements</emphasis> EJB3Remote
+{
+ @WebServiceRef
+ <emphasis role="bold">public</emphasis> TestEndpointService
service4;
+
+ @WebServiceRef
+ <emphasis role="bold">public</emphasis> TestEndpoint port3;
+</screen><para><emphasis role="bold">WebServiceRef
Customization</emphasis></para><para>Starting from jboss-5.0.x we offer
a number of overrides and extensions to the WebServiceRef annotation. These
include</para><itemizedlist><listitem><para> define the port that
should be used to resolve a container-managed port
</para></listitem><listitem><para> define default Stub property
settings for Stub objects </para></listitem><listitem><para>
define the URL of a final WSDL document to be used
</para></listitem></itemizedlist><para>Example:</para><screen
xml:space="preserve"> <service-ref>
+ <service-ref-name>OrganizationService</service-ref-name>
+
<wsdl-override>file:/wsdlRepository/organization-service.wsdl</wsdl-override>
+ </service-ref>
+
+ <service-ref>
+ <service-ref-name>OrganizationService</service-ref-name>
+ <config-name>Secure Client Config</config-name>
+
<config-file>META-INF/jbossws-client-config.xml</config-file>
+
<handler-chain>META-INF/jbossws-client-handlers.xml</handler-chain>
+ </service-ref>
+
+ <service-ref>
+ <service-ref-name>SecureService</service-ref-name>
+
<service-impl-class>org.jboss.tests.ws.jaxws.webserviceref.SecureEndpointService</service-impl-class>
+
<service-qname>{http://org.jboss.ws/wsref}SecureEndpointService</service-qname>
+ <port-component-ref>
+
<service-endpoint-interface>org.jboss.tests.ws.jaxws.webserviceref.SecureEndpoint</service-endpoint-interface>
+
<port-qname>{http://org.jboss.ws/wsref}SecureEndpointPort</port-qname>
+ <stub-property>
+
<prop-name>javax.xml.ws.security.auth.username</prop-name>
+ <prop-value>kermit</prop-value>
+ </stub-property>
+ <stub-property>
+
<prop-name>javax.xml.ws.security.auth.password</prop-name>
+ <prop-value>thefrog</prop-value>
+ </stub-property>
+ </port-component-ref>
+ </service-ref>
+</screen><para>For details please see <emphasis
role="bold">service-ref_5_0.dtd</emphasis> in the jboss docs
directory.</para><para> </para></section>
+<section
id="JBossWS-UserGuide_Dispatch"><title>Dispatch</title><para>XMLWeb
Services use XML messages for communication between services and service clients. The
higher level JAX-WS APIs are designed to hide the details of converting between Java
method invocations and the corresponding XML messages, but in some cases operating at the
XML message level is desirable. The Dispatch interface provides support for this mode of
interaction.</para><para>Dispatch supports two usage modes, identified by the
constants javax.xml.ws.Service.Mode.MESSAGE and javax.xml.ws.Service.Mode.PAYLOAD
respectively:</para><para><emphasis
role="bold">Message</emphasis> In this mode, client applications work
directly with protocol-specific message structures. E.g., when used with a SOAP protocol
binding, a client application would work directly with a SOAP
message.</para><para><emphasis role="bold">Message
Payload</emphasis> In this mode, client applications work with the payload of
messages rather!
than the messages themselves. E.g., when used with a SOAP protocol binding, a client
application would work with the contents of the SOAP Body rather than the SOAP message as
a whole.</para><para>Dispatch is a low level API that requires clients to
construct messages or message payloads as XML and requires an intimate knowledge of the
desired message or payload structure. Dispatch is a generic class that supports input and
output of messages or message payloads of any type.</para><screen
xml:space="preserve"> Service service = Service.create(wsdlURL,
serviceName);
+ Dispatch dispatch = service.createDispatch(portName, StreamSource.class,
Mode.PAYLOAD);
+
+ String payload = "<ns1:ping xmlns:ns1='<ulink
url="http://oneway.samples.jaxws.ws.test.jboss.org/'/">h...;
+ dispatch.invokeOneWay(<emphasis role="bold">new</emphasis>
StreamSource(<emphasis role="bold">new</emphasis>
StringReader(payload)));
+
+ payload = "<ns1:feedback xmlns:ns1='<ulink
url="http://oneway.samples.jaxws.ws.test.jboss.org/'/">h...;
+ Source retObj = (Source)dispatch.invoke(<emphasis
role="bold">new</emphasis> StreamSource(<emphasis
role="bold">new</emphasis> StringReader(payload)));
+</screen></section>
+<section
id="JBossWS-UserGuide_Asynchronous_Invocations"><title>Asynchronous
Invocations</title><para>The BindingProvider interface represents a component
that provides a protocol binding for use by clients, it is implemented by proxies and is
extended by the Dispatch interface.</para><para>BindingProvider instances may
provide asynchronous operation capabilities. When used, asynchronous operation invocations
are decoupled from the BindingProvider instance at invocation time such that the response
context is not updated when the operation completes. Instead a separate response context
is made available using the Response interface.</para><screen
xml:space="preserve"> <emphasis
role="bold">public</emphasis> <emphasis
role="bold">void</emphasis> testInvokeAsync() <emphasis
role="bold">throws</emphasis> Exception
+ {
+ URL wsdlURL = <emphasis role="bold">new</emphasis>
URL("<ulink url="http://">http://</ulink>" +
getServerHost() + ":8080/jaxws-samples-asynchronous?wsdl");
+ QName serviceName = <emphasis role="bold">new</emphasis>
QName(targetNS, "TestEndpointService");
+ Service service = Service.create(wsdlURL, serviceName);
+ TestEndpoint port = service.getPort(TestEndpoint.class);
+
+ Response response = port.echoAsync("Async");
+
+ // access future
+ String retStr = (String) response.get();
+ assertEquals("Async", retStr);
+ }
+</screen></section>
+<section id="JBossWS-UserGuide_Oneway_Invocations"><title>Oneway
Invocations</title><para>@Oneway indicates that the given web method has only
an input message and no output. Typically, a oneway method returns the thread of control
to the calling application prior to executing the actual business
method.</para><screen xml:space="preserve">@WebService
(name="PingEndpoint")
+@SOAPBinding(style = SOAPBinding.Style.RPC)
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> PingEndpointImpl
+{
+ <emphasis role="bold">private</emphasis> <emphasis
role="bold">static</emphasis> String feedback;
+
+ @WebMethod
+ @Oneway
+ <emphasis role="bold">public</emphasis> <emphasis
role="bold">void</emphasis> ping()
+ {
+ log.info("ping");
+ feedback = "ok";
+ }
+
+ @WebMethod
+ <emphasis role="bold">public</emphasis> String feedback()
+ {
+ log.info("feedback");
+ <emphasis role="bold">return</emphasis> feedback;
+ }
+}
+</screen></section>
+<section
id="JBossWS-UserGuide_Oneway_Invocations_697545"><title>Timeout
Configuration</title><para>There are two properties to configure the http
connection timeout and client receive time out:</para><screen
xml:space="preserve"> public void testConfigureTimeout() throws Exception
{ //Set timeout until a connection is established ((BindingProvider)
port).getRequestContext(). put("javax.xml.ws.client.connectionTimeout",
"6000"); //Set timeout until the response is received
((BindingProvider) port).getRequestContext().
put("javax.xml.ws.client.receiveTimeout", "1000");
port.echo("testTimeout"); }
+</screen></section>
+</section>
+<section id="JBossWS-UserGuide_Common_API"><title>Common
API</title><para>This sections describes concepts that apply equally to
<link linkend="JBossWS-UserGuide_Web_Service_Endpoints">Web Service
Endpoints</link> and <link
linkend="JBossWS-UserGuide_Web_Service_Clients">Web Service
Clients</link>.</para><section
id="JBossWS-UserGuide_Handler_Framework"><title>Handler
Framework</title><para>The handler framework is implemented by a JAX-WS
protocol binding in both client and server side runtimes. Proxies, and Dispatch instances,
known collectively as binding providers, each use protocol bindings to bind their abstract
functionality to specific protocols.</para><para>Client and server-side
handlers are organized into an ordered list known as a handler chain. The handlers within
a handler chain are invoked each time a message is sent or received. Inbound messages are
processed by handlers prior to binding provider processing. Outbound messages are
processed by handlers after a!
ny binding provider processing.</para><para>Handlers are invoked with a
message context that provides methods to access and modify inbound and outbound messages
and to manage a set of properties. Message context properties may be used to facilitate
communication between individual handlers and between handlers and client and service
implementations. Different types of handlers are invoked with different types of message
context.</para><section
id="JBossWS-UserGuide_Logical_Handler"><title>Logical
Handler</title><para>Handlers that only operate on message context properties
and message payloads. Logical handlers are protocol agnostic and are unable to affect
protocol specific parts of a message. Logical handlers are handlers that implement
javax.xml.ws.handler.LogicalHandler.</para></section>
+<section id="JBossWS-UserGuide_Protocol_Handler"><title>Protocol
Handler</title><para>Handlers that operate on message context properties and
protocol specific messages. Protocol handlers are specific to a particular protocol and
may access and change protocol specific aspects of a message. Protocol handlers are
handlers that implement any interface derived from javax.xml.ws.handler.Handler except
javax.xml.ws.handler.LogicalHandler.</para></section>
+<section
id="JBossWS-UserGuide_Service_endpoint_handlers"><title>Service
endpoint handlers</title><para>On the service endpoint, handlers are defined
using the @HandlerChain annotation.</para><screen
xml:space="preserve">@WebService
+@HandlerChain(file = "jaxws-server-source-handlers.xml")
+<emphasis role="bold">public</emphasis> <emphasis
role="bold">class</emphasis> SOAPEndpointSourceImpl
+{
+ ...
+}
+</screen><para>The location of the handler chain file supports 2
formats</para><para>1. An absolute java.net.URL in externalForm. (ex:
<ulink
url="http://myhandlers.foo.com/handlerfile1.xml">http://myha....
A relative path from the source file or class file. (ex:
bar/handlerfile1.xml)</para></section>
+<section
id="JBossWS-UserGuide_Service_client_handlers"><title>Service client
handlers</title><para>On the client side, handler can be configured using the
@HandlerChain annotation on the SEI or dynamically using the API.</para><screen
xml:space="preserve"> Service service = Service.create(wsdlURL,
serviceName);
+ Endpoint port = (Endpoint)service.getPort(Endpoint.class);
+
+ BindingProvider bindingProvider = (BindingProvider)port;
+ List<Handler> handlerChain = <emphasis
role="bold">new</emphasis> ArrayList<Handler>();
+ handlerChain.add(<emphasis role="bold">new</emphasis>
LogHandler());
+ handlerChain.add(<emphasis role="bold">new</emphasis>
AuthorizationHandler());
+ handlerChain.add(<emphasis role="bold">new</emphasis>
RoutingHandler());
+ bindingProvider.getBinding().setHandlerChain(handlerChain); // important!
+</screen></section>
+</section>
+<section id="JBossWS-UserGuide_Message_Context"><title>Message
Context</title><para>MessageContext is the super interface for all JAX-WS
message contexts. It extends Map<String,Object> with additional methods and
constants to manage a set of properties that enable handlers in a handler chain to share
processing related state. For example, a handler may use the put method to insert a
property in the message context that one or more other handlers in the handler chain may
subsequently obtain via the get method.</para><para>Properties are scoped as
either APPLICATION or HANDLER. All properties are available to all handlers for an
instance of an MEP on a particular endpoint. E.g., if a logical handler puts a property in
the message context, that property will also be available to any protocol handlers in the
chain during the execution of an MEP instance. APPLICATION scoped properties are also made
available to client applications (see section 4.2.1) and service endpoint i!
mplementations. The defaultscope for a property is HANDLER.</para><section
id="JBossWS-UserGuide_Logical_Message_Context"><title>Logical Message
Context</title><para><link
linkend="JBossWS-UserGuide_Logical_Handler">Logical Handlers</link> are
passed a message context of type LogicalMessageContext when invoked. LogicalMessageContext
extends MessageContext with methods to obtain and modify the message payload, it does not
provide access to the protocol specific aspects of amessage. A protocol binding defines
what component of a message are available via a logical message context. The SOAP binding
defines that a logical handler deployed in a SOAP binding can access the contents of the
SOAP body but not the SOAP headers whereas the XML/HTTP binding defines that a logical
handler can access the entire XML payload of a message.</para></section>
+<section id="JBossWS-UserGuide_SOAP_Message_Context"><title>SOAP
Message Context</title><para>SOAP handlers are passed a SOAPMessageContext
when invoked. SOAPMessageContext extends MessageContext with methods to obtain and modify
the SOAP message payload.</para></section>
+</section>
+<section id="JBossWS-UserGuide_Fault_Handling"><title>Fault
Handling</title><para>An implementation may thow a
SOAPFaultException</para><screen xml:space="preserve">
<emphasis role="bold">public</emphasis> <emphasis
role="bold">void</emphasis> throwSoapFaultException()
+ {
+ SOAPFactory factory = SOAPFactory.newInstance();
+ SOAPFault fault = factory.createFault("this is a fault string!",
<emphasis role="bold">new</emphasis> QName("<ulink
url="http://foo">http://foo</ulink>", "FooCode"));
+ fault.setFaultActor("mr.actor");
+ fault.addDetail().addChildElement("test");
+ <emphasis role="bold">throw</emphasis> <emphasis
role="bold">new</emphasis> SOAPFaultException(fault);
+ }
+</screen><para>or an application specific user
exception</para><screen xml:space="preserve"> <emphasis
role="bold">public</emphasis> <emphasis
role="bold">void</emphasis> throwApplicationException() <emphasis
role="bold">throws</emphasis> UserException
+ {
+ <emphasis role="bold">throw</emphasis> <emphasis
role="bold">new</emphasis> UserException("validation", 123,
"Some validation error");
+ }
+</screen><note><para><para><emphasis
role="bold">Note</emphasis></para><para>In case of the
latter JBossWS generates the required fault wrapper beans at runtime if they are not part
of the deployment</para><para> </para></para></note>
+</section>
+<section id="JBossWS-UserGuide_JBossWS_Extensions"><title>JBossWS
Extensions</title><para>This section describes propriatary JBoss extensions to
JAX-WS, that works with all the supported
stacks.</para><para> </para><section
id="JBossWS-UserGuide_Proprietary_Annotations"><title>Proprietary
Annotations</title><para>For the set of standard annotations, please have a
look at <link
linkend="chap_JBossWS-JAX-WSAnnotations">JAX-WS_Annotations</link>.</para><para> </para><section
id="JBossWS-UserGuide_WebContext"><title>WebContext</title><screen
xml:space="preserve">/**
+ * Provides web context specific meta data to EJB based web service endpoints.
+ *
+ * @author <ulink
url="mailto:thomas.diesler@jboss.org">thomas.diesler@jboss.org</ulink>
+ * @since 26-Apr-2005
+ */
+@Retention(value = RetentionPolicy.RUNTIME)
+@Target(value = { ElementType.TYPE })
+<emphasis role="bold">public</emphasis> @<emphasis
role="bold">interface</emphasis> WebContext {
+
+ /**
+ * The contextRoot element specifies the context root that the web service endpoint is
deployed to.
+ * If it is not specified it will be derived from the deployment short name.
+ *
+ * Applies to server side port components only.
+ */
+ String contextRoot() <emphasis role="bold">default</emphasis>
"";
+
+ /**
+ * The virtual hosts that the web service endpoint is deployed to.
+ *
+ * Applies to server side port components only.
+ */
+ String[] virtualHosts() <emphasis role="bold">default</emphasis>
{};
+
+ /**
+ * Relative path that is appended to the contextRoot to form fully qualified
+ * endpoint address for the web service endpoint.
+ *
+ * Applies to server side port components only.
+ */
+ String urlPattern() <emphasis role="bold">default</emphasis>
"";
+
+ /**
+ * The authMethod is used to configure the authentication mechanism for the web
service.
+ * As a prerequisite to gaining access to any web service which are protected by an
authorization
+ * constraint, a user must have authenticated using the configured mechanism.
+ *
+ * Legal values for this element are "BASIC", or "CLIENT-CERT".
+ */
+ String authMethod() <emphasis role="bold">default</emphasis>
"";
+
+ /**
+ * The transportGuarantee specifies that the communication
+ * between client and server should be NONE, INTEGRAL, or
+ * CONFIDENTIAL. NONE means that the application does not require any
+ * transport guarantees. A value of INTEGRAL means that the application
+ * requires that the data sent between the client and server be sent in
+ * such a way that it can't be changed in transit. CONFIDENTIAL means
+ * that the application requires that the data be transmitted in a
+ * fashion that prevents other entities from observing the contents of
+ * the transmission. In most cases, the presence of the INTEGRAL or
+ * CONFIDENTIAL flag will indicate that the use of SSL is required.
+ */
+ String transportGuarantee() <emphasis
role="bold">default</emphasis> "";
+
+ /**
+ * A secure endpoint does not secure wsdl access by default.
+ * Explicitly setting secureWSDLAccess overrides this behaviour.
+ *
+ * Protect access to WSDL. See <ulink
url="http://jira.jboss.org/jira/browse/JBWS-723">http://jira...
+ */
+ <emphasis role="bold">boolean</emphasis> secureWSDLAccess()
<emphasis role="bold">default</emphasis> <emphasis
role="bold">false</emphasis>;
+}
+</screen></section>
+<section
id="JBossWS-UserGuide_SecurityDomain"><title>SecurityDomain</title><screen
xml:space="preserve">/**
+ * Annotation for specifying the JBoss security domain for an EJB
+ *
+ * @author <a href="mailto:<ulink
url="mailto:bill@jboss.org">bill@jboss.org</ulink>">Bill
Burke</a>
+ **/
+(a)Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME)
+<emphasis role="bold">public</emphasis> @<emphasis
role="bold">interface</emphasis> SecurityDomain
+{
+ /**
+ * The required name for the security domain.
+ *
+ * Do not use the JNDI name
+ *
+ * Good: "MyDomain"
+ * Bad: "java:/jaas/MyDomain"
+ */
+ String value();
+
+ /**
+ * The name for the unauthenticated pricipal
+ */
+ String unauthenticatedPrincipal() <emphasis
role="bold">default</emphasis> "";
+</screen></section></section>
+</section>
+<section id="JBossWS-UserGuide_JAXB_Introductions"><title>JAXB
Introductions</title><para>As Kohsuke Kawaguchi writes on <ulink
url="http://weblogs.java.net/blog/kohsuke/archive/2007/07/binding_3r...
blog</ulink>, one common complaint from the JAXB users is the lack of support for
binding 3rd party classes. The scenario is this you are trying to annotate your classes
with JAXB annotations to make it XML bindable, but some of the classes are coming from
libraries and JDK, and thus you cannot put necessary JAXB annotations on
it.</para><para>To solve this JAXB has been designed to provide hooks for
programmatic introduction of annotations to the runtime.</para><para>This is
currently leveraged by the JBoss JAXB Introductions project, using which users can define
annotations in XML and make JAXB see those as if those were in the class files (perhaps
coming from 3rd party libraries).</para><para> </para><para>JAXB
Introductions are currently supported in JBossWS-N!
ative (server side only, since 3.0.2.GA) and JBossWS-CXF (both server and client side,
since 3.2.1.GA).</para><para>Take a look at the <ulink
url="http://community.jboss.org/docs/DOC-10075">JAXB Introductions
page</ulink> on the wiki and at the examples in the
sources.</para><para> </para></section>
+</section>
+<section
id="JBossWS-UserGuide_Tools"><title>Tools</title><para>The
JBossWS Web Service Framework provides unified tooling for all the supported stacks. This
currently includes common JAX-WS tools for both contract-first and code-first development
and common management tools.</para><section
id="JBossWS-UserGuide_JAXWS_tools"><title>JAX-WS
tools</title><para>Please refer to <link
linkend="chap_JBossWS-JAX-WSTools">JBossWS_JAX-WS_Tools</link> for
details. This covers directions on web service contract generation (bottom-up development)
and consumption (top-down and client development).</para></section>
+<section id="JBossWS-UserGuide_Management_tools"><title>Management
tools</title><para>JBoss and its web service framework come with some tools
allowing WS endpoint management.</para><para>Please refer the <link
linkend="chap_JBossWS-Endpointmanagement">Endpoint management</link>
page for an overview of the available tools. In particular the <link
linkend="chap_JBossWS-Recordsmanagement">JBossWS - Records
management</link> gives administrators a means of performing custom analysis of
their web service traffic as well as exporting communication
logs.</para></section>
+<section id="JBossWS-UserGuide_Web_Service_console"><title>Web
Service console</title><para>All supported stacks provide a web console for
getting the list of the endpoints currently deployed on a given host as well as basic
metrics regarding invocations to them. The console is available at <ulink
url="http://localhost:8080/jbossws/services">http://localhost:8080/jbossws/services</ulink>
assuming your application server is currently bound to
localhost:8080.</para><para> </para></section>
+</section>
+<section
id="JBossWS-UserGuide_Configuration"><title>Configuration</title><section
id="JBossWS-UserGuide_Address_rewrite"><title>Address
rewrite</title><para>JBossWS allows users to configure the soap:address
attribute in the wsdl contract of deployed services as well as wsdl address in the web
service console. [due to a known issue this does not currently work with JBossWS-Metro,
see: <ulink
url="https://jira.jboss.org/jira/browse/JBWS-2462">JBWS-2462...
role="bold">Server configuration
options</emphasis></para><para> </para><para>There're
few attributes in the jbossws deployers configuration (currently in
jbossws.deployer/META-INF/stack-agnostic-jboss-beans.xml) controlling the way the
soap:address attribute in the wsdl is rewritten.</para><screen
xml:space="preserve"><bean name="WSServerConfig"
class="org.jboss.webservices.integration.config.ServerConfigImpl">
+ <property name="mbeanServer"><inject
bean="WSMBeanServerLocator"
property="mbeanServer"/></property>
+
+ <property
name="webServiceHost">${jboss.bind.address}</property>
+ <property
name="modifySOAPAddress">true</property>
+
+ <!--
+ <property
name="webServiceSecurePort">8443</property>
+ <property
name="webServicePort">8080</property>
+ -->
+ </bean>
+</screen><para> </para><para>If the content of
<emphasis><soap:address></emphasis> in the wsdl is a valid URL,
JBossWS will not rewrite it unless <emphasis>modifySOAPAddress</emphasis> is
true. If the content of <emphasis><soap:address></emphasis> is
not a valid URL instead, JBossWS will always rewrite it using the attribute values given
below. Please note that the variable
<emphasis>${jboss.bind.address}</emphasis> can be used to set the address
which the application is bound to at each
startup.</para><para> </para><para>The webServiceSecurePort and
webServicePort attributes are used to explicitly define the ports to be used for rewriting
the SOAP address. If these attributes are not set, the ports will be identified by
querying the list of installed connectors. If multiple connectors are found the port of
the first connector is
used.</para><para> </para><para><emphasis
role="bold">Dynamic
rewrite</emphasis></para><para> </para><para>When the
application se!
rver is bound to multiple addresses or non-trivial real-world network architectures cause
request for different external addresses to hit the same endpoint, a static rewrite of the
soap:address may not be enough. JBossWS allows for both the soap:address in the wsdl and
the wsdl address in the console to be rewritten with the host use in the client request.
This way, users always get the right wsdl address assuming they're connecting to an
instance having the endpoint they're looking for. To trigger this behaviour, the
<emphasis role="bold">jbossws.undefined.host</emphasis> value has to
be specified for the <emphasis>webServiceHost</emphasis>
attribute.</para><screen xml:space="preserve"><property
name="webServiceHost">jbossws.undefined.host</property>
+<property
name="modifySOAPAddress">true</property></screen><para> </para><para>Of
course, when a confidential transport address is required, the addresses are always
rewritten using https protocol and the port currently configured for the https/ssl
connector.</para></section>
+</section></section></chapter>
\ No newline at end of file
Added: stack/cxf/trunk/src/main/doc/JBossWS-wsconsume.xml
===================================================================
--- stack/cxf/trunk/src/main/doc/JBossWS-wsconsume.xml (rev 0)
+++ stack/cxf/trunk/src/main/doc/JBossWS-wsconsume.xml 2010-11-02 18:00:03 UTC (rev
13200)
@@ -0,0 +1,103 @@
+<?xml version="1.0" encoding="UTF-8"?><chapter
id="chap_JBossWS-wsconsume"><title>JBossWS-wsconsume</title><para>wsconsume
is a command line tool and ant task that "consumes" the abstract contract (WSDL
file) and produces portable JAX-WS service and client artifacts. For a more detailed
overview, see <ulink
url="http://community.jboss.org/docs/DOC-13544#TopDown_Using_wsconsu...
wsconsume"</ulink>.</para><para/><section
id="JBossWS-wsconsume_Command_Line_Tool"><title>Command Line
Tool</title><para>The command line tool has the following
usage:</para><screen xml:space="preserve">usage: wsconsume [options]
<wsdl-url>
+options:
+ -h, --help Show this help message
+ -b, --binding=<file> One or more JAX-WS or JAXB binding files
+ -k, --keep Keep/Generate Java source
+ -c --catalog=<file> Oasis XML Catalog file for entity resolution
+ -p --package=<name> The target package for generated source
+ -w --wsdlLocation=<loc> Value to use for
@WebServiceClient.wsdlLocation
+ -o, --output=<directory> The directory to put generated artifacts
+ -s, --source=<directory> The directory to put Java source
+ -t, --target=<2.0|2.1|2.2> The JAX-WS specification target
+ -q, --quiet Be somewhat more quiet
+ -v, --verbose Show full exception stack traces
+ -l, --load-consumer Load the consumer and exit (debug utility)
+ -e, --extension Enable SOAP 1.2 binding extension
+ -a, --additionalHeaders Enables processing of implicit SOAP
headers</screen><para> </para><para><emphasis
role="bold">Note</emphasis> : The wsdlLocation is used when creating
the Service to be used by clients and will be added to the @WebServiceClient annotation,
for an endpoint implementation based on the generated service endpoint interface you will
need to manually add the wsdlLocation to the @WebService annotation on your web service
implementation and not the service endpoint interface.</para><section
id="JBossWS-wsconsume_Examples"><title>Examples</title><para>Generate
artifacts in Java class form only:</para><screen
xml:space="preserve">wsconsume Example.wsdl
+</screen><para>Generate source and class files:</para><screen
xml:space="preserve">wsconsume -k Example.wsdl
+</screen><para>Generate source and class files in a custom
directory:</para><screen xml:space="preserve">wsconsume -k -o custom
Example.wsdl
+</screen><para>Generate source and class files in the org.foo
package:</para><screen xml:space="preserve">wsconsume -k -p org.foo
Example.wsdl
+</screen><para>Generate source and class files using multiple binding
files:</para><screen xml:space="preserve">wsconsume -k -b
wsdl-binding.xml -b schema1-binding.xml -b
schema2-binding.xml</screen></section>
+</section>
+<section id="JBossWS-wsconsume_Maven_Plugin"><title>Maven
Plugin</title><para>The wsconsume tools is included in the <emphasis
role="bold">org.jboss.ws.plugins:maven-jaxws-tools-plugin</emphasis>
plugin. The plugin has two goals for running the tool,
<emphasis>wsconsume</emphasis> and
<emphasis>wsconsume-test</emphasis>, which basically do the same during
different maven build phases (the former triggers the sources generation during
<emphasis>generate-sources</emphasis> phase, the latter during the
<emphasis>generate-test-sources</emphasis> one).</para><para>The
wsconsume plugin has the following parameters:</para><informaltable><tgroup
cols="3"><colspec colnum="1"
colname="col1"/><colspec colnum="2"
colname="col2"/><colspec colnum="3"
colname="col3"/><thead><row><entry>Attribute</entry><entry>Description</entry><entry>Default
</entry></row></thead><tbody><row><entry>bindingFiles</entry><entry>JAXWS
or JAXB binding
file</entry><entry>true</entry></row><row><entry>classpath!
Elements</entry><entry><para>Each classpathElement provides
a</para><para>library file to be added to
classpath</para></entry><entry><para>${project.compileClasspathElements}</para><para>or</para><para>${project.testClasspathElements}</para></entry></row><row><entry>catalog</entry><entry>Oasis
XML Catalog file for entity
resolution</entry><entry>none</entry></row><row><entry>targetPackage</entry><entry>The
target Java package for generated
code.</entry><entry>generated</entry></row><row><entry>bindingFiles</entry><entry>One
or more JAX-WS or JAXB binding
file</entry><entry>none</entry></row><row><entry>wsdlLocation</entry><entry>Value
to use for
@WebServiceClient.wsdlLocation</entry><entry>generated</entry></row><row><entry>outputDirectory</entry><entry>The
output directory for generated
artifacts.</entry><entry><para>${project.build.outputDirectory}</para><para>or</para><para>${project.build.testOutputDirectory}</para></entry></row><row><entry>sourceDirectory</entry><entry!
The output directory for Java
source.</entry><entry>${project!
.build.d
irectory}/wsconsume/java</entry></row><row><entry>verbose</entry><entry>Enables
more informational output about command
progress.</entry><entry>false</entry></row><row><entry>wsdls</entry><entry>The
WSDL files or URLs to
consume</entry><entry>n/a</entry></row><row><entry>extension</entry><entry>Enable
SOAP 1.2 binding
extension.</entry><entry>false</entry></row></tbody></tgroup></informaltable><section
id="JBossWS-wsconsume_Examples_187752"><title>Examples</title><para>You
can use wsconsume in your own project build simply referencing the
<emphasis>maven-jaxws-tools-plugin</emphasis> in the configured plugins in
your pom.xml file.</para><para>The following example makes the plugin consume
the test.wsdl file and generate SEI and wrappers' java sources. The generated sources
are then compiled together with the other project classes.</para><screen
xml:space="preserve"><build>
+ <plugins>
+ <plugin>
+ <groupId>org.jboss.ws.plugins</groupId>
+ <artifactId>maven-jaxws-tools-plugin</artifactId>
+ <version>1.0.0.GA</version>
+ <configuration>
+ <wsdls>
+ <wsdl>${basedir}/test.wsdl</wsdl>
+ </wsdls>
+ </configuration>
+ <executions>
+ <execution>
+ <goals>
+ <goal>wsconsume</goal>
+ </goals>
+ </execution>
+ </executions>
+ </plugin>
+ </plugins>
+</build>
+</screen><para> </para><para>You can also specify multiple wsdl
files, as well as force the target package, enable SOAP 1.2 binding and turn the
tool's verbose mode on:</para><para> </para><screen
xml:space="preserve"><build>
+ <plugins>
+ <plugin>
+ <groupId>org.jboss.ws.plugins</groupId>
+ <artifactId>maven-jaxws-tools-plugin</artifactId>
+ <version>1.0.0.GA</version>
+ <configuration>
+ <wsdls>
+ <wsdl>${basedir}/test.wsdl</wsdl>
+ <wsdl>${basedir}/test2.wsdl</wsdl>
+ </wsdls>
+ <targetPackage>foo.bar</targetPackage>
+ <extension>true</extension>
+ <verbose>true</verbose>
+ </configuration>
+ <executions>
+ <execution>
+ <goals>
+ <goal>wsconsume</goal>
+ </goals>
+ </execution>
+ </executions>
+ </plugin>
+ </plugins>
+</build>
+</screen><para> </para><para>Finally, if the wsconsume invocation
is required for consuming a wsdl to be used in your testsuite only, you might want to use
the <emphasis>wsconsume-test</emphasis> goal as
follows:</para><para> </para><screen
xml:space="preserve"><build>
+ <plugins>
+ <plugin>
+ <groupId>org.jboss.ws.plugins</groupId>
+ <artifactId>maven-jaxws-tools-plugin</artifactId>
+ <version>1.0.0.GA</version>
+ <configuration>
+ <wsdls>
+ <wsdl>${basedir}/test.wsdl</wsdl>
+ </wsdls>
+ </configuration>
+ <executions>
+ <execution>
+ <goals>
+ <goal>wsconsume-test</goal>
+ </goals>
+ </execution>
+ </executions>
+ </plugin>
+ </plugins>
+</build>
+</screen></section>
+</section>
+<section id="JBossWS-wsconsume_Ant_Task"><title>Ant
Task</title><note><para><para><emphasis><emphasis
role="bold">Note</emphasis></emphasis></para><para><emphasis>With
2.0.GA the task was renamed to org.jboss.wsf.spi.tools.ant.WSConsumeTask. Also put
streamBuffer.jar and stax-ex.jar in the classpath of the ant task to generate the
appropriate artefacts. Both jar files are in the jbossws lib directory. For
jbossws-native-2.0.3.GA these files are not automatically installed if you run
jboss-deployXX.</emphasis></para></para></note><para>The
wsconsume ant task has the following
attributes:</para><informaltable><tgroup cols="3"><colspec
colnum="1" colname="col1"/><colspec colnum="2"
colname="col2"/><colspec colnum="3"
colname="col3"/><thead><row><entry>Attribute</entry><entry>Description</entry><entry>Default
</entry></row></thead><tbody><row><entry>fork</entry><entry>Whether
or not to run the generation task in a separate
VM.</entry><entry>true</entry></row><row><entry>keep</e!
ntry><entry>Keep/Enable Java source code
generation.</entry><entry>false</entry></row><row><entry>catalog</entry><entry>Oasis
XML Catalog file for entity
resolution</entry><entry>none</entry></row><row><entry>package</entry><entry>The
target Java package for generated
code.</entry><entry>generated</entry></row><row><entry>binding</entry><entry>A
JAX-WS or JAXB binding
file</entry><entry>none</entry></row><row><entry>wsdlLocation</entry><entry>Value
to use for
@WebServiceClient.wsdlLocation</entry><entry>generated</entry></row><row><entry>destdir</entry><entry>The
output directory for generated
artifacts.</entry><entry>"output"</entry></row><row><entry>sourcedestdir</entry><entry>The
output directory for Java source.</entry><entry>value of
destdir</entry></row><row><entry>target</entry><entry>The
JAX-WS specification target. Allowed values are 2.0, 2.1 and
2.2</entry><entry/></row><row><entry>verbose</entry><entry>Enables
more informational output about command progress.</en!
try><entry>false</entry></row><row><entry>wsdl</entry><entry>T!
he WSDL
file or
URL</entry><entry>n/a</entry></row><row><entry>extension</entry><entry>Enable
SOAP 1.2 binding
extension.</entry><entry><para>false</para></entry></row><row><entry>additionalHeaders</entry><entry>Enables
processing of implicit SOAP
headers</entry><entry>false</entry></row></tbody></tgroup></informaltable><para><emphasis
role="bold">Note</emphasis> : The wsdlLocation is used when creating
the Service to be used by clients and will be added to the @WebServiceClient annotation,
for an endpoint implementation based on the generated service endpoint interface you will
need to manually add the wsdlLocation to the @WebService annotation on your web service
implementation and not the service endpoint
interface.</para><para> </para><para>Also, the following nested
elements are supported:</para><informaltable><tgroup
cols="3"><colspec colnum="1"
colname="col1"/><colspec colnum="2"
colname="col2"/><colspec colnum="3"
colname="col3"/><thead><row><entry>Element</entry><entry>Des!
cription</entry><entry>Default
</entry></row></thead><tbody><row><entry>binding</entry><entry>A
JAXWS or JAXB binding
file</entry><entry>none</entry></row><row><entry>jvmarg</entry><entry>Allows
setting of custom jvm
arguments</entry><entry/></row></tbody></tgroup></informaltable><para> </para><section
id="JBossWS-wsconsume_Examples_184359"><title>Examples</title><para>Generate
JAX-WS source and classes in a separate JVM with separate directories, a custom wsdl
location attribute, and a list of binding files from foo.wsdl:</para><screen
xml:space="preserve"><wsconsume
+ fork="true"
+ verbose="true"
+ destdir="output"
+ sourcedestdir="gen-src"
+ keep="true"
+ wsdllocation="handEdited.wsdl"
+ wsdl="foo.wsdl">
+ <binding dir="binding-files" includes="*.xml"
excludes="bad.xml"/>
+</wsconsume></screen></section>
+</section>
+<section id="JBossWS-wsconsume_Related_information"><title>Related
information</title><itemizedlist><listitem><para> <ulink
url="http://java.sun.com/webservices/docs/2.0/jaxws/customizations.h...
binding customization</ulink>
</para></listitem></itemizedlist></section>
+</chapter>
\ No newline at end of file
Added: stack/cxf/trunk/src/main/doc/JBossWS-wsprovide.xml
===================================================================
--- stack/cxf/trunk/src/main/doc/JBossWS-wsprovide.xml (rev 0)
+++ stack/cxf/trunk/src/main/doc/JBossWS-wsprovide.xml 2010-11-02 18:00:03 UTC (rev
13200)
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="UTF-8"?><chapter
id="chap_JBossWS-wsprovide"><title>JBossWS-wsprovide</title><para>wsprovide
is a command line tool and ant task that generates portable JAX-WS artifacts for a service
endpoint implementation. It also has the option to "provide" the abstract
contract for offline usage. See <ulink
url="http://community.jboss.org/docs/DOC-13544#BottomUp_Using_wsprov...
wsprovide"</ulink> for a detailed
walk-through.</para><para/><section
id="JBossWS-wsprovide_Command_Line_Tool"><title>Command Line
Tool</title><para>The command line tool has the following
usage:</para><screen xml:space="preserve"> usage: wsprovide
[options] <endpoint class name>
+ options:
+ -h, --help Show this help message
+ -k, --keep Keep/Generate Java source
+ -w, --wsdl Enable WSDL file generation
+ -c. --classpath=<path< The classpath that contains the endpoint
+ -o, --output=<directory> The directory to put generated artifacts
+ -r, --resource=<directory> The directory to put resource artifacts
+ -s, --source=<directory> The directory to put Java source
+ -e, --extension Enable SOAP 1.2 binding extension
+ -q, --quiet Be somewhat more quiet
+ -t, --show-traces Show full exception stack traces</screen><section
id="JBossWS-wsprovide_Examples"><title>Examples</title><para>Generating
wrapper classes for portable artifacts in the "generated"
directory:</para><screen xml:space="preserve">wsprovide -o generated
foo.Endpoint
+</screen><para>Generating wrapper classes and WSDL in the
"generated" directory</para><screen
xml:space="preserve">wsprovide -o generated -w foo.Endpoint
+</screen><para>Using an endpoint that references other
jars</para><screen xml:space="preserve">wsprovide -o generated -c
application1.jar:application2.jar foo.Endpoint</screen></section>
+</section>
+<section id="JBossWS-wsprovide_Maven_Plugin"><title>Maven
Plugin</title><para>The wsprovide tools is included in the <emphasis
role="bold">org.jboss.ws.plugins:maven-jaxws-tools-plugin</emphasis>
plugin. The plugin has two goals for running the tool,
<emphasis>wsprovide</emphasis> and
<emphasis>wsprovide-test</emphasis>, which basically do the same during
different maven build phases (the former triggers the sources generation during
<emphasis>process-classes</emphasis> phase, the latter during the
<emphasis>process-test-classes</emphasis> one).</para><para>The
wsprovide plugin has the following parameters:</para><informaltable><tgroup
cols="3"><colspec colnum="1"
colname="col1"/><colspec colnum="2"
colname="col2"/><colspec colnum="3"
colname="col3"/><thead><row><entry> Attribute
</entry><entry> Description </entry><entry> Default
</entry></row></thead><tbody><row><entry>testClasspathElements</entry><entry><para>Each
classpathElement provides a</para><para>library file to b!
e added to
classpath</para></entry><entry><para>${project.compileClasspathElements}</para><para>or</para><para>${project.testClasspathElements}</para></entry></row><row><entry>outputDirectory</entry><entry>The
output directory for generated
artifacts.</entry><entry><para>${project.build.outputDirectory}</para><para>or</para><para>${project.build.testOutputDirectory}</para></entry></row><row><entry>resourceDirectory</entry><entry>The
output directory for resource artifacts
(WSDL/XSD).</entry><entry>${project.build.directory}/wsprovide/resources</entry></row><row><entry>sourceDirectory</entry><entry>The
output directory for Java
source.</entry><entry>${project.build.directory}/wsprovide/java</entry></row><row><entry>extension</entry><entry>Enable
SOAP 1.2 binding
extension.</entry><entry>false</entry></row><row><entry>generateWsdl</entry><entry>Whether
or not to generate
WSDL.</entry><entry>false</entry></row><row><entry>verbose</entry><entry>Enables
more informational output!
about command
progress.</entry><entry>false</entry></row><row!
<entry>
<emphasis
role="bold">endpointClass</emphasis></entry><entry><emphasis
role="bold">Service Endpoint
Implementation.</emphasis></entry></row></tbody></tgroup></informaltable><section
id="JBossWS-wsprovide_Examples_147019"><title>Examples</title><para>You
can use wsprovide in your own project build simply referencing the
<emphasis>maven-jaxws-tools-plugin</emphasis> in the configured plugins in
your pom.xml file.</para><para>The following example makes the plugin provide
the wsdl file and artifact sources for the specified endpoint
class:</para><screen xml:space="preserve"><build>
+ <plugins>
+ <plugin>
+ <groupId>org.jboss.ws.plugins</groupId>
+ <artifactId>maven-jaxws-tools-plugin</artifactId>
+ &lt;version&gt;@pom.version(a)&lt;/version&gt;
+ <configuration>
+ <verbose>true</verbose>
+
<endpointClass>org.jboss.test.ws.plugins.tools.wsprovide.TestEndpoint</endpointClass>
+ <generateWsdl>true</generateWsdl>
+ </configuration>
+ <executions>
+ <execution>
+ <goals>
+ <goal>wsprovide</goal>
+ </goals>
+ </execution>
+ </executions>
+ </plugin>
+ </plugins>
+</build>
+</screen><para> </para><para>The following example does the same,
but is meant for use in your own testsuite:</para><screen
xml:space="preserve"><build>
+ <plugins>
+ <plugin>
+ <groupId>org.jboss.ws.plugins</groupId>
+ <artifactId>maven-jaxws-tools-plugin</artifactId>
+ &lt;version&gt;@pom.version(a)&lt;/version&gt;
+ <configuration>
+ <verbose>true</verbose>
+
<endpointClass>org.jboss.test.ws.plugins.tools.wsprovide.TestEndpoint2</endpointClass>
+ <generateWsdl>true</generateWsdl>
+ </configuration>
+ <executions>
+ <execution>
+ <goals>
+ <goal>wsprovide-test</goal>
+ </goals>
+ </execution>
+ </executions>
+ </plugin>
+ </plugins>
+</build>
+</screen><para> </para></section>
+</section>
+<section id="JBossWS-wsprovide_Ant_Task"><title>Ant
Task</title><note><para><para><emphasis><emphasis
role="bold">Note</emphasis></emphasis></para><para><emphasis>With
2.0.GA the task was renamed to
org.jboss.wsf.spi.tools.ant.WSProvideTask</emphasis></para></para></note><para>The
wsprovide ant task has the following
attributes:</para><informaltable><tgroup cols="3"><colspec
colnum="1" colname="col1"/><colspec colnum="2"
colname="col2"/><colspec colnum="3"
colname="col3"/><thead><row><entry> Attribute
</entry><entry> Description </entry><entry> Default
</entry></row></thead><tbody><row><entry>fork</entry><entry>Whether
or not to run the generation task in a separate
VM.</entry><entry>true</entry></row><row><entry>keep</entry><entry>Keep/Enable
Java source code
generation.</entry><entry>false</entry></row><row><entry>destdir</entry><entry>The
output directory for generated
artifacts.</entry><entry>"output"</entry></row><row><entry>resourcedestdir</entry><entry>The
output dir!
ectory for resource artifacts (WSDL/XSD).</entry><entry>value of
destdir</entry></row><row><entry>sourcedestdir</entry><entry>The
output directory for Java source.</entry><entry>value of
destdir</entry></row><row><entry>extension</entry><entry>Enable
SOAP 1.2 binding
extension.</entry><entry>false</entry></row><row><entry>genwsdl</entry><entry>Whether
or not to generate
WSDL.</entry><entry>false</entry></row><row><entry>verbose</entry><entry>Enables
more informational output about command
progress.</entry><entry>false</entry></row><row><entry><emphasis
role="bold">sei</emphasis></entry><entry><emphasis
role="bold">Service Endpoint
Implementation.</emphasis></entry></row><row><entry>classpath</entry><entry>The
classpath that contains the service endpoint
implementation.</entry><entry>"."</entry></row></tbody></tgroup></informaltable><section
id="JBossWS-wsprovide_Examples_860945"><title>Examples</title><para>Executing
wsprovide in verbose mode with separate output directorie!
s for source, resources, and classes:</para><screen xml:space=!
"preserv
e"><target name="test-wsproivde"
depends="init">
+ <taskdef name="wsprovide"
classname="org.jboss.wsf.spi.tools.ant.WSProvideTask">
+ <classpath refid="core.classpath"/>
+ </taskdef>
+ <wsprovide
+ fork="false"
+ keep="true"
+ destdir="out"
+ resourcedestdir="out-resource"
+ sourcedestdir="out-source"
+ genwsdl="true"
+ verbose="true"
+
sei="org.jboss.test.ws.jaxws.jsr181.soapbinding.DocWrappedServiceImpl">
+ <classpath>
+ <pathelement path="${tests.output.dir}/classes"/>
+ </classpath>
+ </wsprovide>
+</target>
+</screen></section>
+</section></chapter>
\ No newline at end of file
Added: stack/cxf/trunk/src/main/doc/JBossWS-wsrunclient.xml
===================================================================
--- stack/cxf/trunk/src/main/doc/JBossWS-wsrunclient.xml (rev 0)
+++ stack/cxf/trunk/src/main/doc/JBossWS-wsrunclient.xml 2010-11-02 18:00:03 UTC (rev
13200)
@@ -0,0 +1,6 @@
+<?xml version="1.0" encoding="UTF-8"?><chapter
id="chap_JBossWS-wsrunclient"><title>JBossWS-wsrunclient</title><para>wsrunclient
is a command line tool that invokes a JBossWS JAX-WS Web Service client. It builds the
correct classpath and endorsed libs for you. Feel free to use the code for this script to
make your own shell scripts. It is open source after
all.</para><section><title>Usage</title><screen
xml:space="preserve"> wsrunclient [-classpath <additional class
path>] <java-main-class> [arguments...]
+</screen></section>
+<section><title>Examples</title><para>Invoking a standalone
JAX-WS client:</para><screen xml:space="preserve">wsrunclient
echo.EchoClient</screen><para>Invoking a standalone JAX-WS client that uses
external jars:</para><screen xml:space="preserve">wsrunclient
-classpath jar1.jar:jar2.jar echo.EchoClient
+
+</screen></section>
+</chapter>
\ No newline at end of file
Modified: stack/cxf/trunk/src/main/scripts/assembly-bin-dist.xml
===================================================================
--- stack/cxf/trunk/src/main/scripts/assembly-bin-dist.xml 2010-11-02 14:28:01 UTC (rev
13199)
+++ stack/cxf/trunk/src/main/scripts/assembly-bin-dist.xml 2010-11-02 18:00:03 UTC (rev
13200)
@@ -55,6 +55,10 @@
<include>JBossORG-EULA.txt</include>
</includes>
</fileSet>
+ <fileSet>
+ <directory>target/docbook/publish</directory>
+ <outputDirectory>jbossws-cxf-bin-dist/docs</outputDirectory>
+ </fileSet>
<!-- deploy -->
<fileSet>
<directory>target/assembly/deploy-artifacts</directory>