soaplite-devel — SOAP::Lite developers

Re: [Soaplite-devel] Problems with SOAP::Lite client

[Thorsten H. <tho...@ar...>]

Hi Frederic,
 
thanks for the hint, but unfortunately it doesn't work...
 
The Tivoli Data Integrator (ITDI) still doesn't recognize the array.
The guy who developed the service of the ITDI said, it must receive an array of PLZInfos. But he is all into java and autogenerated code, so he is not much of a help...
 
I'm runnin' a little short on ideas (and time...) right now. :-(
 
Bye,
 
Thorsten
 
________________________________

Von: Frédéric Solvignon [mailto:Fre...@lo...]
Gesendet: Mi 10.12.2008 16:35
An: Thorsten Harms
Betreff: RE: [Soaplite-devel] Problems with SOAP::Lite client



Hi,

Try this : 

SOAP::Data->type("tns2:PLZInfo")->name("plzinfos" => \SOAP::Data->value(@data) ));

 

 

De : Thorsten Harms [mailto:tho...@ar...] 
Envoyé : mercredi 10 décembre 2008 16:12
À : soa...@li...
Objet : [Soaplite-devel] Problems with SOAP::Lite client

 

Hi,

 

I'm currently writing a client using SOAP::Lite, that connects to an IBM Tivoli Data Integrator.

 

Here are some excerpts from the wsdl-file:

...
<element name="updatePLZInformationen">
<complexType>
 <sequence>
  <element name="clientid" nillable="true"
   type="xsd:string" />
  <element name="securitytoken" nillable="true"
   type="xsd:string" />
  <element maxOccurs="unbounded" minOccurs="0"
   name="plzinfos" type="tns2:PLZInfo" />
 </sequence>
</complexType>
</element>
...
<complexType name="PLZInfo">
 <sequence>
  <element name="kurzname" nillable="true"
   type="xsd:string" />
  <element name="plz" nillable="true"
   type="xsd:string" />
  <element name="stadt" nillable="true"
   type="xsd:string" />
  <element name="status" nillable="true"
   type="xsd:string" />
  <element name="typ" nillable="true"
   type="xsd:string" />
  <element name="zusatz" nillable="true"
   type="xsd:string" />
 </sequence>
</complexType>
...

 

And here is my code:

...
while(...) {
 # Hash zusammenbasteln
 $hash{"kurzname"} = $kurzname;
 $hash{"plz"} = $plz;
 $hash{"stadt"} = $stadt;
 $hash{"status"} = $status;
 $hash{"typ"} = $typ;
 $hash{"zusatz"} = $zusatz;

 push(@ary,%hash);
}

eval {
 $dss->updatePLZInformationen(@ary); 
};
...
sub updatePLZInformationen() {
 my @data = shift();
 
 my $plz = SOAP::Lite
    -> service('file:/path/Service.wsdl');
 
 $plz->updatePLZInformationen(SOAP::Data->type("xsd:string")->name("clientid" => "foo")->value,
         SOAP::Data->type("xsd:string")->name("securitytoken" => "bar")->value,
         SOAP::Data->type("tns2:PLZInfo")->name("plzinfos" => @data));
}

My problem is, that the last argument ("plzinfos") does not seem to be correct, because the ITDI does not recognize it as an array.

 

Any hints, tipps, etc. would be highly appreciated :-)

 

Thanks in advance,

 

Thorsten

[Soaplite-devel] Problems with SOAP::Lite client

[Thorsten H. <tho...@ar...>]

Hi,
 
I'm currently writing a client using SOAP::Lite, that connects to an IBM Tivoli Data Integrator.
 
Here are some excerpts from the wsdl-file:
...
<element name="updatePLZInformationen">
<complexType>
 <sequence>
  <element name="clientid" nillable="true"
   type="xsd:string" />
  <element name="securitytoken" nillable="true"
   type="xsd:string" />
  <element maxOccurs="unbounded" minOccurs="0"
   name="plzinfos" type="tns2:PLZInfo" />
 </sequence>
</complexType>
</element>
...
<complexType name="PLZInfo">
 <sequence>
  <element name="kurzname" nillable="true"
   type="xsd:string" />
  <element name="plz" nillable="true"
   type="xsd:string" />
  <element name="stadt" nillable="true"
   type="xsd:string" />
  <element name="status" nillable="true"
   type="xsd:string" />
  <element name="typ" nillable="true"
   type="xsd:string" />
  <element name="zusatz" nillable="true"
   type="xsd:string" />
 </sequence>
</complexType>
...
 
And here is my code:
...
while(...) {
 # Hash zusammenbasteln
 $hash{"kurzname"} = $kurzname;
 $hash{"plz"} = $plz;
 $hash{"stadt"} = $stadt;
 $hash{"status"} = $status;
 $hash{"typ"} = $typ;
 $hash{"zusatz"} = $zusatz;

 push(@ary,%hash);
}

eval {
 $dss->updatePLZInformationen(@ary); 
};
...
sub updatePLZInformationen() {
 my @data = shift();
 
 my $plz = SOAP::Lite
    -> service('file:/path/Service.wsdl');
 
 $plz->updatePLZInformationen(SOAP::Data->type("xsd:string")->name("clientid" => "foo")->value,
         SOAP::Data->type("xsd:string")->name("securitytoken" => "bar")->value,
         SOAP::Data->type("tns2:PLZInfo")->name("plzinfos" => @data));
}

My problem is, that the last argument ("plzinfos") does not seem to be correct, because the ITDI does not recognize it as an array.
 
Any hints, tipps, etc. would be highly appreciated :-)
 
Thanks in advance,
 
Thorsten

[Soaplite-devel] getting remote address info

[Gusti A. <gus...@gm...>]

Hi,
  I plan  using soaplite HTTP::Daemon as my service server, and when the
request come i would like to get the ip addresses info of the requester, is
there a way to do this with soaplite?

Thanks

Regards
Gusti Andika

Re: [Soaplite-devel] Soap::Lite License

[Paul K. <pau...@ya...>]

> I need to check if I can add SOAP::Lite to the xCAT dependencies or if that module has to be installed by each user individually.

Both options should be available to you based on what I know about licensing.

Paul.

