Hi:

I am trying to develop a Web Service that will also be accessible by
VB clients on their desktops, I have the server and some clients
running perl (Soap::Lite of course) and now I am trying to develop
the VB client but am not able to use the same Object Oriented access
as I would from Perl.

For example (from the Soap::Lite page):

Perl code in OO style:
use SOAP::Lite +autodispatch =>
uri => 'http://www.soaplite.com/Temperatures',
proxy => 'http://services.soaplite.com/temper.cgi';

my $temperatures = Temperatures->new(32); # get object
print $temperatures->as_celsius;          # invoke method


I want to write an equivalent in Visual Basic. (The VB example on the
Soap::Lite page doesnt help much)

Can anyone help?

Thanks in advance,
Vaibhav.

--
Vaibhav Arya
Mega E-Services
www.megaeservices.com

Hi, Vaibhav!

Yes, Perl autoload magic is not available from COM interface (though
I'll need to do some tests, maybe it's something that could be worked
out). Meantime, you may make OO call using usual syntax:

use SOAP::Lite;

my $soap = new SOAP::Lite
   uri => 'http://www.soaplite.com/Temperatures',
   proxy => 'http://services.soaplite.com/temper.cgi';

my $temperatures = $soap->call('new', 35)->result; # get object
print $soap->as_celsius($temperatures)->result; # invoke method

Object goes as the first parameter during OO call:

$object->method(@parameters)
is (almost) the same as
class::method($object, @parameters)

where class is the class where object belongs.

Though this code could be easily mapped to VB code (use examples in
COM directory), I'm not sure that COM interface will store
$temperatures variable as an object. I'll try in a couple of hours.

Best wishes, Paul.

--- vaibhav_arya@... wrote:
> Hi:
>
> I am trying to develop a Web Service that will also be accessible
> by
> VB clients on their desktops, I have the server and some clients
> running perl (Soap::Lite of course) and now I am trying to develop
> the VB client but am not able to use the same Object Oriented
> access
> as I would from Perl.
>
> For example (from the Soap::Lite page):
>
> Perl code in OO style:
> use SOAP::Lite +autodispatch =>
> uri => 'http://www.soaplite.com/Temperatures',
> proxy => 'http://services.soaplite.com/temper.cgi';
>
> my $temperatures = Temperatures->new(32); # get object
> print $temperatures->as_celsius;          # invoke method
>
>
> I want to write an equivalent in Visual Basic. (The VB example on
> the
> Soap::Lite page doesnt help much)
>
> Can anyone help?
>
> Thanks in advance,
> Vaibhav.
>
> --
> Vaibhav Arya
> Mega E-Services
> www.megaeservices.com
>
>
>
> ------------------------ Yahoo! Groups Sponsor
>
> To unsubscribe from this group, send an email to:
> soaplite-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/

Hi Paul!

> restriction. Probably the most convenient way for you is to use
> ->dispatch_to('Class::[\w:]+');
>
> It should allow you to load all classes that have Class:: in their
> name (but not Class itself). Any regular expressions are allowed, so

I'm trying to use the regex-enabled static dispatch.  Here are my files, and
their locations:

My module is in
   /opt/camelot/lib/PDS/MGT/DEMO/Demo.pm
and looks like
----------------
package Demo;
sub hi  { my ($self, $name) = @_; return "hello, $name\n"; }
sub bye { my ($self, $name) = @_; return "goodbye, cruel $name\n"; }
1;
----------------
My server:
----------------
use SOAP::Transport::HTTP;
my $daemon = SOAP::Transport::HTTP::Daemon
   -> new (LocalPort => 12000)
   -> dispatch_to('PDS::[\w:]+');
$daemon->handle;
-----------------
and my client:
-----------------
use SOAP::Lite;

my $soap = SOAP::Lite
   -> uri('PDS/MGT/DEMO/Demo')
   -> proxy('http://localhost:12001')
   -> hi('test');
print $soap->fault ? $soap->faultdetail."\n" : $soap->result;
------------------
What I get, when I run the client, is
------------------
bash$ perl soap_client.pl
Failed to access class (PDS::MGT::DEMO::Demo): Can't locate PDS/MGT/DEMO/Demo.pm
in @INC (@INC contains: PDS::[\w:]+) at (eval 16) line 3.

Where do I specify the '/opt/camelot/lib' that my module tree lives in?

Hi, Michael!

> Where do I specify the '/opt/camelot/lib' that my module tree lives
> in?

you may specify it as you usually do with lib pragma in server code:

> use SOAP::Transport::HTTP;
use lib '/opt/camelot/lib';

or combine static and dynamic approach in dispatch_to (all
directories will be added to @INC during static dispatch):

-> dispatch_to('/opt/camelot/lib', 'PDS::[\w:]+');

Best wishes, Paul.

