Starting with SOAP

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.
--
Amer Neely
Perl | MySQL programming for all data entry forms.
"Others make web sites. We make web sites work!"

Re: Starting with SOAP

Amer Neely wrote:
> 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

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB

Re: Starting with SOAP

xhoster@gmail.com wrote:
> Amer Neely wrote:
>> 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
>

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/l ib
/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
Perl | MySQL programming for all data entry forms.
"Others make web sites. We make web sites work!"

Re: Starting with SOAP

In article <46CCAE30.3000100@softouch.on.ca>, Amer Neely
wrote:


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


>
> The error:
> Can't locate SOAP/Transport/HTTP.pm in @INC (@INC contains:
> /home/softouch/public_html/cgi-bin/PerlMods/SOAP-0.28/blib/l ib
....

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

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.

--
Jim Gibson

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com

Re: Starting with SOAP

Jim Gibson wrote:
> In article <46CCAE30.3000100@softouch.on.ca>, Amer Neely
> wrote:
>
>
>> 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;
> ...
>
>
>> The error:
>> Can't locate SOAP/Transport/HTTP.pm in @INC (@INC contains:
>> /home/softouch/public_html/cgi-bin/PerlMods/SOAP-0.28/blib/l ib
> ...
>
>> 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.
>
> 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.
--
Amer Neely
w: www.webmechanic.softouch.on.ca/
Perl | MySQL programming for all data entry forms.
"Others make web sites. We make web sites work!"

Re: Starting with SOAP

Amer Neely wrote:

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


--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"

Re: Starting with SOAP

Amer Neely wrote:
> xhoster@gmail.com wrote:
> > Amer Neely wrote:
> >> 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
> >
>
> 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.



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

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB

Re: Starting with SOAP

Amer Neely writes:

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

--
Radek

Re: Starting with SOAP

rahed wrote:
> Amer Neely writes:
>
>> 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).
>

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
w: www.webmechanic.softouch.on.ca/
Perl | MySQL programming for all data entry forms.
"Others make web sites. We make web sites work!"

Re: Starting with SOAP

xhoster@gmail.com wrote:
> Amer Neely wrote:
>> xhoster@gmail.com wrote:
>>> Amer Neely wrote:
>>>> 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
>>>
>> 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?

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.

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

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

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

--
Amer Neely
w: www.webmechanic.softouch.on.ca/
Perl | MySQL programming for all data entry forms.
"Others make web sites. We make web sites work!"

Re: Starting with SOAP

Amer Neely wrote:
> rahed wrote:
>
>> Amer Neely writes:
>>
>>> 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.

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.

Re: Starting with SOAP

Amer Neely wrote:
>>>>
>>> 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.

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.

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


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

Re: Starting with SOAP

Amer Neely wrote:
> xhoster@gmail.com wrote:

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

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?

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

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

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB

Re: Starting with SOAP

Ian Wilson wrote:
> Amer Neely wrote:
> >>>>
> >>> 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.
>
> 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.

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

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB

Re: Starting with SOAP

Ian Wilson wrote:
> Amer Neely wrote:
>> rahed wrote:
>>
>>> Amer Neely writes:
>>>
>>>> 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.
>
> 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.

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

Re: Starting with SOAP

Ian Wilson wrote:
> Amer Neely wrote:
>>>>>
>>>> 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.
>
> 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.

I'm trying, (very trying :)

>>> 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.
>
>
>>
>> Well, I'm still stuck at this module finding stage,
>
> 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
w: www.webmechanic.softouch.on.ca/
Perl | MySQL programming for all data entry forms.
"Others make web sites. We make web sites work!"

Re: Starting with SOAP

xhoster@gmail.com wrote:
> Ian Wilson wrote:
>> Amer Neely wrote:
>>>>> 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.
>> 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.
>
> 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
w: www.webmechanic.softouch.on.ca/
Perl | MySQL programming for all data entry forms.
"Others make web sites. We make web sites work!"

Re: Starting with SOAP

xhoster@gmail.com wrote:
> Amer Neely wrote:
>> xhoster@gmail.com wrote:
>
>>> 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.
>>
>>>> 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?
>> 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.
>
> 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 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?

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.

>>> 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.
>
> 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
w: www.webmechanic.softouch.on.ca/
Perl | MySQL programming for all data entry forms.
"Others make web sites. We make web sites work!"

Re: Starting with SOAP

xhoster@gmail.com wrote:
> Ian Wilson wrote:
>>
>> Just use SOAP::Lite.
>
> What did you have to do to get this to work?

Almost nothing. SOAP::Lite (and associated modules) were already
installed on all my Unix servers - it seems to be part of their standard
operating system installation.