--- On Mon, 11/10/08, sf...@ma... <sf...@ma...> wrote:

> From: sf...@ma... <sf...@ma...>
> Subject: Re: [Soaplite-devel] Soap::Lite License
> To: sc...@pe...
> Cc: soa...@li...
> Date: Monday, November 10, 2008, 9:44 AM
> Hi Scott and Leo,
> 
> I did not realize that all the license information can be
> found in the
> perldoc when I was scanning the web pages for /.+ License/
> ...
> So I thank you for the quick answer.
> 
> To my project: I wrote a plugin, which supports VirtualBox
> virtual
> machines (virtualbox.org) for the Extreme Cluster
> Administration
> Toolkit 2.1 (xcat.sourceforge.net). This way you can
> realize
> virtualized clusters with open source software only, which
> are pretty
> much platform independent. That means, this cluster can run
> on one or
> more physical machines, with Linux/Windows/Mac OS. An
> application is
> the demonstration of such clusters e.g for Sales without
> the hardware
> costs, or for use on machines with high CPU and memory
> ressources.
> I am going to contribute this plugin to the xCAT project
> using the
> SOAP::Lite package, so I need to check if I can add
> SOAP::Lite to the
> xCAT dependencies or if that module has to be installed by
> each user
> individually.
> 
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK
> & win great prizes
> Grand prize is a trip for two to an Open Source event
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Soaplite-devel mailing list
> Soa...@li...
> https://lists.sourceforge.net/lists/listinfo/soaplite-devel

Re: [Soaplite-devel] Soap::Lite License

[<sf...@ma...>]

Hi Scott and Leo,

I did not realize that all the license information can be found in the
perldoc when I was scanning the web pages for /.+ License/ ...
So I thank you for the quick answer.

To my project: I wrote a plugin, which supports VirtualBox virtual
machines (virtualbox.org) for the Extreme Cluster Administration
Toolkit 2.1 (xcat.sourceforge.net). This way you can realize
virtualized clusters with open source software only, which are pretty
much platform independent. That means, this cluster can run on one or
more physical machines, with Linux/Windows/Mac OS. An application is
the demonstration of such clusters e.g for Sales without the hardware
costs, or for use on machines with high CPU and memory ressources.
I am going to contribute this plugin to the xCAT project using the
SOAP::Lite package, so I need to check if I can add SOAP::Lite to the
xCAT dependencies or if that module has to be installed by each user
individually.

Re: [Soaplite-devel] Soap::Lite License

[Scott W. <sc...@pe...>]

On Mon, Nov 10, 2008 at 09:39:39AM +0100, sf...@ma... wrote:
> Hello,
> 
> I would like to use the Soap::Lite in a project, which is developed
> under the Eclipse Public License. Under what license is Soap::Lite
> available and is it possible to include the package in other projects?
> 
> I would appreciate a short answer...

Let's see... short answer...

% perldoc SOAP::Lite
/COPYRIGHT

Here we go...

  COPYRIGHT
       Copyright (C) 2000−2005 Paul Kulchenko. All rights reserved.

       This library is free software; you can redistribute it and/or modify it
       under the same terms as Perl itself.

       This text and all associated documentation for this library is made
       available under the Creative Commons Attribution‐NoDerivs 2.0 license.
       http://creativecommons.org/licenses/by−nd/2.0/

Short answer: same terms as Perl itself (see perldoc perlartistic).

You can find any Perl module's licensing by reading that module's
documentation (usually near the bottom of it) in the COPYRIGHT and/or
LICENSE section.

Good luck with your project,

Scott
-- 
Scott Wiersdorf
<sc...@pe...>

[Soaplite-devel] Soap::Lite License

[<sf...@ma...>]

Hello,

I would like to use the Soap::Lite in a project, which is developed
under the Eclipse Public License. Under what license is Soap::Lite
available and is it possible to include the package in other projects?

I would appreciate a short answer...

Regards, Maurice

[Soaplite-devel] #soap-lite on irc.perl.org

[Martin K. <mar...@fe...>]

Hi there,

Matt S Trout kindly set up this channel on irc.perl.org and currently
acts as channel admin.

Maybe you'd like to hang out there from time to time.

Martin

[Soaplite-devel] soap::lite multipart/related

[kristof c. <kri...@ns...>]

Hi,


I have a question about calling a soap service with mime attachments:


This is my code:
my $ent = build MIME::Entity
  Encoding    => "base64",
  Path        => "/test.jpg",
  Filename    => "test.jpg",
  Disposition => "inline";


@parts = ($ent);
                $soap_response = SOAP::Lite
                -> proxy("http://192.168.168.163:8887/cgi-bin/WebObjects/Vit2Print.woa/SAAJ/Vit2PrintFileTransmit 
")
		->parts(\@parts)
                -> uploadImage("aa","bb");
        };






normally we expect the message to be :


MIME-Version: 1.0
Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml;
        start="<cla...@cl...>"
Content-Description: This is the optional message description.

--MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <cla...@cl...>

<?xml version='1.0' ?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
..
<theSignedForm href="cid:cla...@cl..."/>
..
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

--MIME_boundary
Content-Type: image/tiff
Content-Transfer-Encoding: binary
Content-ID: <cla...@cl...>

...binary TIFF image...
--MIME_boundary--


But with soap::lite we lose the multipart/related header. (indicated  
in red)
Can we do something about that ?

This is a multi-part message in MIME format...

------------=_1222162390-89317-0
Content-Type: text/xml
Content-Disposition: inline
Content-Location: /main_envelope
Content-ID: <main_envelope>

<?xml version="1.0" encoding="UTF-8"?><soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance 
" xmlns:soapenc=
"http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema 
" soap:encodingStyle="http://schem
as.xmlsoap.org/soap/encoding/" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/ 
"><soap:Body><uploadImage><c-gensym3
xsi:type="xsd:string">aa</c-gensym3><c-gensym5  
xsi:type="xsd:string">bb</c-gensym5></uploadImage></soap:Body></ 
soap:Envelope>
------------=_1222162390-89317-0
Content-Type: image/gif; name="test.jpg"
Content-Disposition: attachment; filename="test.jpg"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Mailer: MIME-tools 5.420 (Entity 5.420)

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA




