Hi there,

I've just been looking through cpan, and I'm wondering if I am missing
something obvious.

I can't find anywhere in Soap::Lite where I can set a timeout variable.
I am calling a third party, and sometimes their responses are very slow.
I want to be able to set a maximum response time of 90 seconds (for
example), but can't work out exactly how to do it.

Has anyone done this, and if so, how do I do it?

Thanks

Di

Dianne,

> I can't find anywhere in Soap::Lite where I can set a timeout variable.
> I am calling a third party, and sometimes their responses are very
> slow.
> I want to be able to set a maximum response time of 90 seconds (for
> example), but can't work out exactly how to do it.
>
> Has anyone done this, and if so, how do I do it?

No worries, I ran into the same thing awhile ago.  Here's how I did it:

SOAP::Lite->readable( 1 )->uri( "your_uri" )->proxy( "your_proxy",
timeout => 15 );

Hope this helps!

Regards,

John

Falling You - exploring the beauty of voice and sound
New album, "Touch", available now
http://www.magnatune.com/artists/falling_you

I am happy to see stubmaker.pl and creation of myService.pm
However I am looking for a way for the user of myService.pm to
specify the endpoint either at instantiation of myService or
along the way....something like this

use myService;
my $soa = myService->new ( -endpoint => 'https://localhost:1800');
$soa->thisMethod();
$soa->thatMethod();

Or

my $soa = myService->new();
$soa->endpoint('https://elvis:1800');
$soa->thisMethod();

$soa->endpoint('https://joe:1800');
$soa->thatMethod();

Currently stubmaker.pl is writing the endpoint for all the
discovered methods from WSDL file (hard coded) as in

