Hi,
we have a small but disturbing problem.
We always got the wrong time from a Soap-Service based on a wrong
Language and time-zone.

Is it possible to change the Language for Accept-Language in the
HTTP-Header for SOAP::Lite ?

Best regards
Florian Over

Hello!


is it possible to get methode valueof to work case insensitive?
So
$rez->valueof('//Detail/CODE') en $rez->valueof('//Detail/Code') get
same result.

Thanks.

Pele

Hi,

we have a very special problem here, but i hope anybody can help.

We use SOAP::Lite and Perl fuer an SOAP Server included as CGI-Script.

With Apache 1.3 all work fine:

I send a SOAP Call to get data and get back:

Date: Thu, 07 Dec 2006 17:11:42 GMT
Server: Apache
Content-Length: 3419
SOAPServer: SOAP::Lite/Perl/0.69
Connection: close
Content-Type: text/xml; charset=utf-8

<?xml version="1.0" encoding="UTF-8"?><soap:Envelope
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ecceroma="http://ecceroma.ecce-terram.de/ECCEROMAServer"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><getUs
erDataResponse
xmlns="http://ecceroma.ecce-terram.de/ECCEROMAServer"><errors
xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="ecceroma:Error[0]"
/><outParameters xsi:type="SOAP-ENC:Array"
SOAP-ENC:arrayType="ecceroma:Parameter[19]">
...
<key xsi:type="xsd:string">Ecom_ShipTo_Postal_City</key><value
xsi:type="xsd:string">CONTENTDATA</value></item>

The CONTENTDATA have german "umlaute", coded as UTF-8.

Now i use apache 2.0 (or apache 2.2, have the same effect). Nothing
other is changed, the configuration is near to the default.

No i get the answer from the SOAP-Server:

Date: Thu, 07 Dec 2006 17:14:44 GMT
Server: Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7d
SOAPServer: SOAP::Lite/Perl/0.69
Content-Length: 3419
Connection: close
Content-Type: text/xml; charset=utf-8

<?xml version="1.0" encoding="UTF-8"?><soap:Envelope
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ecceroma="http://ecceroma.ecce-terram.de/ECCEROMAServer"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><getUs
erDataResponse
xmlns="http://ecceroma.ecce-terram.de/ECCEROMAServer"><errors
xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="ecceroma:Error[0]"
/><outParameters xsi:type="SOAP-ENC:Array"
SOAP-ENC:arrayType="ecceroma:Parameter[19]">
...
<key xsi:type="xsd:string">Ecom_ShipTo_Postal_City</key><value
xsi:type="xsd:string">CONTENTDATA</value></item>

And now the CONTENTDATA is coded in ISO-LATIN 1 (ISO 8859/1).

I dont understand this.AddDefaultCharset dont have somethink to do with
this.

Any idea ?

best regards

Frank

--
ECCE TERRAM Internet Services GmbH               Tel:   0441 500 120
An der grossen Wisch 36                          Fax:   0441 500 1229
26133 Oldenburg
Ex Astris Scientia

I've seen topics somewhat related to this, and am getting nervous
because nobody seems to have a good answer.  My company has developed
a series of SOAP services using SOAP::Lite on Linux.  We've
successfully had other Perl, PHP, Ruby and Java clients access the
services, but no luck with .NET yet.  We've created a simple service
to try and identify the problem, which hopefully somebody will be able
to help with.

I consume the following document literal (wrapped) WSDL file:
http://alpha.wirespring.net/web_services/Endpoints/SOAP/Demo?WSDL,
generate a dll using wsdl.exe and csc.  You can re-generate it if you
like, but the method call for return_chars() looks like this:

     public string
return_chars([System.Xml.Serialization.XmlElementAttribute(
			 "return_chars",
			 Namespace="urn:Endpoints/SOAP/Demo"
		 )] return_chars return_chars1) {
         object[] results = this.Invoke("return_chars", new object[] {
                     return_chars1});
         return ((string)(results[0]));
     }


We then compile a C# client against Demo.dll (the Security section is
optional, since we've disabled the authentication to try and work this
bug out):

using System;
using System.Diagnostics;
using System.Net;
using System.Web.Services;
using System.Web.Services.Protocols;
using System.Xml.Serialization;

class Example1 {

	 public static void Main(string[] args) {
		 // Set parameters
		 return_chars x = new return_chars();
		 x.input_string = "NET SOAP test string";
		 x.second_string = "";

		 //Security auth_info = new Security();
		 //auth_info.Account = "ACCOUNTNAME";
		 //auth_info.Username = "username";
		 //auth_info.Password = "password";

		 Demo myDemo = new Demo();
		 //myDemo.SecurityValue = auth_info;
		 Console.WriteLine("Got return value: " + myDemo.return_chars(x));
	 }
}

When we execute the client, it hits the server, which returns back
valid-looking XML, however myDemo.return_chars(x) is null.  We used
.NET Webservice Studio to examine the response content.  This is what
the server is sending back:

ResponseCode: 200 (OK)
Pragma:no-cache
SOAPAction:"Endpoints/SOAP/Demo#return_chars"
X-Cache:MISS from alpha.wirespring.net
Transfer-Encoding:chunked
Cache-Control:no-cache
Content-Type:text/xml
Date:Fri, 08 Dec 2006 18:58:43 GMT
Expires:Fri, 08 Dec 2006 18:58:43 GMT
Server:Apache/1.3.34 (Unix) mod_perl/1.29

<?xml version="1.0" encoding="utf-16"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
     <return_charsResponse