______________________________________________________________________
Looking for Web-to-Print Solutions?
Visit our website : http://www.vit2print.com


This e-mail, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information and/or information protected by
intellectual property rights.
If you are not the intended recipient, please note that any review,
dissemination, disclosure, alteration, printing, copying or
transmission of this e-mail and/or any file transmitted with it, is
strictly prohibited and may be unlawful.
If you have received this e-mail by mistake, please immediately notify
the sender and permanently delete the original as well as any copy of
any e-mail and any printout thereof.
We may monitor e-mail to and from our network.

NSS nv Tieltstraat 167 8740 Pittem Belgium






Looking for Web-to-Print Solutions?
Visit our website :   http://www.vit2print.com


This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information and/or information protected by intellectual property rights.
If you are not the intended recipient, please note that any review, dissemination, disclosure, alteration, printing, copying or transmission of this e-mail and/or any file transmitted with it, is strictly prohibited and may be unlawful.
If you have received this e-mail by mistake, please immediately notify the sender and permanently delete the original as well as any copy of any e-mail and any printout thereof.
We may monitor e-mail to and from our network.

NSS nv Tieltstraat 167 8740 Pittem Belgium 

Re: [Soaplite-devel] Why does value slot of SOM object not include attribute data?

[Jason S. <jas...@gm...>]

Hey Martin,

On Thu, Sep 18, 2008 at 11:30 PM, Martin Kutter
<mar...@fe...> wrote:
> Hi Jason,
>
> your proposed patch reads fine - I'll try it out.

cool, thanks!

> I don't know whether o_value is used somewhere, or whether there has
> just been some planned usage which has been left unimplemented  - I'll
> have to look it up.
>
> SOAP::Lite's biggest problem by now is that the test suite is relatively
> weak, so we cannot tell whether some change breaks existing SOAP::Lite
> applications. And SOAP::Lite is so widespread that breaking existing
> code is a pretty bad thing...

Ah, good to know that. How can I help? I have a contract that will pay
me money to help SOAP::Lite improve itself.

Can I add more test cases? If so which ones would be good to focus on?

Does the documentation need updating? Which parts? Do new pieces need
adding - I heard someone mention the idea of a cookbook.

Does the code need to be re-worked? I don't have much of an issue with
the code as it stands - but I do find a large number of subroutines
that have similar names and similar purposes and aren't exactly clear
as to what they do. But that is because I am new to the codebase.

Any other ways that I could spend someone else's money and help the
Perl and SOAP::Lite community?

Cheers, jas.

Re: [Soaplite-devel] Making SOAP::Lite painlessly support document-literal encoding

[Jason S. <jas...@gm...>]

Hey All,

I like your suggestions Martin.

I think the namespace SOAP::Lite::Server::Document is definitely the way to go.

I support the idea of using a SOAP::Data object in addition to an XML
scalar as the value for either the client or the server.

I will make a patch and some test cases and send them to the list.

Cheers, jas.

On Thu, Sep 18, 2008 at 11:25 PM, Martin Kutter
<mar...@fe...> wrote:
> Hi Jason,
>
> forcing the server developer to create XML may or may not be a good
> idea, depending on it's complexity.
>
> How about making the proposed SOAP::Server::Document a bit more DWIM by
> accepting either a scalar (which is supposed to be plain XML) or a
> SOAP::Data object?
>
> This would ease migration for existing web services which want to move
> to SOAP::Server::Document
>
> Maybe SOAP::Lite::Server::Document would be the more appropriate name -
> the use of the SOAP namespace has provoked numerous errors on CPAN, so
> SOAP::Lite is a better namespace for new modules.
>
> Thanks for your ideas,
>
> Martin
>
> Am Donnerstag, den 18.09.2008, 14:10 +0530 schrieb Jason Stewart:
>> Hey All,
>>
>> So I've been doing a lot of digging through the codebase understanding
>> how doc/lit could be used at the moment, and I find that the ease of
>> use that S::L provides for rpc/enc is not matched in it's doc/lit
>> support. I don't think it would take very much effort to enable simple
>> support for doc/lit on both the client and the server - but very
>> likely there would be issues with compatibility with Java and .NET
>> implementations that would have to be worked out.
>>
>> For me the major difference is that a client wanting to use a doc/lit
>> service wants to simply attach a pre-produced XML payload to the soap
>> message - and the server wants to retrieve that message - WITHOUT ANY
>> INTERFERENCE FROM SOAP::LIT.
>>
>> so we have:
>>
>> -- begin of client.pl 8< --
>>
>> use SOAP::Lite;
>> my $soap = SOAP::Lite->new( proxy => 'http://localhost:80/helloworld.pl');
>>
>> my $xml =<<XML;
>>  <sayHello xmlns="urn:HelloWorld">
>>    <name>Kutter</name>
>>    <givenName>Martin</givenName>
>>  </sayHello>
>>
>>  <sayHelloResponse>
>>    <sayHelloResult>Hello Martin Kutter!</sayHelloResult>
>>  </sayHelloResponse>
>> XML
>>
>> $soap->on_action( sub { "urn:HelloWorld#sayHello" });
>> $soap->autotype(0);
>> $soap->default_ns('urn:HelloWorld');
>>
>> my $som = $soap->document($xml)->call("sayHello");
>>
>>  die $som->fault->{ faultstring } if ($som->fault);
>>  print $som->result, "\n";
>>
>> -- end of client.pl --
>>
>> -- begin server.pl 8< --
>>
>> package HelloWorld;
>> use SOAP::Lite;
>>
>> use base qw(SOAP::Server::Document);
>>
>> sub sayHello {
>>   my $self = shift;
>>   my $doc = shift;
>>   my $som = shift;
>>
>>   my $ret_val = some_processing_method($doc);
>>   return $ret_val;
>> }
>>
>> -- end of server.pl --
>>
>> The client builds an XML document inserts it into the request using
>> the document() method on the SOAP object.
>>
>> The client subclasses from SOAP::Server::Document so it gets the XML
>> payload as the second argument on the stack, processes it somehow, and
>> returns an XML payload back to the client.
>>
>> feedback?
>>
>> Cheers, jas.
>>
>
>

Re: [Soaplite-devel] Why does value slot of SOM object not include attribute data?

