SOAP Web Services Using CXF/JiBX [JAX-WS]
SOAP Web Services Using CXF/JiBX [JAX-WS]
I was never a fan of the contract-first approach, but after using Apache CXF/JiBX, I believe this is the best way to develop web services progressively from a requirements and design phase.
Join the DZone community and get the full member experience.Join For Free
Building integrations to CRM applications? Find out eight things that each product manager and technical executive should know in The CRM Integration Guide: 8 Things Experts Are Considering in Their API Strategy.
Advantages of Apache CXF
Figure 1. SOAP web services architecture (SOAP > WSDL > UDDI).
Apache CXF is currently the most widely used framework and is often preferred over Axis. This is because:
It separates the JAX-WS code from the core application code.
It is compliant with the Spring Framework.
It is more performant than all JAX-WS implementations.
It supports both JAX-WS and JAX-RS.
It is the most popular JAX-WS framework and is replacing all other implementations.
It is relatively easy to use and generates lesser code with Eclipse support being available.
Figure 2. CXF Architecture with all components; note the front-ends and pluggable data bindings (Source).
Advantages of JiBX
JiBX, unlike other binding frameworks, provides two distinct advantages:
It generates an additional binding class apart from the regular schema. This separates the Java code changes from the binding changes, which means that both can be changed independently of each other.
It optimizes the bytecode generated and is a more performant data binding mechanism by a factor of two or more than other binding mechanisms. It does so by using various goals or phases including code generation, binding compiler, and the binding runtime. The number of Java classes and configuration code generated by JiBX is far greater and is the acceptable tradeoff to achieve the performance gain.
Figure 3. JiBX simple XML binding (Source).
CXF/JiBX Using Eclipse (Spring/Standalone Server)
You need the following tools and dependencies (with specific versions) to build this sample:
Maven Connector for Eclipse (M2E).
CXF Codegen Plugin (Maven Eclipse Connector).
JiBX Maven Plugin (Maven Eclipse Connector).
Maven Configuration (Spring Dependencies).
These are the steps to follow to create a sample "Calculator" web service using CXF and JiBX (using this as a reference).
There are a very few (next to none) links that explain the step-by-step web service creation. After my reading of Apache CXF and JiBX, I would recommend it for all JAX-WS/SOAP based web development in terms of performance. Though I have not done any benchmarking myself, I am impressed with the facts provided for both CXF and JiBX. You can use the below steps to understand (deploy) and then use it directly (as RI) into your project or product.
The only drawback seems to be that the curve in understanding both frameworks completely (read the Depths section) can be at times perplexing. Since there are many features that one never uses in a normal web services project or product, you may be skeptical that you have missed something or there might be something more in there. To start off, I've given the detailed steps below.
1. Create a Maven Project in Eclipse
You can download the attached source code and understand further the Maven Project Object Model. I am outlining the most important sections here:
The properties contain the version for easy reference and changes to the Maven build file. The above properties are the right version, but you may want to try JiBX 1.2.6+ and also Spring 4.0.0+. Also, you may want to try this on JDK 1.8.0; we used JDK 1.7.0.
The above dependencies are only for Apache CXF and the version is read from the properties section. This contains all the dependencies required for building this project related to CXF.
The above dependencies are only for JiBX and the version is read from the properties section. This contains all the dependencies required for building this project related to CXF.
The above dependencies are only for Spring. Note that only Spring Context is required for building and running this project. This is true even if you would want to deploy this on a web or app server.
2. Contract First Web Services (Develop the WSDL/XSD in Eclipse)
I was never a fan of the contract-first approach. However, after using Apache CXF/JiBX, I've started to believe that this is the best way of developing web services progressively from the requirements and design phase. If you plan early, at the end you may just want to (or have to) copy and paste your specification to generate code using Maven (CXF/JiBX). Otherwise, it will involve only some work to create the WSDL/XSD out of your documented service specifications in a Software Requirements Specification or System Design document.
You may go through the WSDL/XSD in the attached source code. (Note that the XSD contains the types as normal verb names. The standards recommend that the response/request message names be suffixed with HttpIn, HttpOut, Request, Response, SoapIn, SoapOut.)
Figure 4. XML Schema Definition (XSD).
You may go through the WSDL/XSD in the attached source code.
Figure 5. Web Services Definition Language (WSDL).
3. Run the Maven Build (MVN Install)
The following is the code extract from the pom.xml for generate-sources from the cxf-codegen-plugin. Also shown is the declaration (inclusion) of the Maven Compiler for running the Binding Compiler.
Figure 6. Maven code extract for generating Java sources for web services (note the -nexclude flag for types).
This goal is used to generate the Java Types using the JiBX maven plugin. It also generates the binding.xml. All of the generated code will be available under the target/generated-sources.
Figure 7. Maven Code Extract for 'Generating Java Type from Schema (note that we have mentioned a mock custom JiBX code generation XML).
The bind goal to bind the generated sources, types and the binding. This phase is the Binding Compiler and when a request is made, then the binding runtime will kick-in or trigger.
Figure 8. Maven Code Extract for the binding compiler (Note the paths to the generated sources and binding).
4. Identify the Generated Classes (and Better Understand CXF/JiBX)
Spend some time to identify the generated classes and artifacts to better understand and appreciate the cxf-codegen-plugin and jibx-maven-plugin.
Figure 9. Maven code extract for binding compiler.
5. Deploy and Run (Start With Standalone Java Using Spring Context)
You can run the main class at de.frvabe.sample.calculator.Main. This will load (and deploy the web services endpoint) the web services configuration using a Spring ClassPathXmlApplicationContext (from the spring configuration calculator-app-context.xml).
Fig. 10 Running the main class (console)
6. Verify on the Browser
Check if WSDL exists and is accessible. Alternatively, use SoapUI. Find the request provided and the response returned using SoapUI.
Figure 12. SOAP response (using SoapUI).
The function performed is a dummy add with the value supplied (and zero) and the result is returned as response.
You can download the archive here. You may choose to run this example on Tomcat, Weblogic, Websphere, or JBoss. Try adding functionality or exploring other sophisticated code generation capabilities of JiBX as per your project requirements.
You may want to use other reference implementations of JAX-WS or use the default JAXB for developing web services. This article is specifically for SOAP using CXF/JiBX (Eclipse, Standalone, and Tomcat).
Published at DZone with permission of Sumith Puri , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.