You are viewing a plain text version of this content. The canonical link for it is here.
Posted to sandesha-dev@ws.apache.org by Gilbert Pilz <Gi...@bea.com> on 2007/03/08 02:02:48 UTC
Sandesha1 / WebLogic Server 9.* interop problem
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.
Re: Sandesha1 / WebLogic Server 9.* interop problem
Posted by Paul Fremantle <pz...@gmail.com>.
Seems like a reasonable change. Can you please raise a JIRA and attach a patch?
Paul
On 3/8/07, Gilbert Pilz <Gi...@bea.com> wrote:
> 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.
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: Sandesha1 / WebLogic Server 9.* interop problem
Posted by Paul Fremantle <pz...@gmail.com>.
Seems like a reasonable change. Can you please raise a JIRA and attach a patch?
Paul
On 3/8/07, Gilbert Pilz <Gi...@bea.com> wrote:
> 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.
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org