«

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!"

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

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

Jim Gibson wrote:
> In article <>, 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/lib
> ...
>
>> 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!"

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/"

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

<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

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

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

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!"

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

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

--
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!"

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.