Hi, I have the distinguished pleasure of needing to interface with a SOAP service from within Pharo Smalltalk. Currently taking a look at SoapOpera and iWSDL projects on Squeaksource. These projects seem to be unchanged since 2010 and broken in Pharo 1.4 Probably I will be spending some time to bring these to life again in current Pharo, but if anyone has some better pointers to use, please let me know. cheers Johan
Am 03.06.2013 um 15:46 schrieb Johan Brichau <johan@inceptive.be>:
Hi,
I have the distinguished pleasure of needing to interface with a SOAP service from within Pharo Smalltalk.
Currently taking a look at SoapOpera and iWSDL projects on Squeaksource. These projects seem to be unchanged since 2010 and broken in Pharo 1.4
Probably I will be spending some time to bring these to life again in current Pharo, but if anyone has some better pointers to use, please let me know.
Welcome to the club! The short version is: I use SOAP templates ! (like a lot of people out there) In order to use SOAP properly you need a full namespace aware xml parser, a xml schema parser, a WSDL parser plus code generator and the will to abuse HTTP completely . Even if you build a perfect tool you'll maybe face the not so perfect responses from the remote side. So my strategy with SOAP since years is (advizable only if there isn't a huge API with a huge variance of parameters): - Create all needed SOAP calls with any tool and snapshot them - build a small templating tool to insert values - send the snippet with every misguided header/setup the remote side needs to operate - take the response and first thing is strip off SOAP envelope - parse the xml and use pastell or something like that to query values to build objects (using it this way even has a name to make it look more professional. It is called document oriented SOAP :) ) Sounds hackish? Sounds stupid? Yes, you are right, it is. But it is by far less stupid as SOAP is. Sorry but I had to write this :) Norbert
ah ah +1000! And WS-* with all kinds of crypto doesn't help! Phil Le 3 juin 2013 18:09, "Norbert Hartl" <norbert@hartl.name> a écrit :
Am 03.06.2013 um 15:46 schrieb Johan Brichau <johan@inceptive.be>:
Hi,
I have the distinguished pleasure of needing to interface with a SOAP service from within Pharo Smalltalk.
Currently taking a look at SoapOpera and iWSDL projects on Squeaksource. These projects seem to be unchanged since 2010 and broken in Pharo 1.4
Probably I will be spending some time to bring these to life again in current Pharo, but if anyone has some better pointers to use, please let me know.
Welcome to the club!
The short version is: I use SOAP templates ! (like a lot of people out there)
In order to use SOAP properly you need a full namespace aware xml parser, a xml schema parser, a WSDL parser plus code generator and the will to abuse HTTP completely . Even if you build a perfect tool you'll maybe face the not so perfect responses from the remote side. So my strategy with SOAP since years is (advizable only if there isn't a huge API with a huge variance of parameters):
- Create all needed SOAP calls with any tool and snapshot them - build a small templating tool to insert values - send the snippet with every misguided header/setup the remote side needs to operate - take the response and first thing is strip off SOAP envelope - parse the xml and use pastell or something like that to query values to build objects (using it this way even has a name to make it look more professional. It is called document oriented SOAP :) )
Sounds hackish? Sounds stupid? Yes, you are right, it is. But it is by far less stupid as SOAP is.
Sorry but I had to write this :)
Norbert
Am 03.06.2013 um 18:14 schrieb "phil@highoctane.be" <phil@highoctane.be>:
ah ah +1000!
And WS-* with all kinds of crypto doesn't help!
No, I'm done with it since that project I described http://norbert.hartl.name/blog/2010/10/05/isnt-soap-supposed-to-make-it-clea... Norbert
Le 3 juin 2013 18:09, "Norbert Hartl" <norbert@hartl.name> a écrit :
Am 03.06.2013 um 15:46 schrieb Johan Brichau <johan@inceptive.be>:
Hi,
I have the distinguished pleasure of needing to interface with a SOAP service from within Pharo Smalltalk.
Currently taking a look at SoapOpera and iWSDL projects on Squeaksource. These projects seem to be unchanged since 2010 and broken in Pharo 1.4
Probably I will be spending some time to bring these to life again in current Pharo, but if anyone has some better pointers to use, please let me know.
Welcome to the club!
The short version is: I use SOAP templates ! (like a lot of people out there)
In order to use SOAP properly you need a full namespace aware xml parser, a xml schema parser, a WSDL parser plus code generator and the will to abuse HTTP completely . Even if you build a perfect tool you'll maybe face the not so perfect responses from the remote side. So my strategy with SOAP since years is (advizable only if there isn't a huge API with a huge variance of parameters):
- Create all needed SOAP calls with any tool and snapshot them - build a small templating tool to insert values - send the snippet with every misguided header/setup the remote side needs to operate - take the response and first thing is strip off SOAP envelope - parse the xml and use pastell or something like that to query values to build objects (using it this way even has a name to make it look more professional. It is called document oriented SOAP :) )
Sounds hackish? Sounds stupid? Yes, you are right, it is. But it is by far less stupid as SOAP is.
Sorry but I had to write this :)
Norbert
I can perfectly understand the feeling :-) Phil On Mon, Jun 3, 2013 at 6:35 PM, Norbert Hartl <norbert@hartl.name> wrote:
Am 03.06.2013 um 18:14 schrieb "phil@highoctane.be" <phil@highoctane.be>:
ah ah +1000!
And WS-* with all kinds of crypto doesn't help!
No, I'm done with it since that project I described
http://norbert.hartl.name/blog/2010/10/05/isnt-soap-supposed-to-make-it-clea...
Norbert
Le 3 juin 2013 18:09, "Norbert Hartl" <norbert@hartl.name> a écrit :
Am 03.06.2013 um 15:46 schrieb Johan Brichau <johan@inceptive.be>:
Hi,
I have the distinguished pleasure of needing to interface with a SOAP service from within Pharo Smalltalk.
Currently taking a look at SoapOpera and iWSDL projects on Squeaksource. These projects seem to be unchanged since 2010 and broken in Pharo 1.4
Probably I will be spending some time to bring these to life again in current Pharo, but if anyone has some better pointers to use, please let me know.
Welcome to the club!
The short version is: I use SOAP templates ! (like a lot of people out there)
In order to use SOAP properly you need a full namespace aware xml parser, a xml schema parser, a WSDL parser plus code generator and the will to abuse HTTP completely . Even if you build a perfect tool you'll maybe face the not so perfect responses from the remote side. So my strategy with SOAP since years is (advizable only if there isn't a huge API with a huge variance of parameters):
- Create all needed SOAP calls with any tool and snapshot them - build a small templating tool to insert values - send the snippet with every misguided header/setup the remote side needs to operate - take the response and first thing is strip off SOAP envelope - parse the xml and use pastell or something like that to query values to build objects (using it this way even has a name to make it look more professional. It is called document oriented SOAP :) )
Sounds hackish? Sounds stupid? Yes, you are right, it is. But it is by far less stupid as SOAP is.
Sorry but I had to write this :)
Norbert
On 03 Jun 2013, at 18:08, Norbert Hartl <norbert@hartl.name> wrote:
In order to use SOAP properly you need a full namespace aware xml parser, a xml schema parser, a WSDL parser plus code generator and the will to abuse HTTP completely . Even if you build a perfect tool you'll maybe face the not so perfect responses from the remote side.
Even using the Java stack with all its tools and frameworks, SOAP is still terrible. Especially if you have to interface with Microsofts' idea of SOAP and web services. But Johan implied already that it would not be fun. On the other hand, I think that XML Support _is_ namespace aware. So it would not be too hard to actually generate/parse SOAP messages for real. You could get already pretty far with that, IMHO. Sven PS: In another life I did http://common-lisp.net/project/cl-soap/ - it was never perfect but it kind of worked to talk to Google AdWords. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
Easy answer to SOAP problems: IBM Datapower SOA Appliance. http://www-03.ibm.com/software/products/us/en/datapower/ I played with this one: http://www-03.ibm.com/software/products/us/en/datapower-xi50 Current stuff is http://article.wn.com/view/2013/04/29/SOA_Software_Enables_REST_Services_on_... Short version: you shell out EUR 250K + IBM consulting fees and this translates whatever SOAP you want into something readable and it does it fast. Note: this is one of the hottest selling products of IBM at the moment, they ship it by the boatload to banks and organisations requiring heavy security/regulations. Putting Pharo behind this makes for a pretty good solution. Phil On Mon, Jun 3, 2013 at 7:31 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 03 Jun 2013, at 18:08, Norbert Hartl <norbert@hartl.name> wrote:
In order to use SOAP properly you need a full namespace aware xml parser, a xml schema parser, a WSDL parser plus code generator and the will to abuse HTTP completely . Even if you build a perfect tool you'll maybe face the not so perfect responses from the remote side.
Even using the Java stack with all its tools and frameworks, SOAP is still terrible. Especially if you have to interface with Microsofts' idea of SOAP and web services.
But Johan implied already that it would not be fun.
On the other hand, I think that XML Support _is_ namespace aware. So it would not be too hard to actually generate/parse SOAP messages for real. You could get already pretty far with that, IMHO.
Sven
PS: In another life I did http://common-lisp.net/project/cl-soap/ - it was never perfect but it kind of worked to talk to Google AdWords.
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
Thanks for all the feedback! The SoapOpera library is using XMLSupport and I think it is a basic generate/parse library for SOAP messages. Given the time constraints and the limited number of soap calls we need to implement, I think we will roughly go for Norbert's approach (using XMLSupport) and see if we can/need to work on the SoapOpera library in the future. Or maybe we make a 'lightweight soap' library... I don't know. Johan On 03 Jun 2013, at 19:31, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 03 Jun 2013, at 18:08, Norbert Hartl <norbert@hartl.name> wrote:
In order to use SOAP properly you need a full namespace aware xml parser, a xml schema parser, a WSDL parser plus code generator and the will to abuse HTTP completely . Even if you build a perfect tool you'll maybe face the not so perfect responses from the remote side.
Even using the Java stack with all its tools and frameworks, SOAP is still terrible. Especially if you have to interface with Microsofts' idea of SOAP and web services.
But Johan implied already that it would not be fun.
On the other hand, I think that XML Support _is_ namespace aware. So it would not be too hard to actually generate/parse SOAP messages for real. You could get already pretty far with that, IMHO.
Sven
PS: In another life I did http://common-lisp.net/project/cl-soap/ - it was never perfect but it kind of worked to talk to Google AdWords.
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
In our works ( VA).. we had the "Document-Literal" SOAP wrapper approach and generally works easy and fine. I would say it is order more easier than what I see Norbert mention, unless I miss something in deference to his better experience in Pharo. With XMLRPC in Pharo I could do a lot Java - Smalltalk experimentally... and I believe it should not be very tough to cobble up the simplest workable SOAP interface bi-directional with Document/Literal approach http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/ The namespace complication, which we have avoided/ I would avoid till the reasons are high enough to justify. ******************** Not tested.. but did see this... at some time.. all squeak based.. http://www.mars.dti.ne.jp/~umejava/smalltalk/soapOpera/soapCore.html http://wiki.squeak.org/squeak/1399.diff?id=29 http://wiki.squeak.org/squeak/1228.diff?id=33 http://www.mars.dti.ne.jp/~umejava/smalltalk/soapOpera/index.html On Wed, Jun 5, 2013 at 6:48 PM, Johan Brichau <johan@inceptive.be> wrote:
Thanks for all the feedback!
The SoapOpera library is using XMLSupport and I think it is a basic generate/parse library for SOAP messages. Given the time constraints and the limited number of soap calls we need to implement, I think we will roughly go for Norbert's approach (using XMLSupport) and see if we can/need to work on the SoapOpera library in the future. Or maybe we make a 'lightweight soap' library... I don't know.
Johan
On 03 Jun 2013, at 19:31, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 03 Jun 2013, at 18:08, Norbert Hartl <norbert@hartl.name> wrote:
In order to use SOAP properly you need a full namespace aware xml
parser, a xml schema parser, a WSDL parser plus code generator and the will to abuse HTTP completely .
Even if you build a perfect tool you'll maybe face the not so perfect responses from the remote side.
Even using the Java stack with all its tools and frameworks, SOAP is still terrible. Especially if you have to interface with Microsofts' idea of SOAP and web services.
But Johan implied already that it would not be fun.
On the other hand, I think that XML Support _is_ namespace aware. So it would not be too hard to actually generate/parse SOAP messages for real. You could get already pretty far with that, IMHO.
Sven
PS: In another life I did http://common-lisp.net/project/cl-soap/ - it was never perfect but it kind of worked to talk to Google AdWords.
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
Am 05.06.2013 um 15:41 schrieb S Krish <krishnamachari.sudhakar@gmail.com>:
In our works ( VA).. we had the "Document-Literal" SOAP wrapper approach and generally works easy and fine.
I would say it is order more easier than what I see Norbert mention, unless I miss something in deference to his better experience in Pharo.
Can you elaborate on your explanation? I would like to know how your approach works and how it is different to what I do.
With XMLRPC in Pharo I could do a lot Java - Smalltalk experimentally... and I believe it should not be very tough to cobble up the simplest workable SOAP interface bi-directional with Document/Literal approach
http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/
The namespace complication, which we have avoided/ I would avoid till the reasons are high enough to justify.
I'm sorry but I don't understand what you are saying. I think to build any generic interface for SOAP you need to parse and generate XML properly according to the WSDL spec (I answered Svens email right now explaining it). I would like to see another approach that is simple and smarter than mine. Norbert
********************
Not tested.. but did see this... at some time.. all squeak based..
http://www.mars.dti.ne.jp/~umejava/smalltalk/soapOpera/soapCore.html
http://wiki.squeak.org/squeak/1399.diff?id=29
http://wiki.squeak.org/squeak/1228.diff?id=33
http://www.mars.dti.ne.jp/~umejava/smalltalk/soapOpera/index.html
On Wed, Jun 5, 2013 at 6:48 PM, Johan Brichau <johan@inceptive.be> wrote: Thanks for all the feedback!
The SoapOpera library is using XMLSupport and I think it is a basic generate/parse library for SOAP messages. Given the time constraints and the limited number of soap calls we need to implement, I think we will roughly go for Norbert's approach (using XMLSupport) and see if we can/need to work on the SoapOpera library in the future. Or maybe we make a 'lightweight soap' library... I don't know.
Johan
On 03 Jun 2013, at 19:31, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 03 Jun 2013, at 18:08, Norbert Hartl <norbert@hartl.name> wrote:
In order to use SOAP properly you need a full namespace aware xml parser, a xml schema parser, a WSDL parser plus code generator and the will to abuse HTTP completely . Even if you build a perfect tool you'll maybe face the not so perfect responses from the remote side.
Even using the Java stack with all its tools and frameworks, SOAP is still terrible. Especially if you have to interface with Microsofts' idea of SOAP and web services.
But Johan implied already that it would not be fun.
On the other hand, I think that XML Support _is_ namespace aware. So it would not be too hard to actually generate/parse SOAP messages for real. You could get already pretty far with that, IMHO.
Sven
PS: In another life I did http://common-lisp.net/project/cl-soap/ - it was never perfect but it kind of worked to talk to Google AdWords.
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
The approach taken is to simply put the more or less fixed prefix - suffix Soap Envelope Message to the Document/ Literal XML content. It is the receiving Server that then does the task of unmarshalling the XML content and then custom interpreting it for actions.. messageName is the operation to be executed.. <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"> <soap:Body> <tns:messageName xmlns:tns="http://api.ws.liq.misys.com/"> ----- the document literal XML--- </tns:messageName t> </soap:Body> </soap:Envelope> On Wed, Jun 5, 2013 at 10:02 PM, Norbert Hartl <norbert@hartl.name> wrote:
Am 05.06.2013 um 15:41 schrieb S Krish <krishnamachari.sudhakar@gmail.com
:
In our works ( VA).. we had the "Document-Literal" SOAP wrapper approach and generally works easy and fine.
I would say it is order more easier than what I see Norbert mention, unless I miss something in deference to his better experience in Pharo.
Can you elaborate on your explanation? I would like to know how your approach works and how it is different to what I do.
With XMLRPC in Pharo I could do a lot Java - Smalltalk experimentally... and I believe it should not be very tough to cobble up the simplest workable SOAP interface bi-directional with Document/Literal approach
http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/
The namespace complication, which we have avoided/ I would avoid till the reasons are high enough to justify.
I'm sorry but I don't understand what you are saying. I think to build any generic interface for SOAP you need to parse and generate XML properly according to the WSDL spec (I answered Svens email right now explaining it).
I would like to see another approach that is simple and smarter than mine.
Norbert
********************
Not tested.. but did see this... at some time.. all squeak based..
http://www.mars.dti.ne.jp/~umejava/smalltalk/soapOpera/soapCore.html
http://wiki.squeak.org/squeak/1399.diff?id=29
http://wiki.squeak.org/squeak/1228.diff?id=33
http://www.mars.dti.ne.jp/~umejava/smalltalk/soapOpera/index.html
On Wed, Jun 5, 2013 at 6:48 PM, Johan Brichau <johan@inceptive.be> wrote:
Thanks for all the feedback!
The SoapOpera library is using XMLSupport and I think it is a basic generate/parse library for SOAP messages. Given the time constraints and the limited number of soap calls we need to implement, I think we will roughly go for Norbert's approach (using XMLSupport) and see if we can/need to work on the SoapOpera library in the future. Or maybe we make a 'lightweight soap' library... I don't know.
Johan
On 03 Jun 2013, at 19:31, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 03 Jun 2013, at 18:08, Norbert Hartl <norbert@hartl.name> wrote:
In order to use SOAP properly you need a full namespace aware xml
parser, a xml schema parser, a WSDL parser plus code generator and the will to abuse HTTP completely .
Even if you build a perfect tool you'll maybe face the not so perfect responses from the remote side.
Even using the Java stack with all its tools and frameworks, SOAP is still terrible. Especially if you have to interface with Microsofts' idea of SOAP and web services.
But Johan implied already that it would not be fun.
On the other hand, I think that XML Support _is_ namespace aware. So it would not be too hard to actually generate/parse SOAP messages for real. You could get already pretty far with that, IMHO.
Sven
PS: In another life I did http://common-lisp.net/project/cl-soap/ - it was never perfect but it kind of worked to talk to Google AdWords.
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
Am 03.06.2013 um 19:31 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On the other hand, I think that XML Support _is_ namespace aware. So it would not be too hard to actually generate/parse SOAP messages for real. You could get already pretty far with that, IMHO.
I would say XMLSupport has namespaces. With full namespace aware I meant dealing with things like elementFormDefault/attributeFormDefault. Without having that properly implemented and parsed you will have trouble generating something generic. I see this essential because I saw a few WSDLs that did wildly mix the modes. I think this is due the fact that WSDLs are generated with a GUI and people don't know much about the underlying things. Norbert
participants (5)
-
Johan Brichau -
Norbert Hartl -
phil＠highoctane.be -
S Krish -
Sven Van Caekenberghe