December 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Transforming WSDL in a local model - Which HTTP client ? (was Web Services - SoapOpera problems)

by CÃ©drick BÃ©ler

>> >> There are around 900 operations organized in 12 interfaces. So I was thinking implementing 12 classes with methods being the actual RPC call to the application (with ZincHTTP). >> >> I'll try one operation first, then I'll see if it's possible to generate these 900 methods from the WSDL files... > > At its lowest level SOAP is pretty straightforward: HTTP POST a huge bunch of XML, get a huge bunch of XML back. > You could use some spider/debugger to look at a successful client/server interaction and take the XML and somehow parameterize it. > It would be a terrible hack, I know :) Here is what I get with wireshark : POST /TDOptions HTTP/1.1 Host: theHost:8080 Connection: Keep-Alive User-Agent: PHP-SOAP/5.3.3 Content-Type: text/xml; charset=utf-8 SOAPAction: "urn:HpSvcW2010_RpcEncoded:IHpSvcWTDOptions#NombreEtudiantsTDOption" Content-Length: 574 Authorization: Basic Q0M6Q09OU1VMVA== <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://www.indexeducation.com/frahtm/HpSvcW.html" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <ns1:NombreEtudiantsTDOption> <ATDOption xsi:type="ns1:THpSvcWCleTDOption">762</ATDOption> </ns1:NombreEtudiantsTDOption> </SOAP-ENV:Body></SOAP-ENV:Envelope> HTTP/1.1 200 OK Content-Type: text/xml; charset=UTF-8 Content-Length: 560 Connection: Close Proxy-Connection: Close <?xml version="1.0"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <NS1:NombreEtudiantsTDOptionResponse xmlns:NS1="http://www.indexeducation.com/frahtm/HpSvcW.html"> <return xsi:type="xsd:unsignedInt">1</return> </NS1:NombreEtudiantsTDOptionResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> > >> Anyway, this is not that important and if I don't succeed, I will at least learn to use ZincHTTP :)) > > That would be good. > > Sven > >

Dec. 1, 2010

Re: [Pharo-project] Transforming WSDL in a local model - Which HTTP client ? (was Web Services - SoapOpera problems)

by Sven Van Caekenberghe

On 01 Dec 2010, at 16:09, CÃ©drick BÃ©ler wrote: > uhm, thanks for your remarks. I guess I won't spend too much time on that then... > > but, just to be more precise, I don't want to do something general (I'm not in enterprise environnement either), I just want to request an application located in my school. > This application only exposes services (described by several varaitions of wsdl files which I think aren't totally valid). > > There are around 900 operations organized in 12 interfaces. So I was thinking implementing 12 classes with methods being the actual RPC call to the application (with ZincHTTP). > > I'll try one operation first, then I'll see if it's possible to generate these 900 methods from the WSDL files... At its lowest level SOAP is pretty straightforward: HTTP POST a huge bunch of XML, get a huge bunch of XML back. You could use some spider/debugger to look at a successful client/server interaction and take the XML and somehow parameterize it. It would be a terrible hack, doable for a couple of calls, but not for 900! > Anyway, this is not that important and if I don't succeed, I will at least learn to use ZincHTTP :)) That would be good. Sven

Dec. 1, 2010

Re: [Pharo-project] Transforming WSDL in a local model - Which HTTP client ? (was Web Services - SoapOpera problems)

by mkobetic＠gmail.com

"Philippe Marschall"<philippe.marschall(a)netcetera.ch> wrote: > Yes, SOAP it not just some XML format. You have to sink a lot of > resources into the implementation and tool support. Keep in mind that > even Cincom with all their resources didn't manage to make their SOAP > library talk to SAP. They had to build a proprietary connector. That's not quite what happened, the SAP Connect relies on the WS stack to do the WS part, it adds SAP specific integration, and yes it also provides the alternative proprietary RFC protocol as well (not everything in SAP was exposed via WS at that point). Anyway, I can certainly sympathise with the sentiment expressed in this thread. IMO, CORBA comes out as the pinacle of simplicity when compared to the WS stack as it is today. The problem is not just the sheer number of specs, but also the laxity and vagueness of individual specs themselves. There's so much room for different interpretations of everything that interoperability beyond trivial examples is nearly impossible (generally the small monkeys just have to ape what the few gorillas decide to do). Anyway, the easiest in this case likely is to simply observe the communication of the PHP based solution and implement just that specific protocol. Each WSDL spec basically defines (whatever that means in the WS context) a custom protocol, you need just one of those, not all of them.

Dec. 1, 2010