--- "Brutsch, Michael" <mbrutsch@...> wrote:
> Hi Paul!
>
> > restriction. Probably the most convenient way for you is to use
> > ->dispatch_to('Class::[\w:]+');
> >
> > It should allow you to load all classes that have Class:: in
> their
> > name (but not Class itself). Any regular expressions are allowed,
> so
>
> I'm trying to use the regex-enabled static dispatch.  Here are my
> files, and their locations:
>
> My module is in
>   /opt/camelot/lib/PDS/MGT/DEMO/Demo.pm
> and looks like
> ----------------
> package Demo;
> sub hi  { my ($self, $name) = @_; return "hello, $name\n"; }
> sub bye { my ($self, $name) = @_; return "goodbye, cruel $name\n";
> }
> 1;
> ----------------
> My server:
> ----------------
> use SOAP::Transport::HTTP;
> my $daemon = SOAP::Transport::HTTP::Daemon
>   -> new (LocalPort => 12000)
>   -> dispatch_to('PDS::[\w:]+');
> $daemon->handle;
> -----------------
> and my client:
> -----------------
> use SOAP::Lite;
>
> my $soap = SOAP::Lite
>   -> uri('PDS/MGT/DEMO/Demo')
>   -> proxy('http://localhost:12001')
>   -> hi('test');
> print $soap->fault ? $soap->faultdetail."\n" : $soap->result;
> ------------------
> What I get, when I run the client, is
> ------------------
> bash$ perl soap_client.pl
> Failed to access class (PDS::MGT::DEMO::Demo): Can't locate
> PDS/MGT/DEMO/Demo.pm in @INC (@INC contains: PDS::[\w:]+) at (eval
> 16) line 3.
>
> Where do I specify the '/opt/camelot/lib' that my module tree lives
> in?
>
> ------------------------ Yahoo! Groups Sponsor
>
> To unsubscribe from this group, send an email to:
> soaplite-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/

Paul:

Thanks for your message, will try and keep you updated!

My understanding is that the problem in the COM-OO interface is that
VB requires to have an object interface defined before you can
instantiate the same. Here the oject of type temprature is not pre-
defined for the VB world so the code (which I was trying, earlier):

Dim a as Temperature
Set a = SoapObject.new("35")

Will not work because VB does not recognise the object Temperature
yet.

Is my understanding correct?

MS SOAP Toolkit offers some sort of a TypeMapper together with their
WSML, does anyone have any idea about that?

Thanks again Paul

Regards,
Vaibhav

--
Vaibhav Arya
Mega E-Services
www.megaeservices.com

Hi, Vaibhav!

--- vaibhav_arya@... wrote:
> My understanding is that the problem in the COM-OO interface is
> that
> VB requires to have an object interface defined before you can
> instantiate the same. Here the oject of type temprature is not pre-
> defined for the VB world so the code (which I was trying, earlier):
>
> Dim a as Temperature
> Set a = SoapObject.new("35")
Cannot tell you for sure about first line (you may even try to skip
it), but second line should probably look like:

Set a = SoapObject.call("new", 35)

> Will not work because VB does not recognise the object Temperature
yet.
Right. This declaration shouldn't be there. However interface still
can return object from SoapObject.call(). I'll try tomorrow.

Best wishes, Paul.

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/

I am trying to access an existing class using a technique similar to
the 'Temperature' example in the Guide.  In all of my existing
classes, the methods expect the first parameter to be the class (i.e.
they all start out "my $self = shift;")  However, in your example, the
'as_celsius' method does not do this, while the 'c2f' method *does*.
This means I cannot use my existing class methods work with the remote
access example.  Does this make sense?

Hi, Michael!

inlined.

--- mbrutsch@... wrote:
> I am trying to access an existing class using a technique similar
> to
> the 'Temperature' example in the Guide.  In all of my existing
> classes, the methods expect the first parameter to be the class
> (i.e.
> they all start out "my $self = shift;")  However, in your example,
> the
> 'as_celsius' method does not do this, while the 'c2f' method
> *does*.
Actually it does. see 'shift' there? It gets first parameter (object)
and accesses _temperature field of it.

sub as_celsius {
       return 5/9*(shift->{_temperature}-32);
   }

> This means I cannot use my existing class methods work with the
> remote access example.  Does this make sense?
Actually you may not only use existing methods, but also combine
function calls with method calls (though it's not always a good idea,
but if you have established function interface and want to wrap it
into SOAP interface it could help):

sub method_or_function {
   shift if UNIVERSAL::isa($_[0] => __PACKAGE__);
   ......
}

first line shifts parameter in case of CLASS/OBJECT method call and
leave it there otherwise (function call). YOu may also distinguish
between CLASS/OBJECT calls if you check ref($_[0]).
Does it help?

Best wishes, Paul.

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/

Whenever I return a null from a method call, I get the error "Use of
uninitialized value".  It works fine when I return anything else.
Any thoughts?

Paul,

I am setting up an object, like so:

my $soap = SOAP::Lite
   ->uri/proxy/etc();

