If you like writing plain old Java objects and then watching a WSDL appear like a reluctant magic trick you are in the right place. This guide walks through a bottom up SOAP web service workflow in Eclipse using Java and Apache CXF. Expect Maven dependency chores a little bit of classloader drama and enough logging to make debugging less tragic.

Why bottom up for SOAP in Eclipse

Bottom up means you start with a POJO that expresses your API and then generate or expose a WSDL from that code. It is great for fast iteration and keeping the Java model first. It also keeps the WSDL sane when you write a thoughtful API rather than trying to translate an emotional spreadsheet into XML.

Project setup and Maven dependencies

Create a standard Maven project in Eclipse and add CXF runtime dependencies. Keep versions centralized so your dependency tree does not look like modern art. At minimum include the CXF JAX WS frontend and the HTTP transport artifacts.

<dependencies>
  <dependency>
    <groupId>org.apache.cxf</groupId>
    <artifactId>cxf-rt-frontend-jaxws</artifactId>
    <version>3.4.4</version>
  </dependency>
  <dependency>
    <groupId>org.apache.cxf</groupId>
    <artifactId>cxf-rt-transports-http</artifactId>
    <version>3.4.4</version>
  </dependency>
</dependencies>

Include the CXF Maven plugin if you want a build time WSDL file. That helps ensure stable contracts for consumers and keeps your CI from generating different artifacts on different days.

Design the POJO service

Make a plain old Java interface that describes the contract and a class that implements it. Add JAX WS annotations like @WebService and @WebMethod on the interface or class depending on your style. Keep parameter and return types JAXB friendly so the generated WSDL does not look like a prize for an obscure dictionary contest.

Example structure

• com.example.service.YourService interface with @WebService
• com.example.service.impl.YourServiceImpl with business logic
• Model classes that are simple and serializable by JAXB

Expose or generate the WSDL

For development a quick and dirty approach is to call Endpoint.publish in a main method to expose the service and let CXF publish a runtime WSDL URL. For production you should generate a WSDL at build time so consumers get a stable contract and so you stop blaming the server for version drift.

Runtime exposure

Use javax.xml.ws.Endpoint.publish to spin up a tiny HTTP server for tests. It is fast and fine for local testing.

Build time WSDL

Configure the CXF codegen or plugin in Maven to produce a WSDL during the build. This ensures your consumers and your CI are reading from the same truth file.

Deployment options

For quick iteration use an embedded server. For realistic behavior package a WAR and deploy to Tomcat. You can wire CXF via a servlet mapping or by keeping a minimal web.xml. Choose the approach that matches your ops team patience level.

Things to watch

• Classloader quirks when running in servlet containers can cause mysterious NoSuchMethod errors. They love to surprise you on Fridays.
• Conflicting CXF or JAX WS versions across the container and your app will make runtime life spicy. Manage versions centrally.

Testing the endpoint

Fire up SOAP UI for a GUI driven test or send raw SOAP envelopes with curl or any HTTP client if you enjoy typing XML. Verify the operation responses headers and fault handling. If something looks wrong log the raw SOAP messages and read them like a confession note.

Logging and troubleshooting

Enable CXF or logging interceptors to capture inbound and outbound XML. Seeing the actual SOAP envelopes will save hours of guessing and the occasional therapy session. Pay attention to faults and HTTP status codes and confirm the WSDL matches the deployed contract.

Recap and best practices

• Start with clean POJOs and JAX WS annotations to keep the contract readable
• Use Maven to manage CXF dependencies and plugin configuration
• Expose WSDL at runtime for dev and generate WSDL at build time for production
• Deploy to embedded server for dev and package a WAR for Tomcat when you need realism
• Log raw SOAP messages and watch classloader issues

Follow these steps and you will have a bottom up SOAP web service in Eclipse that is testable maintainable and slightly less likely to cause a page of blame in your team chat. You will also gain the smug satisfaction that comes from turning Java into interoperable XML and surviving to tell the tale.