[Martin K. <mar...@fe...>]

Hi Jason,

your proposed patch reads fine - I'll try it out.

I don't know whether o_value is used somewhere, or whether there has
just been some planned usage which has been left unimplemented  - I'll
have to look it up.

SOAP::Lite's biggest problem by now is that the test suite is relatively
weak, so we cannot tell whether some change breaks existing SOAP::Lite
applications. And SOAP::Lite is so widespread that breaking existing
code is a pretty bad thing...

Martin

Am Donnerstag, den 18.09.2008, 13:56 +0530 schrieb Jason Stewart:
> Hey All,
> 
> Is there any feedback on this?
> 
> I would like to clean up the deserialize(), decode(), decode_object(),
> decode_value() maze - but I don't understand the implications of how
> these subs are inter-connected.
> 
> My reading of the code is that the information that is stored in the
> o_value slot of the SOM object is *useless* - the attribute
> information has been discarded. Since the deserializer has already
> parsed this and stored it all in the _content element of the SOM
> object - why is this being re-parsed?
> 
> Cheers, jas.
> 
> On Sun, Sep 14, 2008 at 1:17 PM, Jason Stewart
> <jas...@gm...> wrote:
> > Hey Martin,
> >
> > On Sat, Sep 13, 2008 at 11:32 AM, Martin Kutter
> > <mar...@fe...> wrote:
> >> ... then we probably should change the deserializer to fill all
> >> appropriate slots: With a XML node containing XML attributes, clearly
> >> the attr slot should be filled.
> >
> > Here is what I find about the deserializer:
> > deserialize() first calls decode() and then calls decode_object()
> > which calls decode_value()
> >
> > decode_value() calls decode_object() for each child element.
> >
> > decode_value() returns the $child_name and the $child_value.
> >
> > decode_value() does *not* encode the attributes into the $child_value
> > in any way. So that is the main issue.
> >
> > Here is a meta point. I have no idea why decode_object() is ever
> > called by deserialize - presumably it sets up some important SOAP
> > internal information. But all the XML data is present after the call
> > to decode(). The building up of the o_value slot for the SOM object is
> > a waste of time as far as I can tell - given that the return value of
> > decode() is a perl data structure representation of the XML, why build
> > up a second one that is missing data?
> >
> > I don't think the SOM methods should use the o_value slot, and instead
> > should use the complete data structure that is present in the _content
> > key of the SOM object.
> >
> > Given how new I am at the SOAP code, it is very likely I've
> > misunderstood something.
> >
> > Any feedback?
> >
> > Cheers, jas.
> >
> 

Re: [Soaplite-devel] Making SOAP::Lite painlessly support document-literal encoding

[Martin K. <mar...@fe...>]

Hi Jason,

forcing the server developer to create XML may or may not be a good
idea, depending on it's complexity.

How about making the proposed SOAP::Server::Document a bit more DWIM by
accepting either a scalar (which is supposed to be plain XML) or a
SOAP::Data object?

This would ease migration for existing web services which want to move
to SOAP::Server::Document

Maybe SOAP::Lite::Server::Document would be the more appropriate name -
the use of the SOAP namespace has provoked numerous errors on CPAN, so
SOAP::Lite is a better namespace for new modules.

Thanks for your ideas,

Martin

Am Donnerstag, den 18.09.2008, 14:10 +0530 schrieb Jason Stewart:
> Hey All,
> 
> So I've been doing a lot of digging through the codebase understanding
> how doc/lit could be used at the moment, and I find that the ease of
> use that S::L provides for rpc/enc is not matched in it's doc/lit
> support. I don't think it would take very much effort to enable simple
> support for doc/lit on both the client and the server - but very
> likely there would be issues with compatibility with Java and .NET
> implementations that would have to be worked out.
> 
> For me the major difference is that a client wanting to use a doc/lit
> service wants to simply attach a pre-produced XML payload to the soap
> message - and the server wants to retrieve that message - WITHOUT ANY
> INTERFERENCE FROM SOAP::LIT.
> 
> so we have:
> 
> -- begin of client.pl 8< --
> 
> use SOAP::Lite;
> my $soap = SOAP::Lite->new( proxy => 'http://localhost:80/helloworld.pl');
> 
> my $xml =<<XML;
>  <sayHello xmlns="urn:HelloWorld">
>    <name>Kutter</name>
>    <givenName>Martin</givenName>
>  </sayHello>
> 
>  <sayHelloResponse>
>    <sayHelloResult>Hello Martin Kutter!</sayHelloResult>
>  </sayHelloResponse>
> XML
> 
> $soap->on_action( sub { "urn:HelloWorld#sayHello" });
> $soap->autotype(0);
> $soap->default_ns('urn:HelloWorld');
> 
> my $som = $soap->document($xml)->call("sayHello");
> 
>  die $som->fault->{ faultstring } if ($som->fault);
>  print $som->result, "\n";
> 
> -- end of client.pl --
> 
> -- begin server.pl 8< --
> 
> package HelloWorld;
> use SOAP::Lite;
> 
> use base qw(SOAP::Server::Document);
> 
> sub sayHello {
>   my $self = shift;
>   my $doc = shift;
>   my $som = shift;
> 
>   my $ret_val = some_processing_method($doc);
>   return $ret_val;
> }
> 
> -- end of server.pl --
> 
> The client builds an XML document inserts it into the request using
> the document() method on the SOAP object.
> 
> The client subclasses from SOAP::Server::Document so it gets the XML
> payload as the second argument on the stack, processes it somehow, and
> returns an XML payload back to the client.
> 
> feedback?
> 
> Cheers, jas.
> 

Re: [Soaplite-devel] Making SOAP::Lite painlessly support document-literal encoding

[<ma...@il...>]

Hi all!  Greetings from the Barcelona Supercomputing Center where I just gave a talk on Moby-2 :-)

Could someone please forward this discussion to the Moby-dev list?  The people here are **very** interested in what's happening in this sub-project of Moby!!

Thanks!

M



On the Road!

-----Original Message-----
From: "Ed Kawas" <ed....@gm...>