my $object = $soap
   -> call(new => parm1,
               => parm2)
   -> result;

Then I call a method on that object:

my $result = $soap
   -> method($object)
   -> result;

$result contains the result.  However, if I split the $soap->result
off, like so:

$soap
   -> method($object);

my $result = $soap
   -> result;

I always get '1' as a result.  I'm trying to use the following line
you sent me last week:

> print $soap->fault ? $soap->faultstring : $soap->result;

What am I doing wrong?

Thanks,
Michael

Hi, Michael!

Because it's REAL null (undef) value. if you do
$a = undef;
print $a;

you'll also get warning on this.

in our situation it could be
$a = $soap->something->result; # returns undef
print $a;

and you'll get warning again with -w.

What did you expect to get? I tried to reproduce as much Perlish
behavior as possible :)

Best wishes, Paul.

--- mbrutsch@... wrote:
> Whenever I return a null from a method call, I get the error "Use
> of
> uninitialized value".  It works fine when I return anything else.
> Any thoughts?
>
>
> ------------------------ Yahoo! Groups Sponsor
>
> To unsubscribe from this group, send an email to:
> soaplite-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/

Paul,

I wish to return an empty string, as in

$a = "";
print $a;

which returns no error with -w, but does with SOAP::Lite (perhaps you
are treating an empty string as undef?)


> Hi, Michael!
>
> Because it's REAL null (undef) value. if you do
> $a = undef;
> print $a;
>
> you'll also get warning on this.
>
> in our situation it could be
> $a = $soap->something->result; # returns undef
> print $a;
>
> and you'll get warning again with -w.
>
> What did you expect to get? I tried to reproduce as much Perlish
> behavior as possible :)
>
> Best wishes, Paul.
>
> --- mbrutsch@i... wrote:
> > Whenever I return a null from a method call, I get the error "Use
> > of
> > uninitialized value".  It works fine when I return anything else.
> > Any thoughts?

Hi, Michael!

While other methods for $soap object you may stack with arrow syntax
(->) because they return $soap object itself (when assigned value),
method call always returns SOAP::SOM object which gives you access to
the results of call:

my $soap = SOAP::Lite->....;
my $som = $soap->method(@parameters);
print $som->result;

which is the same as:

print $soap->method(@parameters)->result;

You skip assignment of result of method call, and got the wrong
results. Hope it helps.

Best wishes, Paul.

--- mbrutsch@... wrote:
> Paul,
>
> I am setting up an object, like so:
>
> my $soap = SOAP::Lite
>   ->uri/proxy/etc();
>
> my $object = $soap
>   -> call(new => parm1,
>               => parm2)
>   -> result;
>
> Then I call a method on that object:
>
> my $result = $soap
>   -> method($object)
>   -> result;
>
> $result contains the result.  However, if I split the $soap->result
> off, like so:
>
> $soap
>   -> method($object);
>
> my $result = $soap
>   -> result;
>
> I always get '1' as a result.  I'm trying to use the following line
> you sent me last week:
>
> > print $soap->fault ? $soap->faultstring : $soap->result;
>
> What am I doing wrong?
>
> Thanks,
> Michael
>
>
> ------------------------ Yahoo! Groups Sponsor
>
> To unsubscribe from this group, send an email to:
> soaplite-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/

Michael,
As I understand it, you need to create a response object to access the
result. For example:

---
my $soap = SOAP::Lite
	 -> proxy($proxy)
	 -> uri($uri);

my $response = $soap->call($method => (@args));

# Exit error if there is a transport problem
if (!ref $response) {
	 print STDERR "Error: Transport: ", $soap->transport->status, "\n";
	 exit(1);
}

# Exit error if there is an application problem
if ($response->fault) {
	 print STDERR "Error: ", $response->faultcode, ": ",
$response->faultstring, "\n";
	 print STDERR "       ", $response->faultdetail, "\n";
	 exit(1);
}

# Exit success if everything goes ok
print $response->result;
exit(0);
---

Hope that helps,
Mike

> -----Original Message-----
> From: mbrutsch@... [mailto:mbrutsch@...]
> Sent: Thursday, April 12, 2001 11:07 AM
> To: soaplite@yahoogroups.com
> Subject: [soaplite] Re: client-server forwarding trickery
>
>
> Paul,
>
> I am setting up an object, like so:
>
> my $soap = SOAP::Lite
>   ->uri/proxy/etc();
>
> my $object = $soap
>   -> call(new => parm1,
>               => parm2)
>   -> result;
>
> Then I call a method on that object:
>
> my $result = $soap
>   -> method($object)
>   -> result;
>
> $result contains the result.  However, if I split the $soap->result
> off, like so:
>
> $soap
>   -> method($object);
>
> my $result = $soap
>   -> result;
>
> I always get '1' as a result.  I'm trying to use the following line
> you sent me last week:
>
> > print $soap->fault ? $soap->faultstring : $soap->result;
>
> What am I doing wrong?
>
> Thanks,
> Michael
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-~>
> Find software faster. Search more than 20,000
> software solutions on KnowledgeStorm. Register
> now and get started.
> http://us.click.yahoo.com/HTDXJD/uMSCAA/zf4EAA/WNqXlB/TM
> --------------------------------------------------------------
> -------_->
>
> To unsubscribe from this group, send an email to:
> soaplite-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/

