VW7.7.1 to WebSphere 8 web services communication issue
Locked
VW7.7.1 to WebSphere 8 web services communication issue
 
|
Hi,
We're upgrading our web services servers and have run into a bit of a problem communicating between WebSphere Application Server (V8) and VisualWorks 7.7.1. The issue appears to be the inclusion of some xmlns information in our userObject, which contains a userid, token and company. This is what we send from Smalltalk: client := self getMacroClient. request := (WebServices.Struct new) at: #userObject put: userObject; at: #name put: 'VRX2RX_REF_SLN_2'; at: #technology put: '10NMRequest'; at: #testsite put: 'Oslo1'; yourself. response := client executeSelector: #queryLibraryMacro args: (Array with: request). where #userObject is: Struct: {UserObject} {#user->'[hidden email]' #authenticationToken->'0dc66234780389b4a92679f10fff4d66' #company->'IBM'} This is the information that currently gets sent from Smalltalk to WebSphere (looking at the transportEntity in the client request variable): Version 1. <?xml version="1.0" encoding="UTF-8" standalone="no"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://srdctm.ibm.com/macro/"> <SOAP-ENV:Body> <ns:QueryLibraryMacroRequest> <userObject> <user xmlns="http://srdctm.ibm.com/common/">[hidden email]</user> <authenticationToken xmlns="http://srdctm.ibm.com/common/">0dc66234780389b4a92679f10fff4d66</authenticationToken> <company xmlns="http://srdctm.ibm.com/common/">IBM</company> </userObject> <name>VRX2RX_REF_SLN_2</name> <technology>10NMRequest</technology> <testsite>Oslo1</testsite> </ns:QueryLibraryMacroRequest> </SOAP-ENV:Body> </SOAP-ENV:Envelope> This does not work. Using SoapUI, I verified that Version 2, without the xmlns= phrase works fine: Version 2. <?xml version="1.0" encoding="UTF-8" standalone="no"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://srdctm.ibm.com/macro/"> <SOAP-ENV:Body> <ns:QueryLibraryMacroRequest> <userObject> <user>[hidden email]</user> <authenticationToken>0dc66234780389b4a92679f10fff4d66</authenticationToken> <company>IBM</company> </userObject> <name>VRX2RX_REF_SLN_2</name> <technology>10NMRequest</technology> <testsite>Oslo1</testsite> </ns:QueryLibraryMacroRequest> </SOAP-ENV:Body> </SOAP-ENV:Envelope> And actually, the SoapUI version (Version 3) that SoapUI derives from the wsdl file is: Version 3. <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mac="http://srdctm.ibm.com/macro/"> <soapenv:Header/> <soapenv:Body> <mac:QueryLibraryMacroRequest> <userObject> <user>[hidden email]</user> <authenticationToken>0dc66234780389b4a92679f10fff4d66</authenticationToken> <company>IBM</company> </userObject> <name>VRX2RX_REF_SLN_2</name> <technology>10NMRequest</technology> <testsite>Oslo1</testsite> </mac:QueryLibraryMacroRequest> </soapenv:Body> </soapenv:Envelope> This works too. I'm not familiar with the standards so don't know who is right or wrong, but obviously just need it to work. Our WebSphere programmers have tried removing the xmlns= coming from Smalltalk, but no success so far. We're now trying to remove the information sent on our end from Smalltalk. So the quesion is "How can I best remove the xmlns="http://srdctm.ibm.com/common/ phrase from aWsdlClient>>request>>transportEntity? I should also note that our old WebSphere server still works fine with this phrase included. I was told that the new websphere servers use jax-ws instead of jax-rpc, so that may be the difference. Thanks for any suggestions. Mark
|
Re: VW7.7.1 to WebSphere 8 web services communication issue
|
|
Mark,
usually, VisualWorks obeys the configuration whether to write elements qualified or unqualified. The <userObject> shows that #unqualified is in effect. The fact that the <user> element is denoted with its namespace means that the element seems to be in a different namespace (other than xmlns:ns="http://srdctm.ibm.com/macro/"). Please check your schema definitions. If these are fine, then you might need to check whether the XMLObjectBinding for the WSDL schema types have been created properly. You can find it in XMLObjectBinding.Registry. Inspecting the marshaler for the userObject and the contained RelationMarshalers should give you first insights. Regards Holger Guhl -- Senior Consultant * Certified Scrum Master * [hidden email] Tel: +49 231 9 75 99 21 * Fax: +49 231 9 75 99 20 Georg Heeg eK Dortmund Handelsregister: Amtsgericht Dortmund A 12812 Am 18.07.2013 17:31, schrieb Mark Petersen: Hi, _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: VW7.7.1 to WebSphere 8 web services communication issue
|
|
Holger, thanks for your suggestions. Indeed,
the userObject is in a different namespace, so it seems right. Is
there a way to force qualified or unqualified? I'll be checking on
that and interested to see what difference it produces.
Thanks,
Mark, usually, VisualWorks obeys the configuration whether to write elements qualified or unqualified. The <userObject> shows that #unqualified is in effect. The fact that the <user> element is denoted with its namespace means that the element seems to be in a different namespace (other than xmlns:ns="http://srdctm.ibm.com/macro/"). Please check your schema definitions. If these are fine, then you might need to check whether the XMLObjectBinding for the WSDL schema types have been created properly. You can find it in XMLObjectBinding.Registry. Inspecting the marshaler for the userObject and the contained RelationMarshalers should give you first insights. Regards Holger Guhl -- Senior Consultant * Certified Scrum Master * Holger.Guhl@... Tel: +49 231 9 75 99 21 * Fax: +49 231 9 75 99 20 Georg Heeg eK Dortmund Handelsregister: Amtsgericht Dortmund A 12812 Am 18.07.2013 17:31, schrieb Mark Petersen: Hi, We're upgrading our web services servers and have run into a bit of a problem communicating between WebSphere Application Server (V8) and VisualWorks 7.7.1. The issue appears to be the inclusion of some xmlns information in our userObject, which contains a userid, token and company. This is what we send from Smalltalk: client := self getMacroClient. request := (WebServices.Struct new) at: #userObject put: userObject; at: #name put: 'VRX2RX_REF_SLN_2'; at: #technology put: '10NMRequest'; at: #testsite put: 'Oslo1'; yourself. response := client executeSelector: #queryLibraryMacro args: (Array with: request). where #userObject is: Struct: {UserObject} {#user->'mpeterse@...' #authenticationToken->'0dc66234780389b4a92679f10fff4d66' #company->'IBM'} This is the information that currently gets sent from Smalltalk to WebSphere (looking at the transportEntity in the client request variable): Version 1. <?xml version="1.0" encoding="UTF-8" standalone="no"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://srdctm.ibm.com/macro/"> <SOAP-ENV:Body> <ns:QueryLibraryMacroRequest> <userObject> <user xmlns="http://srdctm.ibm.com/common/">mpeterse@...</user> <authenticationToken xmlns="http://srdctm.ibm.com/common/">0dc66234780389b4a92679f10fff4d66</authenticationToken> <company xmlns="http://srdctm.ibm.com/common/">IBM</company> </userObject> <name>VRX2RX_REF_SLN_2</name> <technology>10NMRequest</technology> <testsite>Oslo1</testsite> </ns:QueryLibraryMacroRequest> </SOAP-ENV:Body> </SOAP-ENV:Envelope> This does not work. Using SoapUI, I verified that Version 2, without the xmlns= phrase works fine: Version 2. <?xml version="1.0" encoding="UTF-8" standalone="no"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://srdctm.ibm.com/macro/"> <SOAP-ENV:Body> <ns:QueryLibraryMacroRequest> <userObject> <user>mpeterse@...</user> <authenticationToken>0dc66234780389b4a92679f10fff4d66</authenticationToken> <company>IBM</company> </userObject> <name>VRX2RX_REF_SLN_2</name> <technology>10NMRequest</technology> <testsite>Oslo1</testsite> </ns:QueryLibraryMacroRequest> </SOAP-ENV:Body> </SOAP-ENV:Envelope> And actually, the SoapUI version (Version 3) that SoapUI derives from the wsdl file is: Version 3. <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mac="http://srdctm.ibm.com/macro/"> <soapenv:Header/> <soapenv:Body> <mac:QueryLibraryMacroRequest> <userObject> <user>mpeterse@...</user> <authenticationToken>0dc66234780389b4a92679f10fff4d66</authenticationToken> <company>IBM</company> </userObject> <name>VRX2RX_REF_SLN_2</name> <technology>10NMRequest</technology> <testsite>Oslo1</testsite> </mac:QueryLibraryMacroRequest> </soapenv:Body> </soapenv:Envelope> This works too. I'm not familiar with the standards so don't know who is right or wrong, but obviously just need it to work. Our WebSphere programmers have tried removing the xmlns= coming from Smalltalk, but no success so far. We're now trying to remove the information sent on our end from Smalltalk. So the quesion is "How can I best remove the xmlns="http://srdctm.ibm.com/common/ phrase from aWsdlClient>>request>>transportEntity? I should also note that our old WebSphere server still works fine with this phrase included. I was told that the new websphere servers use jax-ws instead of jax-rpc, so that may be the difference. Thanks for any suggestions. Mark
|
Re: VW7.7.1 to WebSphere 8 web services communication issue
|
|
Mark,
one can do all kind of dirty tricks, and I must admit that I did a lot of that :-[ , just for the sake of making communication between tools work. Effectively, VisualWorks does a good and thorough job when it exposes the correct namespace references. I have thought a bit about the un/qualified setting and I think it won't help to change that, because "unqualified" means that objects in a *common* namespace don't need explicit notion of the namespace. As far as I can see, you have "unqualified" setting anyway. You could suppress the disturbing output by hacking into the code where the "superfluous" namespace gets written. A little bit easier is to walk through the XML document before you write it and replace the namespace in those nodes that disturb the picture. But that's all hacking around. The best you can do is to make sure that the nodes belong to the same namespace. After all, all this XML modeling and the schemas are not for annoying us but they have a meaning. It serves to communicate a well defined model. By "fixing" an XML artifact you may construct an output that "works", but it's also a violation of the underlying schema. As far as I can guess now, there is a flaw in the XML model, because the userObject refers to elements that are not defined in the underlying schema. If you fix that, you'll get a clean and stable communication right from the start. Cheers, Holger Am 23.07.2013 14:00, schrieb Mark Petersen: Holger, thanks for your suggestions. Indeed, the userObject is in a different namespace, so it seems right. Is there a way to force qualified or unqualified? I'll be checking on that and interested to see what difference it produces. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: VW7.7.1 to WebSphere 8 web services communication issue
|
|
Mark, I would suggest to try VW 7.9.1. There was some fixes and cleaning in namespace assignment to nodes. It may help. If it doesn’t try Holger’ suggestion to fix the XML document. Tamara Kogan Smalltalk Development Cincom Systems From: [hidden email] [mailto:[hidden email]] On Behalf Of Holger Guhl Mark, Holger, thanks for your suggestions. Indeed, the userObject is in a different namespace, so it seems right. Is there a way to force qualified or unqualified? I'll be checking on that and interested to see what difference it produces.
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: VW7.7.1 to WebSphere 8 web services communication issue
|
|
Re: VW7.7.1 to WebSphere 8 web services communication issue
|
|
In reply to this post by Kogan, Tamara
Tamara, Holger, thanks again.
I opted to remove the xmlns information embedded in the userObject. I suspect the issue is in the WebSphere server code, but I don't have access to it. I think our XML document on the Smalltalk side is correct. It's all internal between the servers anyway so maybe more tolerable, but agree not ideal solution. I have been also trying to use the latest release of VW7.10Jul13 but we are getting a TLSHandshakeFailure issue with it when we try to define the client. So we're dead in the water with it right now. James Savidge is working with us to have someone take a look. Thanks,
Mark, I would suggest to try VW 7.9.1. There was some fixes and cleaning in namespace assignment to nodes. It may help. If it doesn’t try Holger’ suggestion to fix the XML document. Tamara Kogan Smalltalk Development Cincom Systems From: [hidden email] [[hidden email]] On Behalf Of Holger Guhl Sent: Tuesday, July 23, 2013 9:32 AM To: Mark Petersen Cc: vwnc Subject: Re: [vwnc] VW7.7.1 to WebSphere 8 web services communication issue Mark, one can do all kind of dirty tricks, and I must admit that I did a lot of that :-[ , just for the sake of making communication between tools work. Effectively, VisualWorks does a good and thorough job when it exposes the correct namespace references. I have thought a bit about the un/qualified setting and I think it won't help to change that, because "unqualified" means that objects in a *common* namespace don't need explicit notion of the namespace. As far as I can see, you have "unqualified" setting anyway. You could suppress the disturbing output by hacking into the code where the "superfluous" namespace gets written. A little bit easier is to walk through the XML document before you write it and replace the namespace in those nodes that disturb the picture. But that's all hacking around. The best you can do is to make sure that the nodes belong to the same namespace. After all, all this XML modeling and the schemas are not for annoying us but they have a meaning. It serves to communicate a well defined model. By "fixing" an XML artifact you may construct an output that "works", but it's also a violation of the underlying schema. As far as I can guess now, there is a flaw in the XML model, because the userObject refers to elements that are not defined in the underlying schema. If you fix that, you'll get a clean and stable communication right from the start. Cheers, Holger Am 23.07.2013 14:00, schrieb Mark Petersen: Holger, thanks for your suggestions. Indeed, the userObject is in a different namespace, so it seems right. Is there a way to force qualified or unqualified? I'll be checking on that and interested to see what difference it produces. Thanks,
Mark, usually, VisualWorks obeys the configuration whether to write elements qualified or unqualified. The <userObject> shows that #unqualified is in effect. The fact that the <user> element is denoted with its namespace means that the element seems to be in a different namespace (other than xmlns:ns="http://srdctm.ibm.com/macro/"). Please check your schema definitions. If these are fine, then you might need to check whether the XMLObjectBinding for the WSDL schema types have been created properly. You can find it in XMLObjectBinding.Registry. Inspecting the marshaler for the userObject and the contained RelationMarshalers should give you first insights. Regards Holger Guhl -- Senior Consultant * Certified Scrum Master * Holger.Guhl@... Tel: +49 231 9 75 99 21 * Fax: +49 231 9 75 99 20 Georg Heeg eK Dortmund Handelsregister: Amtsgericht Dortmund A 12812 Am 18.07.2013 17:31, schrieb Mark Petersen: Hi, We're upgrading our web services servers and have run into a bit of a problem communicating between WebSphere Application Server (V8) and VisualWorks 7.7.1. The issue appears to be the inclusion of some xmlns information in our userObject, which contains a userid, token and company. This is what we send from Smalltalk: client := self getMacroClient. request := (WebServices.Struct new) at: #userObject put: userObject; at: #name put: 'VRX2RX_REF_SLN_2'; at: #technology put: '10NMRequest'; at: #testsite put: 'Oslo1'; yourself. response := client executeSelector: #queryLibraryMacro args: (Array with: request). where #userObject is: Struct: {UserObject} {#user->'mpeterse@...' #authenticationToken->'0dc66234780389b4a92679f10fff4d66' #company->'IBM'} This is the information that currently gets sent from Smalltalk to WebSphere (looking at the transportEntity in the client request variable): Version 1. <?xml version="1.0" encoding="UTF-8" standalone="no"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://srdctm.ibm.com/macro/"> <SOAP-ENV:Body> <ns:QueryLibraryMacroRequest> <userObject> <user xmlns="http://srdctm.ibm.com/common/">mpeterse@...</user> <authenticationToken xmlns="http://srdctm.ibm.com/common/">0dc66234780389b4a92679f10fff4d66</authenticationToken> <company xmlns="http://srdctm.ibm.com/common/">IBM</company> </userObject> <name>VRX2RX_REF_SLN_2</name> <technology>10NMRequest</technology> <testsite>Oslo1</testsite> </ns:QueryLibraryMacroRequest> </SOAP-ENV:Body> </SOAP-ENV:Envelope> This does not work. Using SoapUI, I verified that Version 2, without the xmlns= phrase works fine: Version 2. <?xml version="1.0" encoding="UTF-8" standalone="no"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://srdctm.ibm.com/macro/"> <SOAP-ENV:Body> <ns:QueryLibraryMacroRequest> <userObject> <user>mpeterse@...</user> <authenticationToken>0dc66234780389b4a92679f10fff4d66</authenticationToken> <company>IBM</company> </userObject> <name>VRX2RX_REF_SLN_2</name> <technology>10NMRequest</technology> <testsite>Oslo1</testsite> </ns:QueryLibraryMacroRequest> </SOAP-ENV:Body> </SOAP-ENV:Envelope> And actually, the SoapUI version (Version 3) that SoapUI derives from the wsdl file is: Version 3. <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mac="http://srdctm.ibm.com/macro/"> <soapenv:Header/> <soapenv:Body> <mac:QueryLibraryMacroRequest> <userObject> <user>mpeterse@...</user> <authenticationToken>0dc66234780389b4a92679f10fff4d66</authenticationToken> <company>IBM</company> </userObject> <name>VRX2RX_REF_SLN_2</name> <technology>10NMRequest</technology> <testsite>Oslo1</testsite> </mac:QueryLibraryMacroRequest> </soapenv:Body> </soapenv:Envelope> This works too. I'm not familiar with the standards so don't know who is right or wrong, but obviously just need it to work. Our WebSphere programmers have tried removing the xmlns= coming from Smalltalk, but no success so far. We're now trying to remove the information sent on our end from Smalltalk. So the quesion is "How can I best remove the xmlns="http://srdctm.ibm.com/common/ phrase from aWsdlClient>>request>>transportEntity? I should also note that our old WebSphere server still works fine with this phrase included. I was told that the new websphere servers use jax-ws instead of jax-rpc, so that may be the difference. Thanks for any suggestions. Mark
|
| Free forum by Nabble | Edit this page |