On Windows XP, I installed ActiveState ActivePerl 5.8.0. I recall I had
problems with finding SOAP::Lite for earlier versions but I'm pretty
sure it was straightforward for 5.8.0. I used the command line package
manager `ppm` - I wasn't aware of a GUI package manager.

> What version of SOAP::Lite do you use?

C:\>ppm
PPM - Programmer's Package Manager version 3.1.
Copyright (c) 2001 ActiveState SRL. All Rights Reserved.

Entering interactive shell. Using Term::ReadLine::Stub as readline library.

Type 'help' to get started.

ppm> query soap
Querying target 1 (ActivePerl 5.8.0.806)
1. SOAP-Lite [0.55] Library for Simple Object Access Protocol
(SOAP) clie~


> When I point SOAP::Lite at a .net WSDL, it just dies from
> internal errors.

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


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.

Re: Starting with SOAP

Amer Neely wrote:
> Ian Wilson wrote:
>
>> 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' ...

Oops yes :-)

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

The commands I gave work on Unix, The modules seem to be packaged
differently by ActiveState for Windows. Maybe its a difference between
SOAP::Lite versions 0.55 and 0.65. Even though there's no CGI.pm on
Windows, you can still refer to SOAP::Transport::HTTP::CGI in your Perl
programs.

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

Bear in mind that I use Apache on Windows to test CGI based
web-services. If you are using the standalone HTTP daemon, that's
something I haven't tried yet.



Just tried a standalone demon - its fine too

------------------------------8<---------------------------------
#!perl -w

use SOAP::Transport::HTTP;

#use Demo;

# don't want to die on 'Broken pipe' or Ctrl-C
$SIG{PIPE} = $SIG{INT} = 'IGNORE';

my $daemon = SOAP::Transport::HTTP::Daemon
-> new (LocalPort => 8081)
-> dispatch_to('C:/path/to/cgi-bin/SoapModules')
;

print "Contact to SOAP server at ", $daemon->url, "\n";
$daemon->handle;
------------------------------8<---------------------------------
#!perl
use strict;
use warnings;

use SOAP::Lite;

my $temperature=SOAP::Lite
-> uri('Temperature')
-> proxy('http://localhost:8081');

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

Temperature.pm in SoapModules is as in my other post.

In one Command Prompt window ...
C:> perl TempServer.pl
Contact to SOAP server at http://pcname:8081/

In a different Command Prompt window ...
C:> perl tempclient2.pl
99.5
C:>

Re: Starting with SOAP

Ian Wilson wrote:

> 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
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
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?
--
Amer Neely
w: www.webmechanic.softouch.on.ca/
Perl | MySQL programming for all data entry forms.
"Others make web sites. We make web sites work!"

Re: Starting with SOAP

Ian Wilson wrote:
> xhoster@gmail.com wrote:

> > When I point SOAP::Lite at a .net WSDL, it just dies from
> > internal errors.
>
> 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::Packager. If
SOAP::Lite does "use SOAP::Packager" 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

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB

Re: Starting with SOAP

xhoster@gmail.com wrote:
> Ian Wilson wrote:
>
>> 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.

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.

Re: Starting with SOAP

Amer Neely wrote:
> Ian Wilson wrote:
>
>> 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
> 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
> 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?

Finally got something to work.

I removed SOAP::Lite and re-installed it. Did some tweaking with my
local client / server pair of scripts (thanks to the examples provided
by xhoster I believe). I'm not sure the re-install had anything to do
with my success - in fact I doubt it.

The client uses SOAP::Lite, but the server uses SOAP - go figure.

Of course now the trick is to get things to work under a different
environment, and passing an actual variable. Sigh, back to crawling.

Much much thanks to all who responded - it's been another learning
experience.

For those interested here are my 2 working scripts:
(Windows 2K Professional, AS Perl v5.8.8, Apache 2.2, SOAP::Lite 0.69)

#! /usr/bin/perl
## the 'server' half of SOAP
BEGIN
{
open (STDERR,">>$0-err.txt");
print STDERR "\n",scalar localtime,"\n";
}

use strict;
use warnings;
use SOAP::Transport::HTTP;
SOAP::Transport::HTTP::CGI
-> dispatch_to('LarMar')
-> handle;

package LarMar;
sub ShowMe
{
return "Hello from $0";
}
1;

------------------------ 8< cut here ------------------

#! /usr/bin/perl
## the 'client' half of SOAP

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

use strict;
use warnings;

use SOAP::Lite qw (debug trace);

my $soap = SOAP::Lite
-> uri('LarMar')
-> proxy('http://localhost/cgi-bin/soap/larmar_server.pl');