Date: Thu, 18 Sep 2008 07:54:49 
To: 'Jason Stewart'<jas...@gm...>; 'Mark'<ma...@il...>; 'Martin Kutter'<mar...@fe...>; <soa...@li...>
Subject: RE: Making SOAP::Lite painlessly support document-literal encoding


Hi Jason,

I like the fact that you hand off the XML document to the server service
developer. Also the ability of the client to just attach a document looks
good too. I wonder how other toolkits do it? I am pretty sure that if the
soap envelope was compatible with other toolkits and all I could do was
get/set the XML document, I would definitely start using S::L for doc/lit
services.

Eddie

-----Original Message-----
From: Jason Stewart [mailto:jas...@gm...]
Sent: September-18-08 1:40 AM
To: Mark; Martin Kutter; soa...@li...; Ed Kawas
Subject: Making SOAP::Lite painlessly support document-literal encoding

Hey All,

So I've been doing a lot of digging through the codebase understanding
how doc/lit could be used at the moment, and I find that the ease of
use that S::L provides for rpc/enc is not matched in it's doc/lit
support. I don't think it would take very much effort to enable simple
support for doc/lit on both the client and the server - but very
likely there would be issues with compatibility with Java and .NET
implementations that would have to be worked out.

For me the major difference is that a client wanting to use a doc/lit
service wants to simply attach a pre-produced XML payload to the soap
message - and the server wants to retrieve that message - WITHOUT ANY
INTERFERENCE FROM SOAP::LIT.

so we have:

-- begin of client.pl 8< --

use SOAP::Lite;
my $soap = SOAP::Lite->new( proxy => 'http://localhost:80/helloworld.pl');

my $xml =<<XML;
 <sayHello xmlns="urn:HelloWorld">
   <name>Kutter</name>
   <givenName>Martin</givenName>
 </sayHello>

 <sayHelloResponse>
   <sayHelloResult>Hello Martin Kutter!</sayHelloResult>
 </sayHelloResponse>
XML

$soap->on_action( sub { "urn:HelloWorld#sayHello" });
$soap->autotype(0);
$soap->default_ns('urn:HelloWorld');

my $som = $soap->document($xml)->call("sayHello");

 die $som->fault->{ faultstring } if ($som->fault);
 print $som->result, "\n";

-- end of client.pl --

-- begin server.pl 8< --

package HelloWorld;
use SOAP::Lite;

use base qw(SOAP::Server::Document);

sub sayHello {
  my $self = shift;
  my $doc = shift;
  my $som = shift;

  my $ret_val = some_processing_method($doc);
  return $ret_val;
}

-- end of server.pl --

The client builds an XML document inserts it into the request using
the document() method on the SOAP object.

The client subclasses from SOAP::Server::Document so it gets the XML
payload as the second argument on the stack, processes it somehow, and
returns an XML payload back to the client.

feedback?

Cheers, jas.

Re: [Soaplite-devel] Making SOAP::Lite painlessly support document-literal encoding

[Ed K. <ed....@gm...>]

Hi Jason,

I like the fact that you hand off the XML document to the server service
developer. Also the ability of the client to just attach a document looks
good too. I wonder how other toolkits do it? I am pretty sure that if the
soap envelope was compatible with other toolkits and all I could do was
get/set the XML document, I would definitely start using S::L for doc/lit
services.

Eddie

-----Original Message-----
From: Jason Stewart [mailto:jas...@gm...] 
Sent: September-18-08 1:40 AM
To: Mark; Martin Kutter; soa...@li...; Ed Kawas
Subject: Making SOAP::Lite painlessly support document-literal encoding

Hey All,

So I've been doing a lot of digging through the codebase understanding
how doc/lit could be used at the moment, and I find that the ease of
use that S::L provides for rpc/enc is not matched in it's doc/lit
support. I don't think it would take very much effort to enable simple
support for doc/lit on both the client and the server - but very
likely there would be issues with compatibility with Java and .NET
implementations that would have to be worked out.

For me the major difference is that a client wanting to use a doc/lit
service wants to simply attach a pre-produced XML payload to the soap
message - and the server wants to retrieve that message - WITHOUT ANY
INTERFERENCE FROM SOAP::LIT.

so we have:

-- begin of client.pl 8< --

use SOAP::Lite;
my $soap = SOAP::Lite->new( proxy => 'http://localhost:80/helloworld.pl');

my $xml =<<XML;
 <sayHello xmlns="urn:HelloWorld">
   <name>Kutter</name>
   <givenName>Martin</givenName>
 </sayHello>

 <sayHelloResponse>
   <sayHelloResult>Hello Martin Kutter!</sayHelloResult>
 </sayHelloResponse>
XML

$soap->on_action( sub { "urn:HelloWorld#sayHello" });
$soap->autotype(0);
$soap->default_ns('urn:HelloWorld');

my $som = $soap->document($xml)->call("sayHello");

 die $som->fault->{ faultstring } if ($som->fault);
 print $som->result, "\n";

-- end of client.pl --

-- begin server.pl 8< --

package HelloWorld;
use SOAP::Lite;

use base qw(SOAP::Server::Document);

sub sayHello {
  my $self = shift;
  my $doc = shift;
  my $som = shift;

  my $ret_val = some_processing_method($doc);
  return $ret_val;
}

-- end of server.pl --

The client builds an XML document inserts it into the request using
the document() method on the SOAP object.

The client subclasses from SOAP::Server::Document so it gets the XML
payload as the second argument on the stack, processes it somehow, and
returns an XML payload back to the client.

feedback?

Cheers, jas.

[Soaplite-devel] Making SOAP::Lite painlessly support document-literal encoding

[Jason S. <jas...@gm...>]

Hey All,

So I've been doing a lot of digging through the codebase understanding
how doc/lit could be used at the moment, and I find that the ease of
use that S::L provides for rpc/enc is not matched in it's doc/lit
support. I don't think it would take very much effort to enable simple
support for doc/lit on both the client and the server - but very
likely there would be issues with compatibility with Java and .NET
implementations that would have to be worked out.

For me the major difference is that a client wanting to use a doc/lit
service wants to simply attach a pre-produced XML payload to the soap
message - and the server wants to retrieve that message - WITHOUT ANY
INTERFERENCE FROM SOAP::LIT.

so we have:

-- begin of client.pl 8< --

