Develop SOAP Web Service As OSGi Bundle With Camel-CXF

Introduction

This article is a continuation of my post on how to develop a RESTful web service. In this one, I am going explain the procedure to develop, build, and test a SOAP base web service. The deployment environment is OSGi container as Talend ESB 5.3.1. The bundle developed here can be deployed to any OSGi container like JBoss Fuse, ServiceMix, etc. With minor modification, it can also be deployed to Tomcat container.

There are two approaches to develop a SOAP base web service. One is called bottom-up or code first approach. With this approach, develop can write SOAP based service using annotation. The container will be able to expose the service with derived WSDL. The other approach is called Top-Down or contract first approach. Each approach has its pros and cons. The rule-of-thumb for the choice is the following:

• For large enterprise applications with SOA governance, the Top-Down approach is the choice. It enforces the controlled changes, business oriented, and language neutral.
• If the organization is small, and you need quick-to-market, the code-first/bottom-up approach is preferred. However, in this case, why don't you choose, RESTful?

The source code for this project has been pushed to gitHub at: https://github.com/garyliu1119/Gary-Liu-ESB. The following is the procedures I push the code to the github:

git add camel-example-cxf-osgi
git commit -m "commit the came-cxf-osg exmaple"
git remote add github https://github.com/garyliu1119/Gary-Liu-ESB.git
git pull github master
git push github master

Verify The Web Service

After download the project, you can compile and deploy the project to an OSGi container by the following commands:

osgi:install -s mvn:org.apache.camel/camel-example-cxf-osgi/2.10.4

watch the log, if there is no errors. it means the Web Service is deployed and started correctly. To verify the web service, we can enter the following URL to a browser:

http://localhost:8040/services/camel-example-cxf-osgi/webservices/incident?wsdl

Note: Different OSGi container may use different port, here I am usng 8040. And the path, services, may vary as well. The port definition is location in the file:

     ${CONTAINER_HOME}/etc/org.ops4j.pax.web.cfg
     org.osgi.service.http.port=8040

And the path is defined in the file:

     ${CONTAINER_HOME}/etcorg.apache.cxf.osgi.cfg"
     org.apache.cxf.servlet.context=/services

The file for WSDL definition is located at:

    src/main/resources/META-INF/wsdl/report_incident.wsdl

Once we verify that the web service is working. We can use SaopUI to test the saop invokation. Here is the sample message you can use:

   
   
      
         111
         2011-03-05
         Christian
         Mueller
         
Bla
         
Bla bla
         cmueller@apache.org
         0049 69 1234567
      
   
    

When you invoke the web service using the above soap xml, you should get the following response:

   
      
         NOK
      
   
    

If you change the givenName to Claus, you will get

     OK

The reason for this is in our route, we look for the giveName in the message body, if it is Claus, we return code of "OK". If you look into the camel route, this will become clear.

pom.xml

The origin of this project is from Apache Camel examples. The code has been distributed with many other ESB continers. The original route is in Java DSL. I converted that to Spring DSL.

There are few interesting points should be noted about this project. The first is the pom.xml. In this file, there is a plugin to generate java code from wsdl, name wsdl2java. You can find the detailed documentation about this utility at

• https://cxf.apache.org/docs/wsdl-to-java.html
• https://cxf.apache.org/docs/maven-cxf-codegen-plugin-wsdl-to-java.html

Camel Route

Here is complete list of the file of camel-context.xml

 


 
  
   
  
  
   
   
   
  
 
    
         
         
         
              request-${date:now:yyyy-MM-dd-HHmmssSSS}
         
         
         
         
         
            
                ${body.givenName} == 'Claus'
                    
                         ref:OK
                    
            
            
                    
                         ref:NOK
                    
            
         
    
 

The the above camel-context, you can see that the web service is exposed through a pojo: ReportIncidentEndpoint. It is an java inteface like this:

@WebService(targetNamespace = "http://reportincident.example.camel.apache.org", name = "ReportIncidentEndpoint")
@XmlSeeAlso({ObjectFactory.class})
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
@Generated(value = "org.apache.cxf.tools.wsdlto.WSDLToJava", date = "2014-03-07T14:05:18.457-06:00", comments = "Apache CXF 2.6.6")
public interface ReportIncidentEndpoint {

    @WebResult(name = "outputReportIncident", targetNamespace = "http://reportincident.example.camel.apache.org", partName = "out")
    @WebMethod(operationName = "ReportIncident", action = "http://reportincident.example.camel.apache.org/ReportIncident")
    @Generated(value = "org.apache.cxf.tools.wsdlto.WSDLToJava", date = "2014-03-07T14:05:18.457-06:00")
    public OutputReportIncident reportIncident(
        @WebParam(partName = "in", name = "inputReportIncident", targetNamespace = "http://reportincident.example.camel.apache.org")
        InputReportIncident in
    );
}

Note: I did not implement the interface method. The CXF library provide default immplementaion. The web service is a cxfEndpoint. The reference for