my %methods = (
   getBbuPcbVersion => {
     endpoint => 'http://localhost:80',
     soapaction => '',
     uri => 'http://www.amcc.com/DAPI/DAPI.xsd',
     parameters => [
       SOAP::Data->new(name => 'obj', type => '', attr => {}),
     ],

Thanks

One of the problems my peers often point out against Perl is that
there are 25 different ways of doing things, from $$ to $PID.
from "key, value" to "key => value", etc.

So I say to them, that is Perl's strength...

However, I fail to see the author's motivation for using
object-message-sequencing approach in his SOAP::Lite's tutorials
and man pages. IMHO, the author should've chosen easy-perl
over cool-perl style.

Here is a typical example, keep in mind that we have
a novice user who is trying to learn a new technology but is
confronted with short cuts and idioms of a language.

print SOAP::Lite
    -> service()
    -> proxy()
    -> someMethod()
    -> result ;

I'll not bore you with the dereferencing operator and when
() should be used and when not and how white spaces are cleaned up
by the interpreter (including newline chars).
If it was me, I'd write my tutorials like this

my $soap = SOAP::Lite->new();
my $svc  = $soap->service();
my $proxy = $svc->proxy();
my $response = $proxy->someMethod();
my $result = $response->result();

print "result = $result \n";

In my opinion, the $obj->method()->method()->method() chaining
while sexy is not debugable as any of the nodes along the way
could've given away. And the interpreter would say line x has problem

If there is some technical reason for coding like this, I'd like
to learn, other wise, may I ask the author to consider this input.


Thank you

On Fri, 4 Mar 2005, Medi Montaseri wrote:
> Here is a typical example, keep in mind that we have
> a novice user who is trying to learn a new technology but is
> confronted with short cuts and idioms of a language.
>
> print SOAP::Lite
>    -> service()
>    -> proxy()
>    -> someMethod()
>    -> result ;
>
> If it was me, I'd write my tutorials like this
>
> my $soap = SOAP::Lite->new();
> my $svc  = $soap->service();
> my $proxy = $svc->proxy();
> my $response = $proxy->someMethod();
> my $result = $response->result();
>
> print "result = $result \n";
>
> In my opinion, the $obj->method()->method()->method() chaining
> while sexy is not debugable as any of the nodes along the way
> could've given away. And the interpreter would say line x has problem

I tend to agree.  I found I needed to insert fault handling code between
each of those.  I ended up doing something like this...


sub main {
     # Connect to the server
     my $soap = create_soap_instance($opt_resource, $opt_server);

     # Create the test service object
     my $response = $soap->call(new => 1);
     soap_assert($response);
     my $testsys = $response->result;

     if (! $testsys) {
         die "Could not create testsys object\n";
     }

     $response = $soap->get_software_types($testsys);
     soap_assert($response);

     if (! $response->result) {
         warn "No results received\n";
         return -1;
     }

     foreach my $row (@{$response->result}) {
         print $row->{software_type}, "\n";
     }
     return 1;
}


sub create_soap_instance {
     my $resource = shift || return undef;
     my $server = shift || return undef;

     my $soap = SOAP::Lite
         -> uri($resource)
         -> proxy($server,
                  options => {compress_threshold => 10000});
     return $soap;
};

sub soap_assert {
     my $response = shift;
     if ($response->fault) {
         print join ', ',
         $response->faultcode,
         $response->faultstring;
         return undef;
     }
     return 1;
}


I think the soap_assert() routine is quite valuable, since it allows
ample use of fault handling without cluttering the main routine into
unreadibility.  I found with the tutorials that the way they were
written made it especially difficult to figure out my own newbie
mistakes, and that if fault handling code had been liberally included,
such as above, I would have gotten error messages much more easily, and
learned SOAP::Lite faster.

Bryce

Hi all -

As interesting as SOAP and web services are, I am pressed for time.
Although I know I'll have to learn more, I simply need a full blown
working "Hello World" example - does not have to be any more
complex.  My requirement is to build a web service that takes a
string and returns a string - should be very straightforward.
However, in one single response, it would be nice to see:

The .pm
The .pl
The .Net code

I don't know if I need a WSDL file - the O'Reilly example site
doesn't allude to one.

The single method should accept a string and return a string.  In
short, if the response contains all of these files and I plop them in
place (fixing the .PM (lib) and perl path), I should be able to
compile the .Net code and execute the method against the service.

I have tried combining some of the examples found so far, and the
farthest I get is a return of "null" from the "HelloWorld" sample.  I
request a working sample that compiles and runs and makes no
assumptions about my familiarity with namespaces, etc.

In short - I need the "Canonical Example for Dummies".

I'm using SOAP::Lite and VS .Net 2003 (C#).

Would any kind soul be able to help?

Best,
Mike

Mike,

I can help you, but keep in mind that I never got it to work with
complex types. When I return rows of data, I just convert my data to the
equivalent of a flat file and return that as a string. It's lame, but it
works.

Anyhow, the attachment just says hello. You place the files from the
perl folder in your web tree where SOAP::Lite is running, then you need
to update the bottom of the WSDL file I included to reflect the web
location on your local machine of the actual sayhellodispatcher.cgi file
(e.g. http://localhost/soap/sayhellodispatcher.cgi). Then you need to
specify to visual studio your local web address to the WSDL file (e.g.
http://localhost/soap/HelloSOAPLite.wsdl ) when you add a web reference.

Let me know if you have any questions.

-Matt

p.s. I tested this example and it works.



m_j_conroy wrote:

>Matt,
>
>I saw your post on Google groups with the WSDL snippet.  Do you have
>an end-to-end example from the .Net code forward for a SOAP::Lite
>server called by a .Net client?  A simple HelloWorld example is
>literally sufficient.  Any help would be much obliged... I realize
>this email is coming out of the blue.
>
>Best,
>Mike Conroy
>
>
>
>
>
>
>

my $ex = SOAP::Lite->proxy('ex.websvc.acme.com:4321')->uri('urn:Ex/WebSvc');
my $resultStruct = $ex->exOp("abcd", [1, 2, 3, 4])->result;

print $resultStruct->{elem1}->[0]->{elem1}, "\n";
print $resultStruct->{elem1}->[0]->{elem2}, "\n";
print $resultStruct->{elem1}->[1]->{elem1}, "\n";
print $resultStruct->{elem1}->[1]->{elem2}, "\n";
print $resultStruct->{elem2}, "\n";

Mike,

I can help you, but keep in mind that I never got it to work with
complex types. When I return rows of data, I just convert my data to the
equivalent of a flat file and return that as a string. It's lame, but it
works.

Anyhow, the attachment just says hello. You place the files from the
perl folder in your web tree where SOAP::Lite is running, then you need
to update the bottom of the WSDL file I included to reflect the web
location on your local machine of the actual sayhellodispatcher.cgi file
(e.g. http://localhost/soap/sayhellodispatcher.cgi). Then you need to
specify to visual studio your local web address to the WSDL file (e.g.
http://localhost/soap/HelloSOAPLite.wsdl ) when you add a web reference.

Let me know if you have any questions.

-Matt

p.s. I tested this example and it works.



m_j_conroy wrote:

>Matt,
>
>I saw your post on Google groups with the WSDL snippet.  Do you have
>an end-to-end example from the .Net code forward for a SOAP::Lite
>server called by a .Net client?  A simple HelloWorld example is
>literally sufficient.  Any help would be much obliged... I realize
>this email is coming out of the blue.
>
>Best,
>Mike Conroy
>
>
>
>
>
> 
>

Greetings!

My task is to write a SOAP server, that would dispatch requests to
some modules using its own "sophisticated" naming scheme. Imagine
that I have several modules somehow located in directory tree, and
I've got a mapping of module names to their paths. Due to some
requirements I cannot place modules in SOAP::Lite's default naming
scheme (like My::Example), but I can dynamically map URI to module and
call the needed methods myself. Is there any possibility to make SOAP
::Transport::HTTP::CGI (or whatever) call some specified sub as a
handler for ANY request, giving method URI to it as a parameter and
taking its result as a respone for SOAP call, while this sub parses
URI and calls the needed modules itself, forming a return value? I'm
not afraid of some additional coding :), but I don't want to patch
original SOAP::Lite distribution, that's why I'm asking you for some
gentle solution.

Many thanks in advance!

Hello.

I'm complete newbie in SOAP::Lite, so please be elenient.

I'm using combination of Apache + mod_perl + Apache::SOAP from SOAP::Lite
distribution.

I'm trying to understand process of object creation on server side
while using WSDL.

For example, I have service 'Hello', represented by module Hello.pm on
server side. I want to call Hello's constructor, passing some data as
its arguments and use it in subsequent calls. But after reading
SOAP::Lite pod doc., I still can't find the way of creating Hello object.
All the samples I've found demonstrate how to make service calls
described by WSDL in non-OO way, i.e.

  use SOAP::Lite;
          print SOAP::Lite
            -> service('http://www.xmethods.net/sd/StockQuoteService.wsdl')
            -> getQuote('MSFT');

But how can I call getQuote as object method rather than class one ?
Any help would be greatly appreciated.

Andrew

Andrew,

>  use SOAP::Lite;
>          print SOAP::Lite
>            ->
> service('http://www.xmethods.net/sd/StockQuoteService.wsdl')
>            -> getQuote('MSFT');

Is this better?

      my $success = eval
      {
           my $service = SOAP::Lite->service( "uri://to.WSDL.file" );
           $service->someMethod( $someParam, @someArrayOParams );
      };

Regards,

John

Falling You - exploring the beauty of voice and sound
New album, "Touch", available now
http://www.magnatune.com/artists/falling_you

--- In soaplite@yahoogroups.com, jmzorko@m... wrote:
>
> Andrew,
>
> >  use SOAP::Lite;
> >          print SOAP::Lite
> >            ->
> > service('http://www.xmethods.net/sd/StockQuoteService.wsdl')
> >            -> getQuote('MSFT');
>
> Is this better?
>
>      my $success = eval
>      {
>           my $service = SOAP::Lite->service( "uri://to.WSDL.file" );
>           $service->someMethod( $someParam, @someArrayOParams );
>      };
>
> Regards,
>
> John
>
> Falling You - exploring the beauty of voice and sound
> New album, "Touch", available now
> http://www.magnatune.com/artists/falling_you

Sorry, I've sent prev. message to the wrong address.
Thanks fore reply. Anyway, this is not what I'm looking for.

$service->someMethod( $someParam, @someArrayOParams );

Code above calls someMethod as a class method rather than object's one.
I.e. I'd like to have object initialized (I also waht to be able to
pass some args. into class' constructor), something like this:

$obj = $service->SOAP::new('args');
$obj->someMethod(11).

I know it is possible without using WSDL thi way:

$service = SOAP::Lite->proxy(..)->uri(..);
$obj = $service->call(new => 'args')->result;
$obj->someMethod('xx');

But I didn't see any directions on using such things with WSDL. All I
saw is just a phrases about that in this case $service is not a
SOAP::SOM. So, does it mean that I can't get object reference while
using WSDL?


Please advise.
Thanks, Andrew

I am trying to accessing the XML results below. I expected the results
to be array of hashes based on my reading. But it appears to be a hash
of hashes. I have include the raw XML results, a portion of the  code
I use to access it and the program run results.  I have tried a number
of different approaches and example code without getting the results I
want. Can anyone see what I am doing wrong?

- Dustin -

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Body>
   <ns1:getTableMetadataResponse
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ns1="urn:com.cisco.nm.wlse.xmlapi.inventory">
    <getTableMetadataReturn xsi:type="ns1:TableMetadata">
     <columns xsi:type="ns1:TableColumn">
      <name xsi:type="xsd:string">CWVLWLANNUCASTKEYINDEX</name>
      <type xsi:type="xsd:string">INTEGER</type>
     </columns>
     <columns xsi:type="ns1:TableColumn">
      <name xsi:type="xsd:string">CWVLWLANNUCASTKEYLEN</name>
      <type xsi:type="xsd:string">INTEGER</type>
     </columns>
     <columns xsi:type="ns1:TableColumn">
      <name xsi:type="xsd:string">CWVLWLANNUCASTKEYVALUE</name>
      <type xsi:type="xsd:string">VARCHAR</type>
     </columns>
     <columns xsi:type="ns1:TableColumn">
      <name xsi:type="xsd:string">VLANID</name>
      <type xsi:type="xsd:string">INTEGER</type>
     </columns>
    </getTableMetadataReturn>
   </ns1:getTableMetadataResponse>
  </soapenv:Body>
</soapenv:Envelope>


Code to print out results

my $tablemeta = SOAP::Lite
   -> proxy('http://XXXX:XXXXXX@10.1.1.9:1741/services/Inventory')
   -> uri('urn:com.cisco.nm.wlse.xmlapi.inventory')
   -> on_debug(sub{print@_})
   -> getTableMetadata($tlisting);

if ($tablemeta->fault) {
   print $tablemeta->faultcode, " ", $tablemeta->faultstring, "\n",
$tablemeta->faultdetail, "\n";
} else {
   my $tablemetawork = $tablemeta->result;
   for my $k1 ( keys %$tablemetawork ) {
     print "k1: $k1\n";
     for my $k2 ( keys %{$tablemetawork->{ $k1 }} ) {
       print "$k1: $k2 $tablemetawork->{ $k1 }{ $k2 }\n";
     }
   }
}


Portion of output
k1: columns
columns: name VLANID
columns: type INTEGER

On 2005-03-06 at 05:42:36 dustintodd wrote:

>I am trying to accessing the XML results below. I expected the
>results
>to be array of hashes based on my reading. But it appears to be a
>hash
>of hashes. I have include the raw XML results, a portion of the  code
>I use to access it and the program run results.  I have tried a
>number
>of different approaches and example code without getting the results
>want. Can anyone see what I am doing wrong?
>
>- Dustin -
I take it that you are not using S::L 0.65, where this issue has been
addressed. This is how Data::Dumper shows the
<getTableMetadataReturn> element

$VAR1 = bless( {
   'columns' => [
     bless( {
       'type' => 'INTEGER',
       'name' => 'CWVLWLANNUCASTKEYINDEX'
     }, 'TableColumn' ),
     bless( {
       'type' => 'INTEGER',
       'name' => 'CWVLWLANNUCASTKEYLEN'
     }, 'TableColumn' ),
     bless( {
       'type' => 'VARCHAR',
       'name' => 'CWVLWLANNUCASTKEYVALUE'
     }, 'TableColumn' ),
     bless( {
       'type' => 'INTEGER',
       'name' => 'VLANID'
     }, 'TableColumn' )
   ]
}, 'TableMetadata' );

If you cannot upgrade to 0.65 then you will need to use an approach
like this:

my $som = $soap->getTableMetadata($tlisting);
my @columns = $som->match('//columns')->valueof;
for my $column (@columns) {
     print "$column->{name} $column->{type}\n";
}


Duncan

On 2005-03-06 at 00:11:13 and11_bf wrote:

>--- In soaplite@yahoogroups.com, jmzorko@m... wrote:
>>
>> Andrew,
>>
>> >  use SOAP::Lite;
>> >          print SOAP::Lite
>> >            ->
>> > service('http://www.xmethods.net/sd/StockQuoteService.wsdl')
>> >            -> getQuote('MSFT');
>>
>> Is this better?
>>
>>      my $success = eval
>>      {
>>           my $service = SOAP::Lite->service( "uri://to.WSDL.file"
>>);
>>           $service->someMethod( $someParam, @someArrayOParams );
>>      };
>>
>> Regards,
>>
>> John
>>
>> Falling You - exploring the beauty of voice and sound
>> New album, "Touch", available now
>> http://www.magnatune.com/artists/falling_you
>
>Sorry, I've sent prev. message to the wrong address.
>Thanks fore reply. Anyway, this is not what I'm looking for.
>
>$service->someMethod( $someParam, @someArrayOParams );
>
>Code above calls someMethod as a class method rather than object's
>one.
>I.e. I'd like to have object initialized (I also waht to be able to
>pass some args. into class' constructor), something like this:
>
>$obj = $service->SOAP::new('args');
>$obj->someMethod(11).
>
>I know it is possible without using WSDL thi way:
>
>$service = SOAP::Lite->proxy(..)->uri(..);
>$obj = $service->call(new => 'args')->result;
>$obj->someMethod('xx');

I don't think this will do what you are claiming. $obj will just be a
variable in your client, it will not have any reference to a remote
object. You still need to do
$soap->someMethod($obj, 'xx');
to pass the object back to the remote system.
>
>But I didn't see any directions on using such things with WSDL. All I
>saw is just a phrases about that in this case $service is not a
>SOAP::SOM. So, does it mean that I can't get object reference while
>using WSDL?
>
Using WSDL you can get the SOAP::SOM object from the most recent call
by

my $result = $service->someMethod();
my $som = $service->call;

The 'O' in SOAP stopped meaning 'Object' a long time ago. It is
probably best to treat SOAP as a mechanism for RPC and for
transferring XML documents. It is not a way of handling remote
objects.
S::L does provide some support for that though using 'autodispatch',
but that will only be of use when both client and server are written
in perl.

Regards
Duncan

Hello,

I tried to define a timeout for a SOAP client:

         my $timeout = 1;
         my $soap = SOAP::Lite
                 -> uri('urn:FooBar')
                 -> proxy('http://localhost:9009', timeout => $timeout)
         ;

My client gets an undefined object from its method call upon
timeout (peeking into the fault data, reveals that it was due to a
timeout).
So far so good.

It seems that the timeout breaks something, so the server
dies too (I get a "Broken pipe" on the server's side).

Anyone knows why the server dies and how to avoid that?

I'm avoiding it now by ignoring sig-pipe signals:
         $SIG{PIPE}='IGNORE';
However, I wonder why this happens and why isn't any of the
lower layers is handling this.


Thanks.

Shlomo.

On Sat, Mar 05, 2005 at 11:03:47AM -0000, ?????? ????? scratched on the wall:

> My task is to write a SOAP server, that would dispatch requests to
> some modules using its own "sophisticated" naming scheme. Imagine
> that I have several modules somehow located in directory tree, and
> I've got a mapping of module names to their paths. Due to some
> requirements I cannot place modules in SOAP::Lite's default naming
> scheme (like My::Example), but I can dynamically map URI to module and
> call the needed methods myself. Is there any possibility to make SOAP
> ::Transport::HTTP::CGI (or whatever) call some specified sub as a
> handler for ANY request, giving method URI to it as a parameter and
> taking its result as a respone for SOAP call, while this sub parses
> URI and calls the needed modules itself, forming a return value? I'm
> not afraid of some additional coding :), but I don't want to patch
> original SOAP::Lite distribution, that's why I'm asking you for some
> gentle solution.

   I am faced with a similar problem.  In addition to not being able to
   use a structured namespace, I need to support an environment where
   security is taken very seriously, but where modules to our SOAP
   server can be written by people without a lot of knowledge or
   understanding of SOAP (in other words, security is my problem, but
   I'm not writing most of the code).

   In addition, all calls are authenticated using SOAP Headers, and
   I wanted to handle that auth/auth centrally, rather than have each
   exported function start with the same four lines of code (assuming
   the developer remembers to put it there!).  I also export both the
   auth/auth info and the full request SOM object to the function as
   "localized package globals" (only in Perl could there be such a
   thing!) so that the average developer can just use the normal
   function style, but those that require more specific information
   (like parameter type info or names) can access that if required.

   In order to do all this, I'm using the "dispatch_to" method to
   dispatch into a directory of modules.  All of those modules have
   exactly one line:

-<dir to dispatch_to>/wsModule/Pkg.pm---------------------------------
package wsModule::Pkg; our( @ISA ) = ( 'Project::WebsvcsBase'); 1;
----------------------------------------------------------------------

   Substituting the project, project module, and package name as required
   (this project is a very big deployment).

   The WebsvcsBase class is pre-loaded by mod_perl, so there is no need for
   a "use" statement and the security hassles of that under a "dispatch_to".
   The WebsvcsBase package has an AUTOLOAD function that catches all unknown
   calls, which in this case is all of them.  My
   Project::WebsvcsBase::AUTOLOAD function extracts the SOAP Headers
   and does the auth/auth on that, then converts the call to
   "wsModule::Pkg::Function" into something like
   "Project::Module::Pkg::Websvcs::Function".  After checking to be sure
   the function doesn't start with "_" (used to indicate a package
   internal helper function that should not be exposed to SOAP), "-> can()"
   is called on the package to see if the package/function exists, and
   get a CODE ref if it does.  Finally, the localized package globals are
   set and the call is dispatched to the altered package path as a class
   method.

   This is pretty complex and carries some baggage (like the need for
   the "wsModule/Pkg.pm" files), but it gives me total control over the
   altering and dispatch of all calls.  If you make sure the package
   Project::WebsvcsBase ONLY has the AUTOLOAD function, and you make
   sure the $AUTOLOAD var is not undef (indicating an explicit call to
   AUTOLOAD( )), then you've got only one spot that everything must go
   through in a controlled way.

   If all you need is to take a request (with SOAP-Action and URI path)
   and convert it to a new module path, it would be much simpler to
   write an "on_dispatch( )" hook into SOAP::Server.  The SOAP::Server
   module still dispatches the call with one of the existing systems
   (dispatch_with, dispatch_to), but you can define (and limit) the
   conversion from URI to Perl module path.  In my case I might be able
   to the auth/auth verification there, but I couldn't store the
   localized symbols.  If you do choose to do that, it might not be
   obvious, but errors can result in a "die SOAP::Fault -> new(...)"
   call; there is no need (nor ability) to return error codes or the
   like.


   Talking with other SOAP::Lite developers, this desire to have better
   control over the dispatch seems like a fairly common thing.  I have
   considered writing a patch to the core sources to implement a
   "dispatch_thru" system, by which the user could designate a
   superclass such as Project::WebsvcsBase.  The SOAP::Server module
   would then create a "@Package....::ISA = ( $dispatch_thru_superclass )"
   entry in the symbol table for each call that came through and
   dispatch the call to that class (perhaps even local() to keep things
   tidy and neat).

   Why didn't I do it?  In short, if you think the SOAP::Lite examples
   are opaque and difficult to follow, try looking at the core sources.
   I'll grant Paul a lot of credit in the fact that it works, but the
   source seems to value "compact and clever" over "easy to read and
   understand."  It is very difficult to follow and understand, and even
   more difficult to modify "in the spirit" of the original style (at
   least for me).  I may still write such a patch, but for now it was
   considered easier to auto-generate the stub class files.

     -j

--
                      Jay A. Kreibich | CommTech, Emrg Net Tech Svcs
                         jak@... | Campus IT & Edu Svcs
           <http://www.uiuc.edu/~jak> | University of Illinois at U/C

All,

I finally figured out the (very) simple solution to my proxy
problem... here's a brief recount of the problem and my findings...

I'm using a web service which operates on HTTPS/SSL.  I was trying to
use the S::L->uri()->service() syntax and I was finding that S::L was
attempting to issue a GET over HTTP to my proxy, rather than the HTTP
CONNECT method that is required for interaction with a web server over
SSL through a proxy (at least the proxy that I'm using).  I tried two
different methods of specifying the proxy:
   - setting environment variable https_proxy=http://my-proxy:80
   - using the S::L syntax...
     S::L->uri()->proxy(...,proxy=>[http=>'http://my-proxy:80'])

Much to my chagrin and confusion, the above (undesirable) behavior
only occurred in Windows - on my Debian GNU/Linux box, my code did the
right thing.  I'm still not sure what's different to cause the UNIX
setup to work differently.

Anyway, the solution is to use the environment variable approach, but
the variable name in all caps.  Simply setting the environment
variable HTTPS_PROXY=http://my-proxy:80 instead of the lower-case
version, forces the use of the Crypt::SSLeay proxy support rather than
the (default) LWP::UserAgent support.

I found this here:
     http://www.icewalkers.com/Perl/5.8.0/lib/Crypt/SSLeay.html

So, ultimately, this is completely unrelated to S::L and rather only
on the strange behavior of the packages listed above that S::L makes
use of.

Hopefully this helps someone, sometime!
Kind Regards,
-brian

Greetings!

Well,  if  that  can help you, this is how I've got to use one sub for
handling  all  the  incoming  SOAP  requests without losing any needed
info.  Sincerely  speaking, I had to parse a lot of SOAP::Lite code to
understand  how  to  do it :). This script can be executed as both CGI
and daemon application - see implementation for details. The core code
that lets you use your own dispatcher is:
         -> on_action(sub { return; })
         -> on_dispatch(sub { $handler->request(shift); return qw(RequestsHandler
handle); })
         -> dispatch_to($handler)
And handle() sub retrieves method name and URI and - in this example -
requires  the  module  represented  by  URI. In this example if URI is
"urn:dir1/dir2/test.pl" it gonna be the following:
   <WEB_SERVER_ROOT>/dir1/dir2/test.pl
Thus  you  get  all  the  SOAP  requests  in one sub and link/call any
package/method  you  need  basing its import scheme on SOAP method URI
and name any way you like.

#!perl -w

use SOAP::Transport::HTTP;
require URI;

$DAEMON_PORT = 8000;

my $handler = RequestsHandler->new(!!! PUT ANY GLOBAL PARAMETERS TO PASS TO
REQUESTS HANDLER !!!);

my $server = (!$ENV{'SCRIPT_FILENAME'} ?
         SOAP::Transport::HTTP::Daemon
                 -> new(LocalAddr => 'localhost', LocalPort => $DAEMON_PORT) :
         SOAP::Transport::HTTP::CGI
                 -> new);
print "SOAP server started at ", $server->url, "\n" if
(!$ENV{'SCRIPT_FILENAME'});
$server
         -> on_action(sub { return; })
         -> on_dispatch(sub { $handler->request(shift); return qw(RequestsHandler
handle); })
         -> dispatch_to($handler)
         -> handle;

package RequestsHandler;

use Inline;

sub new {
         my $class = shift;
         my $self  = {};
         $self->{!!! GLOBAL PARAMETER 1 !!!} = shift;
       ...
         $self->{!!! GLOBAL PARAMETER N !!!} = shift;
         $self->{_request} = undef;
         bless ($self, $class);
         return $self;
}

sub request {
         my $self = shift;
         return (@_ ? $self->{_request} = shift : $self->{_request});
}

sub handle {
         my $self = shift;
       my $method_uri  = URI->new($self->{_request}->namespaceuriof || '')->path;
         my $method_name = $self->{_request}->dataof->name;
       require "$self->{'_root_dir'}/$method_uri";
         return &$method_name(@_);
}

--
Nikita Dedik

Hi,

I'm having a slight problem with a call to an external SOAP service, to
give a simple example the XML generated for the function call when I turn
on debug for SOAP::Lite shows:

<functionname xmlns="">
       <firstname>simon</firstname>
       <surname>fairey</surname>
</functionname>

this fails unless I change it to:

<functionname xmlns="http://www.soapserviceprovider.com">
       <firstname>simon</firstname>
       <surname>fairey</surname>
</functionname>

I have set uri() etc. but can find no way to set the xmlns attribute of the
function call.

I've not used SOAP::Lite extensively but can find nothing to indicate how I
might do this, any suggestions?

The approximate perl code looks like:

use SOAP::Lite +trace =>
   qw(debug);

my $soap = SOAP::Lite
       ->service('http://url to a WSDL provider');

my $first = SOAP::Data->value('simon')->name('first');
my $last = SOAP::Data->value('fairey')->name('last');

$soap->autotype(0);
$soap->uri('http://www.soapserviceprovider.com/');
$soap->functionname($first, $last);

I'm thinking I am missing something in the way the methods for SOAP::Lite
equate to the XML generated for a SOAP request.

Si
********************************************************************************\
**
This email may contain confidential material. If you were not an
intended recipient, please notify the sender and delete all copies.
We may monitor email to and from our network.

Hi All,

I've installed SOAP::Lite and tried to test the sample. The client throws
exception the following exception when exception:

not well-formed (invalid token) at line 1, column 1, byte 1 at
/usr/local/lib/perl5/site_perl/5.8.6/i686-linux/XML/Parser.pm line 187
#!/usr/bin/env perl5.8.6

use SOAP::Transport::HTTP;
use World;

SOAP::Transport::HTTP::CGI
   -> dispatch_to('World')
   -> handle;
  at soapClient.pl line 9


------

The following is the code I've tested with:

World.pm
--------
package World;

sub new {
    bless {}, shift;
};

sub HelloWorld {
    my ($self) = @_;

    return "Answer from sub HelloW\n";
};

sub GoodByeWorld {
    my ($self,$adjective) = @_;
    return "Goodbye $adjective \n";
}

1;

soapserver.cgi#!/usr/bin/env perl5.8.6

use SOAP::Transport::HTTP;
use World;

SOAP::Transport::HTTP::CGI
   -> dispatch_to('World')
   -> handle;

soapclient.pl
--------------
#!/usr/local/bin/perl
use SOAP::Lite;
my $soap = SOAP::Lite
    ->uri('World')
    ->proxy('http://localhost/soap/soapserver.cgi');
   #->on_debug(sub{warn @_});
$som = $soap->GoodBye("Bad world");
if ( $som->fault ) {
    warn $som->faultcode() ||'', " : ", $som->faultstring()||'',
       " : ",$som->faultdetail()||'',"\n";
} else {
    print $som->result();
}


--------------
Does anybody know why the error occurs and how to overcome this. Does it
indicate that the server is not properly serving the XML...?

The module versions installed are as below:
         SOAP::Lite => 0.60
         XML::Parser => 2.34

Fedora Core 3/ Apache 2.0.52

Regards
--Shobhan

--
!!@!!
Don't be afraid to experiment. The best way to learn stuff is to play with
it.

At 2005-03-10, 13:04:52 show2sh <show2sh@...> wrote:

>Hi All,
>
>I've installed SOAP::Lite and tried to test the sample. The client
>throws
>exception the following exception when exception:
>
>not well-formed (invalid token) at line 1, column 1, byte 1 at
>/usr/local/lib/perl5/site_perl/5.8.6/i686-linux/XML/Parser.pm line 187
>#!/usr/bin/env perl5.8.6
>
>use SOAP::Transport::HTTP;
>use World;
>
>SOAP::Transport::HTTP::CGI
>  -> dispatch_to('World')
>  -> handle;
> at soapClient.pl line 9
>
>------
>
>The following is the code I've tested with:
>
>World.pm
>--------
>package World;
>
>sub new {
>   bless {}, shift;
>};
>
>sub HelloWorld {
>   my ($self) = @_;
>
>   return "Answer from sub HelloW\n";
>};
>
>sub GoodByeWorld {
>   my ($self,$adjective) = @_;
>   return "Goodbye $adjective \n";
>}
>1;
>
>soapserver.cgi#!/usr/bin/env perl5.8.6
>
>use SOAP::Transport::HTTP;
>use World;
>
>SOAP::Transport::HTTP::CGI
>  -> dispatch_to('World')
>  -> handle;
>
>soapclient.pl
>--------------
>#!/usr/local/bin/perl
>use SOAP::Lite;
>my $soap = SOAP::Lite
>   ->uri('World')
>   ->proxy('http://localhost/soap/soapserver.cgi');
>  #->on_debug(sub{warn @_});
>$som = $soap->GoodBye("Bad world");

This is not the name of the method in your server class. Should it be
GoodByeWorld?

Duncan




Send instant messages to your online friends http://uk.messenger.yahoo.com

I have an Axis Web Service in Java. When I have an Axis client I
know how to use the Axis framework to pass HTTP Cookies between
client and WS on every invocation. Basically there is a HTTP Header
that looks like "Cookie: JSESSIONID=blah blah" in every SOAP request
that is sent across the wire.

How do I achieve the same using SOAP-Lite and Perl to communicate
with this Java WS ? I am a beginner in Perl so if someone could tell
me exactly what needs to be done I would really be very grateful.

Thanks
Avinash

On 2005-03-10 at 18:36:07 ghostwhoowalks wrote:

>I have an Axis Web Service in Java. When I have an Axis client I
>know how to use the Axis framework to pass HTTP Cookies between
>client and WS on every invocation. Basically there is a HTTP Header
>that looks like "Cookie: JSESSIONID=blah blah" in every SOAP request
>that is sent across the wire.
>
>How do I achieve the same using SOAP-Lite and Perl to communicate
>with this Java WS ? I am a beginner in Perl so if someone could tell
>me exactly what needs to be done I would really be very grateful.
>
>Thanks
>Avinash
See here

http://cookbook.soaplite.com/#using%20cookies

Basically, SOAP::Lite uses LWP::UserAgent for the http client, and
you can use any functions of that module.

Duncan

Hello,

I have always had problems using search engines to find what I
wanted,as it always poped up results that I was in no way looking for.
I just happen to go through a very simple page, with relavent links on
computing and felt that it could be useful to you too. You may go to
http://www.yahoouk.org/computing for the computing catalog with the
following sub areas : Computer Hardware, Computer Peripherals,Computer
Programming,Computer Security,Computer Services,Computer Storage
Devices,Document Management,Ecommerce, Email, Enterprise Software
Help Desk Services, Internet Service Providers, Memory, Network Design
& Construction, Network Hardware, Online Content, Printers, Software
Applications, Software Development and Web Hosting.

Kathy

Hi,

In older versions of SOAP::Lite, i had ste use_prefix to 0 in order to
supress the namesp1: values. is there a new way to do this in the
current versions?
--
  Brad Miele
  Technology Director
  IPNStock
  (866) 476-7862 x902
  bmiele@...

sorry realize that it was new in beta...


On Fri, 11 Mar 2005 15:48:57 -0500, Brad Miele <brad.miele@...> wrote:
> Hi,
>
> In older versions of SOAP::Lite, i had ste use_prefix to 0 in order to
> supress the namesp1: values. is there a new way to do this in the
> current versions?
> --
>  Brad Miele
>  Technology Director
>  IPNStock
>  (866) 476-7862 x902
>  bmiele@...
>


--
  Brad Miele
  Technology Director
  IPNStock
  (866) 476-7862 x902
  bmiele@...

That feature was introduced in SOAP::Lite 0.65 Beta - and it should
still be there in Beta 3.

Check and make sure you don't have 0.60 installed...

Brad Miele wrote:

> Hi,
>
> In older versions of SOAP::Lite, i had ste use_prefix to 0 in order to
> supress the namesp1: values. is there a new way to do this in the
> current versions?
> --
> Brad Miele
> Technology Director
> IPNStock
> (866) 476-7862 x902
> bmiele@...
>
> *Yahoo! Groups Sponsor*
> ADVERTISEMENT
> click here
>
<http://us.ard.yahoo.com/SIG=129mcum30/M=298184.6018725.7038619.3001176/D=groups\
/S=1705701014:HM/EXP=1110660560/A=2593423/R=0/SIG=11el9gslf/*http://www.netflix.\
com/Default?mqso=60190075>
>
>
>
> ------------------------------------------------------------------------
> *Yahoo! Groups Links*
>
>     * To visit your group on the web, go to:
>       http://groups.yahoo.com/group/soaplite/
>
>     * To unsubscribe from this group, send an email to:
>       soaplite-unsubscribe@yahoogroups.com
>       <mailto:soaplite-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
>     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>

I'm having some strange and unsettling troubles with a SOAP::Lite
server in a mod_perl environment.  I think that SOAP::Lite may not
re-initialize properly after serving a SOAP fault.

Every so often, we get a malformed request, which results in a
server-generated SOAP fault, as expected.  On the server, we have
subclassed SOAP::Server::Parameters in order to handle the request and
do some fairly intensive logging.  I can see from the (lack of) logs
that our code is never called when a fault is generated.  So far, so good.

Things move along swimmingly until we get another request handled by
the same Apache process.  What we are seeing in our message handler is
that the incoming parameters match those of the *previous* request,
the one that resulted in a fault.  I can tell this by manually
inspecting the logs and watching TCP traces in Ethereal, but I can't
see any way to identify this condition in running code.  The
som->fault is false once we have entered the message handler, so it
appears that at least some of the state is reset for each request.

The problem goes away entirely if I configure Apache to serve only one
request per child process.  Obviously, this works for troubleshooting,
but isn't a real solution for a production environment.

Is it really possible that SOAP::Lite does not clear its state for
each new request?  I'm a little skeptical that I'm seeing what I think
I'm seeing, since nobody else appears to be freaking out about this.
Has anyone ever seen this before?

Thanks for any insights you can offer,
Scott Franklin