soap:encodingStyle="http://xml.apache.org/xml-soap/literalxml">
       <s-gensym18 xsi:type="xsd:string">N.E.T. .S.O.A.P .t.e.s.t.
.s.t.r.i.n.g</s-gensym18>
     </return_charsResponse>
   </soap:Body>
</soap:Envelope>

The visual tool in .NET WebService Studio also indicates that the
result string is null.  Oddly, though, when I use the Java-based
StrikeIron Web Service Analyzer, I get the exact same return content,
but it does correctly grab the return string.

At this point we're about out of ideas, so I'd appreciate any insight
that you may have!

Hi!

I'm using SOAP::Lite with VB6. It works ... nearly ;-)

When I'm using the current version (0.65) there always is generated an
error about missing HASH-values (or something similar) so I'm using the
0.52.

Now I have got two problems:

1. It doesn't seem to recognize the cookies that my SOAP server (PHP)
sends. The problem is that it can't work with sessions (tests with PHP as
SOAP client were sucessful so the problem lies within SOAP::Lite)

2. I tried to avoid this problem by manually setting a session variable as
GET parameter in the proxy URL
(http://server.domain.tld/soap/server.php?id=12345)  This works - but it
seems to be that I can choose to tell the class the proxy adress _or_ the
adress of the wsdl file. I haven't found an option to set _both_
parameters at once.

Is there any further documentation for SOAP::Lite with Visual Basic? I
have found only some sample code but nothing that really goes in the deep.

Thanks!

Michael
--
"The Macintosh may only have 10% of the market,
but it is clearly the top 10%" - Douglas Adams 1952-2001

Hello,

I'm trying to do a simple SOAP application very similar to the
hibyeout.pl example on the "Quick start reference".

When I try to run the program it reports the next problem:
"Can't locate object method "new" via package "SOAP::Packager::MIME"
(perhaps you forgot to load "SOAP::Packager::MIME"?) at
/usr/libdata/perl5/i386-openbsd/5.8.6/SOAP/Lite.pm line 3241."

There is no SOAP::Packager::MIME package on CPAN but Lite.pm has a
reference in... (packager => SOAP::Packager::MIME->new)

I installed manually the needed packages (.pm files) copying them to
/usr/libdata/perl5/i386-openbsd/5.8.6 directory because I can't
install cpan neither make in that host:

- SOAP::Lite.pm
- SOAP::Packager.pm
- SOAP::Defs.pm


Do I need to install more packages?

Thank you in advance,

David Morón,

Hi,

I wrote a small daemon that receives some index value via SOAP and
does further time consuming things based on the value.

The SOAP client is supposed not to care if the further actions are
sucessfull and it should not wait for the time consuming part to finish.

Is there any way to send a SOAP result to the client while still
"staying" in the context of the subroutine/method?

Right now I have something like this:

client.pl
---------
my $soap = SOAP::Lite
             -> on_fault(sub{})
             -> uri($uri)
             -> proxy($proxy);

my $index = "123";
my $result = $soap->doSomething($index);

server.pl
---------
my $daemon = SOAP::Transport::HTTP::Daemon
     -> new (LocalAddr => $host, LocalPort => $port, Reuse => 1)
     -> dispatch_to('FOO');

$daemon->handle;

package FOO;

sub doSomething {
  my $par = shift;
  doTimeConsumingStuff($par);
  return;
}

What would be the appropriate way to send a return value to client and
keep processing $par?

I did some searching in this group and read some messages regarding
asynchronous messaging. It seemed an overkill to me implementing some
kind of task tracking system as I really do not care about the actual
result of doSomething();. Most examples also seem to be using the SOAP
daemon within an Apache context, which is not what I am using.

I´m kind of lost so any hint will be greatly appreciated :)

Thanks,

Emre

Hi,

I don't have a lot of experience doing this kind of thing, but here's
what I would try first (untested code):


my $par = shift;

my $child_pid = fork();
if ($child_pid) {
     # this is the parent, we'll just return
     return;
}
else {
     # this is the child, we'll do the hard stuff and then bail
     doTimeConsumingStuff($par);
     exit;
}


On 12/23/06, h_emre_k <kwah@...> wrote:
>
>
>
>
>
>
> Hi,
>
>  I wrote a small daemon that receives some index value via SOAP and
>  does further time consuming things based on the value.
>
>  The SOAP client is supposed not to care if the further actions are
>  sucessfull and it should not wait for the time consuming part to finish.
>
>  Is there any way to send a SOAP result to the client while still
>  "staying" in the context of the subroutine/method?
>
>  Right now I have something like this:
>
>  client.pl
>  ---------
>  my $soap = SOAP::Lite
>              -> on_fault(sub{})
>              -> uri($uri)
>              -> proxy($proxy);
>
>  my $index = "123";
>  my $result = $soap->doSomething($index);
>
>  server.pl
>  ---------
>  my $daemon = SOAP::Transport::HTTP::Daemon
>      -> new (LocalAddr => $host, LocalPort => $port, Reuse => 1)
>      -> dispatch_to('FOO');
>
>  $daemon->handle;
>
>  package FOO;
>
>  sub doSomething {
>   my $par = shift;
>   doTimeConsumingStuff($par);
>   return;
>  }
>
>  What would be the appropriate way to send a return value to client and
>  keep processing $par?
>
>  I did some searching in this group and read some messages regarding
>  asynchronous messaging. It seemed an overkill to me implementing some
>  kind of task tracking system as I really do not care about the actual
>  result of doSomething();. Most examples also seem to be using the SOAP
>  daemon within an Apache context, which is not what I am using.
>
>  I´m kind of lost so any hint will be greatly appreciated :)
>
>  Thanks,
>
>  Emre

