Starting with SOAP

Discussion in 'Perl Misc' started by Amer Neely, Aug 22, 2007.

  1. Amer Neely

    Amer Neely Guest

    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, Aug 22, 2007
    #1
    1. Advertising

  2. Amer Neely

    Guest

    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
     
    , Aug 22, 2007
    #2
    1. Advertising

  3. Amer Neely

    Amer Neely Guest

    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!"
     
    Amer Neely, Aug 22, 2007
    #3
  4. Amer Neely

    Amer Neely Guest

    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, Aug 23, 2007
    #4
  5. 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/"
     
    Tad McClellan, Aug 23, 2007
    #5
  6. Amer Neely

    Guest

    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
     
    , Aug 23, 2007
    #6
  7. Amer Neely

    rahed Guest

    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, Aug 23, 2007
    #7
  8. Amer Neely

    Amer Neely Guest

    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!"
     
    Amer Neely, Aug 23, 2007
    #8
  9. Amer Neely

    Amer Neely Guest

    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, Aug 23, 2007
    #9
  10. Amer Neely

    Ian Wilson Guest

    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.
     
    Ian Wilson, Aug 23, 2007
    #10
  11. Amer Neely

    Ian Wilson Guest

    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.
     
    Ian Wilson, Aug 23, 2007
    #11
  12. Amer Neely

    Guest

    Amer Neely <> wrote:
    > 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
     
    , Aug 23, 2007
    #12
  13. Amer Neely

    Guest

    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
     
    , Aug 23, 2007
    #13
  14. Amer Neely

    Amer Neely Guest

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

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


    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
    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, Aug 23, 2007
    #14
  15. Amer Neely

    Amer Neely Guest

    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!"
     
    Amer Neely, Aug 23, 2007
    #15
  16. Amer Neely

    Amer Neely Guest

    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!"
     
    Amer Neely, Aug 23, 2007
    #16
  17. Amer Neely

    Amer Neely Guest

    wrote:
    > Amer Neely <> wrote:
    >> 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!"
     
    Amer Neely, Aug 23, 2007
    #17
  18. Amer Neely

    Amer Neely Guest

    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!"
     
    Amer Neely, Aug 23, 2007
    #18
  19. Amer Neely

    Guest

    Ian Wilson <> wrote:
    > 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
     
    , Aug 24, 2007
    #19
  20. Amer Neely

    Ian Wilson Guest

    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.
     
    Ian Wilson, Aug 24, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Sham Ramakrishnan
    Replies:
    2
    Views:
    8,413
    Sham Ramakrishnan
    Jul 1, 2003
  2. mooseshoes

    To SOAP or Not To SOAP?

    mooseshoes, Sep 4, 2003, in forum: XML
    Replies:
    3
    Views:
    414
    Heinz Häberle
    Sep 21, 2003
  3. Nagesh
    Replies:
    2
    Views:
    9,453
    =?ISO-8859-1?Q?Arne_Vajh=F8j?=
    Aug 12, 2006
  4. comp.text.xml
    Replies:
    0
    Views:
    522
    comp.text.xml
    Sep 20, 2006
  5. Amogh Hooshdar

    any library for SOAP 1.1 or SOAP 1.2?

    Amogh Hooshdar, Jan 25, 2008, in forum: Python
    Replies:
    1
    Views:
    400
    Paul Watson
    Mar 11, 2008
Loading...

Share This Page