|
These remarks are based on the source code for
the nightly build of WSIF on 23 Feb. 2004. A number of deficiencies are
noted:
1.
org.apache.wsif.providers.soap.apacheaxis.WSIFOperation_ApacheAxis exposes a
number of accessors to the details of the SOAP binding for the WSDL operation,
such as getInputEncodingStyle, getSOAPActionURI, getOutputUse,
getOperationStyle. Unfortunately, these
methods return incorrect results until after the operation has been invoked,
since too little initialization goes on in the constructor of
WSIFOperation_ApacheAxis. The member variables holding this information in
the instance of WSIFOperation_ApacheAxis are populated only in the method
prepare(Call) which is only called during the invocation of the operation.
The time-dependence of these results is not documented. Perhaps this is an
optimization that could be removed -- it would be better in a number of ways to
fill in the information as the instance is initialized.
2. Similarly, the Call object used by Axis
and produced by the WSIFPort_ApacheAxis object should be properly
initialized when created, rather than only at invocation time. If the user
tries to fix this by setting correct values in the Call object by querying the
WSIFOperation_ApacheAxis object, the wrong values might be inserted.
3. Furthermore, there is no guarantee that
the Call object retrieved before the invocation will be the same as the one used
during the invocation. The current code keeps a single Call object
associated with the WSIFPort_ApacheAxis, which will cause a failure if the same
port is used from multiple threads.
For example, if
wsifaxisport.getCall().registerTypeMapping is called, the mapping will be placed
in the registry for the default encoding style, which might then be set to a
different value when the operation is invoked. The result would be that no
serializers or deserializers (or the wrong ones) would be found.
I think the point of the optimization was to
allow both call and operation objects to be reused and properly set up when
the invocation occurs, but user code accessing these objects needs a way to
initialize them correctly before the operation is invoked. Some
suggested fixes:
a) split prepare() up into parts dependent and
independent of the operation parameter actuals, and allow public access to the
actuals-independent part. The user could then call this part immediately
after creating the WSIFOperation and retrieving its Call object.
b) abandon the optimization to reuse Call objects
or add methods to grab one for the duration of an invocation, including its
setup, and release it for reuse (the port would then presumably cache Call
objects not-in-use).
Jeff
|