use SOAP::Lite;
my $soap = SOAP::Lite->new( proxy => 'http://localhost:80/helloworld.pl');

my $xml =<<XML;
 <sayHello xmlns="urn:HelloWorld">
   <name>Kutter</name>
   <givenName>Martin</givenName>
 </sayHello>

 <sayHelloResponse>
   <sayHelloResult>Hello Martin Kutter!</sayHelloResult>
 </sayHelloResponse>
XML

$soap->on_action( sub { "urn:HelloWorld#sayHello" });
$soap->autotype(0);
$soap->default_ns('urn:HelloWorld');

my $som = $soap->document($xml)->call("sayHello");

 die $som->fault->{ faultstring } if ($som->fault);
 print $som->result, "\n";

-- end of client.pl --

-- begin server.pl 8< --

package HelloWorld;
use SOAP::Lite;

use base qw(SOAP::Server::Document);

sub sayHello {
  my $self = shift;
  my $doc = shift;
  my $som = shift;

  my $ret_val = some_processing_method($doc);
  return $ret_val;
}

-- end of server.pl --

The client builds an XML document inserts it into the request using
the document() method on the SOAP object.

The client subclasses from SOAP::Server::Document so it gets the XML
payload as the second argument on the stack, processes it somehow, and
returns an XML payload back to the client.

feedback?

Cheers, jas.

Re: [Soaplite-devel] Why does value slot of SOM object not include attribute data?

[Jason S. <jas...@gm...>]

Hey All,

Is there any feedback on this?

I would like to clean up the deserialize(), decode(), decode_object(),
decode_value() maze - but I don't understand the implications of how
these subs are inter-connected.

My reading of the code is that the information that is stored in the
o_value slot of the SOM object is *useless* - the attribute
information has been discarded. Since the deserializer has already
parsed this and stored it all in the _content element of the SOM
object - why is this being re-parsed?

Cheers, jas.

On Sun, Sep 14, 2008 at 1:17 PM, Jason Stewart
<jas...@gm...> wrote:
> Hey Martin,
>
> On Sat, Sep 13, 2008 at 11:32 AM, Martin Kutter
> <mar...@fe...> wrote:
>> ... then we probably should change the deserializer to fill all
>> appropriate slots: With a XML node containing XML attributes, clearly
>> the attr slot should be filled.
>
> Here is what I find about the deserializer:
> deserialize() first calls decode() and then calls decode_object()
> which calls decode_value()
>
> decode_value() calls decode_object() for each child element.
>
> decode_value() returns the $child_name and the $child_value.
>
> decode_value() does *not* encode the attributes into the $child_value
> in any way. So that is the main issue.
>
> Here is a meta point. I have no idea why decode_object() is ever
> called by deserialize - presumably it sets up some important SOAP
> internal information. But all the XML data is present after the call
> to decode(). The building up of the o_value slot for the SOM object is
> a waste of time as far as I can tell - given that the return value of
> decode() is a perl data structure representation of the XML, why build
> up a second one that is missing data?
>
> I don't think the SOM methods should use the o_value slot, and instead
> should use the complete data structure that is present in the _content
> key of the SOM object.
>
> Given how new I am at the SOAP code, it is very likely I've
> misunderstood something.
>
> Any feedback?
>
> Cheers, jas.
>

Re: [Soaplite-devel] Why does value slot of SOM object not include attribute data?

[Jason S. <jas...@gm...>]

Hey everyone,

Is there any feedback on this?

I would like the output of dataof() to return a SOAP::Data object that
can be serialized into the XML that it was created from - and
currently it is broken. My proposed patch would fix this.

Cheers, jas.

On Sun, Sep 14, 2008 at 12:32 PM, Jason Stewart
<jas...@gm...> wrote:
> Hey Martin,
>
> I don't believe the only issue is with the deserializer - I believe it
> is also with the _as_data() method of SOAP::SOM. Here is the current
> method:
>
> sub _as_data {
>    my $self = shift;
>    my $pointer = shift;
>
>    SOAP::Data
>        -> new(prefix => '', name => o_qname($pointer), name =>
> o_lname($pointer), attr => o_lattr($pointer))
>        -> set_value(o_value($pointer));
> }
>
> First the 'name' key to new() is duplicated - seems like a bug, and
> second the value is set to o_value($pointer) - which is just the
> simple hash-reference given by the deserializer. This is not recursive
> - so unless o_value($pointer) return a valid SOAP::Data instance this
> is useless.
>
> I suggest the following recursive fix:
>
> sub _as_data {
>  my $self = shift;
>  my $node = shift;
>
>  my $data = SOAP::Data->name(o_qname($node))->attr(o_attr($node));
>
>  if (defined o_child($node)) {
>    my @children;
>    foreach my $child (@{ o_child($node) }) {
>      push(@children,$self->_as_data($child));
>    }
>    $data->set_value(\SOAP::Data->value(@children));
>  } else {
>    $data->value(o_value($node));
>  }
>
>  return $data;
> }
>
> This now produces a correct SOAP::Data object with all the attributes
> included for the subelements.
>
> Any feedback? jas.
>
> On Sat, Sep 13, 2008 at 11:32 AM, Martin Kutter
> <mar...@fe...> wrote:
>> ... then we probably should change the deserializer to fill all
>> appropriate slots: With a XML node containing XML attributes, clearly
>> the attr slot should be filled.
>>
>> Martin
>>
>>
>> Am Freitag, den 12.09.2008, 17:03 +0530 schrieb Jason Stewart:
>>> Hey,
>>>
>>> I dug a bit deeper...
>>>
>>> Maybe what I need to understand here is why the SOAP::SOM object that
>>> is generated by the deserializer has the construct that is the
>>> sub-elements without attributes as the value slot.
>>>
>>> The struct has 7 slots:
>>> 0) qname
>>> 1) attr
>>> 2) child
>>> 3) chars
>>> 4) value
>>> 5) lname
>>> 6) lattr
>>>
>>> The child slot is an accurate representation of the sub-tree with
>>> attributes, but the value slot only has element data (names of
>>> elements as keys, and the text of the elements as values).
>>>
>>> So the whole issue is that the value slot does not include attribute
>>> data. So this is not a bug as a design limitation.
>>>
>>> I'm back at simply wanting to get at the XML payload of the Body tag.
>>> And I'm wanting to set the xml payload of the body response tag
>>> without a gross hack to keep it from being wrapped in a method tag by
>>> the serializer.
>>>
>>> Cheers, jas.
>>>
>>
>>
>