print $soap
-> ShowMe()
-> result;
------------------------ 8< cut here ------------------

--
Amer Neely
w: www.webmechanic.softouch.on.ca/
Perl | MySQL programming for all data entry forms.
"Others make web sites. We make web sites work!"

Re: Starting with SOAP

Amer Neely wrote:
> (thanks to the examples provided by xhoster I believe)

Sigh.

:-)

Re: Starting with SOAP

On Thu, 23 Aug 2007 10:45:44 -0400, Amer Neely 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.

If you have a choice here I would strongly recomend against using
SOAP. Almost every implementation of SOAP uses a mutually
imcompatable subset of the soap standard. Cross platform soap support
is a pain.

Re: Starting with SOAP

David Formosa (aka ? the Platypus) wrote:
> On Thu, 23 Aug 2007 10:45:44 -0400, Amer Neely 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.
>
> If you have a choice here I would strongly recomend against using
> SOAP. Almost every implementation of SOAP uses a mutually
> imcompatable subset of the soap standard. Cross platform soap support
> is a pain.
>

You know, I'm sort of finding that out myself. I added a simple twist to
my 'working' code and it didn't work.

I'm going to investigate alternatives (Mechanize ?) for this little project.

--
Amer Neely
w: www.webmechanic.softouch.on.ca/
Perl | MySQL programming for all data entry forms.
"Others make web sites. We make web sites work!"

Re: Starting with SOAP

Ian Wilson wrote:
> Amer Neely wrote:
>> (thanks to the examples provided by xhoster I believe)
>
> Sigh.
>
> :-)

Woops, yes, I see now that it was yourself :) All these indents ....

Actually, I'm going to investigate an alternative to SOAP (Mechanize ?)
for this little project. From some other posts here, and my own limited
experience, it seems SOAP maybe isn't quite suited for cross-platform work.

--
Amer Neely
w: www.webmechanic.softouch.on.ca/
Perl | MySQL programming for all data entry forms.
"Others make web sites. We make web sites work!"

Re: Starting with SOAP

Amer Neely wrote:
> David Formosa (aka ? the Platypus) wrote:
> > On Thu, 23 Aug 2007 10:45:44 -0400, Amer Neely
> > 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.
> >
> > If you have a choice here I would strongly recomend against using
> > SOAP. Almost every implementation of SOAP uses a mutually
> > imcompatable subset of the soap standard. Cross platform soap support
> > is a pain.
> >
>
> You know, I'm sort of finding that out myself. I added a simple twist to
> my 'working' code and it didn't work.
>
> I'm going to investigate alternatives (Mechanize ?) for this little
> project.

But if the other end of the project insists on using SOAP, how will
Mechanize get around that insistence? Have you convinced the other person
to give up on SOAP as well?

I think what you have is fundamentally a political problem (or at least,
that is what it is when I've run into it). The guy on the other end says
SOAP will be "easier". This is true in a sense. By drawing a little box
around his program and declaring everything outside that box to be someone
else's problem, he makes it easier *for him*. If he can get away with
that, then Mechanize isn't going to help you as it can't pierce the box.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB

Re: Starting with SOAP

xhoster@gmail.com wrote:
> Amer Neely wrote:
>> David Formosa (aka ? the Platypus) wrote:
>>> On Thu, 23 Aug 2007 10:45:44 -0400, Amer Neely
>>> 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.
>>> If you have a choice here I would strongly recomend against using
>>> SOAP. Almost every implementation of SOAP uses a mutually
>>> imcompatable subset of the soap standard. Cross platform soap support
>>> is a pain.
>>>
>> You know, I'm sort of finding that out myself. I added a simple twist to
>> my 'working' code and it didn't work.
>>
>> I'm going to investigate alternatives (Mechanize ?) for this little
>> project.
>
> But if the other end of the project insists on using SOAP, how will
> Mechanize get around that insistence? Have you convinced the other person
> to give up on SOAP as well?
>
> I think what you have is fundamentally a political problem (or at least,
> that is what it is when I've run into it). The guy on the other end says
> SOAP will be "easier". This is true in a sense. By drawing a little box
> around his program and declaring everything outside that box to be someone
> else's problem, he makes it easier *for him*. If he can get away with
> that, then Mechanize isn't going to help you as it can't pierce the box.
>
> Xho
>

Yes, I think that is the situation I'm into. I've asked for more
clarification from the other party, I've been operating kind of blind so
far.

--
Amer Neely
w: www.webmechanic.softouch.on.ca/
Perl | MySQL programming for all data entry forms.
"Others make web sites. We make web sites work!"