Web services are self-contained, self-describing, modular applications that you can publish, locate, and invoke across the Web. The functions provided by Web services can range from simple requests to complex business processes. A group of Web services interacting together defines a particular Web service application in a Service-Oriented Architecture (SOA). For more information, see developerWorks WebSphere Web Services zone.
Question: I am using WebSphere® Studio Application Developer 5.1.1 and SOAP/JMS for a Web service project. I understand JMS and HTTP routers and their enablement. I also understand how Servlet and MDB are defined in respected deployment descriptor. What I expected was that WSAD will create a skeleton code for MDB, but I did not see it. I was expecting that I will customize MDB by modifying onMessage() method. So how do I use MDB?
The actual MDB used for routing is configured by the wizard into the EJB Router project. The MDB used is provided in the WebSphere webservices.jar file,
com.ibm.ws.webservices.engine.transport.jms.JMSListenerMDB, and is referred to by the name of WebServicesJMSRouter. If you look at the
ejb-jar.xml file of the EJB Router project, you see this configuration. You do not need to write any MDB code.
See WebSphere Studio Application Developer in Building a JMS Web Service using SOAP over JMS and WebSphere Studio on how to use SOAP/JMS in WebSphere Studio.
This JMS support is similar to the way a JavaBean SOAP/HTTP web service is handled. You do not see or change the router servlet. The receiving and routing of the message is part of the core Web services engine's function. It is meant to be transparent to the user.
Question: How can I get SOAP with Attachments to work for a .NET client calling a WebSphere Web Service?
Answer: Unfortunately, Microsoft® has chosen not to support SOAP with Attachments and will therefore not support the new WS-I Attachments Profile 1.0 which is currently a working draft. WebSphere, as part of its JAX-RPC support, has full support for SOAP with Attachments.
I do not know of any way to have .NET send a message compliant to SOAP with Attachments. An alternative is to include the Attachment (for example, binary data) as a base64 encoded byteArray in the body of the SOAP message. The size of the attachment content increases by more than 25% due to the base64 encoding. the base64 encoding. Unfortunately, this means introducing xsd types of xsd:base64Binary in the WSDL.
Question: How do I use the WebSphere Application Assembly Tool (AAT) to edit the webservices.xml file for deployment to WAS 5.0.2?
Answer: The AAT is being replaced by the new Application Server Toolkit (ASTK) which includes in it an Assembly Toolkit. The ASTK includes a version of Eclipse in the installation and the same editors and Eclipse plug-ins for the Web services deployment are shipped in WebSphere Studio Application Developer 5.1. When the WebSphere Information Center references using the Assembly Toolkit to edit Web services configuration, it is referring to the Assembly Toolkit in the ASTK, not the AAT.
For WebSphere Application Server 5.0.2, the ASTK is a separate download that you can find at WebSphere Application Server V5.0.2 Application Server Toolkit.
In WebSphere Application Server 5.1, installation images include the V5.1 ASTK. The V5.0.2 ASTK is not compatible with WebSphere Application Server 5.1.
Question: Using WAS 5.0.2, I have an EJB which is returning an Array of JavaBeans (TestObject). The WSDL fragment is below. The SOAP message being returned by the service running in WAS 5.0.2 incorrectly has the complexObject name as the outer element of the return. WAS 5.1 returns the correct message.
<element name="getTestObjectsResponse"> <complexType> <sequence> <element maxOccurs="unbounded" name="getTestObjectsReturn" type="tns2:TestObject"/> </sequence> </complexType> </element> ... <wsdl:message name="setTestValueResponse"> <wsdl:part element="intf:setTestValueResponse" name="parameters"/> </wsdl:message>
Calling the service running in WebSphere Studio 5.1, you receive the expected message with the correct outer element:
<soapenv:Body> <getTestObjectsResponse xmlns="http://test.com"> <getTestObjectsReturn xmlns:ns="http://test.com"> <ns:bigDecimal>9.999999</ns:bigDecimal>
Calling the service running in WebSphere Application Server 5.0.2, you receive an incorrect message that is using the complex object name instead of getTestObjectsReturn.
<soapenv:Body> <getTestObjectsResponse xmlns="http://test.com"> <ns:TestObject xmlns:ns9="http://test.com"> <ns:bigDecimal>9.999999</ns:bigDecimal>
Answer: This is a known problem that has been fixed in the WebSphere Application Server 5.0.2 fixpacks or by using the latest version, 5.1. The fixpacks are cumulative. Apply the latest fixpack 126.96.36.199, which you can download at WebSphere Application Server 5.0.2 Cumulative Fix 5.
Question: Does WebSphere 5.0.2 support the J2EE 1.4 Web Services standards?
Answer: WebSphere Application Server 5.0.2 and 5.1 support JAX-RPC/JSR101 1.0 and JSR109, which were early versions of Java™ standards for Web services targeted for inclusion in J2EE 1.4. The finalized version of J2EE 1.4 requires support for updated versions of JAX-RPC/JSR101 1.1 and JSR921 (update of JSR109) and also requires support for JAX-R. IBM will support J2EE 1.4 in WebSphere Application Server 6.0. You can download a technical preview of WebSphere Application Server Technology for Developers V6.
Question: What are the differences between the open source Apache Axis SOAP engine and the WebSphere SOAP engine?
Answer: IBM® contributed resources and code to the Apache Axis project and provided tooling support for Axis as a runtime in WebSphere Studio 5.1. You can run Axis within WebSphere Application Server as a client or server, but IBM does not support Axis as a production environment and does not provide support or fixes for Axis. The WebSphere SOAP Engine is fully supported for production with 7*24 support available.
Since Axis is open source, the source code is available and developers may contribute to the Axis code base. The WebSphere SOAP Engine source code is not available.
IBM contributed moving Apache Axis to use a set of standards based mappings and APIs (in addition to their proprietary APIs). Axis is a J2SE SOAP engine and supports the JAX-RPC/JSR101 standard. It does not require a J2EE container and does not provide support for the JSR109 standard. The WebSphere SOAP Engine 5.0.2 and later provides conformant support for JAX-RPC and JSR109. WebSphere Application Server 6.0 will bring specification version upgrades (JAX-RPC (101) 1.1, JSR 109 1.1, SAAJ 1.2 support). Axis 1.1 does not fully support WS-I Basic Profile 1.0 or the latest version of the Java Web Services standards, which WebSphere does support.
The WebSphere SOAP Engine has significant performance enhancements beyond Axis. Each release of WebSphere contains significant Web services performance improvements. For performance reasons, it is best to be running the latest supported version of WebSphere Application Server. The latest version is 5.1.
There are some proprietary, non-standard features in Axis that IBM does not support in the IBM SOAP Engine, such as additional types of handlers. The WebSphere supported APIs are based on the JAX-RPC and JSR109 standards with a few IBM extensions for features for which standards have not been established, such as the deployment descriptors for WS-Security and the endpoint address for JMS. There is added declarative support for WS-Security. There is support for SOAP over JMS that requires no changes to client code except setting of the endpoint address.
There are more subtle differences between Axis and WebSphere. WebSphere has threadsafe client stubs, AXIS intentionally chose not to make theirs threadsafe as a simpler, high performing option. WebSphere implements a stricter model for DII call objects; the Axis call object is forgiving and will make "guesses" for information not provided, such as the return type. In general, WebSphere is stricter in its interpretations of standards.There are inefficiencies in the Axis use of multiple copies of deserialized data and use of metadata/introspection for serialization/deserialization.
For more information, see the following:
- Axix Documentation site
- WebSphere Application Server V5.1 Trial Program
- WebSphere Application Server Technology for Developers V6 (technical preview)
Question: Is it possible to integrate JAX-RPC handler "seamlessly" into the WAS 5.02 framework?
Answer: Yes, JAX-RPC1.0 handlers are officially supported in WebSphere Application Server 5.0.2 and later. The following articles help you write JAX-RPC handlers:
Question: Which security standards or specifications are implemented in WebSphere Application Server 5.02 and 5.1?
Answer: WebSphere Application Server supports the following specifications:
- Web Services Security: SOAP Message Security Draft 13 (formerly Web Services Security Core Specification). Current support is based on the OASIS draft level specification.
- Web Services Security: Username Token Profile Draft 2
For more information, see Securing Web services based on WS-Security.
Question: If my Web service method throws custom Java exceptions, must I define specific faults in my WSDL file for a Web service deployed on WAS 5.0.2?
Answer: WebSphere and the JAX-RPC standard do not require explicitly defined custom faults in WSDL. The custom fault is mapped to a RemoteException instead of the custom exception, which would be a logical mapping of the custom fault. However, the industry best practice is to define custom faults in WSDL and that is my recommendation. For more information on faults, see:
- Exception handling with JAX-RPC.
- In WS-I Basic Profile, see section 4.7.14 Enumeration of Faults.
Question: Can I use XSLT in a JAX-RPC handler to transform my message to adapt to version changes in my WSDL interface in WebSphere 5.0.2?
Answer: Within a JAX-RPC handler, the user will get an SAAJ Message, which is a DOM-like structure to represent the message. This needs to be converted to a DOM first to allow it to be passed to a JAXP-based XSLT transformer to transform the message. Likewise, the inverse would have to be done on the way out (for example, transform the resulting DOM into an SAAJ structure to send out).
In 6.0, it becomes easier since SAAJ 1.2 extends the DOM APIs. Therefore, a user can create a DOMSource from the DOM element at the root of the tree.
Section 188.8.131.52 of JSR 109 specifies that "A Handler must not change the message in any way that would cause the previously executed authorization check to execute differently. A Handler.handleRequest() method must not change the operation name, number of parts in the message, or types of the message parts." Therefore, since WebSphere is compliant with JSR 109, it restricts what can be done in JAX-RPC handlers.
The JSR-109 restrictions are intended to preserve the contract between requestor and provider, so you cannot change the operation or the types of the operation's parameters. You can change the values and some of the nested types. The point is that the top-level XML constructs in the SOAP message are needed to determine how to dispatch to the service. You cannot change the dispatch behavior.
If you are using WebSphere Web Services Gateway, it is possible to deploy two sets of JAX-RPC handlers for each service, one set for the request inbound to Gateway, and one set for the outbound call out of Gateway. The JSR-109 restriction exists on the JAX-RPC handlers on the incoming server side. The JSR-109 restriction does not exist on the JAX-RPC handlers on the outgoing client side in WSGW or in any JAX-RPC client.
The author would like to thank Russ Butek, Greg Truty, and Andre Tost for their help in preparing this article.
- Redbook: Patterns: Service Oriented Architecture and Web Services
- Redbook: Using Web Services for Business Integration
- Redbook: WebSphere Version 5.1 Application Developer 5.1.1 Web Services Handbook
- Redbook: WebSphere Web Services Information Roadmap
- Enterprise Java Programming with IBM WebSphere, Second Edition, Addison Wesley, 2004
- Web Services Architectures and Best Practices
- Performance Best Practices for Using WAS Web Services
- Web Services Education Overview
- Web Services Demos with WebSphere Studio
About Meet the Experts
Meet the Experts is a monthly feature on the developerWorks WebSphere Web site. We give you access to the best minds in IBM WebSphere, product experts and executives, who are waiting to answer your questions. You submit the questions, and we post answers to the most popular questions.
Dig deeper into WebSphere on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.