Re: [Soaplite-devel] Why does value slot of SOM object not include attribute data?

[Jason S. <jas...@gm...>]

Hey Martin,

On Sat, Sep 13, 2008 at 11:32 AM, Martin Kutter
<mar...@fe...> wrote:
> ... then we probably should change the deserializer to fill all
> appropriate slots: With a XML node containing XML attributes, clearly
> the attr slot should be filled.

Here is what I find about the deserializer:
deserialize() first calls decode() and then calls decode_object()
which calls decode_value()

decode_value() calls decode_object() for each child element.

decode_value() returns the $child_name and the $child_value.

decode_value() does *not* encode the attributes into the $child_value
in any way. So that is the main issue.

Here is a meta point. I have no idea why decode_object() is ever
called by deserialize - presumably it sets up some important SOAP
internal information. But all the XML data is present after the call
to decode(). The building up of the o_value slot for the SOM object is
a waste of time as far as I can tell - given that the return value of
decode() is a perl data structure representation of the XML, why build
up a second one that is missing data?

I don't think the SOM methods should use the o_value slot, and instead
should use the complete data structure that is present in the _content
key of the SOM object.

Given how new I am at the SOAP code, it is very likely I've
misunderstood something.

Any feedback?

Cheers, jas.

Re: [Soaplite-devel] Why does value slot of SOM object not include attribute data?

[Jason S. <jas...@gm...>]

Hey Martin,

I don't believe the only issue is with the deserializer - I believe it
is also with the _as_data() method of SOAP::SOM. Here is the current
method:

sub _as_data {
    my $self = shift;
    my $pointer = shift;

    SOAP::Data
        -> new(prefix => '', name => o_qname($pointer), name =>
o_lname($pointer), attr => o_lattr($pointer))
        -> set_value(o_value($pointer));
}

First the 'name' key to new() is duplicated - seems like a bug, and
second the value is set to o_value($pointer) - which is just the
simple hash-reference given by the deserializer. This is not recursive
- so unless o_value($pointer) return a valid SOAP::Data instance this
is useless.

I suggest the following recursive fix:

sub _as_data {
  my $self = shift;
  my $node = shift;

  my $data = SOAP::Data->name(o_qname($node))->attr(o_attr($node));

  if (defined o_child($node)) {
    my @children;
    foreach my $child (@{ o_child($node) }) {
      push(@children,$self->_as_data($child));
    }
    $data->set_value(\SOAP::Data->value(@children));
  } else {
    $data->value(o_value($node));
  }

  return $data;
}

This now produces a correct SOAP::Data object with all the attributes
included for the subelements.

Any feedback? jas.

On Sat, Sep 13, 2008 at 11:32 AM, Martin Kutter
<mar...@fe...> wrote:
> ... then we probably should change the deserializer to fill all
> appropriate slots: With a XML node containing XML attributes, clearly
> the attr slot should be filled.
>
> Martin
>
>
> Am Freitag, den 12.09.2008, 17:03 +0530 schrieb Jason Stewart:
>> Hey,
>>
>> I dug a bit deeper...
>>
>> Maybe what I need to understand here is why the SOAP::SOM object that
>> is generated by the deserializer has the construct that is the
>> sub-elements without attributes as the value slot.
>>
>> The struct has 7 slots:
>> 0) qname
>> 1) attr
>> 2) child
>> 3) chars
>> 4) value
>> 5) lname
>> 6) lattr
>>
>> The child slot is an accurate representation of the sub-tree with
>> attributes, but the value slot only has element data (names of
>> elements as keys, and the text of the elements as values).
>>
>> So the whole issue is that the value slot does not include attribute
>> data. So this is not a bug as a design limitation.
>>
>> I'm back at simply wanting to get at the XML payload of the Body tag.
>> And I'm wanting to set the xml payload of the body response tag
>> without a gross hack to keep it from being wrapped in a method tag by
>> the serializer.
>>
>> Cheers, jas.
>>
>
>

Re: [Soaplite-devel] Why does value slot of SOM object not include attribute data?

[Jason S. <jas...@gm...>]

Hey,

I dug a bit deeper...

Maybe what I need to understand here is why the SOAP::SOM object that
is generated by the deserializer has the construct that is the
sub-elements without attributes as the value slot.

The struct has 7 slots:
0) qname
1) attr
2) child
3) chars
4) value
5) lname
6) lattr

The child slot is an accurate representation of the sub-tree with
attributes, but the value slot only has element data (names of
elements as keys, and the text of the elements as values).

So the whole issue is that the value slot does not include attribute
data. So this is not a bug as a design limitation.

I'm back at simply wanting to get at the XML payload of the Body tag.
And I'm wanting to set the xml payload of the body response tag
without a gross hack to keep it from being wrapped in a method tag by
the serializer.

Cheers, jas.

Re: [Soaplite-devel] Fwd: More info on SOAP::Lite document/literal

[Robbie B. <rob...@gm...>]

2008/9/12 Jason Stewart <jas...@gm...>:
>
> Again, fixing the attribute bugs would really solve this.
>

I'm sure if you gave Martin a patch it would be most welcome ;)

Re: [Soaplite-devel] Bug in SOAP::SOM->dataof()

[Jason S. <jas...@gm...>]

Hey Martin,

I dug a bit deeper. I see that the search methods are all working
fine. The methods are create SOAP::Data objects and setting the value
using set_value(o_value($pointer)) and o_value is defined as:

sub o_value { $_[0]->[4] }

Here is the value of $pointer:

