Starting with SOAP

[Amer Neely]

I need to update a script on one server with data from a form on another
server. It has been suggested that SOAP would work for this. I've never
used SOAP, and am overwhelmed with the number of 'SOAP*' modules on
CPAN. I've read that perhaps I should use a language with better support
for SOAP (PHP ?) but the existing script is in Perl and I'd prefer to
stick with that if possible.

I've got some bookmarked tutorials / documents etc. which I am reading
through but really need some very basic direction as to what modules I
might need to get started with this. I've successfully installed
SOAP-0.28 on the server where the data will be coming from (the
client?), but just need a nudge in the right direction.

 

[xhoster]

I need to update a script on one server with data from a form on another
server. It has been suggested that SOAP would work for this. I've never
used SOAP, and am overwhelmed with the number of 'SOAP*' modules on
CPAN. I've read that perhaps I should use a language with better support
for SOAP (PHP ?) but the existing script is in Perl and I'd prefer to
stick with that if possible.

It sounds like the tail is wagging the dog. For one thing, you probably
shouldn't update scripts based on form submissions. Why not update some
database that the script accesses? That would probably solve the problem
right there. But if you want Perl script-to-Perl script communication,
pick a protocol that Perl is good at, rather than picking a random protocol
and then figure out to implement in Perl.

Xho

 

[Amer Neely]

It sounds like the tail is wagging the dog. For one thing, you probably
shouldn't update scripts based on form submissions. Why not update some
database that the script accesses? That would probably solve the problem
right there. But if you want Perl script-to-Perl script communication,
pick a protocol that Perl is good at, rather than picking a random protocol
and then figure out to implement in Perl.

Xho

Sounds like good advice. However the 'other script' is not in my
control, and I'm not even sure it is Perl - likely PHP. The owner is the
one looking for a SOAP solution. They are asking for an XML document of
the form data.

At present the form data is not being saved in a database, so that is
not an immediate solution, although I could present that to my client
and the 3rd party.

I have managed to get some headway on some test scripts. But an error
message is confusing me.

The server code:
#! /usr/bin/perl
## test using SOAP to display values from another script

BEGIN
{
open (STDERR,">>$0-err.txt");
print STDERR "\n",scalar localtime,"\n";
}

use strict;
use warnings;

use lib '/home/softouch/public_html/cgi-bin/PerlMods/SOAP-0.28/blib/lib';
use SOAP::Transport::HTTP;
SOAP::Transport::HTTP::CGI
-> dispatch_to('ShowMe')
-> handle;

package LarMar;

sub ShowMe
{
my $incoming = shift;
return "$incoming\n";
}

######################################

The error:
Can't locate SOAP/Transport/HTTP.pm in @INC (@INC contains:
/home/softouch/public_html/cgi-bin/PerlMods/SOAP-0.28/blib/lib
/usr/lib/perl5/5.8.8/i686-linux /usr/lib/perl5/5.8.8
/usr/lib/perl5/site_perl/5.8.8/i686-linux /usr/lib/perl5/site_perl/5.8.8
/usr/lib/perl5/site_perl/5.8.7/i686-linux /usr/lib/perl5/site_perl/5.8.7
/usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl/5.8.4
/usr/lib/perl5/site_perl/5.8.3 /usr/lib/perl5/site_perl/5.8.2
/usr/lib/perl5/site_perl/5.8.1 /usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl/5.6.2 /usr/lib/perl5/site_perl .) at
larmar_server.pl line 14.
BEGIN failed--compilation aborted at larmar_server.pl line 14.
#######################################

It seems that it is looking for HTTP.pm, but HTTP is a directory under
SOAP/Transport. CGI.pm is in the HTTP directory.

This is modified from a script in the SOAP::Lite distribution.

 

[Amer Neely]

It looks like you didn't install the SOAP::Transport::HTTP module,
which should be installed as .../SOAP/Transport/HTTP.pm.

