VW7.7.1 to WebSphere 8 web services communication issue

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

VW7.7.1 to WebSphere 8 web services communication issue

MarkPetersen
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

Mark K. Petersen
Semiconductor Research
and Development Center

IBM Systems and Technology Group
Home Office: (319) 406-4165 Cell: (319) 483-8347
Internet email: [hidden email]

Internal DMACS Community

 
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Reply | Threaded
Open this post in threaded view
|

Re: VW7.7.1 to WebSphere 8 web services communication issue

Holger Guhl
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,

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

Mark K. Petersen
Semiconductor Research
and Development Center

IBM Systems and Technology Group
Home Office: (319) 406-4165 Cell: (319) 483-8347
Internet email: [hidden email]

Internal DMACS Community

 

_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: VW7.7.1 to WebSphere 8 web services communication issue

MarkPetersen
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 K. Petersen
Semiconductor Research
and Development Center

IBM Systems and Technology Group
Home Office: (319) 406-4165 Cell: (319) 483-8347
Internet email: [hidden email]

Internal DMACS Community

 



From:        Holger Guhl <[hidden email]>
To:        Mark Petersen/Fishkill/IBM@IBMUS,
Cc:        vwnc <[hidden email]>
Date:        07/19/2013 12:14 PM
Subject:        Re: [vwnc] 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 *
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

Mark K. Petersen
Semiconductor Research
and Development Center

IBM Systems and Technology Group
Home Office: (319) 406-4165 Cell: (319) 483-8347
Internet email:
mpeterse@...
Internal DMACS Community

 



_______________________________________________
vwnc mailing list
vwnc@...
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Reply | Threaded
Open this post in threaded view
|

Re: VW7.7.1 to WebSphere 8 web services communication issue

Holger Guhl
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 K. Petersen
Semiconductor Research
and Development Center

IBM Systems and Technology Group
Home Office: (319) 406-4165 Cell: (319) 483-8347
Internet email: [hidden email]

Internal DMACS Community

 



From:        Holger Guhl [hidden email]
To:        Mark Petersen/Fishkill/IBM@IBMUS,
Cc:        vwnc [hidden email]
Date:        07/19/2013 12:14 PM
Subject:        Re: [vwnc] 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,

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

Mark K. Petersen
Semiconductor Research
and Development Center

IBM Systems and Technology Group
Home Office: (319) 406-4165 Cell: (319) 483-8347
Internet email:
[hidden email]
Internal DMACS Community

 



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: VW7.7.1 to WebSphere 8 web services communication issue

Kogan, Tamara

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
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 K. Petersen
Semiconductor Research
and Development Center

IBM Systems and Technology Group

Home Office: (319) 406-4165 Cell: (319) 483-8347
Internet email: [hidden email]

Internal DMACS Community

 

 



From:        Holger Guhl [hidden email]
To:        Mark Petersen/Fishkill/IBM@IBMUS,
Cc:        vwnc [hidden email]
Date:        07/19/2013 12:14 PM
Subject:        Re: [vwnc] 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,

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

Mark K. Petersen
Semiconductor Research
and Development Center

IBM Systems and Technology Group

Home Office: (319) 406-4165 Cell: (319) 483-8347
Internet email:
[hidden email]
Internal DMACS Community

 

 



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

 


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: VW7.7.1 to WebSphere 8 web services communication issue

Holger Kleinsorgen
In reply to this post by MarkPetersen
at least 7.7 seems to add namespaces to non-root elements even if elementFormDefault="unqualified" is specified

MarkPetersen wrote
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.
Reply | Threaded
Open this post in threaded view
|

Re: VW7.7.1 to WebSphere 8 web services communication issue

MarkPetersen
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 K. Petersen
Semiconductor Research
and Development Center

IBM Systems and Technology Group
Home Office: (319) 406-4165 Cell: (319) 483-8347
Internet email: [hidden email]

Internal DMACS Community

 



From:        "Kogan, Tamara" <[hidden email]>
To:        "Holger Guhl" <[hidden email]>, Mark Petersen/Fishkill/IBM@IBMUS,
Cc:        "vwnc" <[hidden email]>
Date:        07/23/2013 09:04 AM
Subject:        RE: [vwnc] 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] [[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 K. Petersen
Semiconductor Research
and Development Center

IBM Systems and Technology Group
Home Office: (319) 406-4165 Cell: (319) 483-8347
Internet email:
mpeterse@...
Internal DMACS Community

 

 



From:        
Holger Guhl <holger@...>
To:        
Mark Petersen/Fishkill/IBM@IBMUS,
Cc:        
vwnc <vwnc@...>
Date:        
07/19/2013 12:14 PM
Subject:        
Re: [vwnc] 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 *
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

Mark K. Petersen
Semiconductor Research
and Development Center

IBM Systems and Technology Group
Home Office: (319) 406-4165 Cell: (319) 483-8347
Internet email:
mpeterse@...
Internal DMACS Community

 

 



_______________________________________________
vwnc mailing list

vwnc@...
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
 

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc