soaplite-devel

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

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

[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

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