The HTTP directory in .../SOAP/Transport will be the home of modules
such as SOAP::Transport::HTTP::CGI.

Because of Perl's naming convention for modules, is possible and common
for module XXX.pm and directory XXX to exist in the same directory.

Arghh. I was under the impression that the double-colons '::' were
directory delimiters. So the line
use SOAP::Transport::HTTP;
should be looking for SOAP/Transport/HTTP, which holds the CGI.pm module.

When I do a search for 'soap::transport::http' at CPAN I get a list, and
the first hit, SOAP::Transport::HTTP, takes me to 'SOAP-Lite-0.69'. The
documentation leads me to believe that SOAP::Transport::HTTP is included
in SOAP-Lite-0.69.

Obviously I'm way off track in my belief system. This is one of the more
confusing things I find about Perl.

 

[Tad McClellan]

I was under the impression that the double-colons '::' were
directory delimiters.

They are.

errr, almost.

Double colons are directory _separators_.

A "delimiter" goes on both ends (it marks the "limits"),
a "separator" goes between things.

So the line
use SOAP::Transport::HTTP;
should be looking for SOAP/Transport/HTTP,

No, it is looking for a _file_ (named .../SOAP/Transport/HTTP.pm)
not a directory.

 

[xhoster]

Sounds like good advice. However the 'other script' is not in my
control, and I'm not even sure it is Perl - likely PHP. The owner is the
one looking for a SOAP solution. They are asking for an XML document of
the form data.

I'm still not sure I follow. You own one part and not the other part, and
you want your part to be in Perl. But would your part be the SOAP client
or the SOAP server? And what is this "form" data, is it a CGI form? And
is that coming from the other party, or is their a third party submitting
the form, which you are supposed to do convert into SOAP and pass it along?

At present the form data is not being saved in a database, so that is
not an immediate solution, although I could present that to my client
and the 3rd party.

If the form isn't in soapy XML, and that is what they want it in, then
just saving the form as is in a database isn't going to help. But anyway,
I think there was miscommunication. You don't want to update a script
(i.e. change the source code of a script) on another server, you just
want to interact with a script on another server, right? If so, then
you might want to ask "What changes would your script make to the database
if my script called your script the way you want it to? Why not just
let me make those changes myself?" Unfortunately, many people think
that the "right" way to do things is to treat the database just as some
opaque bit-bucket and the "real" data lives in some XML-object model and
therefore can't be assessed directly in the database. These people are
almost always wrong, but sometimes they are the ones signing the
paycheck.

<snip errors>

I think the module finding problems have already been addressed, but
just a word of caution. Just because you can make a client and a
server, both from Perl using SOAP::Lite, that will work with each other
doesn't mean much. It doesn't mean the client will work with another
language's server, or the server will work with another language's client.

Xho

 

[rahed]

When I do a search for 'soap::transport::http' at CPAN I get a list,
and the first hit, SOAP::Transport::HTTP, takes me to
SOAP-Lite-0.69'. The documentation leads me to believe that
SOAP::Transport::HTTP is included in SOAP-Lite-0.69.

Obviously I'm way off track in my belief system. This is one of the
more confusing things I find about Perl.

With SOAP::Lite you can have both soap client and server and for light
loading there's a http daemon included (SOAP::Transport::HTTP).

 

[Amer Neely]

With SOAP::Lite you can have both soap client and server and for light
loading there's a http daemon included (SOAP::Transport::HTTP).

Yes, that was my understanding. That is why I'm confused as to why I'm
getting an error message telling me it can't find can't locate
SOAP/Transport/HTTP.pm. As far as I can tell SOAP::Lite installed OK.

Bear in mind I'm absolutely new to SOAP and using code supplied as an
example in the documentation as a starting point. SOAP was suggested as
a means of getting some form data from one server to another, but I'm
beginning to wonder if it's worth it. If someone has an alternative
(besides the database route already suggested) please jump in.

 