I recommend you to also take care of the zombies in your father code.
If the parent exits (before the child did), you would produce ghosts
processes.

Write a method, checking the child after the time consuming stuff exited, to
catch if your child is a zombie.

Otherwhise, returning in the client method is pretty fine in this case, as
already mentioned by Mike.

In the parent method you could use
waitpid($child_pid, 0);

If (for any reason) you are about to spawn more than one process in your code,
you should think about using POSIX 'WNOHANG'

use POSIX 'WNOHANG';
$SIG{CHLD} = sub { while( waitpid(-1,WNOHANG)>0 ) {} };

Best regards,
Georg

On Monday 25 December 2006 19:00, Mike South wrote:
> Hi,
>
> I don't have a lot of experience doing this kind of thing, but here's
> what I would try first (untested code):
>
>
> my $par = shift;
>
> my $child_pid = fork();
> if ($child_pid) {
>     # this is the parent, we'll just return
>     return;
> }
> else {
>     # this is the child, we'll do the hard stuff and then bail
>     doTimeConsumingStuff($par);
>     exit;
> }
>
> On 12/23/06, h_emre_k <kwah@...> wrote:
> > Hi,
> >
> >  I wrote a small daemon that receives some index value via SOAP and
> >  does further time consuming things based on the value.
> >
> >  The SOAP client is supposed not to care if the further actions are
> >  sucessfull and it should not wait for the time consuming part to finish.
> >
> >  Is there any way to send a SOAP result to the client while still
> >  "staying" in the context of the subroutine/method?
> >
> >  Right now I have something like this:
> >
> >  client.pl
> >  ---------
> >  my $soap = SOAP::Lite
> >              -> on_fault(sub{})
> >              -> uri($uri)
> >              -> proxy($proxy);
> >
> >  my $index = "123";
> >  my $result = $soap->doSomething($index);
> >
> >  server.pl
> >  ---------
> >  my $daemon = SOAP::Transport::HTTP::Daemon
> >      -> new (LocalAddr => $host, LocalPort => $port, Reuse => 1)
> >      -> dispatch_to('FOO');
> >
> >  $daemon->handle;
> >
> >  package FOO;
> >
> >  sub doSomething {
> >   my $par = shift;
> >   doTimeConsumingStuff($par);
> >   return;
> >  }
> >
> >  What would be the appropriate way to send a return value to client and
> >  keep processing $par?
> >
> >  I did some searching in this group and read some messages regarding
> >  asynchronous messaging. It seemed an overkill to me implementing some
> >  kind of task tracking system as I really do not care about the actual
> >  result of doSomething();. Most examples also seem to be using the SOAP
> >  daemon within an Apache context, which is not what I am using.
> >
> >  I´m kind of lost so any hint will be greatly appreciated :)
> >
> >  Thanks,
> >
> >  Emre

Dear All,

We are looking For Perl & MySQL candidates for a CMMi  Software company in Chennai

Skill: Perl & MySQL
Work Location: Chennai
Exp: 2+Years
 
If you are looking for a good opening Please send the resume to
chennaijobs@..., (chennaijobs  @gmail.com)
(Mention  Perl, MySQL (Skill)/Experience/Current Location in the subject line)

 Please provide this info for a faster processing.

Name:
Contact NO:
Cell:
Landline:
Current company:
Current Location:
Current Salary:
Expected Salary:
Notice Period with Present Employer:
Total IT Experience:
Relevant Experience:
Key Skills:
Are you willing to relocate?: Y/N

Regards
Deepak
Chennai
98402 96832

Hi,

I'm having a few problems getting my WSDL to match the return value
from a SOAP::Lite daemon v0.67. I am using the examples on the quick
start guide, namely the http daemon and calling a simple package the
returns what you send it.

