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