[Amer Neely]

I'm still not sure I follow. You own one part and not the other part, and
you want your part to be in Perl. But would your part be the SOAP client
or the SOAP server? And what is this "form" data, is it a CGI form? And
is that coming from the other party, or is their a third party submitting
the form, which you are supposed to do convert into SOAP and pass it along?

You have it pretty much right. I built a form for a client, who now
wants to take that data and pass it to another server so it can be used
to update a page there. I don't own the receiving code (the SOAP
server?) but the owner suggested SOAP as a means to do this. Hence my
immersion into SOAP. A quick scan on CPAN revealed some 300 SOAP
modules, so I'm really sinking here.

If the form isn't in soapy XML, and that is what they want it in, then
just saving the form as is in a database isn't going to help. But anyway,
I think there was miscommunication. You don't want to update a script
(i.e. change the source code of a script) on another server, you just
want to interact with a script on another server, right?

Yes, I just need to pass the form data (marked up as XML).

If so, then

you might want to ask "What changes would your script make to the database
if my script called your script the way you want it to? Why not just
let me make those changes myself?" Unfortunately, many people think
that the "right" way to do things is to treat the database just as some
opaque bit-bucket and the "real" data lives in some XML-object model and
therefore can't be assessed directly in the database. These people are
almost always wrong, but sometimes they are the ones signing the
paycheck.

I think you are under the impression there is a database already - there
isn't. I don't see why a database should be needed if SOAP works the way
it's presented (and if I understand it correctly).

<snip errors>

I think the module finding problems have already been addressed, but
just a word of caution. Just because you can make a client and a
server, both from Perl using SOAP::Lite, that will work with each other
doesn't mean much. It doesn't mean the client will work with another
language's server, or the server will work with another language's client.

Xho

Well, I'm still stuck at this module finding stage, so it may have been
addressed but certainly not resolved. As you mention, both a client and
server can be built from SOAP::Lite. I'm trying to get something working
(a client and server) before I tackle passing the form data to a
third-party script.

 

[Ian Wilson]

True AFAIK.

I'm confused as to why I'm
getting an error message telling me it can't find can't locate
SOAP/Transport/HTTP.pm. As far as I can tell SOAP::Lite installed OK.

I think your problem is with installation of SOAP modules and not with
usage of SOAP or SOAP::Lite.

These commands should all return without any error messages
$ perl -MSOAP::Lite -e1
$ perl -MSOAP::Transport::HTTP -e1
$ perl -MSOAP::Transport::HTTP::CGI -e

Somewhere in one of the directories listed in @INC you should have
SOAP/Lite.pm
SOAP/Transport/HTTP.pm
SOAP/Transport/HTTP/CGI.pm
(and many other related modules)

Bear in mind I'm absolutely new to SOAP and using code supplied as an
example in the documentation as a starting point. SOAP was suggested as
a means of getting some form data from one server to another, but I'm
beginning to wonder if it's worth it. If someone has an alternative
(besides the database route already suggested) please jump in.