Hi, Michael!

you're absolutely right. All simple types defined in spec will return
undef value if transferred as <name ...../> or <name ....></name>. As
far as I can understand it makes difference only for string (empty
string becames undef), because for all other values empty string is
not allowed value anyway. Since null/undef values are marked as such
on wire or can be completely omitted I may convert undef string
values back to empty strings in deserializer. Any objections?

Best wishes, Paul.

--- mbrutsch@... wrote:
> Paul,
>
> I wish to return an empty string, as in
>
> $a = "";
> print $a;
>
> which returns no error with -w, but does with SOAP::Lite (perhaps
> you
> are treating an empty string as undef?)
>
>
> > Hi, Michael!
> >
> > Because it's REAL null (undef) value. if you do
> > $a = undef;
> > print $a;
> >
> > you'll also get warning on this.
> >
> > in our situation it could be
> > $a = $soap->something->result; # returns undef
> > print $a;
> >
> > and you'll get warning again with -w.
> >
> > What did you expect to get? I tried to reproduce as much Perlish
> > behavior as possible :)
> >
> > Best wishes, Paul.
> >
> > --- mbrutsch@i... wrote:
> > > Whenever I return a null from a method call, I get the error
> "Use
> > > of
> > > uninitialized value".  It works fine when I return anything
> else.
> > > Any thoughts?
>
>
> ------------------------ Yahoo! Groups Sponsor
>
> To unsubscribe from this group, send an email to:
> soaplite-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/

Paul Kulchenko wrote:

> Hi, Michael!
>
> you're absolutely right. All simple types defined in spec will return
> undef value if transferred as <name ...../> or <name ....></name>. As
> far as I can understand it makes difference only for string (empty
> string becames undef), because for all other values empty string is
> not allowed value anyway. Since null/undef values are marked as such
> on wire or can be completely omitted I may convert undef string
> values back to empty strings in deserializer. Any objections?

No, that would be fine.  I am just ignoring the warnings, at this point.
   Everything else is working great!  SOAP::Lite is most excellent!

Thanks,
Michael

>
> Best wishes, Paul.
>
> --- mbrutsch@... wrote:
>
>> Paul,
>>
>> I wish to return an empty string, as in
>>
>> $a = "";
>> print $a;
>>
>> which returns no error with -w, but does with SOAP::Lite (perhaps
>> you
>> are treating an empty string as undef?)
>>
>>
>>
>>> Hi, Michael!
>>>
>>> Because it's REAL null (undef) value. if you do
>>> $a = undef;
>>> print $a;
>>>
>>> you'll also get warning on this.
>>>
>>> in our situation it could be
>>> $a = $soap->something->result; # returns undef
>>> print $a;
>>>
>>> and you'll get warning again with -w.
>>>
>>> What did you expect to get? I tried to reproduce as much Perlish
>>> behavior as possible :)
>>>
>>> Best wishes, Paul.
>>>
>>> --- mbrutsch@i... wrote:
>>>
>>>> Whenever I return a null from a method call, I get the error
>>>
>> "Use
>>
>>>> of
>>>> uninitialized value".  It works fine when I return anything
>>>
>> else.
>>

Hello,

We are trying to secure the communication between a soap client and soap
daemon using ssl over http.

Our soap client would be something like:

#!perl -w
#
#SOAP Client
#
use SOAP::Lite;
print SOAP::Lite
-> uri('Demo')
-> proxy('https://services.soaplite.com/hibye.cgi')
-> hi()
-> result;

However Im not sure how to code the daemon to serve ssl.  Currently our
daemon is like

#!perl -w
#
#SOAP Daemon
#

use SOAP::Transport::HTTP;
use Demo;

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

SOAP::Transport::HTTP::CGI
    -> new (LocalPort => 80)
    -> dispatch_to('/home/soaplite/modules')   ;

print "Contact to SOAP server at ", $daemon->url, "\n"; $daemon->handle;




Any thoughts or pointers?

Thank you in advance.

Oops,

The proxy line in the client should be:

-> proxy('https://loclhost/hibye.cgi')

Not:

-> proxy('https://services.soaplite.com/hibye.cgi')

Thanks again




-------- Original Message --------
Subject: SSL Soap Daemon
Date: Fri, 13 Apr 2001 09:46:43 -0500
From: Steve McKay <smckay@...>
To: soaplite@yahoogroups.com



Hello,

We are trying to secure the communication between a soap client and soap
daemon using ssl over http.

Our soap client would be something like:

#!perl -w
#
#SOAP Client
#
use SOAP::Lite;
print SOAP::Lite
-> uri('Demo')
-> proxy('https://services.soaplite.com/hibye.cgi')
-> hi()
-> result;

However Im not sure how to code the daemon to serve ssl.  Currently our
daemon is like

#!perl -w
#
#SOAP Daemon
#

use SOAP::Transport::HTTP;
use Demo;

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

SOAP::Transport::HTTP::CGI
    -> new (LocalPort => 80)
    -> dispatch_to('/home/soaplite/modules')   ;

print "Contact to SOAP server at ", $daemon->url, "\n"; $daemon->handle;




Any thoughts or pointers?

Thank you in advance.

Hi, Steve!

Currently SSL functionality is not supported for daemons. I know
about Net::Daemon::SSL and IO::Socket::SSL, but this functionality is
not integrated yet for couple of reasons: Net::Daemon::SSL is just
the first version, and nobody asked for it before :).

It's on my todo list, but couple of other things, like attachment
generation, performance hints, async processing, better WSDL support
and header handlers have higher priority. I'll give it a try and if
it'll be easy, I'll add it. if not, you can try it youself and I'll
definitely include it in distribution with your credits.

Best wishes, Paul.

--- "McKay, Steve" <smckay@...> wrote:
> Oops,
>
> The proxy line in the client should be:
>
> -> proxy('https://loclhost/hibye.cgi')
>
> Not:
>
> -> proxy('https://services.soaplite.com/hibye.cgi')
>
> Thanks again
>
>
>
>
> -------- Original Message --------
> Subject: SSL Soap Daemon
> Date: Fri, 13 Apr 2001 09:46:43 -0500
> From: Steve McKay <smckay@...>
> To: soaplite@yahoogroups.com
>
>
>
> Hello,
>
> We are trying to secure the communication between a soap client and
> soap
> daemon using ssl over http.
>
> Our soap client would be something like:
>
> #!perl -w
> #
> #SOAP Client
> #
> use SOAP::Lite;
> print SOAP::Lite
> -> uri('Demo')
> -> proxy('https://services.soaplite.com/hibye.cgi')
> -> hi()
> -> result;
>
> However Im not sure how to code the daemon to serve ssl.  Currently
> our
> daemon is like
>
> #!perl -w
> #
> #SOAP Daemon
> #
>
> use SOAP::Transport::HTTP;
> use Demo;
>
> # don't want to die on 'Broken pipe' or Ctrl-C
> $SIG{PIPE} = $SIG{INT} = 'IGNORE';
>
> SOAP::Transport::HTTP::CGI
>    -> new (LocalPort => 80)
>    -> dispatch_to('/home/soaplite/modules')   ;
>
> print "Contact to SOAP server at ", $daemon->url, "\n";
> $daemon->handle;
>
>
>
>
> Any thoughts or pointers?
>
> Thank you in advance.
>
>
>
>
>
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor
>
> To unsubscribe from this group, send an email to:
> soaplite-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/

I have two questions:

   1.  I can't seem to find out how to set a header in the response
       packet, how does that work?
   2.  After receiving a response using autodispatch how can I get at
       the header? For example, I have the following code:

         $auth = Plumbing::Auth->new(name(email => $email),
                                     name(password => $pass));

       I've tried $auth->valueof('//authInfo') but obviously that works
       on the Plumbing::Auth class not SOAP::SOM. Is there another way?
       Or will I have to use the object interface, and if that is the
       case, how would my snippet above translate over?

So, I guess it's more like 2.5 questions but I hope someone can help
me.

--
chalk slayer

Hi, Ashley!

--- Ashley Clark <aclark@...> wrote:
>   1.  I can't seem to find out how to set a header in the response
>       packet, how does that work?

return 1, SOAP::Header->name(a => 1)->uri('http://my.namespace'), 2;

will return 1,2 as the result AND specified header as header.
Position is irrelevant. SOAP::Header has EXACTLY the same methods as
SOAP::Data. uri is RECOMMENDED, because header must be namespace
qualified.

>   2.  After receiving a response using autodispatch how can I get
> at
>       the header? For example, I have the following code:
>
>         $auth = Plumbing::Auth->new(name(email => $email),
>                                     name(password => $pass));
>
>       I've tried $auth->valueof('//authInfo') but obviously that
> works
>       on the Plumbing::Auth class not SOAP::SOM. Is there another
> way?
>       Or will I have to use the object interface, and if that is
> the
>       case, how would my snippet above translate over?

First, SOAP::Lite->self will return OBJECT that is used for
autodispatch and $soap->call will return SOAP::SOM object for the
last call.

so, in your case:

$authinfo = SOAP::Lite->self->call->valueof('//authInfo');
# or ->dataof(...) if you need to have access to attributes

As for OO interface, you may call

my $soap = SOAP::Lite->uri('http://something/Plumbing/Auth')
                      ->proxy(...);