0  ARRAY(0x87a7e08)
   0  'soap:Body'
   1  HASH(0x879e348)
        empty hash
   2  ARRAY(0x87a7bc8)
      0  ARRAY(0x879eeac)
         0  'sayHello'
         1  HASH(0x879e3c0)
            'xmlns' => 'urn:HelloWorld'
         2  ARRAY(0x879ebdc)
            0  ARRAY(0x879e588)
               0  'name'
               1  HASH(0x879e480)
                    empty hash
               2  'Kutter'
               3  undef
               4  'Kutter'
               5  '{urn:HelloWorld}name'
               6  HASH(0x879e4f8)
                    empty hash
            1  ARRAY(0x879e918)
               0  'givenName'
               1  HASH(0x879e7b0)
                  'middleName' => 'windy'
               2  'Martin'
               3  undef
               4  'Martin'
               5  '{urn:HelloWorld}givenName'
               6  HASH(0x879e858)
                  'middleName' => 'windy'
         3  undef
         4  HASH(0x879ecfc)
            'givenName' => 'Martin'
            'name' => 'Kutter'
         5  '{urn:HelloWorld}sayHello'
         6  HASH(0x879ee1c)
              empty hash
   3  undef
   4  HASH(0x87a7c88)
      'sayHello' => HASH(0x84dc224)
         'givenName' => 'Martin'
         'name' => 'Kutter'
   5  '{http://schemas.xmlsoap.org/soap/envelope/}Body'
   6  HASH(0x87a7d78)
        empty hash

Looking at the item at index 4 we cans see the hash representation has
been stripped of all it's attributes.

So....

Either these methods should not be doing set_value(o_value($pointer)),

Or, the thing at index 4 is being constructed incorrectly for the SOM object.

Cheers, jas.

Re: [Soaplite-devel] Fwd: More info on SOAP::Lite document/literal

[Jason S. <jas...@gm...>]

Hey Martin,

On Fri, Sep 12, 2008 at 1:49 AM, Martin Kutter <mar...@fe...> wrote:

> 2) What should ->document() do? return the plain XML? Returning the
> content of the soap:Body element is less useful as it may seem - there
> may be information in the header, too.

I was thinking that document() should return the XML content of the
Body tag, but after digging a bit more I think it is unnecessary - as
the SOM class has all the needed methods: body, envelope, header, etc,
but there is the bug with attributes that is making them not useful.

It seems a bit redundant to serialize them, and then deserialize them,
but not such a big deal.

Again, fixing the attribute bugs would really solve this.

> One current workaround could be setting ->outputxml(1) on the SOAP
> object and processing the XML by other means (like XML::Simple or the
> like).

But doesn't this only affect the *client*? This is needed for the *server*.

Cheers, jas.

Re: [Soaplite-devel] Bug in SOAP::SOM->dataof()

[Jason S. <jas...@gm...>]

Hey Martin,

On Fri, Sep 12, 2008 at 1:49 AM, Martin Kutter <mar...@fe...> wrote:
> Hi Jason,
>
> 1) throwing away attributes sounds like a bug to me.

Here is my client:

#!/usr/bin/perl -w
use strict;

use SOAP::Lite; my $soap = SOAP::Lite->new( proxy =>
	    'http://localhost:80/cgi-bin/doc-lit-server-test.pl');

$soap->on_action( sub { "urn:HelloWorld#sayHello" });
$soap->autotype(0);
$soap->default_ns('urn:HelloWorld');

my $som = $soap->call("sayHello",
		      SOAP::Data->name('name')
                                         ->value( 'Kutter' ),
		      SOAP::Data->name('givenName')
                                         ->value('Martin')
                                         ->attr({middleName=>'windy'}),
		     );

die $som->fault->{ faultstring } if ($som->fault);
print $som->result, "\n";

Here is the server:
#!/usr/bin/perl -w
use strict;
use SOAP::Transport::HTTP;

my $server = new SOAP::Transport::HTTP::CGI;
$server->dispatch_to('HelloWorld')
  ->handle;

BEGIN {
  package HelloWorld;
  use SOAP::Lite;
  use Data::Dumper;

  use base qw(SOAP::Server::Parameters);

  sub sayHello {
    my $self = shift;
    my $som = pop;

    warn "Argument Check: ", Dumper($som);

    my $body = $som->dataof('//Body');

    warn "Body Check: ", Dumper($body);

    SOAP::Data->name('sayHelloResult')->value($body);
  }
}

Here is the output in the log file for the two warns:
(I've just taken the _content key from the SOM object)

'_content' => [
  'soap:Envelope',
  {
    'xmlns:soapenc' => 'http://schemas.xmlsoap.org/soap/encoding/',
    'xmlns:xsi' => 'http://www.w3.org/2001/XMLSchema-instance',
    'soap:encodingStyle' => 'http://schemas.xmlsoap.org/soap/encoding/',
    'xmlns:xsd' => 'http://www.w3.org/2001/XMLSchema',
    'xmlns:soap' => 'http://schemas.xmlsoap.org/soap/envelope/'
  },
  [
    [
      'soap:Body',
      {},
      [
        [
          'sayHello',
          {
            'xmlns' => 'urn:HelloWorld'
          },
          [
            [
              'name',
              {},
              'Kutter',
              undef,
              'Kutter',
              '{urn:HelloWorld}name',
              {}
            ],
            [
              'givenName',
              {
                'middleName' => 'windy'
              },
              'Martin',
              undef,
              'Martin',
              '{urn:HelloWorld}givenName',
              {
                'middleName' => 'windy'
              }
            ]
          ],
          undef,
          {
            'name' => 'Kutter',
            'givenName' => 'Martin'
          },
          '{urn:HelloWorld}sayHello',
          {}
        ]
      ],
      undef,
      {
        'sayHello' => $VAR1->{'_content'}[2][0][2][0][4]
      },
      '{http://schemas.xmlsoap.org/soap/envelope/}Body',
      {}
    ]
  ],

and here is the output of dataof():
Body Check: $VAR1 = bless( {
    '_name' => 'Body',
    '_uri' => 'http://schemas.xmlsoap.org/soap/envelope/',
    '_signature' => [],
    '_value' => [
                  {
                    'sayHello' => {
                                  'name' => 'Kutter',
                                  'givenName' => 'Martin'
                                }
                  }
                ],
    '_prefix' => 'soap',
    '_attr' => {}
  }, 'SOAP::Data' );

So dataof() is throwing away all the attributes on the sub-elements of
Body. This seems bad to me, and it seems unintended according to
Martin. So I will look to see why this is happening.

Cheers, jas.