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 <[email protected]> wrote: > > Am 05.06.2013 um 15:41 schrieb S Krish <[email protected] > >: > > 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 <[email protected]> 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 <[email protected]> wrote: >> >> > >> > On 03 Jun 2013, at 18:08, Norbert Hartl <[email protected]> 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 >> > >> > >> >> >> > >
