Building a Java EE Application with JAX-WS SOAP Web Services

SOAP remains useful when Java applications must exchange strongly typed, contract-driven messages with established enterprise systems. A Java EE application using JAX-WS can expose operations through a WSDL document, validate XML payloads and integrate with clients written in Java, .NET or other languages.

This approach suits Australian organisations connecting newer services to banking, logistics, government or healthcare platforms that still depend on SOAP. The example below uses NetBeans and GlassFish, although the same design principles apply to other Java EE-compatible servers.

Choosing the project structure and tools

Create a Maven Web Application in NetBeans and select a Java EE version supported by the target GlassFish installation. Java EE 7 or 8 is a practical choice for legacy JAX-WS deployments, while newer Jakarta EE projects use changed package names such as jakarta.xml.ws. Confirm the server and JDK combination before writing code, because namespace mismatches can prevent deployment.

The NetBeans IDE provides project templates, code completion, server registration and deployment controls in one workspace. Keep the application separated into service, domain and persistence layers. The web service should translate transport-level requests into business operations rather than containing database queries and complex rules itself.

For a sample application, imagine a parcel-rating service used by a Melbourne retailer. A client submits an account number, destination postcode and package details, and the service returns a quoted delivery price. A clear domain model makes the SOAP contract easier to understand and test.

Defining the SOAP endpoint

A JAX-WS endpoint is usually a public class annotated with @WebService. Its operations should accept simple, stable data transfer objects rather than exposing internal entity classes. For example:

@WebService
public class ParcelRateService {

    @WebMethod
    public RateQuote calculateRate(ParcelRequest request) {
        return new RateQuote("EXPRESS", 18.50, "AUD");
    }
}

The request and response classes can use JAXB annotations to control XML names and structure. @XmlType, @XmlElement and @XmlAccessorType help create predictable documents, while validation in the service layer ensures that a missing postcode or negative parcel weight produces a controlled SOAP fault.

Avoid exposing overloaded methods or Java-specific types such as HashMap in the public contract. Use explicit fields, enumerations and collections where appropriate. Australian postcodes should be represented as strings, since leading zeroes matter for some regions, and currency should be expressed clearly as Australian dollars rather than inferred from a number.

Publishing and testing the service

With the endpoint class inside the web module, deploy the application to GlassFish. Depending on the server configuration, the WSDL will be available at an address similar to:

http://localhost:8080/ParcelService/ParcelRateService?wsdl

The WSDL describes operations, message types, bindings and the service address. Treat it as a public contract: changing an element name or making a required field optional can affect every consuming system. In a production environment, place the endpoint behind a suitable reverse proxy and use HTTPS rather than exposing a development URL directly.

A service can be tested with SoapUI or a generated Java client. Check successful requests, malformed XML, missing fields, SOAP faults and unusually large values. If the application later needs reliable asynchronous processing, a JMS queue can complement the synchronous endpoint; a JMS queue tutorial demonstrates the related NetBeans and GlassFish workflow.

Generating and consuming a client

A Java consumer can generate proxy classes from the WSDL with wsimport, or through the IDE’s web-service client wizard. The generated Service class provides access to a port interface, allowing application code to invoke the remote operation as though it were a local method.

URL wsdl = new URL(
    "https://services.example.com/ParcelService/ParcelRateService?wsdl"
);
ParcelRateService service = new ParcelRateService(wsdl);
ParcelRatePortType port = service.getParcelRatePort();

RateQuote quote = port.calculateRate(request);

Do not hard-code the endpoint in business logic. Configure the address through deployment properties, environment variables or a service registry so that development, staging and production can use different URLs. Set connection and request timeouts, log correlation identifiers and handle SOAPFaultException without exposing internal stack traces to callers.

For systems used across Sydney, Perth and regional areas, network latency and intermittent links should be included in testing. A client that works on a local network may need retries or a queue when connecting over commercial broadband or an NBN service with variable conditions.

Securing the application for production

Transport security through HTTPS protects messages in transit, but it does not authenticate every caller by itself. Depending on the integration agreement, use mutual TLS, HTTP authentication or WS-Security with signed and encrypted SOAP headers. Store credentials in server-managed secrets rather than source control, and apply least-privilege permissions to database and messaging resources.

Australian deployments should account for the Privacy Act 1988 and the Notifiable Data Breaches scheme when SOAP messages contain names, addresses, health information or payment-related data. Minimise sensitive fields, restrict XML logs and define retention periods. XML parsers must also reject external entity resolution and unsafe document expansion to reduce XXE and denial-of-service risks.

Monitor response times, fault rates and endpoint availability, then document the WSDL version used by each consumer. A small interface catalogue prevents teams from silently depending on an obsolete contract and makes support easier when a client is maintained by a separate supplier.

Practical checks before deployment

A reliable implementation benefits from a short review before the first production release.

  • Confirm that the JAX-WS API, JDK and GlassFish versions are compatible.
  • Keep WSDL contracts stable and version breaking changes explicitly.
  • Generate client proxies from the deployed contract, not from an outdated local file.
  • Validate request fields and return meaningful, standards-compliant SOAP faults.
  • Configure HTTPS, authentication, timeouts and secret storage outside application source code.
  • Test XML security, large payloads, retries and concurrent requests.
  • Remove sensitive values from logs and record enough metadata for Australian privacy compliance.

NetBeans can also support surrounding development tasks, from JavaDoc generation to interface prototyping; its custom palette guide is useful when building desktop administration tools for service operators. With a stable contract, disciplined security controls and repeatable deployment, JAX-WS remains a practical bridge between modern Java EE applications and long-lived enterprise systems.