Community hub
0 subscribers7 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Jakarta XML Web Services.
Nothing was collected or created yet.
Jakarta XML Web Services
View on Wikipediafrom Wikipedia
| Jakarta XML Web Services | |
|---|---|
| Other names | Java API for XML Web Services, JAX-WS |
| Original author | Sun Microsystems |
| Developer | Eclipse Foundation |
| Stable release | 2.3.3
/ February 19, 2020 |
| Repository | |
| Written in | Java |
| Operating system | Cross-platform |
| Platform | Java |
| Type | Application framework |
| License | EPL 2.0 or GPL v2 w/Classpath exception |
| Website | projects |
The Jakarta XML Web Services (JAX-WS; formerly Java API for XML Web Services) is a Jakarta EE API for creating web services, particularly SOAP services. JAX-WS is one of the Java XML programming APIs.
Overview
[edit]The JAX-WS 2.2 specification JSR 224 defines a standard Java- to-WSDL mapping which determines how WSDL operations are bound to Java methods when a SOAP message invokes a WSDL operation. This Java-to-WSDL mapping determines which Java method gets invoked and how that SOAP message is mapped to the method’s parameters.
This mapping also determines how the method’s return value gets mapped to the SOAP response.
JAX-WS uses annotations, introduced in Java SE 5, to simplify the development and deployment of web service clients and endpoints. It is part of the Java Web Services Development Pack. JAX-WS can be used in Java SE starting with version 6.[1] As of Java SE 11, JAX-WS was removed. For details, see JEP 320.
JAX-WS 2.0 replaced the JAX-RPC API in Java Platform, Enterprise Edition 5 which leans more towards document style Web Services.
This API provides the core of Eclipse Metro.
JAX-WS also is one of the foundations of WSIT.
Standards Supported
[edit]- JAX-WS 2.0/2.1/2.2 (JSR 224)
- WS-I Basic Profile 1.2 and 2.0
- WS-I Attachments Profile 1.0
- WS-I Simple SOAP Binding Profile 1.0
- WS-Addressing 1.0 - Core, SOAP Binding, WSDL Binding
Main JWS Packages
[edit]| Package | Description |
|---|---|
| javax.xml.ws | Has the Core JAX-WS APIs |
| javax.xml.ws.http | Has APIs specific to XML/HTTP Binding |
| javax.xml.ws.soap | Has APIs specific to SOAP/HTTP Binding |
| javax.xml.ws.handler | Has APIs for message handlers |
| javax.xml.ws.spi | defines SPIs for JAX-WS |
| javax.xml.ws.spi.http | Provides HTTP SPI that is used for portable deployment of JAX-WS in containers |
| javax.xml.ws.wsaddressing | Has APIs related to WS-Addressing |
| javax.jws | Has APIs specific to Java to WSDL mapping annotations |
| javax.jws.soap | Has APIs for mapping the Web Service onto the SOAP protocol |
XML Web Services related Specs
[edit]| Java EE 7 | |||
| Specification | Version | Stds. Body | JSR/Url |
|---|---|---|---|
| JAX-WS | 2.3 | JCP | 224 |
| Web Services | 1.3 | JCP | 109 |
| WS Metadata | 2.1 | JCP | 181 |
| JAXB | 2.2 | JCP | 222 |
| SAAJ | 1.3 | JCP | 67 |
| SOAP | 1.2 | W3C | soap |
| XML | 1.1 | W3C | xml |
| WSDL | 1.1 | W3C | wsdl |
Jakarta Web Services Metadata
[edit]Jakarta Web Services Metadata (JWS; formerly Web Services Metadata for Java platform and Java Web Services), as a part of Jakarta XML Web Services (JAX-WS), is a Java programming language specification (JSR-181) primarily used to standardize the development of web service interfaces for the Jakarta EE platform. Version is 2.1 was released on December 15, 2009.[2]
Implementations
[edit]- Eclipse Metro in Eclipse Enterprise for Java (EE4J)
- Apache CXF
- Apache Axis2
- JBossWS in WildFly
- IBM WebSphere Jax-Ws in WebSphere
- Oracle Weblogic
References
[edit]External links
[edit]- Official website
- java.net project pages
- Documentation
- Tutorials
- JAX-WS Tutorials Archived 2015-01-28 at the Wayback Machine
Jakarta XML Web Services
View on Grokipediafrom Grokipedia
Jakarta XML Web Services (JAX-WS) is a standard API within the Jakarta EE platform for developing and consuming XML-based web services, particularly those using SOAP protocols.[1] It enables Java developers to create endpoints and clients that handle XML messaging, abstracting complexities such as SOAP envelope processing, WSDL mapping, and transport bindings.[2] The specification defines portable mechanisms for implementing services based on Jakarta SOAP with Attachments (SAAJ) and integrates Jakarta Web Services Metadata for annotation-driven development.[1]
Originally known as Java API for XML Web Services (JAX-WS), it evolved from earlier Java EE technologies like JAX-RPC, with JAX-WS 2.0 introduced in Java EE 5 via JSR 224 to simplify web service creation through annotations and dynamic proxies.[3] Following Oracle's donation of Java EE to the Eclipse Foundation in 2017, JAX-WS transitioned to the Jakarta EE namespace, renaming packages from
javax.xml.ws to jakarta.xml.ws starting with version 3.0 in Jakarta EE 9 (2020).[4] The latest version, 4.0, was released as part of Jakarta EE 10 in 2022, requiring Java SE 11 or higher and incorporating updates like functional interface annotations and API extensions for endpoint references, though it was removed from the Jakarta EE platform requirements in Jakarta EE 11, released in 2025. It remains available as a standalone specification.[1][5]
Key features include support for both document/literal and RPC/encoded styles, asynchronous invocation via AsyncHandler, and tools for generating Java artifacts from WSDL documents using commands like wsimport and wsgen.[3] It promotes interoperability with non-Java systems through standards compliance and allows deployment on Jakarta EE servers like Apache Tomcat or Eclipse GlassFish.[6] While RESTful services have gained popularity via Jakarta RESTful Web Services (JAX-RS), JAX-WS remains essential for enterprise scenarios requiring formal contracts and reliable messaging.[7]
History and Development
Origins and Evolution from JAX-WS
Jakarta XML Web Services traces its origins to the early standardization efforts for web services within the Java ecosystem under the Java Community Process (JCP). The foundational work began with JSR 109, titled "Implementing Enterprise Web Services," which was approved on October 14, 2002. This specification defined the programming model and runtime architecture for deploying web services clients and endpoints in the J2EE 1.4 platform, building on the earlier JAX-RPC 1.1 (JSR 101) for SOAP-based RPC interactions and leveraging J2EE components such as servlets, JSPs, and EJBs.[8] The specification evolved into the modern JAX-WS framework through JSR 224, which introduced Java API for XML-Based Web Services (JAX-WS) 2.0 as the successor to JAX-RPC. Approved on May 11, 2006, JAX-WS 2.0 provided enhanced support for contemporary standards, including WSDL 2.0 and SOAP 1.2, along with asynchronous invocation capabilities and non-HTTP transport options. It integrated seamlessly with Java EE 5, released on May 11, 2006, marking the initial official release of JAX-WS within the enterprise platform.[9][10] Subsequent maintenance releases further refined JAX-WS. JAX-WS 2.1, released in 2007, incorporated annotations from JSR 250 ("Common Annotations for the Java Platform"), finalized on April 17, 2006, to standardize resource injection and lifecycle management across Java EE components, reducing boilerplate code in web service development. JAX-WS 2.2, integrated into Java EE 6 on December 10, 2009, added client-side support for features like MTOM for optimized binary data handling and WS-Policy for declarative policy attachments, along with full Web Services Addressing (WS-Addressing) compliance, enhancing interoperability and security. Although JSR 261 for JAX-WSA was proposed in 2005 and withdrawn in December 2006, its addressing concepts were subsumed into JAX-WS 2.2 under JSR 224 maintenance.[11][12][13][14][15] The evolution of JAX-WS culminated in a major transition when Oracle announced on August 23, 2017, its donation of Java EE—including JAX-WS—to the Eclipse Foundation, aiming to foster open-source governance, accelerate innovation, and expand community involvement for long-term platform stability. This handover laid the groundwork for rebranding JAX-WS as Jakarta XML Web Services, shifting from javax.* to jakarta.* namespaces while preserving the core API.[16]Transition to Eclipse Jakarta EE
In 2017, Oracle transferred stewardship of Java EE to the Eclipse Foundation, leading to its rebranding as Jakarta EE and initiating a community-driven evolution of its specifications.[17] As part of this handover, the Java API for XML-Based Web Services (JAX-WS) was transitioned into the Eclipse EE4J project ecosystem, with the Eclipse Project for JAX-WS officially created in June 2018 to manage its ongoing development under open governance.[18] This shift emphasized compatibility with existing Java EE applications while preparing for namespace updates, including requirements for backward migration tools to facilitate transitions from legacy deployments.[19] A pivotal change occurred with the release of Jakarta EE 9 in 2020, which mandated a namespace transition fromjavax.* to jakarta.* packages across all specifications to avoid trademark conflicts and enable independent evolution. Jakarta XML Web Services 3.0, released in November 2020, marked the first full specification under this new namespace, maintaining functional parity with JAX-WS 2.3 while aligning with Jakarta SOAP with Attachments and Jakarta Web Services Metadata. The subsequent Jakarta XML Web Services 4.0, finalized in February 2022, introduced enhancements such as the @FunctionalInterface annotation on AsyncHandler for better support of asynchronous operations and expanded WS-Addressing capabilities, including new APIs for enabling/disabling addressing features on endpoints and clients via annotations like @Addressing.[1] These updates also incorporated binding declarations like jaxws:enableAsyncMapping to generate async polling and callback methods from WSDL definitions.[20]
As of 2025, Jakarta XML Web Services remains at version 4.0 (with minor service releases like 4.0.2 in May 2024), fully aligned with Jakarta EE 10 (released in 2022) and Jakarta EE 11 (released in June 2025).[1] No major breaking changes have been introduced post-4.0, preserving backward compatibility through tools such as the Eclipse Transformer for JAR files and OpenRewrite for source code refactoring.[21] The focus has shifted toward modularization efforts in Jakarta EE 11, optimizing the specification for modern Java platforms like Java SE 21 while supporting cloud-native deployments without altering core XML web services functionality.[22]
Overview and Purpose
Core Functionality
Jakarta XML Web Services (JAX-WS) is a Java API specification for implementing XML-based web services, primarily focused on SOAP-based interactions, that enables developers to create and consume web service endpoints and clients through standardized mappings between WSDL documents and Java code.[23] It builds on foundational technologies like WSDL 1.1 for service descriptions, providing a framework to define operations, bind data, and exchange messages in a platform-independent manner.[23] This API assumes familiarity with XML structures and basic web service concepts, such as service endpoint interfaces (SEI), which serve as the contract for service operations.[23] At its core, JAX-WS facilitates service publication through the Endpoint API, allowing a Java class implementing an SEI to be exposed as a web service endpoint at a specified URL, such as by invokingEndpoint.publish("http://example.com/service", serviceInstance).[23] For client-side consumption, it supports invocation via the Dispatch API for low-level message handling or through generated proxy classes derived from WSDL, enabling seamless calls to remote services as if they were local methods.[23] SOAP message processing is integral, including support for attachments through mechanisms like MTOM (Message Transmission Optimization Mechanism) and XOP (XML-binary Optimized Packaging), which optimize the transmission of binary data within XML envelopes.[23]
The specification accommodates both synchronous and asynchronous operations, where synchronous calls block until a response is received, and asynchronous ones return immediately with callbacks or futures for later handling, configurable based on service requirements. The AsyncHandler interface is annotated with @FunctionalInterface in version 4.0.[23] It supports various message passing styles, including RPC (Remote Procedure Call) for operation-oriented invocations, document/literal for schema-based XML documents, and document/wrapped for a hybrid approach that wraps parameters in elements.[23] Exception handling is managed through SOAPFault representations, which map WSDL-defined faults to Java exceptions, ensuring robust error propagation in both service and client contexts.[23] These features collectively enable reliable, interoperable web services within broader Jakarta EE environments up to version 10.[1]
Role in Jakarta EE Ecosystem
Jakarta XML Web Services (JAX-WS) served as a core specification within the Jakarta EE platform up to version 10 for developing and deploying SOAP-based web services, positioning it alongside Jakarta RESTful Web Services (JAX-RS) to address diverse integration needs in enterprise environments.[23] While JAX-RS supports lightweight RESTful APIs, JAX-WS enables structured, standards-compliant SOAP messaging for scenarios requiring enhanced reliability, security, and interoperability, such as in regulated industries or cross-platform B2B exchanges.[24] This duality allows developers to select SOAP for formal contract-driven interactions via WSDL or REST for resource-oriented designs, ensuring flexibility in modern application architectures.[25] The specification depends on Jakarta SOAP with Attachments (SAAJ) for low-level SOAP message creation, manipulation, and attachment handling, which forms the foundation for request-response exchanges.[23] It also relies on Jakarta Web Services Metadata for declarative annotations that map Java interfaces to WSDL contracts, simplifying endpoint configuration without manual XML editing.[26] Within the ecosystem, JAX-WS integrates with Contexts and Dependency Injection (CDI) to enable injectable resources in web service endpoints, such as injecting EntityManager instances from Jakarta Persistence (JPA) for database operations during service invocation.[25] This allows seamless incorporation into broader enterprise beans or servlet-based applications, leveraging Jakarta EE's container-managed lifecycle for transactions and security. Common use cases for JAX-WS include enterprise system integration where SOAP's built-in standards like WS-Security and WS-ReliableMessaging ensure compliant data exchange between heterogeneous systems.[24] It is particularly suited for B2B scenarios demanding interoperability with non-Java platforms adhering to WS-I profiles, as well as migrating legacy SOAP services to Jakarta EE without protocol changes.[27] In contrast to REST alternatives, JAX-WS excels in environments prioritizing formal governance and auditing over simplicity, such as financial services or supply chain management.[28] From Jakarta EE 9, JAX-WS supported modular deployment and was optional in profiles like the Web Profile while integral to the full platform up to EE 10. In Jakarta EE 11 (full release June 2025), it was removed entirely from the platform specifications alongside SAAJ and JAXB, streamlining the core platform but requiring external dependencies like the Metro implementation for continued use in SOAP-based services.[29] As of Jakarta EE 11 (released June 2025), JAX-WS is no longer included in the platform specifications, allowing developers to use it via standalone libraries like Metro for SOAP-based services.[30] This modularity from earlier versions and the subsequent removal align with the namespace migration fromjavax to jakarta, facilitating adoption in microservices or cloud-native setups without mandating the full stack.[23]
Standards and Specifications
Supported Web Service Standards
Jakarta XML Web Services (JAX-WS) primarily implements the SOAP messaging protocol in versions 1.1 and 1.2 to enable XML-based communication between web services and clients, with mandatory support for both versions to ensure broad interoperability.[23] SOAP 1.1 serves as the default in many configurations, while SOAP 1.2 support was explicitly added in later specifications, including HTTP bindings for each.[23] These protocols define the structure of messages, including envelopes, headers, and bodies, facilitating reliable data exchange over transport protocols like HTTP.[23] For service description, JAX-WS aligns with WSDL 1.1, providing a complete standardized mapping that allows developers to generate WSDL documents from Java code or vice versa, ensuring precise interoperability in defining service operations, ports, and bindings.[23] Support for WSDL 2.0 is referenced in metadata and partial contexts but remains deferred for full implementation, with continued mandatory conformance to WSDL 1.1 as the core standard.[23] To promote compliance and cross-platform compatibility, JAX-WS requires adherence to the WS-I Basic Profile 1.1, which specifies interoperability rules for SOAP 1.1, WSDL 1.1, and related technologies, superseding earlier versions like 1.0.[23] The specification includes Java-to-WSDL bindings, where annotations such as @WebService automatically generate compliant WSDL descriptions from Java interfaces, incorporating customization options for operations and data types to maintain semantic fidelity.[23] Interoperability is further enhanced through support for WS-* policies, including WS-Security for message-level authentication and integrity via handler integration, and WS-ReliableMessaging for guaranteed delivery, both leveraging the WS-Policy 1.5 framework to declare and enforce policy assertions.[23][31] Handler chains provide a modular extension mechanism for protocol processing, allowing insertion of custom logic for headers, security, or transformations without altering core message flows.[23] Binary data handling is optimized via MTOM (SOAP Message Transmission Optimization Mechanism), which enables efficient attachment of large payloads as MIME parts rather than inline base64 encoding, configurable through the MTOMFeature or @MTOM annotation for both services and clients.[23] This feature integrates with underlying XML processing standards like SAAJ for attachment management, ensuring seamless support for optimized transmissions in SOAP envelopes.[23] Overall, these alignments, carried forward from JAX-WS 2.1 into Jakarta XML Web Services 4.0 (part of Jakarta EE 10, released 2022), emphasize robust, standards-compliant web services. However, as of Jakarta EE 11 (released June 2025), JAX-WS is no longer a required platform component and must be provided via external libraries for use in EE 11-compliant environments.[5]Related XML Specifications
Jakarta SOAP with Attachments (SAAJ), formerly known as SAAJ 1.3 under the Java EE specification, provides an API for creating, accessing, and manipulating SOAP messages in Java applications, including elements such as headers, bodies, and MIME attachments.[32] This API enables developers to produce and consume messages that conform to SOAP 1.1, SOAP 1.2, and the SOAP Messages with Attachments specification, facilitating low-level control over message structure without relying on higher-level web service frameworks.[33] SAAJ integrates directly with Jakarta XML Web Services by allowing theDispatch interface to handle raw SOAPMessage objects, supporting message-oriented communication modes for SOAP bindings.[34]
Jakarta Web Services Metadata (JWS), formerly JSR-181, introduces annotation-based metadata to define web services in Java, enabling the mapping of implementation classes to SOAP protocol bindings and decoupling service descriptions from deployment descriptors like web.xml.[35] Annotations such as @WebService and @WebMethod specify service endpoints, operations, and parameters, streamlining development by generating WSDL contracts automatically from annotated Java code.[26] This metadata model supports customization of WSDL-to-Java mappings and prioritizes application-provided annotations over runtime-generated ones.[34]
Beyond core components, Jakarta XML Web Services integrates with Jakarta XML Binding (JAXB) for XML schema-to-Java object mapping, where JAXB handles marshalling and unmarshalling of data types in web service payloads, ensuring seamless conversion between XML representations and Java instances.[34] For hybrid architectures, implementations like Apache CXF allow a single service class to expose both SOAP endpoints via JAX-WS and RESTful resources via Jakarta RESTful Web Services (JAX-RS), sharing data bindings and providers to support mixed-protocol applications.[36]
In terms of evolution, SAAJ version 3.0, with maintenance releases, was included as part of Jakarta EE 10 in 2022, incorporating namespace changes from javax.xml.soap to jakarta.xml.soap for alignment with the Eclipse Foundation's branding and improved compatibility with modern Java modules.[37] Similarly, Jakarta Web Services Metadata stabilized at version 3.0 in 2020 as part of Jakarta EE 9, refining annotation semantics and processing models to enhance portability across compliant runtimes.[35] As of Jakarta EE 11 (released June 2025), both SAAJ and JAXB are removed from the platform, requiring external provision for continued use, while JWS metadata support may depend on implementation choices.[5]
API Structure
As of version 4.0 (included in Jakarta EE 10, released 2022), which is the final version of the specification within the platform, the Jakarta XML Web Services API is organized around several core packages that provide the foundational elements for developing and consuming web services in Java. Note that Jakarta XML Web Services was removed from the Jakarta EE 11 platform (released June 2024), though the API remains available for standalone use.[29][1]Main Packages and Classes
The primary package,jakarta.xml.ws, contains the core APIs for defining, accessing, and managing web services, including client-side proxies and server-side endpoints.[38] This package serves as the entry point for most developers, encapsulating the runtime behavior and standard interfaces required for SOAP-based interactions.[39]
Key classes within jakarta.xml.ws include Service, which acts as a factory for creating proxies to web service ports and instances of Dispatch<T> for dynamic invocations.[40] The Endpoint class represents a web service endpoint and is used to publish services on a server, handling the binding and invocation of implementor objects.[41] WebServiceException functions as the base runtime exception, encompassing faults and errors encountered during service operations, such as communication failures or configuration issues.[42] Additionally, Dispatch<T> enables low-level, message-oriented access to endpoints without relying on generated proxies, supporting both synchronous and asynchronous invocations.[43]
The API's package structure includes subpackages that extend functionality for specific aspects of web services. The jakarta.xml.ws.spi package provides the service provider interface, allowing implementations to register and manage providers for runtime discovery. jakarta.xml.ws.handler defines the handler chain framework for intercepting and processing inbound and outbound messages. Subpackages such as jakarta.xml.ws.addressing support WS-Addressing for endpoint references and message routing, jakarta.xml.ws.binding handles protocol bindings like SOAP, and jakarta.xml.ws.soap provides SOAP-specific features including fault handling.
A related package, jakarta.xml.bind, is integral for data binding, as Jakarta XML Web Services delegates XML-to-Java mapping to it, ensuring consistent serialization and deserialization of service payloads.[39] In typical usage, developers create a Service instance using Service.create() with a WSDL location and service QName, then access ports via methods like getPort() to obtain proxies for endpoint interactions.[40] Annotations from the API can configure these elements declaratively, such as specifying bindings or features.[38]
Key Annotations and Metadata
Jakarta XML Web Services employs an annotation-based programming model to define web service endpoints, operations, and bindings declaratively within Java code, thereby simplifying the development process by embedding metadata directly into classes and methods. This approach, rooted in the Web Services Metadata specification, allows developers to specify service contracts without relying on external configuration files, enabling tools to generate necessary artifacts like WSDL documents automatically.[23][44] The primary annotations include@WebService, which marks a Java class or interface as a web service endpoint and configures attributes such as the target namespace, service name, and WSDL location. For instance, @WebService(targetNamespace = "http://example.com") defines the endpoint's namespace for WSDL generation. The @WebMethod annotation designates a method as a web service operation, allowing customization of the operation name and exclusion from the service if needed, with defaults using the method name. Parameter and return value mappings are handled by @WebParam and @WebResult, which specify names, modes (IN, OUT, INOUT), and whether they appear in SOAP headers; by default, parameters are IN mode without headers. The @SOAPBinding annotation controls the SOAP message format, including style (RPC or DOCUMENT), use (LITERAL or ENCODED), and parameter style (WRAPPED or BARE), defaulting to DOCUMENT/LITERAL/WRAPPED for compatibility with modern SOAP standards.[23][45][46]
Advanced annotations extend this model for specialized behaviors. The @HandlerChain annotation references an external XML file defining custom handler chains for message processing, such as logging or security, integrating logical and protocol handlers into the runtime pipeline. @BindingType selects the protocol binding, like SOAP 1.1 over HTTP (the default) or SOAP 1.2, influencing how the endpoint communicates and appears in generated WSDL. The @Oneway annotation marks asynchronous operations that do not return a response, requiring void return types, no Holder parameters, and no checked exceptions to ensure fire-and-forget semantics.[23][20]
These annotations serve as metadata that replaces traditional XML deployment descriptors, such as web.xml or jaxws.xml, by providing all necessary configuration in a portable, code-centric manner. Tools like wsgen process annotated classes to generate WSDL contracts and supporting artifacts at build or deployment time, supporting a "contracts-first" or "code-first" development paradigm without manual WSDL editing.[23][20]
The annotations were originally defined in JSR-181 and have been retained across Jakarta XML Web Services versions, with no new annotations introduced in version 4.0 (the final version). A key change occurred in version 3.0, shifting the package namespace from javax.* to jakarta.* (e.g., jakarta.jws.WebService) to align with the broader transition from Java EE to the Eclipse Foundation's Jakarta EE platform, ensuring compatibility while modernizing the ecosystem.[23][44]
Implementations and Tools
Reference Implementation
The reference implementation of Jakarta XML Web Services is the Metro project, maintained by the Eclipse Foundation as part of the Eclipse EE4J top-level project. Originally developed as the JAX-WS Reference Implementation (RI) under Oracle (formerly Sun Microsystems), Metro has evolved into a modular web services stack that provides runtime support, development tools, and example applications for implementing XML-based web services in the Jakarta EE ecosystem.[47][48] Metro's versioning aligns with Jakarta XML Web Services specification releases: the 3.x series (e.g., 3.0.0 released November 2020, 3.0.2 in May 2021) implements Jakarta XML Web Services 3.0, supporting the namespace migration tojakarta.* packages for Jakarta EE 9 compatibility. The 4.x series (e.g., 4.0.0 released October 2023, with minor updates like 4.0.3 as of November 2025) delivers Jakarta XML Web Services 4.0 for Jakarta EE 10, incorporating enhancements for better integration with modern Java features. As of November 2025, Metro 4.x provides full compatibility with Jakarta EE 11, integrated within reference runtimes like Eclipse GlassFish 8.0, released in 2025.[49][1][50]
Core components of Metro encompass the JAX-WS runtime engine, which handles service endpoint invocation and message dispatching; a SAAJ (SOAP with Attachments API for Java) implementation for manipulating SOAP messages and attachments; and WSIT (Web Services Interoperability Technologies) for enabling advanced WS-* protocol support, including security (WS-Security), reliable messaging (WS-ReliableMessaging), and policy-driven configurations. The distribution also bundles essential tools such as wsgen for generating web service artifacts (e.g., WSDL and server-side stubs) from annotated Java classes, and wsimport for consuming WSDL documents to produce client-side proxies and supporting classes, along with comprehensive sample applications demonstrating common usage scenarios.[6][47]
Metro is distributed under the Eclipse Distribution License v1.0 (EDL 1.0), a BSD-style permissive license that facilitates broad adoption and integration. Developers can obtain the implementation artifacts, including the core API, through Maven Central Repository using group ID jakarta.xml.ws and artifact ID jakarta.xml.ws-api (or related runtime bundles like jaxws-ri), enabling straightforward dependency management in build tools.[48][47][51]