[Pharo-project] Web Services - SoapOpera problems
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.
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.
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@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 =================================================
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@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 =================================================
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@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
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@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 =================================================
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
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
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
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
Hello all, Here are some news on my experiments on web services (driven by wsdl files) As a reminder, what I wanted was not to have something generic for all possible wsdl but to generate a kind of class model from the wsdl file of our engineering school planing application. This is kind of working now. But be aware this is a very very personal implementation not usable for others right now (but it might be in the future). The wsdl (client) part I have for now might be useful for others but I doubt this is the case right now (needs to be more generic). Actually I started in the debugger with my particular wsdl files and then developed iteratively (so wsdl stuff can be fun too :) ) . During this process, I finally get more knowledge on wsdl "technology", so it might be doable to make it more generic. I have identified some model weaknesses in it that I need to fix (refactor) and then I'll try to reproduce the process with other wsdl files when I'll have some free time. There are plenty over there (http://www.xmethods.net/ve2/index.po). For now, I'm more concerned on how to use SOAP and I'm just a bit stuck at the moment with the use of SOAP Opera (which I terribly hacked to make it kind of work). (1) I'd like to replace the use of KOM with ZnHTTPComponent - authentication doesn't seem possible natively (but I might be wrong there) -Soap Opera and Kom looks quite intermingled at the moment
Sven: have you looked at SoapOpera ? Do you think it can be decoupled easyly from Kom to use ZnHttpComponent instead ?
(2) the typing system is not implemented (I have a naive object wrapper on them - XSDSimpleType and XSDComplexType + XSDRestriction). - I gave a look at Brenda Larcom implementation of XSD (X Files project on squeaksource - it's MIT even if not specified yet) - I think I need a (clever) way to link XSDSimpleType/XSDComplexType with both my "wsdl" model and the soap implementation and of course map them back and forth with Smalltalk classes
Any comments/idea here would be greatly appreciated ;-) - The "typing system" seems really important to me in term of interoperability with the outside world, but I'd like a clever way to have them mapped to smalltalk class/objects
Thanks in advance for your comments (to me I think we need, a SOAP decoupled from KOM and XSD stufs) Cheers, Cédrick ps: the project is in squeaksource (iWSDL), but keep in mind this is a very very early stage...
Cedric this is excellent to see somebody pushing that.
As a reminder, what I wanted was not to have something generic for all possible wsdl but to generate a kind of class model from the wsdl file of our engineering school planing application. This is kind of working now. But be aware this is a very very personal implementation not usable for others right now (but it might be in the future).
OK learning and abstracting is the way to go :) Better something working than just talking :)
The wsdl (client) part I have for now might be useful for others but I doubt this is the case right now (needs to be more generic). Actually I started in the debugger with my particular wsdl files and then developed iteratively (so wsdl stuff can be fun too :) ) .
During this process, I finally get more knowledge on wsdl "technology", so it might be doable to make it more generic. I have identified some model weaknesses in it that I need to fix (refactor) and then I'll try to reproduce the process with other wsdl files when I'll have some free time. There are plenty over there (http://www.xmethods.net/ve2/index.po).
excellent.
For now, I'm more concerned on how to use SOAP and I'm just a bit stuck at the moment with the use of SOAP Opera (which I terribly hacked to make it kind of work).
(1) I'd like to replace the use of KOM with ZnHTTPComponent - authentication doesn't seem possible natively (but I might be wrong there) -Soap Opera and Kom looks quite intermingled at the moment
Sven: have you looked at SoapOpera ? Do you think it can be decoupled easyly from Kom to use ZnHttpComponent instead ?
It would be good. This is good to have more clients of Zinc.
(2) the typing system is not implemented (I have a naive object wrapper on them - XSDSimpleType and XSDComplexType + XSDRestriction). - I gave a look at Brenda Larcom implementation of XSD (X Files project on squeaksource - it's MIT even if not specified yet) - I think I need a (clever) way to link XSDSimpleType/XSDComplexType with both my "wsdl" model and the soap implementation and of course map them back and forth with Smalltalk classes.
Any comments/idea here would be greatly appreciated ;-) - The "typing system" seems really important to me in term of interoperability with the outside world, but I'd like a clever way to have them mapped to smalltalk class/objects
What do you need exactly do you have an example?
Thanks in advance for your comments (to me I think we need, a SOAP decoupled from KOM and XSD stufs)
Cheers,
Cédrick
ps: the project is in squeaksource (iWSDL), but keep in mind this is a very very early stage...
(2) the typing system is not implemented (I have a naive object wrapper on them - XSDSimpleType and XSDComplexType + XSDRestriction). - I gave a look at Brenda Larcom implementation of XSD (X Files project on squeaksource - it's MIT even if not specified yet) - I think I need a (clever) way to link XSDSimpleType/XSDComplexType with both my "wsdl" model and the soap implementation and of course map them back and forth with Smalltalk classes.
Any comments/idea here would be greatly appreciated ;-) - The "typing system" seems really important to me in term of interoperability with the outside world, but I'd like a clever way to have them mapped to smalltalk class/objects
What do you need exactly do you have an example?
There are several datatypes systems, but in xml world, xml schema seems to be the norm. I'd like to map them back and forth to smalltalk. <naiveThought>would it be possible to make magritte xml schema compliant ?</naiveThought > - There are a list of simple types (see here for an overview - http://books.xmlschemata.org/relaxng/relax-CHP-19.html) [1]. - There is also the notion of restriction/facets that apply to type instance [2]. - Then there are complex type for Arrays, Structure likes, etc... - And last, there are encoded types (for whatever cannot be easily represented I guess) ******** To give an idea, here is what's done in SOAPOpera and some references at the end: ***For simple types (use of a typeDict): -- simpleTypes [#Boolean] : 'xsd:boolean' [#ByteString] : 'xsd:string' [#Double] : 'xsd:double' [#Float] : 'xsd:float' [#Integer] : 'xsd:integer' [#LargeNegativeInteger] : 'xsd:negativeInteger' [#LargePositiveInteger] : 'xsd:positiveInteger' [#SmallInteger] : 'xsd:integer' [#String] : 'xsd:string' ... ***For complexTypes there's a complexType dict that is populated by the encoder ***For encoded (during encoding, if the type is not defined, it's encoded): self typeDict at: type ifAbsent:[ ^self encodeObjectSoapVariable: aSoapVariable]. with for instance self encodeObjectSoapVariable: aSoapVariable = | <auau xsi:type="Squeak-ENC:ReferenceStream">CAAAAAQEAAAAAQQAAAACCAAAAAIGBWhlbGxvEQlTbWFsbHRhbGsEAAAAAw==</auau> **************************** In SoapEncoder 's (with Masashi Umezawa comments - :-) ) initTypeDict "Apparently this mapping is not so sophisticted. " "##TODO: Implement more serious mapping method " | pref | typeDict := super initTypeDict. pref := SoapConstants xsdPrefixColon. #( #(#double #Float) #(#decimal #ScaledDecimal) #(#base64Binary #ByteArray) #(#long #LargePositiveInteger) #(#dateTime #DateAndTime) ) do:[:each | typeDict at: (pref, each first) asSymbol put: each last]. "for Poor Squeak!" ^typeDict *********************References (w3c) http://www.w3.org/TR/xmlschema-2/#built-in-datatypes http://www.w3.org/TR/xmlschema-2/#dt-facet Facets Fundamental Facets (http://www.w3.org/TR/xmlschema-2/#rf-fund-facets) 4.2.1 equal 4.2.2 ordered 4.2.3 bounded 4.2.4 cardinality 4.2.5 numeric Constraining Facets (http://www.w3.org/TR/xmlschema-2/#rf-facets) 4.3.1 length 4.3.2 minLength 4.3.3 maxLength 4.3.4 pattern 4.3.5 enumeration 4.3.6 whiteSpace 4.3.7 maxInclusive 4.3.8 maxExclusive 4.3.9 minExclusive 4.3.10 minInclusive 4.3.11 totalDigits 4.3.12 fractionDigits {base type definition} applicable {facets} If {variety} is list, then [all datatypes] length, minLength, maxLength, pattern, enumeration, whiteSpace If {variety} is union, then [all datatypes] pattern, enumeration else if {variety} is atomic, then string length, minLength, maxLength, pattern, enumeration, whiteSpace boolean pattern, whiteSpace float pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive double pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive decimal totalDigits, fractionDigits, pattern, whiteSpace, enumeration, maxInclusive, maxExclusive, minInclusive,minExclusive duration pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive dateTime pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive time pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive date pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive gYearMonth pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive gYear pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive gMonthDay pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive gDay pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive gMonth pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive hexBinary length, minLength, maxLength, pattern, enumeration, whiteSpace base64Binary length, minLength, maxLength, pattern, enumeration, whiteSpace anyURI length, minLength, maxLength, pattern, enumeration, whiteSpace QName length, minLength, maxLength, pattern, enumeration, whiteSpace NOTATION length, minLength, maxLength, pattern, enumeration, whiteSpace
Cédrick, On 15 Dec 2010, at 12:14, Cédrick Béler wrote:
(1) I'd like to replace the use of KOM with ZnHTTPComponent - authentication doesn't seem possible natively (but I might be wrong there) -Soap Opera and Kom looks quite intermingled at the moment
Sven: have you looked at SoapOpera ? Do you think it can be decoupled easyly from Kom to use ZnHttpComponent instead ?
Zinc HTTP Components has several client and server implementations you can use. Basic and digest authenitication are possible. I don't have time to look at other large/complex packages, but I will try to help you using Zn in any way I can. Regards, Sven
Sven,
Cédrick,
On 15 Dec 2010, at 12:14, Cédrick Béler wrote:
(1) I'd like to replace the use of KOM with ZnHTTPComponent - authentication doesn't seem possible natively (but I might be wrong there) -Soap Opera and Kom looks quite intermingled at the moment
Sven: have you looked at SoapOpera ? Do you think it can be decoupled easyly from Kom to use ZnHttpComponent instead ?
Zinc HTTP Components has several client and server implementations you can use. Basic and digest authenitication are possible. I don't have time to look at other large/complex packages, but I will try to help you using Zn in any way I can.
Thanks for your help. I'm looking at SOAPOpera more in details right now to see how I can use Zn instead (BTW, I really like Zn API, especially since old packages were removed). I think I'll contact the original author too (because all SOAP development were done mainly in 2002 - so there are legacy problem with XMLParsers, OldKom, etc...). I'll come back here for more specific questions. Cheers,
Regards,
Sven
participants (6)
-
Cédrick Béler -
Germán Arduino -
Janko Mivšek -
Philippe Marschall -
Stéphane Ducasse -
Sven Van Caekenberghe