Re: [Pharo-project] A new GUI visual designer

by Igor Stasenko

On 1 December 2010 12:48, nullPointer <epicfan(a)gmail.com> wrote: > > > https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki… > > It really looks very professional. I made a user interface builder for > Polymorph, which I left because I was too complicated for me. I hope that > now someone more knowledgeable can really necessary to implement a tool for > Squeak / Pharo as a visual designer user interfaces. > +1 that's really important stuff. And this project looks very promising. Hope, author(s) can shed a light on it, in what stage it is, what license etc etc. > Regards > -- > View this message in context: http://forum.world.st/A-new-GUI-visual-designer-tp3067111p3067111.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Best regards, Igor Stasenko AKA sig.

Dec. 1, 2010

Re: [Pharo-project] Transforming WSDL in a local model - Which HTTP client ? (was Web Services - SoapOpera problems)

by CÃ©drick BÃ©ler

> On 12/01/2010 03:28 PM, Sven Van Caekenberghe wrote: >> 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. > > Yes, SOAP it not just some XML format. You have to sink a lot of > resources into the implementation and tool support. Keep in mind that > even Cincom with all their resources didn't manage to make their SOAP > library talk to SAP. They had to build a proprietary connector. uhm, thanks for your remarks. I guess I won't spend too much time on that then... but, just to be more precise, I don't want to do something general (I'm not in enterprise environnement either), I just want to request an application located in my school. This application only exposes services (described by several varaitions of wsdl files which I think aren't totally valid). There are around 900 operations organized in 12 interfaces. So I was thinking implementing 12 classes with methods being the actual RPC call to the application (with ZincHTTP). I'll try one operation first, then I'll see if it's possible to generate these 900 methods from the WSDL files... Anyway, this is not that important and if I don't succeed, I will at least learn to use ZincHTTP :)) Thanks > > Cheers > Philippe > >

Dec. 1, 2010

Re: [Pharo-project] FFI question. Is it possible to unload loaded external library

by Igor Stasenko

On 1 December 2010 15:57, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Tue, Nov 30, 2010 at 9:35 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: >> >> Hello, >> >> I need implement remote updating some dll's for running pharo application. >> This dll's used by FFI. >> I want done this by unloading dll from VM. Then loading new updated dll. >> And then continue app execution. >> Is it possible? > see #unloadModule: it should work for modules, loaded via FFI i think. But i never tried to do that. > what does it mean exactly to "load" a dll and "unload" ?? > cheers > > mariano > >> >> Or only way is to restart pharo? > > -- Best regards, Igor Stasenko AKA sig.

Dec. 1, 2010

Re: [Pharo-project] FFI question. Is it possible to unload loaded external library

by Mariano Martinez Peck

On Tue, Nov 30, 2010 at 9:35 PM, Denis Kudriashov <dionisiydk(a)gmail.com>wrote: > Hello, > > I need implement remote updating some dll's for running pharo application. > This dll's used by FFI. > I want done this by unloading dll from VM. Then loading new updated dll. > And then continue app execution. > Is it possible? > what does it mean exactly to "load" a dll and "unload" ?? cheers mariano > > Or only way is to restart pharo? >

Dec. 1, 2010

Re: [Pharo-project] Transforming WSDL in a local model - Which HTTP client ? (was Web Services - SoapOpera problems)

by Philippe Marschall

On 12/01/2010 03:28 PM, Sven Van Caekenberghe wrote: > 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. Yes, SOAP it not just some XML format. You have to sink a lot of resources into the implementation and tool support. Keep in mind that even Cincom with all their resources didn't manage to make their SOAP library talk to SAP. They had to build a proprietary connector. Cheers Philippe

Dec. 1, 2010

Re: [Pharo-project] Transforming WSDL in a local model - Which HTTP client ? (was Web Services - SoapOpera problems)

by Sven Van Caekenberghe

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 <stephane.ducasse(a)inria.fr>: >>> 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 >> ================================================= >> > >

Dec. 1, 2010

Re: [Pharo-project] Transforming WSDL in a local model - Which HTTP client ? (was Web Services - SoapOpera problems

by Janko MivÅ¡ek

CÃ©drick, Nicelly writtend and very down to earth reason why we need better SOA Web Services support ASAP. This is the shortest way for Pharo to get an aura to be more professional and suitable for "enterprise" world. Best regards Janko On 01. 12. 2010 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 <stephane.ducasse(a)inria.fr>: >>> 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 >> ================================================= >> > > > -- Janko MivÅ¡ek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565

Dec. 1, 2010