Re: [Pharo-dev] SOAP in Pharo

2013-06-06 Thread S Krish
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..

http://www.w3.org/2003/05/soap-envelope";>
   
   http://api.ws.liq.misys.com/";>

   - the document literal XML---

   
   




On Wed, Jun 5, 2013 at 10:02 PM, Norbert Hartl  wrote:

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


Re: [Pharo-dev] SOAP in Pharo

2013-06-05 Thread Norbert Hartl

Am 05.06.2013 um 15:41 schrieb S Krish :

> 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  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  wrote:
> 
> >
> > On 03 Jun 2013, at 18:08, Norbert Hartl  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
> >
> >
> 
> 
> 



Re: [Pharo-dev] SOAP in Pharo

2013-06-05 Thread Norbert Hartl

Am 03.06.2013 um 19:31 schrieb Sven Van Caekenberghe :

> 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

Re: [Pharo-dev] SOAP in Pharo

2013-06-05 Thread S Krish
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  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  wrote:
>
> >
> > On 03 Jun 2013, at 18:08, Norbert Hartl  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
> >
> >
>
>
>


Re: [Pharo-dev] SOAP in Pharo

2013-06-05 Thread Johan Brichau
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  wrote:

> 
> On 03 Jun 2013, at 18:08, Norbert Hartl  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
> 
> 




Re: [Pharo-dev] SOAP in Pharo

2013-06-03 Thread p...@highoctane.be
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_IBM_DataPower_To_Help_/#/video

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  wrote:

>
> On 03 Jun 2013, at 18:08, Norbert Hartl  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
>
>
>


Re: [Pharo-dev] SOAP in Pharo

2013-06-03 Thread Sven Van Caekenberghe

On 03 Jun 2013, at 18:08, Norbert Hartl  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




Re: [Pharo-dev] SOAP in Pharo

2013-06-03 Thread p...@highoctane.be
I can perfectly understand the feeling :-)

Phil


On Mon, Jun 3, 2013 at 6:35 PM, Norbert Hartl  wrote:

>
> Am 03.06.2013 um 18:14 schrieb "p...@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-clean/
>
> Norbert
>
> Le 3 juin 2013 18:09, "Norbert Hartl"  a écrit :
>
>>
>> Am 03.06.2013 um 15:46 schrieb Johan Brichau :
>>
>> > 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
>>
>>
>>
>>
>


Re: [Pharo-dev] SOAP in Pharo

2013-06-03 Thread Norbert Hartl

Am 03.06.2013 um 18:14 schrieb "p...@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-clean/

Norbert
> Le 3 juin 2013 18:09, "Norbert Hartl"  a écrit :
> 
> 
> Am 03.06.2013 um 15:46 schrieb Johan Brichau :
> 
> > 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
> 
> 
> 



Re: [Pharo-dev] SOAP in Pharo

2013-06-03 Thread p...@highoctane.be
ah ah +1000!

And WS-* with all kinds of crypto doesn't help!

Phil
Le 3 juin 2013 18:09, "Norbert Hartl"  a écrit :

>
> Am 03.06.2013 um 15:46 schrieb Johan Brichau :
>
> > 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
>
>
>
>


Re: [Pharo-dev] SOAP in Pharo

2013-06-03 Thread Norbert Hartl

Am 03.06.2013 um 15:46 schrieb Johan Brichau :

> 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 





[Pharo-dev] SOAP in Pharo

2013-06-03 Thread Johan Brichau
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