$response = $soap->call(new => name(email => $email),
                                name(password => $pass));
$result = $response->result;
$authInfo = $response->valueof('//authInfo');

Basically OO calls can do the same as autodispatched calls, only you
need to specify object first:

AD:
$result = CLASS->method(@parameters);

OO:
# specify uri as http://something/CLASS
$result = $soap->call('method', @parameters)->result;

AD:
$result = $OBJECT->method(@parameters);

OO:
$result = $soap->call('method', $OBJECT, @parameters)->result;

so, as usual in OO calls, it's translated to function call with
object as the first parameter. ONLY difference is with CLASS, call,
because CLASS name wil NOT go as the first parameter (should be
specified in URI).

Hope it helps.

Best wishes, Paul.

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/

* Paul Kulchenko in "Re: accessing headers while using autodispatch?"
* dated 2001/04/14 12:18 wrote:

> --- Ashley Clark <aclark@...> wrote:
> >   1.  I can't seem to find out how to set a header in the response
> >       packet, how does that work?
>
> return 1, SOAP::Header->name(a => 1)->uri('http://my.namespace'), 2;
>
> will return 1,2 as the result AND specified header as header.
> Position is irrelevant. SOAP::Header has EXACTLY the same methods as
> SOAP::Data. uri is RECOMMENDED, because header must be namespace
> qualified.

One more question then, should this uri be a real address?

[long *excellent* explanation of OO vs AD syntax snipped]

Thanks very much, both for the quick response and the useful answer.
That gets me past my stumbling block here. And also, thank you very
much for providing such a wonderful library.

--
really hacks

Hi, Ashley!

--- Ashley Clark <aclark@...> wrote:
> One more question then, should this uri be a real address?
No, there is no such requirement, but ideally namespace name should
be unique, so usually it's represented by company address (which is
unique) and path that describes particular project/application/task
(which is unique inside the company). It effectively creates globally
unique identifier. For examples, I'm using
http://www.soaplite.com/something_specific. It doesn't need to be
http, it could be something else and doesn't need to be resolved
somewhere. Check XML Namespaces FAQ:
http://www.rpbourret.com/xml/NamespacesFAQ.htm, excellent resource.

> That gets me past my stumbling block here. And also, thank you very
> much for providing such a wonderful library.
Glad you like it. Next version should also provide some interesting
features. Look for announce soon.

Best wishes, Paul.


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/

If you instantiate an object from the client, when does the server-side
memory for that object get freed?

Hi, Michael!

Client doesn't have control on it. Depends on server configuration:
10 minutes of inactivity time by default, can be altered with custom
handler. You can provide function for garbage collection specific for
class (or several classes):

   .......
   -> objects_by_reference(
    'My::PersistentIterator', 'My::SessionIterator'
      => \&garbage_collector)

sub &garbage_collector {
   my(
     $number_of_objects_of_this_class, # if you want to implement
cache
     $current_time,
     $object,
     $type, # ref $object
     $creation_time, # cannot be undef
     $last_access_time, # can be undef if not accessed
   ) = @_;
   .....
   1; # object will be collected
   0; # object will be kept
}

This is the default function:
sub { $_[1]-$_[$_[5] ? 5 : 4] > 600 }
check if access or creation time was more than 10 minutes ago.

Still in infancy, but works.

Best wishes, Paul.

--- "Brutsch, Michael" <mbrutsch@...> wrote:
> If you instantiate an object from the client, when does the
> server-side
> memory for that object get freed?
>
> ------------------------ Yahoo! Groups Sponsor
>
> To unsubscribe from this group, send an email to:
> soaplite-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/

Hi Paul,
I am developing an application on top of SOAP::Lite which of course relies
on the fault method to know if anything obvious went wrong with the
transaction. However, I cannot always count on a SOAP server being up and
running at the location I am using for the proxy.

For some reason, I am not getting the following HTTP errors in any kind of
fault structure:
	 404 Not Found (File does not exist in Apache DocumentRoot)
	 405 Method Not Allowed (Apache disallowed the POST method)
	 500 Can't connect (nothing listening on the port)

Why are these error first being spewed onto STDERR and then killing my
process, instead of being put into a fault method? Shouldn't they be
propogated back to the client in this form, or am I confused? If I am just
confused, how can I detect/handle this situation? I am using SOAP::Lite 0.46
with a forking SOAP::Transport::HTTP::Daemon as my server and SOAP::Lite as
my client.

Here is an example of output I am getting:
	 SOAP call failed: 500 Can't connect to bacardi:808 (Timeout),
<STDIN> line 5.
	  at /export/home/mpercy/source/lib/Access.pm line 98

All line 98 is is this:
	 my $res = $soap->call($method, @args);

Any help you could lend would be greatly appreciated.

Thanks,
Mike

Paul,
I figured it out... I should have been using the on_fault handler... it is
right there in the docs. I thought I was covered from doing a check after
the method call but I guess not. Sorry to bother you.

