Use HTTP to transport web services requests for JAX-WS applications
We can develop an HTTP accessible JAX-WS web service when we have an existing JavaBeans object to enable as a web service.
We must have an annotated JAX-WS JavaBeans object to enable as a web service. Optionally, we can run the wsgen command to create a WSDL file from your annotated JAX-WS JavaBeans component. Specify the -wsdl option with the wsgen command to create the WSDL file.
For example:
app_server_root/bin wsgen.bat -classpath . -wsdl -servicename {http://mynamespace}MyService example.Stock.MyService
app_server_root/bin wsgen.sh -classpath . -wsdl -servicename {http://mynamespace}MyService example.Stock.MyService
(iseries)app_server_root/bin wsgen -classpath . -wsdl -servicename {http://mynamespace}MyService example.Stock.MyService
Supported configurations: The wsimport, wsgen, schemagen and xjc command-line tools are not supported on the z/OS platform. This functionality is provided by the assembly tools provided with WebSphere Application Server running on the z/OS platform. Read about these command-line tools for JAX-WS applications to learn more about these tools.
To learn about developing a JAX-WS web service using annotations, read about developing Java artifacts for JAX-WS applications using JavaBeans.
The application server supports the use of HTTP to transport web services client requests. With HTTP, the web services clients and servers can communicate through SOAP messages. SOAP is the underlying communication protocol used in web services that support the Web Services for Java EE and the JAX-WS specifications.
HTTP is the most commonly used transport for web services.
- Add an HTTP binding and a SOAP address to the WSDL file.
The WSDL file of a web service must include an HTTP binding and a SOAP address, which specifies an HTTP endpoint URL string, that is accessible on the HTTP transport. An HTTP binding is a wsdl:binding element containing a soap:binding element with a transport attribute that ends in soap/http.
In addition to the HTTP binding, a wsdl:port element that references the HTTP binding must be included in the wsdl:service element within the WSDL file. The wsdl:port element contains a soap:address element with a location attribute that specifies an HTTP endpoint URL string.
When you develop the web service, we can use a placeholder such as file:unspecified_location for the endpoint URL string.
If we deploy a JAX-WS JavaBeans component as a web service without a WSDL file, a WSDL file is automatically generated for the component.
- For JAX-WS web services applications, no HTTP transport configuration is needed. The HTTP transport settings are generated dynamically by the application server. The web application archive {WAR) file only needs the JavaBeans object along with the optional WSDL file properly installed.
- Deploy the web services application.
- Configure security for the HTTP transport.
To configure a secure HTTP transport, attach the SSLTransport policy to the application. To specify the basic authentication transport token, use the administration console to set the user ID and the password attributes in the HTTPTransport binding.
- Optional. Configure HTTP session management.
HTTP session management enables JAX-WS web service applications to appear dynamic to application users.
- Optional. Configure the asynchronous response listener for JAX-WS clients.
We can use the asynchronous response listener within the Thin Client for JAX-WS and application client environments to receive responses for requests that are invoked asynchronously.
- Configure the endpoint URL information for HTTP bindings.
The WSDL publisher uses this partial URL string to produce the actual HTTP URL for each port component defined in the EAR file. The published WSDL file can be used by clients, that need to invoke the web service.
Results
You have a JavaBeans object that uses HTTP to transport JAX-WS web services client requests.
What to do next
Publish the WSDL file.
Subtopics
- Deploy web services applications onto application servers
After assembling the artifacts required to enable the web module for web services into an EAR file, we can deploy the EAR file into the application server.
- Use a third-party JAX-WS web services engine
In certain situations we might need to set up a third-party JAX-WS web services engine. For example, set up a third-party JAX-WS web services engine if we need to deploy applications that use a single run time across various application servers such as WebSphere Application Server, JBoss, and WebLogic, or to build JAX-WS web services applications using third party JAX-WS run time such as CXF, Axis2, and Metro.
- Define and manage secure policy set bindings
- Use HTTP session management support for JAX-WS applications
HTTP session management is performed in the HTTP transport layer by using either cookies or URL rewriting. By providing multiple options for tracking a series of requests, HTTP session management enables JAX-WS applications to appear dynamic to application users.
- Invoking JAX-WS web services asynchronously using the HTTP transport
- Making deployed web services applications available to clients
We can publish WSDL files to the file system. If we are a client developer or a system administrator, we can use WSDL files to enable clients to connect to web services.
Related concepts
Web services transactions, high availability, firewalls and intermediary nodes
Related tasks
Use HTTP to transport web services Use the JAX-WS asynchronous response servlet Use the JAX-WS asynchronous response listener Use HTTP session management support for JAX-WS applications Configure the HTTP transport policy Configure the SSL transport policy Develop JAX-WS web services with annotations Generating Java artifacts for JAX-WS applications
wsgen command for JAX-WS applications