Re^3: SOAP and Perl

That is true, but there is also the other side of the story.

As an end user, when you call web service, you don't care whether SOAP is behind everything (although you know that for a fact, but you don't care). All you care is that you are calling a function or a method, whatever how you call it. Obviously you can paa an object to the call (and you don't care how it is marshalled).

One of my web service call accept an Pair object, and return a different Pair object (Pair is nothing more than a pair of interger and bunch of methods), and the server side is in java. When I call it from Ruby, I can define a similar class on the client (in Ruby), and send and receive the Ruby Pair object, as if it is a Java Pair object. That's really handy, makes lots of sense.

When I use SOAP::Lite, I have to treat the object as a hash, which is not a big deal, if the namespace was not mishandled.

Comment on Re^3: SOAP and Perl

Replies are listed 'Best First'.
Re^4: SOAP and Perl by gellyfish (Monsignor) on May 30, 2006 at 18:44 UTC
Well depending on the encoding model you used, it might be more or less useful to be thinking of the exchange as being one of function calls and objects, than to think of them of simply being and exchange of encapsulated XML documents. In its favour SOAP::Lite deals fairly well with `rpc/encoded` SOAP exchanges and you will have few suprises even using that model with WSDL. You will find some problems with `document/literal` type services and more so if you are thinking of the messages as objects. The problem arise partially because there doesn't really exist a consistent and agreed upon way to deserialize an XML document into a Perl object in the way that you can for other languages, partially this is due to Perl's dynamic nature: I can bless any reference into a 'class' without having to (in fact without any standard mechanism to do) predefine the structure of the object. Whereas say with the .Net Framework it is entirely possible and indeed common to reverse engineer a schema and a class into which documents of that schema would deserialize into from an instance of an XML document. This ability underpins the web services support in the framework and you would find similar functionality in the Java tookits. The reflective capabilities and strongly typed nature of modern OO languages like C# or Java make this kind of stuff possible. All is not lost for Perl however, it would be entirely possible to come up with some mechanism whereby an XML can be deserialized into a predefined (or at least predictable) class. For instance the kind of thing that Class::XML does could form the basis of something like this. /J\	[reply] [d/l] [select]
Re^4: SOAP and Perl by perrin (Chancellor) on May 30, 2006 at 16:43 UTC
It sounds like a pretty useful feature. Interoperability between implementations of SOAP does seem to be a general problem. I've seen many complaints about gettting Java and .NET versions to talk to each other. It wouldn't surprise me if SOAP::Lite is simply out-of-date though. A lot of the initial excitement about SOAP seems to have gone away, and community-supported projects like this can suffer when interest drops off. I can't claim to have an informed opinion about this, since I haven't tried to use SOAP::Lite in about three years.	[reply]
Re^5: SOAP and Perl by Anonymous Monk on May 30, 2006 at 18:45 UTC
Very true! Actually nowadays it is much less common to use SOAP for anything other than web service, so better support of WSDL is always a must.	[reply]