SOAP::Lite

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:jason.e.stewart@...] 
Sent: September-18-08 1:40 AM
To: Mark; Martin Kutter; soaplite-devel@...; 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.

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.kawas@...>

Date: Thu, 18 Sep 2008 07:54:49 
To: 'Jason Stewart'<jason.e.stewart@...>; 'Mark'<markw@...>; 'Martin Kutter'<martin.kutter@...>; <soaplite-devel@...>
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:jason.e.stewart@...]
Sent: September-18-08 1:40 AM
To: Mark; Martin Kutter; soaplite-devel@...; 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.

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.
>

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
<martin.kutter@...> 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.
>>
>
>