This topic presents frequently asked questions about the development and implementation of Web services.
The WebSphere product has always extensively supported open source. From a Web services perspective, the WebSphere product contributes a large percentage of the JAX-RPC specification to the open source Apache Axis community. WebSphere Community Edition uses the Apache Axis runtime for its support for JAX-RPC 1.1. With the movement of Web services to a more messaging-centric asynchronous model, the Apache Axis community has created a new version of a Web services runtime that is based on the StAX architecture entitled Axis2.
Axis2 introduces its own proprietary programming and deployment model that is agnostic of any Java-based JCP standards. It did this primarily so that it could support multiple Java-based programming models, whether it JAX-WS, SCA (Apache Tuscany) and Groovy. While the feature pack introduces a standards-based JAX-WS programming model, it actually uses a version of Axis2 as part of its implementation. The feature pack users might see messages during tracing or within call stacks that reflect its Axis2 origins. The WebSphere product is supporting only the JAX-WS programming model and the deployment model that is documented in the information center. Any usage of native Axis2 APIs is not supported by the WebSphere product.
For an overview of the new specifications and features that Apache Axis2 supports in the Feature Pack for Web Services, see welc_newinreleasewsfp.html.
The Application Server Toolkit (AST) and Rational Application Developer assembly tools provide a graphical interface for developing code artifacts, assembling the code artifacts into various archives or modules, and configuring related J2EE V1.2, 1.3 or 1.4 compliant deployment descriptors.
WebSphere Application Server V6.0.x and later are based on J2EE 1.4. For WebSphere Application Server V5.0.2 and V5.1.x, the Web Services for J2EE V1.0 specification is an addition to J2EE 1.3. The J2EE specification 1.4 requires support for Web Services for J2EE V1.1. Minor differences exist between the J2EE 1.3 Version (JSR-109 V1.0) and the J2EE 1.4 V(JSR-109 V1.1).
Web Services for J2EE and WSIF represent two different programming models for accessing Web services. The Web Services for J2EE model is a standard and Java-centric model. This model is also more statically bound to Web Services Description Language (WSDL) documents because of the use of generated stubs. WSIF directly models WSDL. WSIF is more suitable when dynamically interpreting WSDL. WebSphere Application Server V6.0.x leverages both technologies to achieve dynamic, high performing standards-based Web services implementations.
The development and implementation of a Web service is based on the Web Services for J2EE specification in Version 6.0.x and later. You are encouraged to migrate from Apache SOAP because this approach is not recommended for future releases. For information about migrating your Apache SOAP Web services, see Migrating Apache SOAP Web services to Web Services for J2EE standards.
You can review the standards and specifications that are supported by WebSphere Application Server for the Web services runtime in Specifications and API documentation.
WebSphere Application Server supports Web services that are consistent with the WS-I Basic Profile, and should interoperate with any other vendor conforming to this specification.
The SOAP and JMS support uses message-driven beans (MDB) to implement the JMS endpoint. You can use MDBs in the Enterprise JavaBeans (EJB) container and delegate to an enterprise bean. If you want to use a JavaBeans implementation instead of an enterprise bean to implement the service endpoint, create a facade enterprise bean that delegates to the JavaBeans implementation.
No. Currently, no specification exists for SOAP and JMS invocations, therefore each vendor chooses an implementation technique.
Before a client issues a two-way request,
it creates a temporary JMS queue to receive the response. This temporary queue
is specified as the replyTo destination that is in the outgoing JMS request
message. After the server processes the request, it directs the response
to the replyTo destination specified in the request message. The client deletes
the temporary queue after the response is received. The server can handle
simultaneous requests from multiple clients because each incoming request
message contains the destination to which the reply is sent.