Today I’m going to show you how to create a WSDL-first web service using Apache CXF 3.0.1.
Source code can be found here.
What is WSDL-first?
WSDL-first or Contract-first is where you create the WSDL, and then you can create the implementation from this, and since the WSDL is your contract, this would be contract-first.
Ok, let’s see step by step
Create the project file structure. Following Maven’s standard directory layout, create a “web_service_tutorial” folder and from there copy-and-paste the appropriate set of
directory creation commands:
mkdir -p client/src/main/java/client mkdir -p service/src/assembly mkdir -p service/src/main/java/service mkdir -p service/src/test/java/service mkdir -p service/src/main/resources mkdir -p war/src/main/webapp/WEB-INF
Create and configure the Maven pom files.
The following files will need to be added to the specified locations.
web_service_tutorial/pom.xml: This is the parent pom file declaring common dependencies and plugins used by the submodules (service, war, and client)
web_service_tutorial/service/pom.xml: This pom file generates the JAX-WS artifacts (using either CXF’s wsdl2java) that will be referenced by the web service provider and SOAP client. The Maven Assembly Plugin is used here to create a subset of the full service JAR, containing the JAX-WS artifacts and the WSDL but not the web service implementation, for use by the SOAP client. If you know you’re going to be deploying only with servlets, you may optionally set the
packaging value to
jar and remove the
maven-bundle-plugin plugin references from this pom.
web_service_tutorial/service/src/assembly/jaxws-jar.xml: The Maven Assembly Plugin uses this file to create a JAR containing the JAX-WS generated artifacts and the WSDL file.
web_service_tutorial/war/pom.xml: This pom creates the WAR file that will host the web service if you’re using Tomcat. It is not needed for OSGi deployment, but if you omit to add this file be sure to remove this module from the module list in the parent pom.xml.
web_service_tutorial/client/pom.xml: This pom file includes as a dependency the JAX-WS artifact jar created above and uses the Maven Exec Plugin to activate the SOAP client.
Create the web service WSDL and generate the JAX-WS artifacts. Place the below DoubleIt.wsdl file into the
service/src/main/resources directory. OSGi deployment only: Switch to the commented-out OSGi endpoint URL in the soap:address location in the wsdl:service section.
Create the servlet deployment descriptor (web.xml) file (Tomcat deployment only). The deployment descriptor below needs modification based on the web service stack you are using. Once done, place the file in the
war/src/main/webapp/WEB-INF directory of the project.
In order to verify the pom.xml files and generate the JAX-WS and JAXB artifacts run
mvn clean install
Create the Web Service Provider. This class is known as either the SEI (Service Endpoint Interface) implementation or Service Implementation Bean (SIB). The SEI is the DoubleItPortType class that was generated from the WSDL earlier. The methods in the SEI map to the operations defined in the portType section of the WSDL.
Place this DoubleItPortTypeImpl.java file in the
Build and deploy the WAR file
Tomcat embedded deployment: No special configuration or manual download of Tomcat needed. The maven
tomcat7:run-war command will download and run an in-memory Tomcat instance and host the web service WAR on it. This is a very simple and quick way to test the web service works without needing to bother with Tomcat installation or configuration. It is configured to run on localhost:8080 so make sure you don’t have any other servers presently occupying that address.
After deployment, make sure you can access the web service’s WSDL at http://localhost:8080/doubleit/services/doubleit?wsdl before proceeding further.
Create the web service client. The following client tests the DoubleIt operation declared in the WSDL. Place the below WSClient.java file in the
Run the client code. First run
mvn clean install from the client (or parent) submodule to compile the above class. Then, run
mvn exec:exec from the client submodule.