Cédrick,

Contrary to readable, understandable standards like XMLRPC, Json or REST, SOAP 
is terribly complex (like CORBA), especially if you want a general 
implementation that is interoperable with other implementations.

WSDL is a meta specification of an interface. To parse that you need a very 
good XML parser (with namespace support). Then you have to deal with the 
semantics (check the specs, they are huge).

Then you have to do marchalling/unmarchalling of objects to/from XML (again, 
very good parser needed), support lots of other standards and hope types will 
be compatible.

The actual calls using HTTP are pretty simple. You could certainly use Zinc 
HTTP Components for that.

All this technology just to do an RPC call.

In environments like .Net you can litteraly click 1 button and generate a WSDL 
and working client/server from a class/interface. This create the impression 
that this is simple/easy. Interoperability with other SOAP implementations will 
probably be harder.

If I were you, I would write a proxy translating SOAP to/from something simpler 
like REST + Json in a language with good SOAP support like .Net or Java and run 
that next to Smalltalk. Such bridges should be acceptable in enterprise 
environments.

My 2c,

Sven

PS: I once did a (partial) SOAP implementation in Common Lisp ( 
http://common-lisp.net/project/cl-soap/ ) and I know I don't want to do that 
anymore or again, even when somebody would pay me.

On 01 Dec 2010, at 14:56, Cédrick Béler wrote:

> I've read again the thread of september about XMLRPC and therefore the 
> general discussion around services techniques...
> 
> I understand soap is not a priority (and probably not a good technique). This 
> is just I'd like to make an interface to our planing application and all 
> their provide is soap. The sad thing is as it's working out of the box in 
> php, we use php instead... Anyway, I'll continue to find a way to query these 
> services from Pharo... but a straighter one...
> 
> As, I just need a client, I think I'll try to get something simple, like get 
> and parse the wsdl file, then build a local model that can be used to 
> directly query the services... My first thought is to create classes for each 
> services entities, then each method (probably class side) will fire the right 
> soap request...
> 
> If it sounds stupid, please tell me before I spend too much time here ;-)
> 
> Just one question, which HTTP client should I use ? I've been lost since the 
> development of WebClient, Zn*, ...
> 
> TIA
> 
> Cédrick
> 
>> I agree, we must improve soap support. May be when I end with xmlrpc
>> have a bit of time...
>> 
>> 2010/11/30, Stéphane Ducasse <[email protected]>:
>>> thanks for reporting that.
>>> Indeed we should improve on that level.
>>> 
>>> Stef
>>> 
>>> On Nov 30, 2010, at 7:47 PM, Cédrick Béler wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> I'd like to try some webservice experiments. I loaded the last version of
>>>> SoapOpera but then, I struggled a lot and I still can't make it work.
>>>> 
>>>> First, I needed authentication and I didn't found how to do that in SOAP.
>>>> I managed to make it work by hacking Kom.
>>>> Does someone knows how to do that properly or if it's not possible?
>>>> 
>>>> Second, I just can't make it work (whereas I can in PHP and it's dead
>>>> simple :( with SoapClient). I have an error message saying that the
>>>> interface is not known... After investigating a bit, I think that the
>>>> problem is there is no "interpretation" of the wsdl file that describe the
>>>> set of services.
>>>> 
>>>> Can people confirm if I'm wrong or not ?
>>>> What's the current state of SoapOpera development ? Are there alternatives
>>>> ?
>>>> 
>>>> TIA
>>>> 
>>>> ps: in PHP
>>>> 
>>>> $client = new SoapClient($WSDL, array('login'=> $LOGIN,'password'=>
>>>> $PASS));
>>>> $client->TDOptionsPromotion( "whatever parameters");
>>>> 
>>>> in Smalltalk (not the example I tried but something else that nearly
>>>> works, except I get one value, the last one, instead of an array of five)
>>>> 
>>>> call := (SoapCallEntry tcpHost: 'footballpool.dataaccess.eu' port: 80)
>>>> newCall.
>>>> call targetObjectURI: 'data/info.wso'.
>>>> call namespace: 'http://footballpool.dataaccess.eu'.
>>>> call methodName: 'TopGoalScorers'.
>>>> call addParameterNamed: 'iTopN' value: '5'.
>>>> call invokeAndReturn.
>>> 
>>> 
>>> 
>> 
>> 
>> -- 
>> =================================================
>> Germán S. Arduino  <gsa @ arsol.net>   Twitter: garduino
>> Arduino Software & Web Hosting   http://www.arduinosoftware.com
>> PasswordsPro  http://www.passwordspro.com
>> =================================================
>> 
> 
> 


Reply via email to