Thanks,
Mike

> -----Original Message-----
> From: Michael Percy [mailto:mpercy@...]
> Sent: Tuesday, April 17, 2001 6:51 PM
> To: 'soaplite@yahoogroups.com'
> Subject: [soaplite] HTTP Errors
>
>
> Hi Paul,
> I am developing an application on top of SOAP::Lite which of
> course relies
> on the fault method to know if anything obvious went wrong with the
> transaction. However, I cannot always count on a SOAP server
> being up and
> running at the location I am using for the proxy.
>
> For some reason, I am not getting the following HTTP errors
> in any kind of
> fault structure:
>  404 Not Found (File does not exist in Apache DocumentRoot)
>  405 Method Not Allowed (Apache disallowed the POST method)
>  500 Can't connect (nothing listening on the port)
>
> Why are these error first being spewed onto STDERR and then killing my
> process, instead of being put into a fault method? Shouldn't they be
> propogated back to the client in this form, or am I confused?
> If I am just
> confused, how can I detect/handle this situation? I am using
> SOAP::Lite 0.46
> with a forking SOAP::Transport::HTTP::Daemon as my server and
> SOAP::Lite as
> my client.
>
> Here is an example of output I am getting:
>  SOAP call failed: 500 Can't connect to bacardi:808 (Timeout),
> <STDIN> line 5.
> 	 at /export/home/mpercy/source/lib/Access.pm line 98
>
> All line 98 is is this:
>  my $res = $soap->call($method, @args);
>
> Any help you could lend would be greatly appreciated.
>
> Thanks,
> Mike
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-~>
> Secure your servers with 128-bit SSL encryption!
> Grab your copy of VeriSign's FREE Guide,
> "Securing Your Web site for Business." Get it now!
> http://us.click.yahoo.com/KVNB7A/e.WCAA/bT0EAA/WNqXlB/TM
> --------------------------------------------------------------
> -------_->
>
> To unsubscribe from this group, send an email to:
> soaplite-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/

Hi, Michael!

Right. Here is (long) post that explains it with more details:

--- Ray Rizzuto <ray.rizzuto@...> wrote:
> There's no perfect solution to error handling since it depends so
> much on the application.  In my case, I am choosing to treat
Unfortunately not only. It may depend on Server implementation also,
though I tried hard to hide these details from you.
Several situations are possible:
   1. 200 OK + SOAP message (normal result)
   2a. 500 Server Error + error message (not SOAP)
   2b. 400 Bad Method + error message (not SOAP)
   2c. 510 Not Extended + error message (not SOAP)
   3a. 500 Server Error + SOAP message (Fault result)
   3b. 400 Bad Method + SOAP message (Fault result)
   4. 200 OK + SOAP message (Fault result)

  OK Transport + OK SOAP
  1. 200 OK + SOAP message (normal result)

  Error Transport + no SOAP
  2a. 500 Server Error + error message (not SOAP)
  2b. 400 Bad Method + error message (not SOAP)
  2c. 510 Not Extended + error message (not SOAP)
  2d. All other errors

  Error Transport + Fault SOAP
  3a. 500 Server Error + SOAP message (Fault result)
  3b. 400 Bad Method + SOAP message (Fault result)

  OK transport + Fault SOAP
  4. 200 OK + SOAP message (Fault result)

2c will be handled by SOAP::Lite automatically (you won't see it, as
well as redirect from server).
3b and 4 are not allowed according to current spec., though there was
long debates about using 1 and 4 instead of 1 and 3a.

> 1) could you give more details on the parameters passed to the
> fault handler? And also what the fault handler can return and how
> that
> is used?  It seems that what it returns is returned to the failed
> call, but I'm not positive.

on_fault accepts two parameters: SOAP::Lite object and deserialized
result (exactly as you would get it after $soap->mymethod() call).
You may return this deserialized result or create your own and it'll
become the result of call.
In case you returned false (on_fault(sub{})) result of the call will
be deserialized message as if on_fault wasn't call at all (no error
handling).

> 2) in one of the examples you provide, you are creating a new
> SOAP::SOM to return from the fault handler:
>
>   use SOAP::Lite
>     on_fault => sub { my($soap, $res) = @_;
>       eval { die ref $res ? $res->faultdetail : $soap->transport-
> >status };
>       return ref $res ? $res : new SOAP::SOM;
>     };
>
> If I could set the fault values in this new SOM, I would be able to
> address errors uniformly after the original call.  Or am I
> misunderstanding this code?
No, you're not. You cannot assign it, but you may create new SOM
object as result of deserialization:

use SOAP::Lite
   on_fault => sub { my($soap, $res) = @_;
    eval { die ref $res ? $res->faultdetail : $soap->transport->status
};
      return ref $res ? $res :
        $soap->deserializer->deserialize(
          $soap->serializer->fault('Server.Transport',
$soap->transport->status));
    };