The XML I get back from v0.60 on my debian system has the hiResponse
prefixed(see below (1), the XML I get from 0.67 on my solaris system
is not prefixed (2), I'm using midreef to test and it complains that
the hiResonse section does not match the schema, as far as I can see
the schema loooks ok(newbie opinion). If I use the mindreef simulator
it sends back code that looks more like that of v0.60 and passes, i.e.
the elements are prefixed (3). WSDL is pasted below (4).

I think that I need to get SOAP::Lite to send back my response(2) to
like (3) i.e prefixed or adjust my WSDL, any help or examples would be
appreciated.


(1)

SOAPServer: SOAP::Lite/Perl/0.60

<?xml version="1.0" encoding="UTF-8"?><SOAP-ENV:Envelope
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/1999/XMLSchema"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Bod\
y><namesp1:hiResponse
xmlns:namesp1="http://www.soaplite.com/Demo"><param1
xsi:type="xsd:string">echo
me</param1></namesp1:hiResponse></SOAP-ENV:Body></SOAP-ENV:Envelope>


(2)

<soap:Envelope
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
     xmlns:xsd="http://www.w3.org/2001/XMLSchema"
     xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body>
       <hiResponse xmlns="PerlMQ_WS">
          <innerResponse xsi:type="xsd:string">sd</innerResponse>
       </hiResponse>
    </soap:Body>
</soap:Envelope>


(3)

<s0:hiResponse
           xmlns:s0="PerlMQ_WS"
           xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xmlns:xsd="http://www.w3.org/2001/XMLSchema">
          <innerResponse>123</innerResponse>
       </s0:hiResponse>

(4)

<?xml version="1.0"?>
<definitions name="WSMQ_Service" targetNamespace="PerlMQ_WS"
xmlns:tns="PerlMQ_WS" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

  xmlns="http://schemas.xmlsoap.org/wsdl/">
         <types>
                 <xsd:schema targetNamespace="PerlMQ_WS"
elementFormDefault="qualified">
                                         <xsd:complexType
name="MyResponseType">
                                 <xsd:all>
                                         <xsd:element
name="innerResponse" type="xsd:string"/>
                                 </xsd:all>
                         </xsd:complexType>

                 </xsd:schema>
         </types>

         <message name="RequestMessage">
                 <part name="Request" type="xsd:string"/>
         </message>

         <message name="ResponseMessage">
                 <part name="hiResponse" type="tns:MyResponseType"/>
         </message>

         <portType name="WSMQPortType">
                 <operation name="hi">
                         <input message="tns:RequestMessage"/>
                         <output message="tns:ResponseMessage"/>
                 </operation>
         </portType>

         <binding name="WSMQSoapBinding" type="tns:WSMQPortType">
                 <soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
                 <operation name="hi">
                         <soap:operation soapAction="PerlMQ_WS#hi"/>
                 <input>
                                 <soap:body use="encoded"
namespace="PerlMQ_WS"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>

                         </input>
                         <output>
                                 <soap:body use="encoded"
namespace="PerlMQ_WS"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>

                         </output>

                 </operation>
         </binding>

         <service name="WSMQService">
                 <documentation>My first service</documentation>
                 <port name="WSMQPort" binding="tns:WSMQSoapBinding">
                         <soap:address location="http://hostname:5010"/>
                 </port>
         </service>
</definitions>

I've got this going now, someone sent me a good link;

http://www-128.ibm.com/developerworks/webservices/library/ws-whichwsdl/

After reading this I decided to switch my WSDL style to document/literal.

I re-worked the schema(which makes more sense to me in this style) to
suit the messages sent and returned and it works fine. Mindreef was
very strict about the WSDL but hopefully it made me do it right.
Anyway, SOAP::Lite, XMLspy and Mindreef as clients all understand the
WSDL and act accordingly.

If anybody is interested in the code or WSDL I'll just reply to this
post and I'll add it.





--- In soaplite@yahoogroups.com, "martinh2osport" <martin@...> wrote:
>
> Hi,
>
> I'm having a few problems getting my WSDL to match the return value
> from a SOAP::Lite daemon v0.67. I am using the examples on the quick
> start guide, namely the http daemon and calling a simple package the
> returns what you send it.
>
> The XML I get back from v0.60 on my debian system has the hiResponse
> prefixed(see below (1), the XML I get from 0.67 on my solaris system
> is not prefixed (2), I'm using midreef to test and it complains that
> the hiResonse section does not match the schema, as far as I can see
> the schema loooks ok(newbie opinion). If I use the mindreef simulator
> it sends back code that looks more like that of v0.60 and passes, i.e.
> the elements are prefixed (3). WSDL is pasted below (4).
>
> I think that I need to get SOAP::Lite to send back my response(2) to
> like (3) i.e prefixed or adjust my WSDL, any help or examples would be
> appreciated.
>
>
> (1)
>
> SOAPServer: SOAP::Lite/Perl/0.60
>
> <?xml version="1.0" encoding="UTF-8"?><SOAP-ENV:Envelope
> xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
> xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:xsd="http://www.w3.org/1999/XMLSchema"
>
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Bod\
y><namesp1:hiResponse
> xmlns:namesp1="http://www.soaplite.com/Demo"><param1
> xsi:type="xsd:string">echo
> me</param1></namesp1:hiResponse></SOAP-ENV:Body></SOAP-ENV:Envelope>
>
>
> (2)
>
> <soap:Envelope
> soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>     xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
>     xmlns:xsd="http://www.w3.org/2001/XMLSchema"
>     xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>    <soap:Body>
>       <hiResponse xmlns="PerlMQ_WS">
>          <innerResponse xsi:type="xsd:string">sd</innerResponse>
>       </hiResponse>
>    </soap:Body>
> </soap:Envelope>
>
>
> (3)
>
> <s0:hiResponse
>           xmlns:s0="PerlMQ_WS"
>           xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
>           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>           xmlns:xsd="http://www.w3.org/2001/XMLSchema">
>          <innerResponse>123</innerResponse>
>       </s0:hiResponse>
>
> (4)
>
> <?xml version="1.0"?>
> <definitions name="WSMQ_Service" targetNamespace="PerlMQ_WS"
> xmlns:tns="PerlMQ_WS" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>
>  xmlns="http://schemas.xmlsoap.org/wsdl/">
>         <types>
>                 <xsd:schema targetNamespace="PerlMQ_WS"
> elementFormDefault="qualified">
>                                         <xsd:complexType
> name="MyResponseType">
>                                 <xsd:all>
>                                         <xsd:element
> name="innerResponse" type="xsd:string"/>
>                                 </xsd:all>
>                         </xsd:complexType>
>
>                 </xsd:schema>
>         </types>
>
>         <message name="RequestMessage">
>                 <part name="Request" type="xsd:string"/>
>         </message>
>
>         <message name="ResponseMessage">
>                 <part name="hiResponse" type="tns:MyResponseType"/>
>         </message>
>
>         <portType name="WSMQPortType">
>                 <operation name="hi">
>                         <input message="tns:RequestMessage"/>
>                         <output message="tns:ResponseMessage"/>
>                 </operation>
>         </portType>
>
>         <binding name="WSMQSoapBinding" type="tns:WSMQPortType">
>                 <soap:binding style="rpc"
> transport="http://schemas.xmlsoap.org/soap/http"/>
>                 <operation name="hi">
>                         <soap:operation soapAction="PerlMQ_WS#hi"/>
>                 <input>
>                                 <soap:body use="encoded"
> namespace="PerlMQ_WS"
> encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
>
>                         </input>
>                         <output>
>                                 <soap:body use="encoded"
> namespace="PerlMQ_WS"
> encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
>
>                         </output>
>
>                 </operation>
>         </binding>
>
>         <service name="WSMQService">
>                 <documentation>My first service</documentation>
>                 <port name="WSMQPort" binding="tns:WSMQSoapBinding">
>                         <soap:address location="http://hostname:5010"/>
>                 </port>
>         </service>
> </definitions>
>

I'm trying to wrap a raw xml file and send it to the server.  The
server resides as a daemon on the host.  The file contents are written
to xmlString.

Here's some code :

my $soap = SOAP::Lite
    ->uri('http://127.0.0.1/TestingService')
    ->proxy('http://127.0.0.1:8080/TestingService');

my $result = $soap->TestTransfer(SOAP::Data->type('xml' => $xmlString));


I can't get rid of the gensym tags.  I know I'm supposed to escape the
Data->name, but I don't use that anywhere, just Data->type.  Do I need
to explicitly create a method and nest the xml, then use the
$soap->call() - if so, how do I nest raw xml?

Cheers,
Rob

Hi All

I am using SOAP::Lite for writing client scripts. the wsdl schema has a complex
type mentioned below
which are interlinked with each other, Please tell me how to generate a SOAP
Data object of LoginInfo?

<s:complexType name="LoginInfo">
      <s:sequence>
       <s:element name="loginRoles" type="c:ArrayOfString" />
       <s:element name="databases" type="c:ArrayOfDatabaseInfo" />
      </s:sequence>
</s:complexType>

<s:complexType name="DatabaseInfo">
<s:sequence>
   <s:element name="name" type="s:string" />
   <s:element name="enabled" type="s:boolean" />
</s:sequence>
</s:complexType>

<s:complexType name="ArrayOfDatabaseInfo">
<s:sequence>
   <s:element name="databaseInfo" type="change:DatabaseInfo" minOccurs="0"
maxOccurs="unbounded" />
</s:sequence>
</s:complexType>

<s:complexType name="ArrayOfString">
<s:sequence>
   <s:element name="string" type="s:string" minOccurs="0" maxOccurs="unbounded"
/>
  </s:sequence>
</s:complexType>


Cheers!!
Harsha

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Hi,

We have been trying to make SOAP::Lite work for sending attachments to
and from servers, and we have pretty much made everything work
(including patching the code with the patch from sourceforge posted by
Joerg Prante on 2006-11-12). The only problem we are now left with, is
that our servers seem to include the request message's Content-Type
header in its responses. In any permutation of input/output including
attachments, this causes the response to be badly formed (either
because it has the wrong content type, or the wrong MIME boundary string).

Does anyone else have this problem? In all cases that we have tried so
far, the response's Content-Type is simply a clone of the resquest's.

Can anyone help?

Yours
Dave Thorne



... Server code example ...

#!/usr/bin/perl

use strict;
use SOAP::Transport::HTTP;
use MIME::Entity;

my $server = SOAP::Transport::HTTP::CGI ->
packager(SOAP::Packager::MIME->new) -> dispatch_to('runDSSP');
$server -> serializer -> autotype(0);
$server -> handle();

BEGIN {

     use strict;
     use vars qw(@ISA);
     @ISA = qw(SOAP::Server::Parameters);

     sub runDSSP {

         my $self = shift;
         my $envelope = pop; # SOM!!!

         # Create temporary file
         my $rand = rand;
         my $tmp_input = "/tmp/dssp-$rand.pdb";

         # Save PDB data to temporary file
         open(INPUT, ">$tmp_input");
         ${$envelope->parts}[0]->print(\*INPUT);
         close(INPUT);

         # Execute DSSP
         my $output = `/usr/local/bin/dsspcmbi -na $tmp_input`;

         my $ent = build MIME::Entity
             'Type'        => "text/plain",
             'Data'        => $output,
             'Filename'    => "dssp.out",
             'Disposition' => "attachment";;

         # Delete temporary file
         unlink $tmp_input;

         return $ent;
     }

}

Hello,

I've been having the same problem - is there any work around for this? Is this
problem
likely to be fixed in the near future?

I really ike SOAP::Lite as a fast and simple platform for developing web
services; however
this is a very serious limitation as far as I am concerned!

Cheers,

James.

--- In soaplite@yahoogroups.com, "mmmbena1" <mmmbena1@...> wrote:
>
> Hi,
>
> We have been trying to make SOAP::Lite work for sending attachments to
> and from servers, and we have pretty much made everything work
> (including patching the code with the patch from sourceforge posted by
> Joerg Prante on 2006-11-12). The only problem we are now left with, is
> that our servers seem to include the request message's Content-Type
> header in its responses. In any permutation of input/output including
> attachments, this causes the response to be badly formed (either
> because it has the wrong content type, or the wrong MIME boundary string).
>
> Does anyone else have this problem? In all cases that we have tried so
> far, the response's Content-Type is simply a clone of the resquest's.
>
> Can anyone help?
>
> Yours
> Dave Thorne
>
>
>
> ... Server code example ...
>
> #!/usr/bin/perl
>
> use strict;
> use SOAP::Transport::HTTP;
> use MIME::Entity;
>
> my $server = SOAP::Transport::HTTP::CGI ->
> packager(SOAP::Packager::MIME->new) -> dispatch_to('runDSSP');
> $server -> serializer -> autotype(0);
> $server -> handle();
>
> BEGIN {
>
>     use strict;
>     use vars qw(@ISA);
>     @ISA = qw(SOAP::Server::Parameters);
>
>     sub runDSSP {
>
>         my $self = shift;
>         my $envelope = pop; # SOM!!!
>
>         # Create temporary file
>         my $rand = rand;
>         my $tmp_input = "/tmp/dssp-$rand.pdb";
>
>         # Save PDB data to temporary file
>         open(INPUT, ">$tmp_input");
>         ${$envelope->parts}[0]->print(\*INPUT);
>         close(INPUT);
>
>         # Execute DSSP
>         my $output = `/usr/local/bin/dsspcmbi -na $tmp_input`;
>
>         my $ent = build MIME::Entity
>             'Type'        => "text/plain",
>             'Data'        => $output,
>             'Filename'    => "dssp.out",
>             'Disposition' => "attachment";;
>
>         # Delete temporary file
>         unlink $tmp_input;
>
>         return $ent;
>     }
>
> }
>

Hi,

I'm interested to know what the current development status of
SOAP::Lite is. The webpages (http://www.soaplite.com/) haven't been
updated for a year and still list version 0.67 as the latest release
(whereas CPAN currently hosts version 0.69.)

Are any updates planned to either the software or its documentation
in the near future? Is SOAP::Lite still being actively developed/
supported?

Regards,

James.

--- In soaplite@yahoogroups.com, James Sinnott <sinnottj@...> wrote:
>
> Hi,
>
> I'm interested to know what the current development status of
> SOAP::Lite is. The webpages (http://www.soaplite.com/) haven't
been
> updated for a year and still list version 0.67 as the latest
release
> (whereas CPAN currently hosts version 0.69.)
>
> Are any updates planned to either the software or its
documentation
> in the near future? Is SOAP::Lite still being actively developed/
> supported?
>
> Regards,
>
> James.
>

Hello,

that's also the matter I'm interested in. It'd be good if the module
maintainer sent anything about his intentions with the module.
Though I'm not sure if he follows this group.

Radek

I do actively follow the group. I rarely have time to respond however
between work, a kid, and a number of other projects I am actively
engaged in.

I tend to develop SOAP::Lite in bursts when need and opportunity
converge and I have a god chunk of time to work with.

As with any open source project, it is always looking for help and
looking for members from the community to take the initiative to
contribute (some have, and I should go back and incorporate some of
their patches).

I could write a State of the SOAP address to give the community a sense
of what's up... if I did, it would go something like this:

The SOAP protocol is still in wide use today as it has become native to
so many development platforms.SOAP itself has also become an incredibly
stable protocol. The WS-* Wars of the early millenium seem to have died
down, and the few truly useful extensions to SOAP have been selected by
the market.

Most SOAP toolkits as well have stablized along with the protocol.
Relatively speaking, the status of this SOAP toolkit is fair to good.

SOAP::Lite works with the majority of endpoints, but has a number of
interoperability issues with more modern implementations of SOAP servers
and clients. The task of keeping SOAP::Lite up to date is a difficult
one. The source code is notoriously complex, a mark of the ingenious
Paul who created SOAP:Lite, and as a result baffles most inexperienced
Perl programmers, and indeed may even frighten them off. I myself am
given the highest respect in my office for signing up to maintain the
module - I work with some of the brightest and most experienced Perl
programmers in the industry and they all look at SOAP::Lite in awe.

But I am not trying to inflate my ego, I am trying to set the stage for
what should be next for Perl's only SOAP toolkit.

If SOAP::Lite as a project is to attract more contributing authors, it
is essential that the SOAP::Lite code base become easier to work with.
SOAP::Lite could benefit a great deal from shedding a lot of the code
written before the protocol had really matured, before the era of the
WS-i, before a time where other toolkits and servers had agreed upon and
embraced a set of best practices. SOAP::Lite should shift to become
document-driven, as opposed to RPC driven.

SOAP::Lite needs a re-write. SOAP::Lite needs to live up to its name of
"Lite." SOAP::Lite should be built from the ground up to conform to the
WS-i's requirements. It should be built first and foremost around a
wicked WSDL parser and engine. It should be made more modular so that
its components can be more easily swapped out for newer and better
implementations without disrupting users and developers. It should take
advantage of the number of perl modules that have evolved since
SOAP::Lite was conceived to reduce code complexity and obscurity.

SOAP::Lite needs your help. SOAP::Lite needs a group of 2-3 passionate
people to take a fresh look at this critical toolkit for Perl developers
and to usher into a new age of utilization, community growth, usage, and
utility.

Undertaking a project like this is not a trivial task. It requires
months and months of dedicated time and attention. And then it must also
be supported and maintained.

This project would not start from ground zero. There is a vision and a
plethora of tried and true code already within SOAP::Lite that shouldn't
be needlessly thrown away. What we endeavor to do is make SOAP::Lite
easier to grok and easier to work with. What we hope to create is a new
module, called SOAP::Easy.

Byrne Reese
Lead Developer and Maintainer, SOAP::Lite

Thank you for the "State of the SOAP" speech. Good to hear your're
still behind the module development.

I use a limited scope of its functions but it's a part of a bigger
project which is all in Perl.

A while ago someone mentioned this group being too polluted with
spam. Recently I reported several such spams to Yahoo Mail Abuse Help
and still wait if it will have any effect. There is always a
possibility to move the group from Yahoo to a safer place.

Radek

I've been beating my head against this one for a while and not finding
any solutions, so I thought I would post mine.

Talking to the .net service from SOAP was easy with all the interop
stuff.  Passing single parameters worked great to; however, when I
passed an array it would not be de-parsed by .Net.  If I tried to use
the information, the .net service would die with an uninstatitated
object error.  Below is my magic receipe.  There may be other
solutions, but it was the only approach I found which worked.  (Of
course, I stopped looking when I found one.)

The .Net service is quite simple.  It accepts an object array and
returns it.  My goal is to pass parameters in a hash style to avoid
needing to modify the interfaces when I add or remove parameters.

    <%@ WebService Language="VB" Class="CollectionWebServiceExample" %>
    Imports System.Web.Services

    <WebService(Namespace:="echoCollection")> _
    Public Class CollectionWebServiceExample
       Inherits System.Web.Services.WebService

       <WebMethod( Description := "Example for passing an object array")> _
       Public Function EchoCollection( objectArray() as Object ) As
Object()
          EchoCollection = objectArray
       End Function

    End Class

Now, the perl script.  What seems to be the magic trick is matching
the pass parameter variable (objectArray) and making every array item
have the name "anyType".  SOAP::Lite defaults to "item", so every
member must be explicitly set in a SOAP::Data block.

#!/usr/bin/perl -w
########################################
=head1 NAME

echoCollection.pl - a command line client to ping the soap server

=head1 DESCRIPTION

=head1 $Author: selberg $

=head1 $Date: 2006-08-01 11:08:23-07 $

=head1 $Revision: 1.3 $

=head1 COPYRIGHT

Copyright 1/16/2007, Agilent Technologies.

This program is free software.  You may copy,
modify, or redistribute it under the same terms
as Perl itself.

=cut

########################################
use strict "vars";
use SOAP::Lite;
use Getopt::Std;
use Data::Dumper;
my $soapPipeLine;

my $function  = 'EchoCollection';
my $server    = "http://myserver.mydomain.com/echoCollection.asmx";
my $port;
my $nameSpace = 'echoCollection';
my %options;
my @results;
my $i;
my @args;
my $array;
getopt( 'ts:p:n:f:', \%options );

#Turn on the SOAP::Lite trace
SOAP::Trace->import( 'debug' ) if defined( $options{'t'} );

$server    = $options{ 's' } if defined( $options{ 's' } );
$port      = $options{ 'p' } if defined( $options{ 'p' } );
$nameSpace = $options{ 'n' } if defined( $options{ 'n' } );
$function  = $options{ 'f' } if defined( $options{ 'f' } );

$server =~ s/(\/\/[^:\/]+)(:\d+)?/$1:$port/ if defined( $port );

push( @args, 'objectArray' );
push( @args, @ARGV ) if $#ARGV >= 0;
push( @args, [ 1, 2, 3 ] );

@results = soapCall( $function, $server, $nameSpace, @args);
print Dumper( @results );

sub soapCall
{
    my $function          = shift;
    my $server            = shift;
    my $nameSpace         = shift;
    my $arrayName         = shift;
    my @rawValues         = @_;
    my @soapValues;

    my $timeOut;  # = 5;
    my $msServer = 1;

    my $soapPipeLine;
    my @results;
    my $error;
    my @parameters;
    my $arg;
    my $callResult;
    my $buffer;

    $soapPipeLine = SOAP::Lite
                    -> uri( $nameSpace )
                    -> proxy( $server );

    $soapPipeLine-> on_action( sub{ join( '/', @_ ) } ) if defined(
$msServer );  # microsoft workaround
    $soapPipeLine->transport->timeout( $timeOut )       if defined(
$timeOut );

    # custom workaround for passing to .Net
    # on the server side (VB.net):
    # <SoapDocumentMethod( Use:=SoapBindingUse.Literal, _
    #                      ParameterStyle:=SoapParameterStyle.Wrapped, _
    #                      RequestElementName:="EchoCollection" ), _
    # WebMethod( Description := "Example for passing an object array")> _
    # Public Function EchoCollection( objectArray() as Object ) As Object
    #   EchoCollection =  objectArray.Length
    #   EchoCollection = objectArray(0)
    # End Function

    # $arrayName needs to match the name of the pass parameter variable
in the .Net service
    # each array item should be labeled "anyType"

    foreach $buffer (@rawValues)
    {
       push( @soapValues, SOAP::Data->name('anyType' => $buffer) )
    }
    $buffer = SOAP::Data->name( $arrayName => \@soapValues );
    push( @parameters, $buffer );

    eval{
       $callResult = $soapPipeLine->call( $function => @parameters );
    };

    if( $@ )
    {
       warn( $@ . "\n" );
       @results = ();
    }
    else
    {
       if( ref( $callResult ) and $callResult->fault )
       {
          $error .= sprintf( "Fault Code:   " . $callResult->faultcode
. "\n" )   if $callResult->faultcode;
          $error .= sprintf( "Fault String: " .
$callResult->faultstring . "\n" ) if $callResult->faultstring;
          $error .= sprintf( "Fault Detail: " .
$callResult->faultdetail . "\n" ) if $callResult->faultdetail;
          $error .= sprintf( "Fault Actor: "  . $callResult->faultactor
. "\n" )  if $callResult->faultactor;

          warn( $error );
          @results = ();
       }
       elsif( ref( $callResult ) and defined( $callResult->result ) )
       {
          @results = ( $callResult->result );
          push( @results, $callResult->paramsout ) if(
$callResult->paramsout );
       }
    }

    @results = @{ $results[0]->{anyType} } if defined( $results[0] );

    return wantarray ? @results : $results[0];
}

And a slightly edited version has been posted to the SOAP::Lite blog:

http://www.soaplite.com/2007/01/state_of_the_so.html

Chris McMahon wrote:
>  I posted this to perlmonks:
> http://perlmonks.org/?node_id=594790
>
>
> On 1/15/07, *Byrne Reese* < byrne@...
> <mailto:byrne@...>> wrote:
>
>     I do actively follow the group. I rarely have time to respond however
>     between work, a kid, and a number of other projects I am actively
>     engaged in.
>
>     I tend to develop SOAP::Lite in bursts when need and opportunity
>     converge and I have a god chunk of time to work with.
>
>     As with any open source project, it is always looking for help and
>     looking for members from the community to take the initiative to
>     contribute (some have, and I should go back and incorporate some of
>     their patches).
>
>     I could write a State of the SOAP address to give the community a
>     sense
>     of what's up... if I did, it would go something like this:
>
>     The SOAP protocol is still in wide use today as it has become
>     native to
>     so many development platforms.SOAP itself has also become an
>     incredibly
>     stable protocol. The WS-* Wars of the early millenium seem to have
>     died
>     down, and the few truly useful extensions to SOAP have been
>     selected by
>     the market.
>
>     Most SOAP toolkits as well have stablized along with the protocol.
>     Relatively speaking, the status of this SOAP toolkit is fair to good.
>
>     SOAP::Lite works with the majority of endpoints, but has a number of
>     interoperability issues with more modern implementations of SOAP
>     servers
>     and clients. The task of keeping SOAP::Lite up to date is a difficult
>     one. The source code is notoriously complex, a mark of the ingenious
>     Paul who created SOAP:Lite, and as a result baffles most
>     inexperienced
>     Perl programmers, and indeed may even frighten them off. I myself am
>     given the highest respect in my office for signing up to maintain the
>     module - I work with some of the brightest and most experienced Perl
>     programmers in the industry and they all look at SOAP::Lite in awe.
>
>     But I am not trying to inflate my ego, I am trying to set the
>     stage for
>     what should be next for Perl's only SOAP toolkit.
>
>     If SOAP::Lite as a project is to attract more contributing
>     authors, it
>     is essential that the SOAP::Lite code base become easier to work
>     with.
>     SOAP::Lite could benefit a great deal from shedding a lot of the code
>     written before the protocol had really matured, before the era of the
>     WS-i, before a time where other toolkits and servers had agreed
>     upon and
>     embraced a set of best practices. SOAP::Lite should shift to become
>     document-driven, as opposed to RPC driven.
>
>     SOAP::Lite needs a re-write. SOAP::Lite needs to live up to its
>     name of
>     "Lite." SOAP::Lite should be built from the ground up to conform
>     to the
>     WS-i's requirements. It should be built first and foremost around a
>     wicked WSDL parser and engine. It should be made more modular so that
>     its components can be more easily swapped out for newer and better
>     implementations without disrupting users and developers. It should
>     take
>     advantage of the number of perl modules that have evolved since
>     SOAP::Lite was conceived to reduce code complexity and obscurity.
>
>     SOAP::Lite needs your help. SOAP::Lite needs a group of 2-3
>     passionate
>     people to take a fresh look at this critical toolkit for Perl
>     developers
>     and to usher into a new age of utilization, community growth,
>     usage, and
>     utility.
>
>     Undertaking a project like this is not a trivial task. It requires
>     months and months of dedicated time and attention. And then it
>     must also
>     be supported and maintained.
>
>     This project would not start from ground zero. There is a vision
>     and a
>     plethora of tried and true code already within SOAP::Lite that
>     shouldn't
>     be needlessly thrown away. What we endeavor to do is make SOAP::Lite
>     easier to grok and easier to work with. What we hope to create is
>     a new
>     module, called SOAP::Easy.
>
>     Byrne Reese
>     Lead Developer and Maintainer, SOAP::Lite
>
>
>
>

Hi all,

Quick question - should the code fragment below set the User Agent HTTP
header to be "myApp" when called by SOAP::Lite?

@soapargs = ( $url, proxy => [ 'http' => $proxy ], user_agent => "myApp" );
SOAP::Lite->proxy(@soapargs)->uri($uri)->on_fault(...);

It isn't working for me, but it may be a bug elsewhere in my code.

Any advice appreciated.

Thanks!

Mark

Hi,

How does one write a multi-client SOAP daemon (standalone server)?
That is daemon waits for incoming call, picks it up, forks a child and
let the child deal with the actual RPC, parents simply goes right back
up to accept the next call.

Typically one does this after accept(2) returns. But where do I fork
in the following usage.

     my $server = SOAP::Transport::HTTP::Daemon
                 ->new(LocalPort => $port, LocalAddr => $addr);
     $server->dispatch_to(WorkflowMgr);
     print "SOAP Listner available at: [", $server->url(), "]\n";
     $server->handle();

I don't want to fork in my RPCs (or methods) because the forking code
would be duplicated. I think I need to fork before the dispatching
takes place.

Thanks
Medi

medi.montaseri wrote:
> How does one write a multi-client SOAP daemon (standalone server)?
> That is daemon waits for incoming call, picks it up, forks a child and
> let the child deal with the actual RPC, parents simply goes right back
> up to accept the next call.

There are a bunch of examples that come with SOAP::Lite when you install
it. soap.daemon.forkafterprocessing and soap.daemon.forkonaccept should
give you an idea of the possibilities.

Cheers, Dave