The known restrictions that apply when using WSIF include
restrictions on threading, on SOAP headers and unreferenced attachments,
and on data type mappings.
- Threading
- WSIF is not thread-safe.
- External Standards
- WSIF supports:
- SOAP Version 1.1 (not 1.2 or later).
- WSDL Version 1.1 (not 1.2 or later).
WSIF does not provide WS-I compliance, and it does not support
the Java API for XML-based Remote Procedure Calls
(JAX-RPC) Version 1.1 (or later).
- Full schema parsing
- WSIF does not support full schema parsing. For example, Web Services
Description Language (WSDL) references in complex types in the schema
are not handled, and attributes are not handled.
- XML Schema "redefine" elements are not handled and are ignored.
- SOAP
- WSIF does not support:
- SOAP provider interoperability
- The current WSIF default SOAP provider (the IBM® Web
Service SOAP provider) does not fully interoperate with services that
are running on the former (Apache SOAP) provider. This is because
the IBM Web Service SOAP provider is designed to
interoperate fully with a JAX-RPC compliant web service, and Apache
SOAP cannot provide such a service. For information on how to overcome
this restriction, see WSIF SOAP provider: working with existing applications.
- WSIF support for SOAP faults is restricted to SOAP faults originating
from a web service that uses the IBM Web
Service SOAP provider.
Note: This is not primarily a WSIF restriction.
The current SOAP faults specification does not prescribe how to encode
a SOAP fault so that it maps to a Java exception.
Consequently, each web service runtime environment currently chooses
its own SOAP fault format. The IBM Web
Service SOAP provider can understand its own response SOAP faults,
but not the SOAP faults from another provider.
- Data type mappings
- The current WSIF default SOAP provider (the IBM Web
Service SOAP provider) conforms to the JAX-RPC type mapping rules
that were finalized after the former (Apache SOAP) provider was created.
The majority of data types are mapped the same way by both providers.
The exceptions are: xsd:date, xsd:dateTime, xsd:hexBinary and xsd:QName.
Both client and service must use the same mapping rules if any of
these four data types are used. Below is a table detailing the mapping
rules for these four data types:
Table 1. Mapping
rules for the four data types that are mapped differently by Apache
SOAP and JAX-RPC. Column 1 specifies the XML data type,
column 2 specifies the equivalent data type for Apache SOAP, and column
3 specifies the equivalent data type for JAX-RPC.
XML Data Type |
Apache SOAP Java Mapping |
JAX-RPC Java Mapping |
xsd:date |
java.util.Date |
Not supported |
xsd:dateTime |
Not supported |
java.util.Calendar |
xsd:hexBinary |
Hexadecimal string |
byte [ ] |
xsd:QName |
org.apache.soap.util.xml.QName |
javax.xml.namespace.QName |
- Arrays and complex types
- WSIF does not support general complex types, it only handles complex
types that map to Java Beans. To use schema complex
types, you must write your own custom serializers. The specific complex
type and array support for WSIF outbound invocation of web services
is as follows:
- WSIF supports Java classes generated by WebSphere® Studio Application Developer
- Integration Edition (WSAD-IE) message generators (the usual case
when WSDL files are downloaded from somewhere else). The WSAD-IE-based
generation happens automatically when you use the BPEL editor, or
the generation actions available on the Enterprise Services context
menu, or the Business Integration toolbar.
- WSIF does not support Java beans
generated by other tools, including the base WSAD tool.
- For WSAD-IE generated Java beans,
attributes defined in the WSDL do not work. That is to say that these
attributes, although they appear in the Java beans
generated to represent the complex type, do not appear in the SOAP
request created by WSIF.
- WSIF does not support arrays when they are a field of a Java bean. That is to say, WSIF only supports
an array that is passed in as a named <part>.
If an array is wrappered inside a Java bean,
the array is not serialized in the same way.
- Object Serialization
- WSIF does not support serialization of objects across different
releases.
- Asynchronous invocation
- WSIF supports synchronous invocation for all providers. For the
JMS and the SOAP over JMS providers, WSIF also supports asynchronous
invocation. You should call the supportsAsync() method
before trying to execute an asynchronous operation.
- The EJB provider
- The target service of the WSIF EJB provider must be a remote-home
interface, it cannot be an EJB local-home interface. In addition,
the EJB stub classes must be available on the client class path.
- Running outside WebSphere Application Server
- WSIF is not supported for use outside WebSphere Application
Server.