print SOAP::Lite->proxy('http://localhost/')->mymethod->faultstring;

> 3) in the above code, on a transport error @_ has 2 entries, but
> the
> second one seems to just have an empty string.  Is that the defined
> behavior for a transport error?
There should be deserialized message (if you got Fault response) OR
content of the message (if message couldn't be deserialized, for
example HTML code or some string with error message), so if you check
and there is not refrence, you can be sure that it's pure transport
error (and not SOAP Fault).

Best wishes, Paul.

--- Michael Percy <mpercy@...> wrote:
> Paul,
> I figured it out... I should have been using the on_fault
> handler... it is
> right there in the docs. I thought I was covered from doing a check
> after
> the method call but I guess not. Sorry to bother you.
>
> Thanks,
> Mike
>
> > -----Original Message-----
> > From: Michael Percy [mailto:mpercy@...]
> > Sent: Tuesday, April 17, 2001 6:51 PM
> > To: 'soaplite@yahoogroups.com'
> > Subject: [soaplite] HTTP Errors
> >
> >
> > Hi Paul,
> > I am developing an application on top of SOAP::Lite which of
> > course relies
> > on the fault method to know if anything obvious went wrong with
> the
> > transaction. However, I cannot always count on a SOAP server
> > being up and
> > running at the location I am using for the proxy.
> >
> > For some reason, I am not getting the following HTTP errors
> > in any kind of
> > fault structure:
> >  404 Not Found (File does not exist in Apache DocumentRoot)
> >  405 Method Not Allowed (Apache disallowed the POST method)
> >  500 Can't connect (nothing listening on the port)
> >
> > Why are these error first being spewed onto STDERR and then
> killing my
> > process, instead of being put into a fault method? Shouldn't they
> be
> > propogated back to the client in this form, or am I confused?
> > If I am just
> > confused, how can I detect/handle this situation? I am using
> > SOAP::Lite 0.46
> > with a forking SOAP::Transport::HTTP::Daemon as my server and
> > SOAP::Lite as
> > my client.
> >
> > Here is an example of output I am getting:
> >  SOAP call failed: 500 Can't connect to bacardi:808 (Timeout),
> > <STDIN> line 5.
> > 	 at /export/home/mpercy/source/lib/Access.pm line 98
> >
> > All line 98 is is this:
> >  my $res = $soap->call($method, @args);
> >
> > Any help you could lend would be greatly appreciated.
> >
> > Thanks,
> > Mike
> >
> > ------------------------ Yahoo! Groups Sponsor
> > ---------------------~-~>
> > Secure your servers with 128-bit SSL encryption!
> > Grab your copy of VeriSign's FREE Guide,
> > "Securing Your Web site for Business." Get it now!
> > http://us.click.yahoo.com/KVNB7A/e.WCAA/bT0EAA/WNqXlB/TM
> > --------------------------------------------------------------
> > -------_->
> >
> > To unsubscribe from this group, send an email to:
> > soaplite-unsubscribe@yahoogroups.com
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
> ------------------------ Yahoo! Groups Sponsor
>
> To unsubscribe from this group, send an email to:
> soaplite-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

New version of SOAP::Lite released today:

fixed tests on Windows platform
fixed authInfo in UDDI publishing interface
fixed mod_soap (Apache::SOAP) on Perl 5.005/5.004
fixed namespace prefix on arrays of arrays
modified Content-encoding from 'compress' to 'deflate'
added XML::Parser::Lite, regexp-based XML parser
  used automatically when XML::Parser is not available
added XMLRPC::Lite (XMLRPC client and server interface)
added XMLRPC interactive shell (XMLRPCsh.pl)
added dispatching based on URI and SOAPAction (dispatch_with)
added dispatching to object (in addition to class/method)
added dispatch from specific class(es) (dispatch_from)
added SOAP::Fault class for customization of returning Fault message
added INCOMPATIBILITY section in README file
added live tests/examples for UDDI publishing interface
added live tests/examples for basic authentication
added XMLRPC server code that validates with Userland's validator
added more examples, tests and documentation

Module is available from http://www.soaplite.com/,
or from CPAN http://search.cpan.org/search?dist=SOAP-Lite.

Comments are very welcome.

Best wishes, Paul.


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

Paul

There seems to be a problem in V0.50 with changing the default namespace
and encoding space prefixes (SOAP-ENV and SOAP-ENC).  The following
snippet of code works on V0.47 but fails with
"Application failed during request deserialization: Unresolved prefix
'env' for element 'Envelope'" with the new release.

my $s = SOAP::Lite
     -> uri($uri)
     -> namespace('env')
     -> encodingspace('enc')
     -> proxy("$protocol//$server:$port$endpoint")
;

Here's the envelope element created with 0.47:

<env:Envelope xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/1999/XMLSchema"
env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">

and here's the equivalent for 0.50

<env:Envelope xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/1999/XMLSchema"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">

Regards,
Duncan Cameron