There's a interoperability problem between Sandesha1 and WebLogic Server (WLS) 9.*. WLS has a policy that relates to the way it scopes WS-RM sequences. Given a WSDL that looks like this:
<definitions . . .>
...
<portType name="RMSampleService">
<operation name="echoString" parameterOrder="text sequence">
<input message="tns:echoStringRequest" name="echoStringRequest"/>
<output message="tns:echoStringResponse" name="echoStringResponse"/>
</operation>
<operation name="ping" parameterOrder="text">
<input message="tns:pingRequest" name="pingRequest"/>
</operation>
</portType>
...
<binding . . .>
...
</binding>
...
<service name="RMSampleServiceService">
<port binding="tns:RMSampleServiceSoapBinding" name="RMSampleService">
<soap:address location="..."/>
</port>
</service>
</definitions>
WLS requires that any CreateSequence sent to the 'RMSampleService' port must
contain an Offer for a response sequence. The reason for this is that WLS
considers the sequence to apply to all the operations that can be invoked via
that port. Since 'echoString' is a valid operation for the 'RMSampleService'
port, and 'echoString' has an output message, WLS needs a sequence that it can
use to carry any 'echoStringResponse' messages. Note that this is true even if
the SOAP client intends to only invoke the 'ping' operation; at the time the
CreateSequence message is sent, WLS has no way of knowing that the client will
only send 'pingRequest' messages.
For some types of operations ('ping' in this example) it is impossible to
comply with this policy if you are using a Sandesha1 client. Even if the
client invokes SandeshaContext.setSendOffer(true), an Offer will not be sent.
The reason for this is the code at line 145 in
org.apache.sandesha.client.RMSender.java:
if (reqRMMsgContext.isHasResponse() && reqRMMsgContext.isSendOffer()) {
I propose that this line be changed to simply:
if (reqRMMsgContext.isSendOffer()) {
I think Sandesha is getting in the way when it overrides the programmer's
wishes (as indicated by the SandeshaContext.setSendOffer() method) and decides
not to send the Offer because it "knows better". The dangers of creating an
unused response sequence certainly do not seem grave enough to warrant
limiting the programmer's ability to offer response sequences when necessary.
Gilbert Pilz
Sr. Principal Technologist
Office of the CTO
BEA Systems, Inc.
smime.p7s
Description: S/MIME cryptographic signature