For what it's worth, I find Perl and SOAP::Lite to be one of the easiest
SOAP implementations to use. I started with the simplest examples in the
documentation (e.g. The "Temperatures" examples in the Cookbook.

For more complicated services, SOAP::Lite can get a bit tricky, it
certainly has some limitations. I've managed to produce SOAP::Lite
web-services for consumption by .NET clients (C# Visual Studio) and
SOAP::Lite clients for complex Java web-services.

 

[Ian Wilson]

They should be able to provide WSDL which you can use.

A quick scan on CPAN revealed some 300 SOAP
modules, so I'm really sinking here.

Just use SOAP::Lite.

Well, I'm still stuck at this module finding stage,

What platform (OS and version)?

What version of perl

How did you obtain and install SOAP::Lite ?
`perl -MCPAN ...` ?
`ppm install ...` ?

so it may have been
addressed but certainly not resolved. As you mention, both a client and
server can be built from SOAP::Lite. I'm trying to get something working
(a client and server) before I tackle passing the form data to a
third-party script.

Good plan.

 

[xhoster]

(e-mail address removed) wrote:

You have it pretty much right. I built a form for a client, who now
wants to take that data and pass it to another server so it can be used
to update a page there. I don't own the receiving code (the SOAP
server?) but the owner suggested SOAP as a means to do this. Hence my
immersion into SOAP. A quick scan on CPAN revealed some 300 SOAP
modules, so I'm really sinking here.


Yes, I just need to pass the form data (marked up as XML).

If so, then

I think you are under the impression there is a database already - there
isn't.

Sure there is. Whatever the other end is doing that makes a permanent
change, that is a database. It may not be a RDBMS, but surely it is
something, a informal database implemented with the file system, perhaps.

I don't see why a database should be needed if SOAP works the way
it's presented (and if I understand it correctly).

I just think you are adding an needless complication. Instead of
submitting a form to a Perl script, which then translates it into a
different language and submits that to another server, why not just submit
the form directly to the end server?

Well, I'm still stuck at this module finding stage, so it may have been
addressed but certainly not resolved. As you mention, both a client and
server can be built from SOAP::Lite. I'm trying to get something working
(a client and server) before I tackle passing the form data to a
third-party script.

SOAP::Transport::HTTP.pm seems to be part of SOAP::Lite package, while
SOAP::Transport::HTTP::CGI.pm is part of the SOAP package. So if you are
install from CPAN, you would need to install both SOAP and SOAP::Lite.

It all seems needlessly complicated to me, but then again so does
*everything* touching on SOAP.

Xho

 

[xhoster]

They should be able to provide WSDL which you can use.


Just use SOAP::Lite.

What did you have to do to get this to work? What version of SOAP::Lite do
you use? When I point SOAP::Lite at a .net WSDL, it just dies from
internal errors.

Xho

 

[Amer Neely]

True AFAIK.



I think your problem is with installation of SOAP modules and not with
usage of SOAP or SOAP::Lite.

That could be. I'll try installing again, and capture the output.

These commands should all return without any error messages
$ perl -MSOAP::Lite -e1

$ perl -MSOAP::Transport::HTTP -e1

$ perl -MSOAP::Transport::HTTP::CGI -e

No code specified for -e.

.... so I figured you forgot the '1' ...

Can't locate SOAP/Transport/HTTP/CGI.pm in @INC (@INC contains:
C:/usr/site/lib
C:/usr/lib .).
BEGIN failed--compilation aborted.

This is on my home PC, which is acting as the 'client'.

Directory of C:\usr\lib\SOAP

15/08/2007 09:16p <DIR> .
15/08/2007 09:16p <DIR> ..
08/12/2003 09:13a 167,831 Lite.pm
17/04/2002 01:16a 12,182 Test.pm
15/08/2007 09:15p <DIR> Transport


Directory of C:\usr\lib\SOAP\Transport

15/08/2007 09:15p <DIR> .
15/08/2007 09:15p <DIR> ..
14/06/2002 10:13a 3,147 FTP.pm
14/06/2002 10:13a 29,726 HTTP.pm
14/06/2002 10:13a 3,282 IO.pm
14/06/2002 10:13a 8,156 JABBER.pm
17/04/2002 01:16a 2,052 LOCAL.pm
14/06/2002 10:13a 3,749 MAILTO.pm
14/06/2002 10:13a 7,813 MQ.pm
14/06/2002 10:13a 3,744 POP3.pm
14/06/2002 10:13a 6,940 TCP.pm

There is no 'SOAP' directory under /usr/site/lib

Somewhere in one of the directories listed in @INC you should have
SOAP/Lite.pm
SOAP/Transport/HTTP.pm
SOAP/Transport/HTTP/CGI.pm
(and many other related modules)

So it appears my installation is flawed. I will re-install.

