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\