This topic presents frequently asked questions about the development and implementation of Web services.
The Application Server Toolkit 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 Version 1.2, 1.3 or 1.4 compliant deployment descriptors.
WebSphere Application Server Version 6.0.x and later are based on J2EE 1.4. For WebSphere Application Server Version 5.0.2 and Version 5.1.x, the Web Services for J2EE Version 1.0 specification is an addition to J2EE 1.3. The J2EE specification 1.4 requires support for Web Services for J2EE Version 1.1. Minor differences exist between the J2EE 1.3 Version (JSR-109 Version 1.0) and the J2EE 1.4 Version (JSR-109 Version 1.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 Version 6.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, you must 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.