For what it's worth, I find Perl and SOAP::Lite to be one of the easiest
SOAP implementations to use. I started with the simplest examples in the
documentation (e.g. The "Temperatures" examples in the Cookbook.

Yes, I got that one to work fine too. Which gave me encouragement.

For more complicated services, SOAP::Lite can get a bit tricky, it
certainly has some limitations. I've managed to produce SOAP::Lite
web-services for consumption by .NET clients (C# Visual Studio) and
SOAP::Lite clients for complex Java web-services.

I think you are right in that my installation may be flawed - I will
re-install SOAP.

 

[Amer Neely]

They should be able to provide WSDL which you can use.


Just use SOAP::Lite.

I'm trying, (very trying

What platform (OS and version)?

Win2K Professional

What version of perl

ActiveState
This is perl, v5.8.8 built for MSWin32-x86-multi-thread
(with 50 registered patches, see perl -V for more detail)

How did you obtain and install SOAP::Lite ?

`ppm install ...` ?

via the GUI. Version 4.01

 

[Amer Neely]

What did you have to do to get this to work? What version of SOAP::Lite do
you use? When I point SOAP::Lite at a .net WSDL, it just dies from
internal errors.

Xho

As mentioned in my reply to Ian Wilson, I'm using ActiveState on Win2K
Professional

This is perl, v5.8.8 built for MSWin32-x86-multi-thread
(with 50 registered patches, see perl -V for more detail)

so installed SOAP::Lite with the GUI ppm 4.01. But it seems some of the
modules didn't get installed, so I'm going to try a re-install from AS.
Failing that I will try the 'make ....' routine from CPAN.

 

[Amer Neely]

Sure there is. Whatever the other end is doing that makes a permanent
change, that is a database. It may not be a RDBMS, but surely it is
something, a informal database implemented with the file system, perhaps.

Ah, OK, I'll accept that.

I just think you are adding an needless complication. Instead of
submitting a form to a Perl script, which then translates it into a
different language and submits that to another server, why not just submit
the form directly to the end server?

I'm just going on what was suggested by the owner of the 'other' script.
The form data is to be used on 2 separate servers - in other words
duplicated 'live' on the other server. He seems to think sending the
form data as an XML message is the simplest way to do this.

SOAP::Transport::HTTP.pm seems to be part of SOAP::Lite package, while
SOAP::Transport::HTTP::CGI.pm is part of the SOAP package. So if you are
install from CPAN, you would need to install both SOAP and SOAP::Lite.

Yes, I'm beginning to see some light in there as well. The documentation
I find seems to assume a great deal of knowledge on my part already.

It all seems needlessly complicated to me, but then again so does
*everything* touching on SOAP.

I'm glad I'm not the only one

 

[Amer Neely]

Somewhere in one of the directories listed in @INC you should have
SOAP/Lite.pm
SOAP/Transport/HTTP.pm
SOAP/Transport/HTTP/CGI.pm
(and many other related modules)

I've re-installed SOAP-Lite from AS using ppm 4.01 GUI (actually
upgraded it to .69).

But I notice that I now have what seems to be 2 versions of it - one
under /usr/lib and one under /usr/site/lib

SOAP-Lite
Interface to the Simple Object Access Protocol (SOAP)
Version: 0.55-r1
Released: 2005-07-19
Author: Paul Kulchenko <[email protected]>
CPAN: http://search.cpan.org/dist/SOAP-Lite-0.55/

Installed files:
C:/usr/bin/SOAPsh.bat
C:/usr/bin/SOAPsh.pl
C:/usr/bin/XMLRPCsh.bat
C:/usr/bin/XMLRPCsh.pl
C:/usr/bin/stubmaker.bat
C:/usr/bin/stubmaker.pl
C:/usr/lib/Apache/SOAP.pm
C:/usr/lib/Apache/XMLRPC/Lite.pm
C:/usr/lib/IO/SessionData.pm
C:/usr/lib/IO/SessionSet.pm
C:/usr/lib/SOAP/Lite.pm
C:/usr/lib/SOAP/Test.pm
C:/usr/lib/SOAP/Transport/FTP.pm
C:/usr/lib/SOAP/Transport/HTTP.pm
C:/usr/lib/SOAP/Transport/IO.pm
C:/usr/lib/SOAP/Transport/JABBER.pm
C:/usr/lib/SOAP/Transport/LOCAL.pm
C:/usr/lib/SOAP/Transport/MAILTO.pm
C:/usr/lib/SOAP/Transport/MQ.pm
C:/usr/lib/SOAP/Transport/POP3.pm
C:/usr/lib/SOAP/Transport/TCP.pm
C:/usr/lib/UDDI/Lite.pm
C:/usr/lib/XML/Parser/Lite.pm
C:/usr/lib/XMLRPC/Lite.pm
C:/usr/lib/XMLRPC/Test.pm
C:/usr/lib/XMLRPC/Transport/HTTP.pm
C:/usr/lib/XMLRPC/Transport/POP3.pm
C:/usr/lib/XMLRPC/Transport/TCP.pm
C:/usr/lib/auto/SOAP/Lite/.packlist


SOAP-Lite
Perl's Web Services Toolkit
Version: 0.69
Author: Byrne Reese <[email protected]>
CPAN: http://search.cpan.org/dist/SOAP-Lite-0.69/

Installed files:
C:/usr/html/bin/SOAPsh.html
C:/usr/html/bin/XMLRPCsh.html
C:/usr/html/bin/stubmaker.html
C:/usr/html/site/lib/Apache/SOAP.html
C:/usr/html/site/lib/Apache/XMLRPC/Lite.html
C:/usr/html/site/lib/OldDocs/SOAP/Lite.html
C:/usr/html/site/lib/OldDocs/SOAP/Transport/FTP.html
C:/usr/html/site/lib/OldDocs/SOAP/Transport/HTTP.html
C:/usr/html/site/lib/OldDocs/SOAP/Transport/IO.html
C:/usr/html/site/lib/OldDocs/SOAP/Transport/JABBER.html
C:/usr/html/site/lib/OldDocs/SOAP/Transport/LOCAL.html
C:/usr/html/site/lib/OldDocs/SOAP/Transport/MAILTO.html
C:/usr/html/site/lib/OldDocs/SOAP/Transport/MQ.html
C:/usr/html/site/lib/OldDocs/SOAP/Transport/POP3.html
C:/usr/html/site/lib/OldDocs/SOAP/Transport/TCP.html
C:/usr/html/site/lib/SOAP/Client.html
C:/usr/html/site/lib/SOAP/Constants.html
C:/usr/html/site/lib/SOAP/Data.html
C:/usr/html/site/lib/SOAP/Deserializer.html
C:/usr/html/site/lib/SOAP/Fault.html
C:/usr/html/site/lib/SOAP/Header.html
C:/usr/html/site/lib/SOAP/Lite.html
C:/usr/html/site/lib/SOAP/Packager.html
C:/usr/html/site/lib/SOAP/SOM.html
C:/usr/html/site/lib/SOAP/Schema.html
C:/usr/html/site/lib/SOAP/Serializer.html
C:/usr/html/site/lib/SOAP/Server.html
C:/usr/html/site/lib/SOAP/Test.html
C:/usr/html/site/lib/SOAP/Trace.html
C:/usr/html/site/lib/SOAP/Transport.html
C:/usr/html/site/lib/SOAP/Transport/POP3.html
C:/usr/html/site/lib/SOAP/Utils.html
C:/usr/html/site/lib/UDDI/Lite.html
C:/usr/html/site/lib/XML/Parser/Lite.html
C:/usr/html/site/lib/XMLRPC/Lite.html
C:/usr/html/site/lib/XMLRPC/Test.html
C:/usr/html/site/lib/XMLRPC/Transport/HTTP.html
C:/usr/html/site/lib/XMLRPC/Transport/POP3.html
C:/usr/html/site/lib/XMLRPC/Transport/TCP.html
C:/usr/site/bin/SOAPsh.bat
C:/usr/site/bin/SOAPsh.pl
C:/usr/site/bin/XMLRPCsh.bat
C:/usr/site/bin/XMLRPCsh.pl
C:/usr/site/bin/stubmaker.bat
C:/usr/site/bin/stubmaker.pl
C:/usr/site/lib/Apache/SOAP.pm
C:/usr/site/lib/Apache/XMLRPC/Lite.pm
C:/usr/site/lib/IO/SessionData.pm
C:/usr/site/lib/IO/SessionSet.pm
C:/usr/site/lib/OldDocs/SOAP/Lite.pm
C:/usr/site/lib/OldDocs/SOAP/Transport/FTP.pm
C:/usr/site/lib/OldDocs/SOAP/Transport/HTTP.pm
C:/usr/site/lib/OldDocs/SOAP/Transport/IO.pm
C:/usr/site/lib/OldDocs/SOAP/Transport/JABBER.pm
C:/usr/site/lib/OldDocs/SOAP/Transport/LOCAL.pm
C:/usr/site/lib/OldDocs/SOAP/Transport/MAILTO.pm
C:/usr/site/lib/OldDocs/SOAP/Transport/MQ.pm
C:/usr/site/lib/OldDocs/SOAP/Transport/POP3.pm
C:/usr/site/lib/OldDocs/SOAP/Transport/TCP.pm
C:/usr/site/lib/SOAP/Client.pm
C:/usr/site/lib/SOAP/Constants.pm
C:/usr/site/lib/SOAP/Data.pm
C:/usr/site/lib/SOAP/Deserializer.pm
C:/usr/site/lib/SOAP/Fault.pm
C:/usr/site/lib/SOAP/Header.pm
C:/usr/site/lib/SOAP/Lite.pm
C:/usr/site/lib/SOAP/Packager.pm
C:/usr/site/lib/SOAP/SOM.pm
C:/usr/site/lib/SOAP/Schema.pm
C:/usr/site/lib/SOAP/Serializer.pm
C:/usr/site/lib/SOAP/Server.pm
C:/usr/site/lib/SOAP/Test.pm
C:/usr/site/lib/SOAP/Trace.pm
C:/usr/site/lib/SOAP/Transport.pm
C:/usr/site/lib/SOAP/Transport/FTP.pm
C:/usr/site/lib/SOAP/Transport/HTTP.pm
C:/usr/site/lib/SOAP/Transport/IO.pm
C:/usr/site/lib/SOAP/Transport/JABBER.pm
C:/usr/site/lib/SOAP/Transport/LOCAL.pm
C:/usr/site/lib/SOAP/Transport/MAILTO.pm
C:/usr/site/lib/SOAP/Transport/MQ.pm
C:/usr/site/lib/SOAP/Transport/POP3.pm
C:/usr/site/lib/SOAP/Transport/TCP.pm
C:/usr/site/lib/SOAP/Utils.pm
C:/usr/site/lib/UDDI/Lite.pm
C:/usr/site/lib/XML/Parser/Lite.pm
C:/usr/site/lib/XMLRPC/Lite.pm
C:/usr/site/lib/XMLRPC/Test.pm
C:/usr/site/lib/XMLRPC/Transport/HTTP.pm
C:/usr/site/lib/XMLRPC/Transport/POP3.pm
C:/usr/site/lib/XMLRPC/Transport/TCP.pm
C:/usr/site/lib/auto/SOAP/Lite/.packlist

However, PPM will not let me delete the older version.

Could this be why I may be having some difficulties?

 

[xhoster]

(e-mail address removed) wrote:

It may depend on the particular web-service. Can you get a basic
SOAP::Lite client and server working?

I have Apache installed on my Windows XP computers since the target
environment for which I develop is Apache.

In Apache's cgi-bin directory I put service.pl
-----------------------------8<--------------------------------
#!perl
use strict;
use warnings;
use SOAP::Transport::HTTP;
SOAP::Transport::HTTP::CGI
-> dispatch_to('C:/path/to/cgi-bin/SoapModules')
-> handle;
-----------------------------8<--------------------------------

In a subfolder cgi-bin\SoapModules I have Temperature.pm
-----------------------------8<--------------------------------
package Temperature;
sub c2f {
my ($class, $c) = @_;
return 32+$c*9/5;
}
1;
-----------------------------8<--------------------------------

Elsewhere I have a client tempclient.pl
-----------------------------8<--------------------------------
#!perl
use strict;
use warnings;
use SOAP::Lite;

my $temperature=SOAP::Lite
-> uri('Temperature')
-> proxy('http://localhost/cgi-bin/service.pl');

print $temperature
-> c2f(37.5)
-> result;
-----------------------------8<--------------------------------

C:> perl tempclient.pl
99.5
C:>

It works almost without a problem. The only problem is that
SOAP and SOAP::Lite both have package named SOAP:ackager. If
SOAP::Lite does "use SOAP:ackager" and gets the module from
SOAP instead of SOAP::Lite, then it won't work. So I had to arrange for
all of SOAP::Lites modules to come before any of SOAP's in the search
path. Then I just deleted SOAP altogether, which seems to have been
a good decision.

And to the original poster, It also looks like SOAP and SOAP::Lite
both define a package SOAP::Transport::HTML::CGI. One defines it
in it's own .pm file, and the other includes it as an internal
package of SOAP::Transport::HTTP.pm. So perhaps the problem is not
that you need to have both installed but rather than you have to *not*
have both installed.

There's crawling, walking and running stages of learning SOAP::Lite. The
above constitutes crawling. I find it useful to make sure I can crawl
before attempting more advanced forms of locomotion.

Unfortunately, crawling just isn't getting me anywhere. I already know
who to make Perl talk to Perl; if that was the goal I'd wouldn't resort to
SOAP to do it. It is working with WSDLs created by other "frameworks"
there the benefit is, and that is what I can't get working.

Xho

 

[Ian Wilson]

Now I re-read what I wrote, it sounds a bit condescending, that wasn't
what I intended - my apologies for that.

Unfortunately, crawling just isn't getting me anywhere. I already
know who to make Perl talk to Perl; if that was the goal I'd wouldn't
resort to SOAP to do it. It is working with WSDLs created by other
"frameworks" there the benefit is, and that is what I can't get
working.

I suppose this WSDL isn't something you can post here?

Anyway, WSDL is just a convenience. If you understand what the service
expects you can generate a SOAP call without having SOAP::Lite read the
WSDL.

There are some public websites into which you can type the URL of some
WSDL and they will then provide a more human readable interpretation.
That might help.

http://www.mgateway.com/php/wsdlValidator/home.php

What I have found very useful is when the service developer provides
some "test client" that exercises the service. In conjunction with a
network sniffer such as Wireshark it is then possible to view the XML
transmitted and adjust your SOAP::Lite client until it emits
sufficiently similar XML to be acceptable to the service. Some
web-server technologies are more tolerant than others!

If Perl won't grok the WSDL, will Mono? - I found it fairly easy to
generate simple web-service clients using Mono - I had one working
within a day with no prior C/C++/C# experience. Then you can run a
sniffer on that to see what XML is flying back and forth.

http://www.mono-project.com/Web_Services

In your shoes, I'd give up on getting Perl to read the WSDL and try and
construct a SOAP::Lite call for the simplest service defined in that
WSDL, using any of the ideas suggested above.

Your Mileage May Vary

I hope that helps, commiserations if not.