Yes, it is bit restricting. We will correct this soon.
Thanks, -Jaliya ----- Original Message ----- From: "Gilbert Pilz" <[EMAIL PROTECTED]> To: "Jaliya Ekanayake" <[EMAIL PROTECTED]> Sent: Thursday, March 08, 2007 3:49 PM Subject: FW: Sandesha1 / WebLogic Server 9.* interop problem > Jaliya, > > Any thoughts on this? > > - gp > >> -----Original Message----- >> From: Gilbert Pilz >> Sent: Wednesday, March 07, 2007 5:03 PM >> To: [email protected] >> Cc: Mitch Upton >> Subject: 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. >> >
