You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wsif-user@ws.apache.org by Mi Zhang <mi...@thedistillery.com.au> on 2005/01/17 00:42:41 UTC
[SPAM] WSIF - Known restrictions
Hi,
I found the following know restrictions about WSIF from IBM's
website(http://publib.boulder.ibm.com/infocenter/ws51help/index.jsp?topi
c=/com.ibm.websphere.nd.doc/info/ae/ae/rwsf_restrict.html). Can anyone
tell me if these restrictions still exist for the nightly build?
WSIF - Known restrictions
This topic lists the main known restrictions that apply when using WSIF.
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, WSDL references
in complex types in the schema are not handled, and attributes are not
handled.
SOAP
WSIF does not support:
* SOAP headers that are passed as <parts>.
* Unreferenced attachments in SOAP responses.
* Document Encoded style SOAP messages.
Note: This is not primarily a WSIF restriction. Although you can
specify Document Encoded style in WSDL, it is not generally considered
to be a valid option and is not supported by the Web Services
Interoperability Organization <http://www.ws-i.org/> (WS-I).
SOAP client invocations
The following restrictions apply to the use of WSIF SOAP client
invocations and the Web Services Gateway which makes use of these:
* The mixing of WSIF SOAP client invocations with J2EE Web Service
client invocations in the same client environment is not supported.
* The use of WSIF SOAP client invocations local to a WebSphere
Application Server can cause problems in J2EE Web Services deployed on
the same Application Server.
* The use of a Web Services Gateway deployed on a WebSphere
Application Server can cause problems inn J2EE Web Services deployed on
the same Application Server.
An attempt to invoke a J2EE over JMS web service after any WSIF SOAP
over HTTP or SOAP over JMS client invocation will return the following
error and the request will not be sent:
TRAS0014I: The following exception was logged
java.lang.NullPointerException at
com.ibm.ws.webservices.wsif.providers.soap.WSIFJmsSender._invoke(WSIFJms
Sender.java:126)
Any WSIF SOAP over HTTP or SOAP over JMS client invocation (including
implicit WSIF client invocation via the Web Services Gateway) can cause
various problems relating to Security, Internationalization, Request
Metrics, Performance Monitoring and Transactions in J2EE Web Services
deployed on the same Application Server.
SOAP provider interoperability [Version 5.1 and later]
<http://publib.boulder.ibm.com/infocenter/ws51help/topic/com.ibm.websphe
re.nd.doc/info/v51x.gif> [Version 5.1.1 and later]
<http://publib.boulder.ibm.com/infocenter/ws51help/topic/com.ibm.websphe
re.nd.doc/info/v511x.gif>
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 restriction is due to the fact
that 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
<http://publib.boulder.ibm.com/infocenter/ws51help/topic/com.ibm.websphe
re.nd.doc/info/ae/ae/twsf_soap_io.html> SOAP provider: working with
legacy applications
Type mappings [Version 5.1 and later]
<http://publib.boulder.ibm.com/infocenter/ws51help/topic/com.ibm.websphe
re.nd.doc/info/v51x.gif> [Version 5.1.1 and later]
<http://publib.boulder.ibm.com/infocenter/ws51help/topic/com.ibm.websphe
re.nd.doc/info/v511x.gif>
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
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 need to use the same mapping rules if any of these four types
are used. Below is a table detailing the mapping rules for these four
types:
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 normal 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
Thanks,
Mi
<http://publib.boulder.ibm.com/infocenter/ws51help/topic/com.ibm.websphe
re.nd.doc/info/ae/ae/rwsf_synctimeouts.html>
Re: [SPAM] WSIF - Known restrictions
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
i think this list more or less reflect WSIF2 status - changes in CVS
were mostly for compatibility with current AXIS2, better error messages
and other minor fixes.
i am also working on prototype of next gen WSIF called SDI ("Super"
Dynamic Invoker) to alleviate some of limitations in particular much
more flexible handling of complex types and other minor improvements
(like support for SOAP 1.2)
HTH,
alek
Mi Zhang wrote:
> Hi,
>
> I found the following know restrictions about WSIF from IBM's
> website(http://publib.boulder.ibm.com/infocenter/ws51help/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/rwsf_restrict.html).
> Can anyone tell me if these restrictions still exist for the nightly
> build?
>
>
> WSIF - Known restrictions
>
> This topic lists the main known restrictions that apply when using WSIF.
>
> *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, WSDL
> references in complex types in the schema are not handled, and
> attributes are not handled.
> *SOAP*
> WSIF does not support:
>
> * SOAP headers that are passed as <parts>.
> * Unreferenced attachments in SOAP responses.
> * Document Encoded style SOAP messages.
>
> *Note: *This is not primarily a WSIF restriction. Although
> you can specify Document Encoded style in WSDL, it is not
> generally considered to be a valid option and is not
> supported by the Web Services Interoperability Organization
> (WS-I) <http://www.ws-i.org/>.
>
> *SOAP client invocations*
> The following restrictions apply to the use of WSIF SOAP client
> invocations and the Web Services Gateway which makes use of these:
>
> * The mixing of WSIF SOAP client invocations with J2EE Web
> Service client invocations in the same client environment is
> not supported.
> * The use of WSIF SOAP client invocations local to a WebSphere
> Application Server can cause problems in J2EE Web Services
> deployed on the same Application Server.
> * The use of a Web Services Gateway deployed on a WebSphere
> Application Server can cause problems inn J2EE Web Services
> deployed on the same Application Server.
>
> An attempt to invoke a J2EE over JMS web service after any WSIF
> SOAP over HTTP or SOAP over JMS client invocation will return the
> following error and the request will not be sent:
>
>TRAS0014I: The following exception was logged java.lang.NullPointerException at com.ibm.ws.webservices.wsif.providers.soap.WSIFJmsSender._invoke(WSIFJmsSender.java:126)
>
> Any WSIF SOAP over HTTP or SOAP over JMS client invocation
> (including implicit WSIF client invocation via the Web Services
> Gateway) can cause various problems relating to Security,
> Internationalization, Request Metrics, Performance Monitoring and
> Transactions in J2EE Web Services deployed on the same Application
> Server.
> *SOAP provider interoperability*[Version 5.1 and later][Version 5.1.1
> and later]
> 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 restriction is
> due to the fact that 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
> legacy applications
> <http://publib.boulder.ibm.com/infocenter/ws51help/topic/com.ibm.websphere.nd.doc/info/ae/ae/twsf_soap_io.html>
> *Type mappings*[Version 5.1 and later][Version 5.1.1 and later]
> 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 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 need to use the same mapping
> rules if any of these four types are used. Below is a table
> detailing the mapping rules for these four types:
> 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 normal 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
>
> Thanks,
>
> Mi
--
The best way to predict the future is to invent it - Alan Kay