Loading ...
Sorry, an error occurred while loading the content.

RE: [soaplite] in/out parameters binding

Expand Messages
  • Pierre DENIS
    Hi Paul, Thank you for the explanation. If object binding only occurs with SOAP::Lite server and client, it can be surprising because the behavior will be
    Message 1 of 3 , May 10, 2002
    • 0 Attachment
      Hi Paul,

      Thank you for the explanation.

      If object binding only occurs with SOAP::Lite server and client, it can be
      surprising because the behavior will be different from one client to
      Can you tell me which section of SOAP specifies the binding of objects in
      client and server as explained in your example? I've missed that point in

      I've encountered a problem with object binding, this is a simplified example
      of the problem:


      $obj1 = bless { foo => 'bar' } => 'MyPackage';
      $obj2 = bless { foo => 'boo' } => 'MyPackage';

      $result = $soap->call( 'mymethod', $obj1, $obj2);

      After calling the soap service with $soap, the result is:
      $result is a scalar
      $obj1 = bless { foo => 'bar' } => 'MyPackage';
      $obj2 = bless { foo => 'bar' } => 'MyPackage'; ??????????? - $obj2 has
      became $obj1

      I've made many tests, and so far, the problem occurs when I send 2 objects
      of the same type. Then, the second object becomes the first object. The
      memory space of each objects don't change and the 2d object alteration
      occurs in SOAP::Lite, in the in/out binding section.
      On the server side, $obj2 is not altered at all.
      So, if I use the code locally, not through SOAP::Lite, it works fine, but if
      I use it through SOAP::Lite, the 2d object is altered.

      Did I miss something?


      -----Original Message-----
      From: Paul Kulchenko [mailto:paulclinger@...]
      Sent: 09 May 2002 16:34
      To: Pierre DENIS; soaplite@yahoogroups.com
      Subject: Re: [soaplite] in/out parameters binding

      Hi, Pierre!

      --- Pierre DENIS <pdenis@...> wrote:
      > Tell me if I'm wrong, but the purpose is to bind the client
      > parameters with what happens on the server side.

      > It allows the code to run as if it was ran locally. The data the
      > server alter are also altered on the client side, magically.

      > This is really nice, however, it can lead to very tricky bugs,
      > because that is *not* an expected behavior (at least, not by me).
      it is ;)

      when you have

      sub a { $_[0] = 'b' }

      $a = 'a';
      print $a;

      you expect it to print 'b' as far as I understand. That's exactly
      what's happening here.

      > When I use SOAP, I expect the client to be completely shielded from
      > the server.

      > Even if the server change the content of the hashref I'm sending,
      > the client should keep the hashref as-is.
      May or may not be the case. See above. Also when $a is an object:

      $a->foo('bar'); # which is almost the same as foo($a, 'bar')

      may change attributes of $a.

      > But in some occasions, it doesn't. The magic binding propagate the
      > change to the client.
      yes. it's part of contract. if you have a('a'); in early mentioned
      example, you'll get an error.

      > Now, I think it's a specific SOAP::Lite behavior, and that's not a
      > part of SOAP specification (is it?).
      no. It's part of SOAP spec that describes in, out and in/out

      > Moreover, it seems to works only with a
      > client AND server using SOAP::Lite.
      no. it'll work with SOAP::Lite on client AND server side as well as
      with SOAP::Lite on client OR server side. Other implementations use
      information from service description to do the mapping, whereas
      SOAP::Lite uses name/type information to do the same thing.

      > So the behavior would be different with a .net client and a
      > SOAP::Lite server.
      No. At least in theory ;). the ONLY processing that is specific for
      SOAP::Lite is object binding. when you do


      and this method gets executed on server side you expect to get
      modified $a back when this object is modified on server side. However
      there is no way to return this object back as return parameter, so
      SOAP::Lite uses header information to do that. If you have
      non-SOAP::Lite server, your object ($a) won't be updated. Everything
      else, including method result, will work just fine.

      > I think that leads to problems. And to say the truth, I've
      > spent
      > several hours trying to debug something related to that
      > auto-binding.
      Any details? I may add tracing for that step.

      > I would be glad to have an explanation about the purpose of the
      > binding and when it occurs.
      It occurs only when incoming and outcoming parameters have the same
      name and type. SOAP::Lite will try to assign new value and will
      generate an error if you have static value or incompatible type
      (array ref on one side and hash ref on another side), which is
      probably what you expect.

      > Ideally, it would be nice to switch it on or off, so I don't have
      > too much magic happening, but maybe that's already possible.
      no, currently there is no way to switch is off. Although you can
      overload signature() method of SOAP::Serializer and return undef. Is
      it really necessary?

      Best wishes, Paul.

      Do You Yahoo!?
      Yahoo! Shopping - Mother's Day is May 12th!

      To unsubscribe from this group, send an email to:

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    Your message has been successfully submitted and would be delivered to recipients shortly.